Issue #9 - February 2001

Organizational Skills: The Key to a Finished Game

By Gianfranco <pigeon_gb@yahoo.com>

"Hmmm...QBasic is pretty cool! Wow! I can do graphics! Wait a minute! I can make my own video games!"

This is how it starts.

"Attention everyone! I have decided that [insert RPG name here] is too difficult. I will not be programming it anymore."

This is how it ends.

What I just showed you was an all too common occurrence in QBasic game development. At the most, a decent demo might manifest itself out of the work put into a game. Usually, the demo isn't very good at all. An RPG with simply a walkaround demo isn't much of a demo. A platformer with just scenery isn't a demo either.

So what contributes to the trouble of finishing a game? Lack of interest? Maybe. Is the game impossibly over abmitious? Possibly. Too many projects at one time? I have seen that as well.

Sadly the main reason why games don't get finished is because people don't sit down and plan it out. Or if they do, they don't plan it well enough. As a programmer, you know that a lot of things happen behind the scenes. The gamer sees Mario jump. The programmer knows that a button press was detected, Mario's velocity was changed, the screen was refreshed, etc. What does it take to program a great game like "Super Mario Bros."?

Preparation. Before the first line of code was written, the game was already made. The levels were designed, the enemy AI was designed, the overall look and feel of the game was designed. All of it was already there. The game itself can be programmed in three months or less after this. Much less of that time could have been used to produce a working demo.

People should take this same approach to making their own games. I had an RPG, Quest for the World, in the works myself, before I found out about the games already made in QBasic. I thought that I would need to recode everything. Technically I was right, but what I really need to do is sit down and think of EVERYTHING! Everything that can happen in the game has to be documented. I already had a large folder of ideas and such, but none of it was organized. A lot of ideas without any kind of framework just doesn't add up to a game. How could I expect to code anything if I didn't have an idea of what the game needed to do? What if I came up with a working engine, but then decided that I needed the game to have weather effects? How the heck would I do that with something that was pretty much done? I couldn't do that very easily. Thus, parts of my story would have to be altered. Not that it mattered much: the story was pretty much being made as I went along.

Now, if you are finding yourself in a similar situation, STOP CODING!! Sit down, finish the story. Heck, if you can, finish the background information of the world your game is about. Then you can get the main story together and make sense of it. In fact, you start to feel more comfortable with it. Then you can design the layout of the game. Come up with all of the plot twists. Figure it out. It is much easier to write a story and then the game than it is the other way around. Once you understand what you need, you can then start coming up with the ideas for the game itself better.

It is easy to decide the main components of a program: initialization and game. Initialization is where everything that sets up the program is done. It is here that you detect the different settings for video, sound, etc. It is here that most of your variables can be setup. The main menu to the game can be setup here as well. This menu should jump to the different modules in your program. For example, the menu might look like this: play game, options, exit. Play game would start the game module, options would open the options module, and exit would open the exit module, which might be as simple as an END statement or as elaborate as an entire cinema cutscene.

As you can see, the menu module accesses other modules to do different things. Likewise the different things can access different modules to do their jobs, such as the options menu accessing a module to change the keyboard configurations. It is similar to writing a 10 page term paper. If you simply type the paper, it can be difficult. If you make a simple outline first, you have a better idea of what you are doing and so it is easier to finish. If you separate your paper into 3 parts, you can further subdivide it into parts and determine how many paragraphs are needed to finish different secitons. You get a better sense of accomplishment if you can separate your project into parts than if you look at it as one large project.

This is the fun of planning ahead. You get things done. It makes you feel accomplished, and it will allow you to finish your project. You won't feel like what you are doing is useless. I stopped making my RPG because I didn't have a Big Plan to think about. I didn't set goals for myself. Since I didn't really have anything to try to do, I didn't do anything. That is why my project has been sitting on a disk for months. Perhaps it is time to follow my own advice and plan everything out first. Then we will see where we are in three months...