August 01, 2003

Special rules

Special rules are an anti-pattern. If you have a guard character and you want the player to have to snipe the guard in the head in order to prevent a second guard from being alerted, then you shouldn't set it up as a scripted "other characters are alerted UNLESS this, that, or the other". It's far better to set up some rules for determining how the guard characters can see things in the world, and then giving the player the opportunity to take advantage of the placement of the guards. This leads to a world where the parts work in an internally consistent way which leads to better immersion. Also it makes the guards situation a problem solving situation rather than an equivalent of guess the verb[0] or find the button[1].

From a design & programming perspective, it prevents scripts from becoming spaghetti. Special cases become a matter of situation rather than inconsistent behavior.

One thing we've done in the past is to have animations tagged with gamestate altering behavior (e.g. the headshot animation has a tag to kill the character who was shot). This does tend to enforce consistency throughout the game, but I'm not convinced it's the best way to go.

--

[0] Note: I'm not trying to criticize interactive fiction in general. I spent far too many hours playing Zork and Planetfall to be able to do that. Mostly I was too lazy to find a better link.

[1] Final puzzle, it's not a light, it's a button.

Posted by matt at August 1, 2003 11:38 AM
Comments