<< Back to Developer Musings
Engines & Development Thoughts (January 6, 2015)
There are 3 questions you inevitably hear from a technically minded person when they find out you’re working on a game:
- Who did the artwork? (especially if they know my drawing skills).
- How much did it cost?
- Did you use Unity?
Because #1 and #2 can be answered with a single word and a single dollar figure, I’ve chosen to discuss #3 because I think it’ll make a more meatier and interesting blog entry.
If we go back a year ago, when Officer Bumble was in the concept stages, one of the most important decisions that needed to be made was which platforms the game would be made for and which game engine would be used. I knew early on that I wanted to do a simultaneous launch of Officer Bumble onto both Android and iOS platforms (I also originally considered Ouya, but changed my mind when I saw their sales numbers). I knew right away that I should look for a game engine that would allow me to write the game once and then publish to multiple platforms, and I’d heard that Unity was best in class for this particular purpose. After more research, I was disappointed to find that the Unity license was actually a few thousand dollars per OS target, and I’d also read that it didn’t have great support for 2D games, although updates were quickly being made to allow it to better facilitate 2D. I know right now, people are going to tell me there was always the free edition of Unity at the time, however there were usage caps on apps published with free Unity and there was also an annoying splash screen!
I looked at a few more game engines, namely Corona and LibGDX, and then made the best and worst decision that I could possibly have made: I would roll my own “lean” game engine with only the OpenGL functionality that I needed. Since I didn’t have a Mac at this time, nor did I have any knowledge of OpenGL, the first thing I did was buy this excellent book about developing OpenGL ES 2.0 for Android: OpenGL ES2 for Android. I spent a few weeks going through it cover-to-cover, learning all there is to know about OpenGL ES.
After about a month, I had what I though was a workable game engine for Android. However, after adding in some actual gameplay elements, I quickly saw my framerates drop to a dismal 20 - 25fps, with it sporadically going as low as a few frames a second! Clearly my engine was missing a key ingredient: efficiency. After some thought, it was clear that I needed to learn a little bit about OpenGL and Java performance, so I took a step back and purchased some great books on programming for performance with Java and also high performance OpenGL. Performance is going to be the topic of quite a few of my upcoming posts, but for the sake of this story I'll just say that some major engine rewrites were necessary, which set me back a few MONTHS! The biggest challenges were with the garbage collector running mid-game (welcome to object pooling now), writing sprites to the GPU in bulk (instead of one sprite at a time), and moving away from traditional Java structures like ArrayLists and HashMaps in favour of good old fashioned arrays of primitives (I'll write more about why later. Hint: it has to do with iterator objects being created and destroyed every frame).
Anyhow, after about 5 months I had a pretty solid engine that was capable of doing 60FPS and the engine itself was pretty flexible, so that left me with about 3 months to work through having the art assets done by an independent contractor, with me integrating the art as it came through (while at the same time implementing gameplay features). To polish things off at month 9, I added Facebook integration, rolled my own basic leaderboard system and added Google AdMob ads - none of which was very much fun and probably won’t be blogged about.
At month 9, as the artwork continued to roll in, I had to start going on the iOS version. My original plan was to just port over my Android Engine verbatim, but I really didn't want to go through the pain of figuring out the same plumbing on iOS, and I wanted to have the game out in another 3 months - time was tight. Fortunately for me, Apple had just released SWIFT which had a lot of similarities to Java, and I had read that SWIFT also supported the SpriteKit framework which looked to be quite similar to my Android Engine (my engine on steroids basically!). As I usually do, I picked up Apple's SWIFT starter guide as an eBook and spent a few weeks learning the language. I also picked up this excellent book on SpriteKit (Mastering the SpriteKit Framework), while reading this excellent game programming pattern book (Game Programming Patterns) for ideas of how to clean up my sloppy code.
Because of the similarities to Java, I caught onto SWIFT very quickly and, despite a few annoying bugs, I fell in love with SpriteKit (I now consider it as one of the best frameworks related to anything ever written). The SpriteKit framework handled all of the lower-level timing and graphics plumbing that I wanted to avoid, and I was able to have the training mode of the game up and running within a month. From there, it only took another month to port over the rest of the game!
The final month of Officer Bumble, I consider as one of the most brutal months - getting all of the gameplay elements smoothed out to the millisecond (how fast do you run, how fast do weapons come at you, differences between difficulties, ect...). I particularly found matching up the Android and iOS versions very difficult due to the differences in the coordinate systems and the way timing works in each. It also didn't help that my crude level editor was different between versions and I had to match the levels up basically by hand editing the iOS level files. All in all, a very tedious process that using something like Unity would have saved me from.
Looking back, part of me is happy that I rolled my own Android game engine, only because it forced me to learn OpenGl and how to write high performance code. Those lessons made my foray into the iOS version a lot smoother because I knew what pitfalls to avoid and I knew where SpriteKit would run into performance issues if I wasn't careful (ie: using texture atlases instead of raw images, pooling objects, texture context switching, ect...).
However, with all that said, a big part of me wishes I had at least used LibGDX, or would have buckled down and bought Unity. It would have allowed me to focus on developing my vision of the game rather than spend months writing plumbing code.
In the last year, Unity has gone to a monthly subscription model and they've also come out with more tools to support 2D gaming, so I can say with certainty that my next game will be Unity based all the way!
Officer Bumble may never be known as a mobile game changer, but the experience I've gained from this has certainly made me a better programmer and has given me a glimpse into just how much work goes into a seemly simple game. In my regular database-related day job, you won't find anything of mine that runs in more than 16.6ms :)