Game Engines – To build, or not to build: The Eternal Conundrum (Part 4)

Go to Part 3

Design and Development of Condor Wars

It was June 2012. It had been almost 1 year since I traveled to Bogota to work on The Descent for 3 long weeks as I mentioned already in Part 3. During that time we completely forgot about game development for a while and parted ways momentarily. Elias continued work on his baby YouOrderIt, which he was developing exclusively for his restaurant and I continued my graduate studies. In Summer 2012 I started a 12-week internship close to Detroit, Michigan and found myself with a lot of free time on my hands. I was also in a contemplative mood and somewhat depressed during the first couple of weeks of the internship. This was prompted by many factors – the work was not hands-on and I feared losing my technical coding skills. I had this paranoia that if I stopped coding in cold turkey fashion (my new career path demanded a different set of skills – mostly technical but strategic) I would be bound to forget coding and the dread of this idea made me feel worthless. I had been coding for almost 11 years so programming was an essential part of who I was. For this very reason I always kept a side project under my belt at all times in addition to my full-time professional responsibilities.

The situation in Summer 2012 accelerated my desire to get back into coding mainly to feel better about myself:

• I was afraid that after taking a 1 year break my coding skills had decreased (a fallacy since Bill Gates in 1995 claimed he could write “slicker” code than John Carmack during a Windows 95 event even though he hadn’t obviously coded for many years)
• I was living in the middle of nowhere and the setting was depressive, further exacerbating my depressive mood
• I was running out of Breaking Bad episodes to watch, needed something to do ASAP

The situation above made me open Android Studio immediately. I had never played around with Android and OpenGL so I decided to develop a small proof of concept to test ideas and scrape off some of the coding rust I had hypothetically developed over the past year. Also, I didn’t want to deal with the Android Canvas library ever again so OpenGL seemed like the only alternative available. Ten years before during undergrad I had dirtied my hands with OpenGL for 3D programming so I didn’t expect a steep learning curve.

I toyed around with the concept of a spaceship flying through the vacuum of space, moving with the use of thrusters and attempting to avoid planets and asteroids. After a couple of days I had the proof of concept in pretty good shape and had tested out OpenGL graphics rendering, physics, game controls and some game mechanics ideas. It felt like I had gotten back in coding form so I archived the proof of concept and began brainstorming other ideas that had the potential of maturing into an actual game.

After a call with Elias we decided we wanted to release something very small – even smaller than The Descent. The Descent’s development was problematic due to the limitations we faced with the Android Canvas library and because of our lack of focus and direction. We also faced some challenges in our art department which added more obstacles into the mix. After learning from previous mistakes we didn’t want to play around with new ideas but rather with something simple that felt familiar. We also wanted to avoid having to depend on an artist or graphic designer to deliver game assets. We only had a 10-week timeframe and we wanted to control all aspects of development – adding a 3rd party artist/designer in a constrained timeline felt like adding a potential dependency for release. My internship ended by the end of August 2012 and we were targeting to release before I went back to graduate school.

We decided to resurrect a game that Elias had developed in assembly language many years previously called Condor Wars. We already had the game assets – there were only 2 types of sprites: the player’s spaceship and the enemy alien. The latter came in 2 flavors: green and red. The game is reminiscent of Galaga and Galaxian and the mechanics simple – you control a spaceship at the bottom of the screen that can only move left and right. Enemy aliens spawn from the top of the screen and zigzag downwards towards the player. They spawn randomly at certain intervals and the game objective is to dispose of them with the laser. The player can shoot the laser by tapping the screen. The simplicity of this gameplay made the technical requirements trivial:

• Draw a player’s spaceship sprite and the spaceship laser
• Draw a black background with randomly generated stars that move downwards to give the illusion the player is traveling through space
• Draw enemy alien sprites
• Manage an array of enemy objects that spawn randomly from the top of the screen (NPC object management).
• Draw enemy alien explosion animation
• Draw the player’s spaceship explosion animation
• Draw raster fonts that display the player’s score
• Handle collision detection between the player’s laser and enemy bounding boxes and also between the player’s bounding box and enemy bounding boxes (simple rectangle to rectangle collision detection).
• Play sound effects (no music)

The limited technical requirements above didn’t warrant the use of an SDK such as Corona or Cocos2D so using OpenGL seemed like a decent option. There were only 5 types of objects displayed on the screen at any point in time: 1) the player’s spaceship, 2) the player’s laser, 3) the enemy aliens, 4) raster fonts and 5) the black background with stars. Managing the rendering order for these 5 objects was already predefined so a complex Scene Graph implementation was not required. For example we knew the rendering order would be the following:

1. Background and fake star field
2. Player’s spaceship and player’s spaceship explosion effects
3. Enemy aliens and enemy alien explosion effects
4. Player’s spaceship laser
5. Raster fonts

In the draw() method we just made sure to render the game scene in the above order. Some complexities were involved with the loading, managing and rendering of OpenGL Textures for all of these 5 objects. However we developed boilerplate OpenGL texture loading and management code and carried on without deliberating if using an 2D Graphics SDK made better sense.

So after 10 weeks of development we were close to release. My internship ended in late August 2012 and I went back to school. Two weeks later we finished development and released Condor Wars to Google Play. After almost 8 years Condor Wars became Helldorado Team’s first game officially released to an app store. Everything we had done before amounted to technical demos, prototypes and proof of concepts. We downloaded v1.0 of the game from Google Play and the game crashed horribly due to a last minute production release bug. A fix was made and we released v1.1. So we downloaded the patched version and played the game again. But after playing the first couple of levels we realized something: The game was terrible. After 2 or 3 levels we found ourselves bored and you were lucky if you didn’t find yourself yawning beyond level 4. If you had to find 1 word to describe the game it would be sleep-inducing. A friend of ours claimed to have reached level 255 (the last level of the game and a nod to the 8-bit era) but I’m prepared not to believe such tales.

We realized we had found ourselves releasing yet another prototype masquerading as a game – but that had been our intention all along. We had committed to develop and release a technical demo to Google Play in order to experience the Android app release cycle, and we learned valuable lessons from that process. Before development both our mission and goal had been clearly defined and we followed through till the end. In some ways Condor Wars was a pilot test, and the foundational code that was developed for it served as springboard for the development of Condor Wars Redux, where we made some of our biggest mistakes in our game development experience. For Condor Wars we picked the right library (OpenGL) for the technical requirements which had been correctly identified before development, so the mistakes we made with The Descent were not repeated.

When tempted to release something (either a prototype, a demo or some semblance of a game) early due to external or egotistical pressures some conflicted developers advice to consider the words an ancient and wise monarch (who was also an accomplished coder) once said:

“Cherish an unpolished gem in your local machine. Abhor a turd in the App Store.”

– Alexander the Great of Macedon

With Condor Wars we learned that as a developer you are constantly faced with the following predicament: release your technical demo too early thinking that it can pass off as a game, or hold off the release of your pet project until it achieves a certain level of “perfection” or it fulfills your unrealistic ambitions. Most of us are tempted to lean towards the latter, and this is exactly what happened with The Descent (amongst other issues). Despite what Alexander the Great once said, it is better to release a piece of excrement to customers and gain valuable feedback than to let your closely guarded, ambitious project that hasn’t seen the light of day fall into oblivion due to your own high standards.

The disappointing story of Condor Wars Redux, as it was codenamed, will be the subject of our next article.