EGP - Best Supporting Code

When you sit down to design a game, especially when you are working around a simple idea, or striving for a focused gameplay experience, you tend to think along focused lines. I began thinking about Inkblot (in a rough and unfocused sense) back at the end of July when I first read about the Experimental Gameplay Project’s Contest. Over the following weeks, I focused on what I wanted to create, trying to get a clear picture of it. I thought about the Dance Pad – how I could use it in a unique way. I thought about the game mechanics – how the blob should move, and grow. I thought about feedback loops – how I was going to drive the player on, and reward them for playing well.

What I didn’t think about was all the rest of the stuff that has to go into the game before, and around, the gameplay to make it into a whole. In short the supporting code. The Academy of Motion Picture Arts and Sciences gives high regard to actors and actresses in supporting roles for a reason. While they may not be the stars, with all the focus and glamour, the films they are a part of would be pale and flat without them. So to in programming.

I have spent the past two days getting an outline of my game working. I had to work on supporting art resources (not my strong suit). I had to code together the core objects that make the game a program. At the moment it can load resources, change some core options (such as 3D acceleration and Fullscreen mode), and get into a Game Start mode. Fortunately the framework helped a lot, and will continue to do so.

This has been a big lesson to me. I tend strongly towards two activities, Design and Problem Solving. These are the things I love the most. I like to envision new ideas, map them out, and develop them into solid concepts. Most of this happens off-screen, in note books, on scraps of paper, and in my head. I also like to design creative solutions to difficult problems. Whether this is writing the prototype code to do something cool, or finding and crushing the obscure bugs, it tends towards unique and challenging tasks.

I don’t like to write menial code. I hate setting up boring classes, writing dozens of accessors, and generally getting the foundations of the program poured. I would be happy if every task was a new thing to learn, or a new challenge bright and clear. Then, after each solution is revealed, pass off the boring implementation to someone else. Life’s not like that, and good programs (games or otherwise) need a lot of good supporting code behind them.

I should have set more time aside to get my game structure working. So far it’s been 8-9 hours on the code, and about 4-5 on the art. I only got about 4 hours last night, but I made sure that the application ran, and was ready for the gameplay.