|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The Three Goals of the Game Designer
Game designers should:
To illustrate these points, I'll create an fictitious game enemy. Let's make this enemy more relevant to modern game developers than my previous example, Defender, lest someone cry, "Games have changed; the old rules do not apply!" For this example the enemy will be a crocodile, and the setting will be a 3D world – an environment in which the player can run and swim. This is fairly standard stuff, and an area in which designers routinely short-change players by not making things interesting enough. In designing this crocodile, one could just make it a big green lizard with lots of hit points, an appropriate movement speed and a large set of jaws that do damage to the player. To do so would not be horrible – after all, this creature would be somewhat different from the game's other enemies simply because it is capable of chasing the player through water. (See Tomb Raider for examples – its crocodiles, bears, raptors and wolves.) But if this is the extent to which our example crocodile is unique, it is then essentially the same as a bear with a few different stats and the ability to swim. We can do better if we add just a few interesting and unique attributes. So our crocodile will have three more features. First, let's assume our player's in-game character can hold his breath for a specific period. We'll then say that when our crocodile succeeds in biting the character in the water, the player loses some of his precious "breath" (and of course when the player reaches zero, he drowns). Suddenly the player must rethink his strategies related to how long he can swim underwater, what distances he can reach, whether he needs to dispatch or distract enemies on land before entering the water, and so on. If the player did a great deal of swimming in the game before meeting his first crocodile (on previous levels for example, as he encountered water features such as current flows and other aquatic creatures such as small fish), he will now have to adjust the way he plays because the introduction of the crocodile has changed the game. Imparting our crocodile with this one attribute has made the game a dynamic experience. Second, our crocodile, due to its tough leathery skin, is immune to the tranquilizer dart gun in our game that the player uses. With this aspect of the game introduced, the player cannot just shoot his way out of the encounter. Instead, he must react to the situation and make a decision (if only to switch weapons when fighting crocodiles). Finally, let's make our crocodile move fast in the water and on dry land (like a real crocodile), but let's give him a really slow turning rate when on the land. This way, he will only be able to move fast in a straight line when chasing after the player on dry land. If the player zigzags as he runs, he can easily elude the crocodile. So now the crocodile is different from the other enemies in the game in a number of recognizable ways. It is not just faster, tougher and more lethal – it also has some special attributes which will make it more interesting to encounter. The really good game designers have employed this philosophy for years, completely at odds with the "boss monster"style of enemy progression used in many games. This approach to design asks the question, "What does each unit represent on an abstract level?" It makes the game more interesting, because the player must decide and then react. It grants the game interesting dynamics, instead of creating tedious gameplay. Also note that if the player never knows about any of the distinct enemy functions you generate, he will never get any enjoyment from them. Let’s see what kinds of feedback mechanisms we could employ in the crocodile example. First, to give the player feedback about the crocodile's tranquilizer dart immunity, the game could play a different "got hit" sound effect when the dart hits the crocodile; instead of a nice sticking sound (made when the dart "works" on a given creature), the game could make the dart "pa-ting!" and ricochet noise. To inform the player of the crocodile’s interesting land movement features before the player actually encounters any crocodiles, the game designer could drop one or two of these creatures down on the beach, and allow the player to watch the crocodiles chase some small innocuous game creatures from a safe distance. The creatures that run from the crocodiles in straight lines always get eaten; the creatures that run in a zigzag pattern always escape. By affording the player time to study the crocodiles before encountering them, the player could learn something about consistent crocodile behavior as it is within the framework of the game. (Clearly, this sort of solution does not work if the game is nothing but a series of monster-filled rooms. Showing the next obstacle before the player actually has to deal with it can produce a much more interesting gameplay pace; the player has more information on which to base his actions.) The "loss of breath" attack that the crocodile has against the player when fighting in the water is less complicated to communicate: it could be made obvious by subtracting a breath increment each time the crocodile bites, and the game could trigger a player gurgling sound.
|
|
|
Features
