Over the past two months, I was lucky enough to make two games for computer science and software engineering projects. This process was a dream come true -- I could spend hours developing my own games and call it “work.” These projects did come with some restrictions. First, I had only six weeks to complete them. Also, these assignments focused on graphics, interactive systems and object-oriented software development rather than actual game design. As a result, I had to use all the tools and implement all the features the teacher asked me to.

The first project required me to adapt the light-cycle game from Tron into a two-player 3D game that took place on a randomly-generated fractal landscape. The second one involved the creation of a 2D vertically-scrolling space shoot-‘em-up, with some of the units and items possessing certain behaviors and attributes. I could expand on the games however I liked.

Inspiration.

I want to be a game designer one day, so I figured this would be a great opportunity to flesh out my portfolio some more. My mind raced off in all directions as I pondered the possibilities. I knew even before I had started that time would be a problem. I had six weeks to make two games without falling behind in my studies or neglecting my other commitments. I also had to do each one with a programming language I barely knew -- OpenGL for the 3D light-cycle game and Java for the 2D shooter.

My hopes of creating a shooter in the same vein as Epic’s PC-only Tyrian -- a title with a deep, well-told story and the ability to customize your ship -- were never going to be met. I would need six weeks just to do the pre-production work on an ambitious idea like that. I had to scale back my vision to something more realistic, but I couldn’t stop thinking of cool things to put in the two games.

So I made a checklist. I would first focus on meeting the requirements of each project. Then I would work my way down the checklist and add as many features as I could before the deadline arrived. I would have no time for polishing and tweaking. I had to get things right on the first try.

This is what a game looks like. Really.

Four weeks in, I was still coding the engine for the 2D game, and I had just finished the core engine for the 3D game. That meant I had a little under two weeks to add the actual gameplay to the two-player 3D light-cycle title. I also still had to complete the engine, write the data script, and create the graphics, maps, menus, animations, and sounds for the 2D space shooter.

I looked at my checklist with a wistful gleam of sadness in my eyes. My 3D game would not have textures, animations, or music; I only had time to use primitive shapes and decidedly unglamorous lighting effects.  The shooter would end up with only one level -- even the super small and short secret level would be left out. Game development sucks.

This signalled the beginning of a unique crunch period which didn't allow me to walk away from my other commitments. I had to go to dance rehearsals. I had to show up for my compulsory classes. I could rarely work more than a few hours without disruption. The uneven schedule only added to the stress and challenge of a task which already required long spells of concentration and brought frequent demoralizing setbacks.

I had a major issue with the light-cycle game. The camera and the players kept going inside the terrain. I found the problem after several hours of debugging and rewriting code; I slapped my head when I realized how simple the fix was. After that, I discovered another bug that forced a total rewrite of the camera.

You know your game is broken when...

But that wasn’t the end of the frustration. OpenGL requires a very specific order of operations. If you make just one error, you can end up with a bizarrely different visual scene than what you expected. Getting the process right while still learning the features and syntax of the language -- not to mention the mathematical theory at its core -- is nothing short of agonizing. When I added player trails, they appeared anywhere (and on a few occasions, everywhere) except at the tail of each player. Sometimes, things went so badly that the game crashed.

Text rendered on the screen would randomly change color. The engine occasionally did not detect collisions. I began to feel like the game was against me -- like it didn’t want to exist.

Somehow, I managed to get the light-cycle game finished two days before its deadline with almost no bugs and a rock-solid frame rate. I considered trying to add a few cool features to make the game more interesting, but I was well behind schedule with the 2D shooter. I shifted my focus to finishing Shadow Wing, which was due in just under a week.

One down.

At this point, the game was barely functional. I had a complete level map with no enemies, items, or checkpoints to populate it. I had not yet created the code to load this data into the game, the audio was unfinished, and the menu system was merely a rough sketch on paper.

Once again, I looked at my checklist. I had to say goodbye to high scores, the tutorial, and my turret-like enemy. I couldn’t finish my original artwork, either. The development process started to depress me. I had cut corners all over the place, and I still couldn’t even fulfill my scaled-back ambition.

The finished product.

I once heard a successful developer say, "A game is never finished; it's just shipped." I now understand what he meant. The problem with deadlines is that they will always cause you to leave something out or to ship the game before certain features are complete. Deadlines mean compromise. Compromise sucks. Sometimes, games do too.

To check out the version with Chris' edits and Jay's notes, please head over to page two.