Game Engines – To build, or not to build: The Eternal Conundrum (Part 3)
In September 2010 after having maintained a Boxing blog for over 2 years I decided to venture once again into game development. I had taken a hiatus for 2 years after working on a side project of my own and working as a contractor between February 2008 and August 2008. During those months I worked for a small firm developing a game to be used purely for learning/training purposes. It was an experience both challenging and bittersweet but after the end of the contract I decided to venture into other areas and take a break from gaming. I immediately took a technology consulting job working on web technologies and moved on.
I decided to start blogging on the side due to many reasons - I wanted to understand blogging technologies and play around with them a little bit (I hadn’t really done anything web-related until that point), I liked boxing and wanted to write about it and it seemed like a good opportunity to clear my mind for a couple of months. I began posting video highlights of previous legendary fights such as Leonard vs Duran, Hagler vs Hearns, etc. but after several months I decided to put on my pseudo-journalistic hat and started writing boxing articles. I switched from posting simple highlight reels to full fight videos and wrote commentary on the most popular fights at the time. The blog did well for my standards at the time (decent traffic during the weekdays but thousands of page hits the Sundays after a big fight; I also received a meager but very welcome stipend of checks from Google almost every other month since the blog had Google ads all over the place) and was for some unexplained reason very popular in the UK. However by the middle of 2010 the boxing scene (from my perspective) began to deteriorate and my motivation started to waver. I had also received a nasty email from Google saying that I was posting unauthorized copyrighted content in my blog so they immediately shut down my Google AdSense account. No more Google stipends for me! I decided at that moment to never write about boxing ever again.
So enough of the back story. However the situation above prompted me to call Elias and try to persuade him to make another game. Two years is enough time to clear your head and I wanted to face my own fears and try something gaming-related again. Smartphones were starting to flood the market at the time and we both were proficient in Java so we decided to venture into Android game development at once. I had also recently bought a Samsung Galaxy phone so it seemed like a good idea to develop for the Android platform since I already owned an Android-powered device. We began immediately. Also, what better way to enter a new scene than by trying out an existing formula? We tried to recreate the Paper Plane mini game from WarioWare, Inc. for the Game Boy Advance. However instead of flying a paper plane down a series of obstacles the goal was to manuever a construction digger down a series of never-ending rocks across the different layers of Earth’s crust. We titled this project “The Descent”. It was a simple idea however we executed it horribly as you will soon find out.
We spent no time deciding on a technology for the graphics programming implementation. We deliberated between only 2 options: the built-in Android Canvas library or a custom-built OpenGL implementation. And here we made our first mistake. We ruled out using a full-blown 2D Graphics library from the onset because we assumed the game would be so simple it wouldn’t require the full set of capabilities that a 2D Game Development SDK/library (for example Cocos2D, Corona, etc.) offered. A second erroneous assumption was made: we underestimated the technical graphics rendering requirements. We made a blatant assumption on the maximum number of sprites rendered at any point in time on the screen every frame and due to the low technical requirements from our flawed analysis we opted for the inferior and simplistic Canvas library. So down we went that path during the early stages of development.
Our core focus should have been working on gameplay mechanics, game controls (like we found out later this takes a lot of time and play testing by a random sample of beta testers), and the complexities of random obstacle generation. The game didn’t have any levels. Instead there was a mechanism that randomly generated obstacles with specific dimensions and positioned at carefully placed positions depending on the player’s score (the higher the score the more difficult it was to dodge obstacles). By focusing on these elements we could have provided the player with a decent gameplay experience.
But no, instead we quickly paid the price for bad decision-making. We began to realize that the game demanded more graphical technical requirements than previously anticipated. We picked the Canvas library because we thought we only needed the capability to draw a rectangular sprite with specific dimensions at a specific position on the screen (Canvas at the time only provided this capability and without hardware acceleration if I recall correctly). However we needed not only that but also complex collision detection, basic physics, special effects, particles, music and sound effects. We had to write custom implementations for all of these by hand. We spent countless hours writing the collision algorithms to model the collision between the digger and the obstacles. Obstacles were always rectangular so that part of the equation was simple. However the digger had 7 different animation frames and each had different collision shapes (the sprites were in reality rectangular but the actual digger object only filled a subset of this rectangle). Simulating perfect collision in this kind of scenario turned out to be a major headache. However a Game SDK could have easily provided collision algorithms for any kind of scenario (polygon to polygon, per pixel, etc.).
We faced a similar situation with special effects. During the game if the digger hit an obstacle we wanted to model this as an explosion with particle effects but we ended up implementing the crash animation by hand. When the digger crashed we simulated it as an explosion with tiny little pixels scattering outwardly at different velocities. We were not using a 2D Game Engine so there was no Scene Graph - we undertook the pain of Game Object/Entity Management ourselves. We implemented this with a crude array of a fixed length. The game only supported a maximum number of objects active per frame (constrained by the length of the array) and there was no sorting by depth.
For sounds and music we just used the custom Android Media Player implementation which was crude as well and suffered memory leaks (sound and music are tricky and if possible please save yourself a headache and use an external library that excels at this).
So by Spring 2011 we didn’t have a game but rather a mere technical demo full of custom-built technical pieces. Since this was our first real game the quality of these pieces was not the best but it somewhat got the job done. We had forgotten to polish the mechanics and the game controls months before as we had slowly sunk into technical feature development. We sealed our own fate, but we were about to sink ourselves even deeper. In March 2011 I received the news that I would be going back to school in late August 2011 so we had to complete the game by July. I traveled to Bogota in June to meet Elias in person so we could accelerate development by being colocated and tackling development issues face to face. For 3 complete weeks we coded until early morning hours to complete the game but we quickly fell prey to more technical nuisances. We started thinking of Leaderboards and Achievements. It was becoming popular at the time specially for console games but we thought it would be a “good” addition to the complete game experience. This would have been fine had we chosen an Achievements and Leaderboard SDK but not, the temptation to write it ourselves was much too high, and we didn’t know any better. So down we went that path as well - Elias took care of the server side implementation and we immediately got bogged down with the intricacies of making API calls to a Heroku Rails server in order to support High Scores, Leaderboards and Achievements. It took us a full week to fully complete this implementation - a week that could have been better spent by nailing down the remaining gaps in the game controls. Today using Apple Game Center or Google Play Game Services is a no brainer.
Before leaving Bogota I worked on a piece that did actually contribute to the overall gameplay mechanics but it was a late addition. I developed an AI that could play the game by itself - we did this to play test the random generation of obstacles to uncover tough-to-dodge obstacles that would be close to impossible for human players to dodge. This AI could help us tweak the obstacle randomization algorithms. In the end the AI worked well and was able to breeze through the game but we didn’t use the data it offered. We were exhausted. But watching the AI play the game flawlessly served as a congratulatory pat in the back - almost like a standing ovation for getting so close to the finish line. In the final days of my 3 week stint in Bogota there were no more nightly coding sessions. I was just quietly developing this AI in an empty room not knowing if the AI would serve a tangible purpose. But I liked the sound of the idea so I kept going. Elias was busy during the day managing a restaurant.
My memories of those final moments are scattered but we faced roadblocks integrating the sprite bitmaps and faced countless memory issues when loading huge bitmaps in-game using the Canvas library. We even had to write custom code to deal with image compression and circumvent memory exceptions but at this stage any new code written to fix a purely technical artifact served as a band-aid. Nothing could be done this late in the game - we had simply picked the incorrect tool (and focused on wrong areas) for the job and after almost 1 year we clearly started to come to terms with the challenges. It was August 2011 and we were not ready to release. I got on a plane back to the US and we archived the game and froze its concepts. It had been full 11 months of development. Elias and I never spoke about it and we never officially pulled the plug on The Descent. We were just burnt out and after months of arduous technical development we lacked the motivation to continue.
Fortunately the lessons learnt from this experience paved the way for the resurrection of The Descent and its final release in Summer 2015. However, thats a topic for a separate story.