This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
David Edery (CEO), Ryan Williams (director of danger)
Prior dev background (platforms): Web, Steam, Android, iOS
Shipped Android titles: Steambirds, Triple Town
Preferred toolset: Unity
Is fragmentation still a major issue for you? Which devices do you target?
DE: It is not a major worry for us. Fragmentation is a fact of life. We deal with it, and we're a very small company with an extremely small customer-support team. Triple Town was developed by a single engineer for both iOS and Android. If we can handle it, anyone can. Our QA library is mainly comprised of Nexus devices, the more popular Samsung devices, and a couple of Kindle Fires.
Do you have any tips for optimizing the Android dev process?
RW: I've found the biggest boost in development productivity comes from reducing the time between writing code and experiencing the results of the code in-game.
For Unity, which is the engine we've used for mobile development, this means taking advantage of the hot code reloading functionality. It's not well-documented or supported, but if you are playing your game in the Unity Editor and you save a change to the code, Unity will compile the new code and start using it within a few seconds.
It's awesome to use this to work on procedural generation, because you can simply set your generation to repeatedly loop in one screen, and edit your code in the other, and see the changes in action right away. Bugs that take a while to reproduce become much faster to solve: Play the game until you get to the point that the bug appears, and then start hacking on the code.
This doesn't come for free, though; the process by which the editor does the reloading involves a custom serialization of every game object, and not every data type is supported by this serialization. Specifically, dictionaries and generic user-defined classes do not work with hot reloading, and once you go through a hot reload cycle, they become null.
The hot reloading takes place entirely outside of your code and control, and the only way your code can detect that a hot reload has happened is that all the unserializable member variables are suddenly null. If you want to use hot reloading as part of your development process, you have to either refrain from using unserializable types entirely, or find some workaround.
I really wanted to use dictionaries, so I wrote a small class that copies the contents of the dictionary to a pair of lists (which are serializable), and restores the dictionary from the lists when it's found to be null. This adds a fair bit of boilerplate to each dictionary's declaration, so I feel that it could be improved further, but it definitely works. I could share the code for this; it's relatively short.
How have your games sold on Android?
DE: We've done very well on Android. Triple Town has been downloaded over four million times, and Google Play is the top-selling platform for Triple Town. I'm not sure off the top of my head what exactly our conversion rate is there relative to iTunes and Amazon's Appstore, but it is relatively healthy. Amazon has been a bust for us, unfortunately.
Overall, have you found Android dev to be worth the extra work? Are you looking into other mobile platforms?
DE: Yes, it's worth it. We're always considering other platforms, but at present we are not developing for other mobile platforms, no.