On one of the last days of September of 2001 I came up with an idea for a project that would combine the skills I had developed in the visual arts with the exciting world of object-oriented programming, an approach to software design that I was introduced to in a Fall 2000 Java programming class but only came to fully appreciate during the completion of my first assignment for Ryan Moore's Computer Game Design and Production course a year later.

Around that time I gained such faith in the promise of object-oriented programming that I jumped right into the coding process, establishing a mechanism for loading character classes, level backgrounds, contrail effects, and projectiles. A couple weeks later, when I got sprite graphics to appear on the screen and move around, I finally had the confidence to abandon painting and drawing as possible division 3 alternatives that could be pursued in the event that this programming project proved too challenging.

Although my division 3 project bloomed out of a self-indulgent late-night experiment in the loading of externally stored sprite graphics, I came up with a few ways to remind myself that it was the right choice for me academically:

• It encompassed nearly all of the skills that I had learned through my coursework during my first three years.
  
• Instead of languishing on a shelf, my work would entertain a large audience at the end of the year.
  
• The project had the potential to continue to live on in the future in the form of an open source game engine, and would benefit from future more powerful computers.

As my code base spiraled into an ever-increasing number of object definitions and their associated methods and functions, it became necessary to plan out each day's work in my notebook. Each page was filled with ideas for a different feature that I decided was essential for the game. I would usually fill a page with plans while eating at the cafeteria or while lying in bed before falling asleep. The next day would be spent implementing the newly devised algorithms. At any given time I was only focusing on the feature that had been most recently outlined. Nothing further was outlined until the existing plan was successfully implemented. The few times I let my notebook outpace my programming left me feeling overwhelmed. So I rarely formulated plans for any task that I would not be completing within a few hours.

Prioritization and time management are almost impossible when you don't take a step back and look at the whole picture. Nevertheless, I stayed in the trenches and only paid attention to the details. At the time I was too afraid to take a holistic approach to the design of the game engine–the overwhelming number of tasks that remained unfinished would have crushed my spirit. So I only bothered to formulate a vague plan for my project: spend the first half of the year writing the code, the January term composing the music, and the Spring semester devising a storyline and creating the artwork. I figured that if I maintained a regimen of hard work during all of my non-sleeping, non-eating, non-coursework hours, I couldn't go wrong. As it turned out, I completed everything I needed to do to deliver a successful presentation at the end of the year, but not everything that would have been necessary to create a marketable product; the game contains only one level. Within two or three months of my deadline, I realized that I would either have to limit the number of levels, or impose restrictions on the number of hours that I would allow myself to devote to the creation of each screen full of background artwork. I decided that for the sake of a successful presentation, I would be better off having one very good-looking level than several very bad looking levels–or rather several familiar-looking levels with repetitive scenery, something that would have negated the game's biggest innovation: non-tiled, non-repeating, scrolling backgrounds.

Aside from ending up with one level instead of the six that I had envisioned, I managed to meet my other goals: I made two non-player character types, one player character, plus one large boss character. The first character, a female with a gas mask, came out of a sketch I drew during my Christmas break. It was the first character sketch that I was at all happy with, so I began developing it into a game character even before I realized what the plot of the game would be. For a long time I thought that this female would be the game's main character, but as the storyline developed I realized I would need a hero native to Greenland, the eventual setting for the game. (Early on, I had a vague idea that the game would be a science fiction adventure on the planet Mercury, and that the gameplay would take place in caverns under the thin rim of hospitable territory that borders the bitterly cold half of the planet that always faces away from the Sun. Eventually I dropped the science fiction theme but never lost my interest in the cold theme. So now you're an Eskimo fighting to liberate Greenland from an invading army of Canadian imperialists known as the Canadian Expansion Force.) Before creating the main character though, I made a more generic looking enemy thug character that would probably feel at home in any action game under the sun. During the last week of the project I finally got around to making the main character, the Eskimo. I only spent three or four days on the Eskimo character, and as a result it ended up looking simpler and more cartoon-like than the other characters, with thicker line work and a more limited color palette.

Although my time spent composing music was limited to about two or three weeks during the January term, it was actually one of the most wasteful periods of the game development process; my one level allowed for the inclusion of only one audio track. Therefore I had to throw out five of the six completed songs that emerged during that January composing session. (The game's intro theme song and boss music were created in January with the help of my friend Ernest; I threw together the victory celebration music that can be heard at the end of the game on the day before my presentation.)

As the year drew to a close the realization that I would be presenting my work to hundreds of people set in. I did not want to disappoint my audience, and that meant providing them with 20 minutes of accessible, straightforward entertainment. There would be no time for subtlety or thought provocation. I stopped paying attention to the atmospheric exploration-oriented games that had previously inspired me such as Metroid and Out of This World, and shifted my attention to arcade games and action-packed shoot-em-ups like Metal Slug and its two sequels. Likewise, my final presentation was structured to include nothing more technical than a ten second description of what each button on the controller did. There was no discussion of the development process nor was there a rundown of the finished product's system requirements. Instead I focused the audience's attention on the challenges faced by the four volunteers who came forward from the crowd to compete against each other.

A months-long, gradual simplification of the game's overall visual style involved several revisions of the interface (the final one featuring a blocky looking title logo and a font style lifted strait from an 8-bit Nintendo game), a renaming of the game from Polarity to Greenland Invasion, and a rewrite of the storyline that removed every scrap of science fiction, making game less alienating to the general public if not more plausible. This simplified plot line is swiftly revealed to the player via on-screen text during the first few seconds of the game's operation. I eschewed PC game conventions wherever possible in favor of the more juvenile presentation of the 10-year-old console games that my audience likely has fond memories of. On a related note, I didn't come up with a list of people to thank or provide a question and answer session. Leaving these formalities out might have helped to maintain the audience's level of energy and interest, which went towards meeting the same goals that the game content itself was designed to achieve.

Although I worked hard on my division 3 throughout the year, it couldn't have come together without a stroke after stroke of good luck. So much of what went right with this project was out of my hands entirely:

• My computer broke down at the beginning of the year, so I had to buy a new one. Only the new one was powerful enough to handle this project. So I'm actually happy that my old one broke.
  
• A chance encounter with Dillon Markey and Tom Hudson resulted in my joining a band of talented Div 3 students. Packaged as a group, we were we able to attract a large enough audience to fill the main auditorium. Presenting my game in the art gallery would have been a less exciting proposition, because not as many people would have showed up and the presentation would have lacked the immediacy and impact of an auditorium event, with the huge projected screen image and the loud, powerful audio system.
  
• Days before my presentation, an extremely important software driver was released for Mac OS X. Without it, my video game controller would not have worked with my computer, and the user would have had to play the game using the keyboard.
  
• Also only a few days prior to my presentation, a very useful plug-in for my programming language REALbasic was released. It allowed for automatic screen resolution switching and gamma fading, and went a long way towards eliminating the amateurish look of my project.
  
• Two of my friends did not return to Hampshire this year. Without them around, I had nothing better to do than work on my division 3!
  
• As it happened, I had enough time to create what appears to be a finished product. Just the same, I had no time to spare. My video game was probably as ambitious as possible without being too time consuming or stressful to produce.
  
• The four volunteers that stepped forward to play my game during my final presentation seemed to know what they were doing. Each player scored more points than the one that came before him, which kept the audience's level of interest up throughout the show.
  
• Murphy's Law, which states that anything that could possibly go wrong will indeed go wrong, was not in full effect. If someone had stepped on the power strip that was on the floor, or tripped over a cord, or pressed the quit button instead of the begin button, serious problems would have occurred. The success I had with the production and presentation of my division 3 was as much the result of good luck as it was the product of hard work and diligence.

Now that I have finished my work and given my presentation, I want to make my game engine freely available while charging a small fee for CDs containing the game Greenland Invasion. It will be promoted as an example scenario for budding game designers who have already downloaded the free engine but need a content base to build off of. The example game will be helpful in teaching developers the file and directory structure that must be established in order for the game’s content to function properly. The proper directory structure could potentially be gleaned by studying the source code, but it would be very difficult to build a scenario without a base of modifiable content to start from.

A secret code hidden in the game copies all of the engine’s source code onto the user’s desktop. Players lucky enough to discover this Easter egg will be instructed to adhere to the LGPL software license, which allows for the selling of products made with the source code, as long as the base code remains free and open to the public.