We sat down with our Technical Lead for Mobile, Sergi Velez, and asked him some straight questions about how he and his team created the iOS version of Dragon City. In this no-holds barred interview, Sergi talk through the process step by step, flags the pitfalls and the solutions he and our mobile developers encountered. And he shares some of the key learnings from the experience. The process is also summarized in this straight-forward Slideshare.
Please feel free to download and share it.
Sergi, Dragon City was launched for iOS in October 2012 and Android in Fall 2013. How successful has the game been?
From a technical point of view, delivering a game as complex as DC simultaneously and with complete syncronicity across 3 platforms has been a big success for us – and a major learning experience.
Did you have a clear game plan when you started out making Dragon City for iOS?
When we created Dragon City iOS we weren’t planning for a future Android launch, or even thinking about it. – This meant some of our decisions about architecture were a bit short-sighted. And we ended up having to re-write code more than we would have liked. Nonetheless, we learnt a lot from the process – so our next games have been built with a much more solid base, and 100% cross-platform.
Decisions about the game’s architecture – can you tell us a bit more about that?
Well, the game’s motor is based on cocos 2d- x, a 2d opensource engine. We’ve built our own engine, Hydra, on top of cocos 2d-x – giving it new characteristics which are common to all our games: support for asyncronous tasks, communication with Backend, integration with Facebook and GameCenter.
Sergi Vélez, Technical Lead for Mobile at Social Point.
What do you mean by communication with Backend?
So, every action in the game generates what we call a “command”. This command contains information about the action that the user has taken and the consequences it has in the game: when they breed dragons, for instance, or have a battle. These commands are periodically sent to Backend, to the ensure the session remains synchronized.
How does this help if the players loses Internet connection?
Well, this communication process means that we can keep a list of commands in the player’s device – so even if they lose connectitivity, we can send them back to the player when they re-connect. It makes offline gameplay possible.
So offline gameplay is possible – without any problems or issues?
Yes and no. If a player is playing a session on two active devices at the same – unlikely but totally possible – it’s always possible for them to lose data from one game, because it can’t be synchronized. Our work-around solution is to send them an alert inside the game, telling the player that they aren’t connected to the Internet – and explaining that they have to re-connect if they wanted to synchronize their session.
In the Slideshare you say you used two apps – Jenkins and Testflight – to create Dragon City iOS. Can you tell us about them and how you used them?
Jenkins is a Continuous Integration tool. Basically its a tool that creates a new version of the app from the newest source code version every day, automatically. Testflight is a web app that makes it really easy to distribute apps for testing purposes.
Together, they allow us to distribute a daily up-to-date version of the app, so everyone involved can take a look at it. QA can start testing features, product owners & project managers can check what ongoing features are doing and so on.
You mention the Crash Reporter. How important is that?
It’s pretty important! Sometimes it’s hard for us to track down, or even notice when a new bug appears. Sometimes a bug appears with a very specific configuration, or in a certain environment. This tool helps us to get a better picture of what was happening when the app crashed, so the developers can try to reproduce it locally — and fix it.
Sounds sensible. What did you do with your soft launch data?
The updates were quite critical for us: in addition to checking that the new features worked as expected, we needed to check that we hadn’t broken any of the old things.
We can’t do staggered rollouts for updates (at least on iOS), so we really need to make sure everything is ok. If we introduce changes that we know will break older versions of the game, we have a mechanism in place that forces the user to update to the latest version when he or she tries to enter the game.
You and your team are veterans in launching mobile games now, right? What is the one best piece of advice you’d give anyone trying to make a mobile version of their video game?
In the end, launching a game is a learning process. We’ve all learned a lot from Dragon City for mobile, and will continue learning from the next launches we do.
Just make sure to have the right tools to monitor all the things relevant to you, and to react fast when something breaks – because it will!
It’s all about team work. Our multi-talented Dragon City Mobile team scoop awards at Gamelab earlier this year.
In December 2013 we launched Monster Legends, one of Facebook’s top games for 2013, for iOS. Why not take a look at this interview on LAUNCHING MONSTER LEGENDS FOR MOBILE with our Head of Mobile, Alex Besenval, which covers what we did, what we learnt and a little bit more cross-platform secret sauce.