Part 2 [20/02/2001]

eric yiskis 2 ·Odd Squad
Eric Yiskis, Lead Programmer
Our Crystal Balls Are Fuzzy

Last time I talked about how the process of making the game fun was not a straightforward process. We (the programmers) would like it to be. What we would like is at the beginning, to have a list of all the characters, all the features, and what they are all supposed to do. We would assume that “the list” would never change, and that it would contain the right number of features so that we could work eight hours a day for a year and a half, and on the last day the last feature would be complete. Oh, and by the way, we would also like it neatly organized and categorized by the similarity of features.

What do you think the odds are of this scenario coming true? Right, Zero! What happens is that the design group goes off for a month or two and goes into maximum creativity mode. They come back with a zillion interesting, but not very well thought out ideasÑenough ideas for at least seven games. The ideas go something like, “These Mudokons will have armies of flying machines, and you will be able to control one of them, or all of them either by GameSpeakª or through a first-person view, and then you fire bombs, and you can control the bomb and the army of Sligs will be creating a giant energy field but then you punch through and go into a facility where you infiltrate and then it’s like a real-time strategy game where you collect resources, and the environment is changing dynamically and … uh you build a spooce reactor and it blows up the whole planet … oh wait.” At which point the all the blood has drained out of the faces of the programmers, and the lead programmer speaks up … “uh, guys, you have to boil this down into something we can actually do.”

In the early stages, the designers will hammer out what the story and gameplay is mostly about, but those ideas are going to evolve over time. The problem is that nobody really knows how a feature is going to play, or if it will be fun. Each of the designers is looking into his or her crystal ball to try to see the future, trying to see if a feature will be fun or lame. That’s hard to do. It is especially hard when it’s a feature that isn’t in any other game, and nobody has seen it before. Also, they don’t know how the game engine looks or plays because the programmers have just started working on it. It will be months before they can even run characters around on a landscape.

When the engine is up and running, the programmers will put in a feature, and as soon as you look at it, you know that it needs changes. Are “changes” anywhere on the schedule? No, not really. How many changes will it need? Who knows, you have to work on it until it’s awesome, or you give it up for dead. There are some features we never can seem to get to work right and we have to yank them out. That’s okay, though. THIS PROCESS IS WHAT MAKES IT FUN!

Whoa, wait a minute. Changing or ripping out features is what makes it fun? Yep. Remember I was talking about having a “list of features” at the beginning of the project and carrying out the list. If we did it that way, we would have all the lame features mixed in with the cool features. Instead, by constantly adjusting the game, we inject good ideas along the way. Seems obvious doesn’t it? Well there is a dark side to this method. If you change it too much, the game will never get done because all the code you have written up to that point becomes obsolete. That is the crux of the problem, and it is a constant negotiation between programming and the other groups. – Erk