Orphaned Computers & Game Systems

(Archive)
Vol. II, Issue 5    August 1998


Making Worlds:

The Artistic Science of Game Design

by Chris Federico and Adam Trionfo

Some of you may recall the griping in an article that I wrote for Video Magic about not being able to locate a copy of Garry Kitchen's GameMaker for the Commodore 64. I'd had that Activision tool on disk since it had come out in 1985, and I finally learned how to take full advantage of its coding freedom by the early 90s. In 1995, however, my disk stopped loading, which broke my heart. Well, I'm happy to say that I recently acquired it again. Adam had it! He'd thought that his disk didn't work. I took it home and tried loading it anyway, and up popped the title screen!

Needless to say, I immediately made several backup copies using some protection-defying utilities that I'd incidentally obtained after the death of my first GameMaker. I have no ethical qualms about this; Adam's disk is an Activision original, I initially owned an original, and I intend to use the backups as personal safety copies only. I'm so glad to have this application again. I've already completed a new contest to add to my line of "Classic-Style Games." It's called Tyrant.

Now, just in case some of you are thinking, "He thinks he's programming? He's only using a game-construction kit!" I should briefly explain what GameMaker is. It's a quartet of applications: a sprite editor that allows for multiple frames and multicolor mode, a full-screen drawing program that allows for the creation of background scenery, a versatile sound editor that takes full advantage of the C-64's SID (Sound Interface Device) chip, and a song-building application (the one I use the least; some of you know what my opinion is on music in video games).

The heart of GameMaker is the editor, a blank slate on which you code. You load in the sprite files, etc. that you've made, and then you draw from the pull-down list of dozens of commands to manipulate those separately created elements however you wish -- animation speeds, reactions to joystick movement, events upon collision, etc. You fill-in the variables, values, and so on.

If only it were that simple. But these are actual instructions you're piecing together; to get anywhere at all with GameMaker, you have to know how to program. It's not for people who've never studied a language. It's like extended BASIC, with some of the POKEs turned into easier commands like SPRITE 1 X POSITION = 91. Picture a mega-BASIC that runs as fast as machine language, and which leaves absolutely everything up to the programmer -- as if he were utilizing an actual language. You have to calculate everything very minutely, anticipating every possible event and orchestrating every split-second. I would never have been able to tackle GameMaker if I hadn't already been writing BASIC programs for a few years, feeling out the nuances of coding and learning memory-saving tricks like implementing flag variables and whatnot.


Anyway, on with the actual article. There are three phases to designing a game, and although the first phase is the most fun, that and the second are both fun in separate ways. The third can be the nightmare. It's all about your attitude.

The first part of coming up with a game is the part that even non-programmers can do. In fact, it's the part I completed over and over as a kid, inventing video games merely by drawing the screens and devising the plots. Phase one consists of writing out the rules, drawing a picture of the tentative screen layout, making notes about the object of the game (even if it's just "Shoot the bad guys and avoid getting shot yourself"), and then going a little further and deciding exactly how many characters and items will be in the game, what their functions are, what sort of control the player has over his character and so forth. Finally, this pre-coding phase usually necessitates the designation of variables, so that you have a written reference to glance at while you're scrutinizing your code for debugging or change-making.

There are a few things to take into consideration while you're turning an abstract idea into a fixed set of rules, especially if you're planning on passing the game out to your friends or making it somehow available on the 'Net. First of all, what sort of game do you like to play? What would you have liked to see on a C-64 software shelf when that computer was in vogue (or whatever platform you're writing for)? In other words, what game seems like it would be a lot of fun to play, but was never available?

There's usually one major twist to each exciting idea, even if the setting and mechanics fit into one or more of the popular classic categories. Food Fight's twist is that you have to hunt for and pick up every bit of your ammo. Dig-Dug and Boulder Dash's aspect of intrigue is that you create your own maze as you play, dictating the bad guys' routes as well. In Frostbite, you can give up an igloo piece in order to reverse the direction of an ice floe, and a bear shows up if you've beat enough waves, necessitating changes in some of your tactics. (In fact, the Activision programmers used a frequent term for the twist that they felt was essential to any game's ability to remain interesting: the "shark." This came from David Crane's Fishing Derby menace.)

Another thing to think about is the primal human element. There shouldn't only be villainous bombardment. There has to be some way of getting revenge, of being the hunter as well as the hunted. Can you imagine how much less popular Pac-Man would have been if you couldn't make the monsters temporarily turn blue?

There also has to be a measure of relief at intervals. You can't just hammer the player to death. Consider the "easier" (ahem) waves sandwiched between the tough ones in Robotron: 2084, or the fact that you get a new world full of Humanoids every fifth wave in Defender. There has to be something to reach for, a light at the end of every few sections of tunnel. We do, after all, want the player to be motivated to play the game more than once (even if it's just going to be us!).

Now it's time for the programmer in your mind to take over for the imaginer. But coding requires creativity of a sort; it's like fitting together pieces of a complex and yet nearly improvisational puzzle. Everything has to be thought of: What happens if the player's character runs into a wall? How does the program check a bullet's screen position so that it can determine when the player is allowed to fire again? How is the illusion of screen-exiting orchestrated? How are two joystick directions combined to let the program know that the player intends to move his character diagonally?

After all of the routines are finally working properly, not to mention (here's the trick) working congruously with each other, then it's time to do the initial play-testing, during which you'll discover things that you didn't think of before. Uh-oh! What should happen when the score accumulates beyond its number of displayed digits? Why does the gun's firing sound not ring out until a couple of seconds have passed after the bullet graphic left the gun? Why are all of the bad guys still in their "dying explosion" animation frames when the game ends and a new one is started without exiting the actual program?

Debugging isn't much fun, but once you figure out what's wrong and solve each problem, the result is very rewarding (okay, I admit it: You feel absolutely brilliant. And hey, I need all of that that I can get).

Once everything finally works, you start to think about extras -- additional spectacle. This doesn't sound very important, but little audio/visual details can make a game feel more exciting and satisfying. Can you imagine Tempest without the brilliant color flashes juxtaposed with the cold, grating sound effects? So maybe little, easy-to-program things could enhance our hypothetical game here. Something as simple as the walls flashing briefly every time the player shoots a bad guy can really enhance the overall atmosphere. Perhaps certain animated objects would benefit from a couple extra frames of animation. After all, if something doesn't look neat or mean to begin with, there's not much of a visceral reason to blow it up, now, is there?

Finally, after you're positive that there aren't any bugs and that all of the elements that you want are in place and interact correctly with each other, embarking on the third and final phase is unfortunately inevitable. This is the fine-tuning stage. It sometimes takes as long as the coding itself. Now that you've created a world, you're very, very picky about it. Either this alien or that key looks terrible being that color against this certain part of the background; or the bullets go just a touch too slow, making the game too easy; or the main character looks awkward when he walks diagonally; or the bad guys don't home-in on the protagonist quickly enough to be obtrusive opponents (or, worse yet, they bump into each other more than they do anything else).

Readjusting details like this, making sure the rest of the code will get along with this new information, re-saving the game (ALWAYS a good idea before execution, no matter what language you're using), and then repeating the process until everything looks and feels exactly as you want it to, can take forever. But once it's done -- what a feeling! You walk around with a sort of high. Because you've CREATED. You've succeeded at something that you've been working on for days or weeks, and now you're free of it, and something you've produced by yourself is now in the world.

Like anything, programming takes practice. But it's like riding a bike; you don't forget how to do it, because it's more of a knack than an encyclopedic knowledge. Anyone can learn to do it with motivation. Speaking personally, it's much easier than Geometry or Chemistry.

It's really a science of its own, since it's greatly artistic. You become rather intimate with your code, crawling out of bed and into each new day with enthusiasm for getting on with the programming. You'll get overwhelmingly frustrated with a bug that you can't locate or a mechanic that you can't quite smooth out, vowing to give up -- and then the solution will come to you while you're trying to fall asleep, taking a shower, etc.

There are, inarguably, no rules for the creative side of it. Infinite new things are out there, merely waiting to be invented. -- CF