The Self-Modifying Game

Back in the good old days, we programming cowboys had a trick that's seldom used these days: self-modifying code. One segment of code re-wrote another segment of code. This was frowned upon because it made debugging particularly difficult. How could you tell where the problem was arising if you couldn't know which version of the code was actually executing?

Nevertheless, there were some situations in which self-modifying code was useful. One of these was anti-piracy. If self-modifying code was difficult for the programmer to debug, imagine how tough it would be on a pirate! I used that trick twice, and I still smile at the thought of some poor teenage geek running through code, trying to figure it out, and then encountering a piece of code that has changed behind his back. Knowing the way these hackers think, it was certain to send avalanches of "that does not compute!" waves rippling through his brain.

There were also a few cases where self-modifying code could save a few bytes or a few cycles of code, but they were seldom worth the effort. Besides, you couldn't use self-modifying code with a ROM cartridge. All in all, it just wasn't a good idea.

But self-modifying code has always held a fascination for many programmers, and it seems to me that this fascination could carry over nicely to game design. What would it be like to play a game in which the rules changed while you played?

The idea is not original to me; it's been done a number of times. Mathematicians and game theorists have toyed with the idea for years; Douglas Hofstedter discussed such games in Metamagical Themas. While most self-modifying games are really exercises in mathematical cleverness, Cosmic Encounter is genuinely fun. Two of my other milestone games, Illuminati and Magic the Gathering, have mild self-modifying elements in them.

If we wish to be liberal with our definition of self-modification, we could say that Pac-Man has a self-modifying element. When the player eats a power pill, the tables are turned on the ghosts, for now the player can dispatch them by chasing them down. For a short period of time, the roles reverse. This is a kind of rules change.

The problem with self-modifying games is keeping a lid on them. How does one permit rules changes while ensuring that nobody can get a lock on victory with some simple trick? Previous games have accomplished this by restricting rules changes to particular cards that must be played to alter the rules. The players are not allowed to make up any old rule change; they must confine themselves to the set of rules changes that are pre-defined for them. This tends to keep the rules changes rather modest. But I think that the computer offers us a great opportunity to design much richer self-modifying games.

We must be clear to differentiate self-modifying games from variable scenario games. Such games permit the player to make rules modifications at the beginning of the game; most of the times such modifications exist for handicapping purposes or to explore variations on the game. The differentiating factor is the ability to change the structure of the game in the middle of gameplay and the fact that these changes are meant to be an intrinsic part of the gameplay.

The simplest form of self-modifying game does nothing more than change parameters critical to the game. Some variable scenario games permit a certain amount of this during gameplay, but this is primarily for real-time adjustment of play balance. If the player is getting clobbered, he can request a really big gun. Indeed, some games do this automatically; if the game detects that the player is doing poorly, it adjusts one or more game parameters to make things easier for the player. This is not what I mean by a self-modifying game.

What I mean by a self-modifying game is one in which the rules change during play of the game. Of course, we all know that data and process are interchangeable, and since rules are really just processes, rules can also be treated as data, and therefore my claim that parameter-changing games don't count as rules-changing games is not strictly correct. Nevertheless, to convert changeable rules into changeable data requires a degree of abstraction that most people find noisome.

Of course, such abstraction need not be foisted on the players; the program might well change parameter #27 from a 6 to a 7, but the player might experience this change by discovering that his shotgun is now shooting marshmallows.

The trick, of course, is that the changes to the game must be related to the behavior of the player. A simple way to accomplish this would be to set up a series of parallel universes, giving the player the ability to jump between universes that retain the same map, but in which the rules of play are different. Suppose, for example, that we have a standard first-person shooter. The player is stalking through the blue universe when suddenly he is confronted by a hook-nosed warblestomper! Egad! Those things are impervious to all gunfire! Thinking fast, the player hits his Universe Jump button, and finds himself facing the same hook-nosed warblestomper in the orange universe. Here, gunfire is just as useless against warblestompers, but gravity is ten times stronger, and the warblestomper's great mass renders him immobile. With great effort, the player climbs the stairs to a point overlooking the warblestomper and then drops a coin onto the monster, which slices through him like a bullet. But look! Now there's a Muscle-skito flying towards him! Time to change universes!

In general, this kind of environmental change is the easiest way to implement self-modifying games. It makes much more sense than a game in which rules appear to change arbitrarily. The other way to pull it off is the method used in Magic the Gathering: use magic. However, magic seems to me a ploy used by insufficiently imaginative designers. It's rather like the cartoon of the scientist working on a huge mathematical derivation who has obviously hit an impossible obstruction. There's a gap in the equations, with an arrow pointing to the phrase "And then a miracle happens!" followed by the remaining formula. Miracles are a cheap way out, and after a while the arbitrariness of magic confuses the player. It's better to have a complete, consistent system that the player can grasp as a whole.



Chris Crawford on Game Design
Chris Crawford on Game Design
ISBN: 0131460994
EAN: 2147483647
Year: 2006
Pages: 248

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net