This is one of the big hit games of the last twelve months. Following on the heels of Wolfenstein 3D, Doom has achieved cult status and fabulous sales. The fact that it is sold directly by ID Software rather than through a publisher means that they are making a killing on the product. At $40 per sale, if they sell 100,000 units, they’ll gross $4 million with very little sales and marketing costs. Most of that money will go to the developers. But I don’t want to talk about their business model in this review, because this is a design review.
The game has also garnered rave reviews in the press. Everybody gushes with praise for the 3D engine: the curved walls, the up and down motion as you walk, the fine touches such as your gunfire lighting up the scene. There’s no question that the 3D engine in Doom is magnificent. But I don’t want to talk about the 3D engine, because that’s a technical issue and this is a design review.
What I do want to say is that Doom is a very well-designed game. It is a pedestrian design there’s nothing brilliant or innovative, no cutting-edge design concepts that designers should sit up and notice. In design terms, Doom offers nothing that we didn’t have in 1981. It is a collection of old and well-established ideas with really snazzy graphics. But the ideas are assembled with great skill. The designers of Doom implemented the basic precepts of good game design with impressive thoroughness. As such, the game provides an excellent model for beginning game designers. In this design review, I will walk you through those basic precepts of game design and show how Doom implements them.
Transparent response
First: a game should provide a clear and direct response to the player’s actions. When the player does something, the consequences of his action should be made obvious. At the simplest level, the 3D engine provides very transparent response: push the mouse forward and the scene changes in a manner that instantly suggests that you have moved forward. The intuitive nature of this feedback creates confidence in the player that his actions will have understandable consequences. This confidence is buttressed by other behaviors, such as bumping into walls. The player builds a mental image of his world that closely conforms to the visual image he sees on the screen. This is the real value of the 3D engine: it encourages a close association between the player’s mental model of the game world and the visual imagery he sees.
The sounds of the game provide another form of feedback. There are clearly defined sounds that signal danger, identify the monsters lurking nearby, or reveal that a monster has died. The loudness of the sound indicates the nearness of the monster. The plop of a body hitting the ground is often the only indication that an invisible monster is no longer a threat. The player grunts in pain when he is hit. Passing over and therefore picking up an object triggers an acknowledging beep.
The designers did make some minor mistakes in their use of sound. While some sounds are unquestionably informative, other sounds have only cosmetic value. Some of these cosmetic sounds, such as the various gunfire and explosion sounds, are clearly necessary. On the other hand, there are other sounds, more environmental in style, whose value escapes me. For example, when near a pool of water, one can hear little frogs chirping. This atmospheric sound strikes me as a bit of a waste; I have yet to figure out anything of utility from it. Another example: when you stop moving, you can hear yourself breathing heavily. Thinking this to be feedback of some form, I waited patiently to "catch my breath" or "heal" or whatever the game was trying to tell me, but apparently the heavy breathing communicates nothing. This was a minor design error.
One might object: "C’mon Chris, does everything have to be utilitarian? These sounds are just for fun!" The problem is, most of the sounds in the game are utilitarian. The player quickly learns that survival depends on paying close attention to the signals provided by the sounds. To mix a small number of nonutilitarian sounds into a base of primarily utilitarian sounds only serves to confuse the player. If all of the sounds were strictly cosmetic, there would be no problem with having additional cosmetic sounds. Mixing cosmetic and utilitarian sounds is tricky business and should be done carefully. For example, if the cosmetic sounds were all digitized environmental sounds, but the utilitarian sounds were, say, a mixture of computery beeps and a digitized robotlike voice announcing results, then the problem would go away.
Another example of transparent response is the use of icons to indicate certain standard functions. The medical kits that heal injury provide a good example. They are clearly marked with a red cross symbol. Big kits yield 25% healing; little kits yield 10% healing. There are a variety of other goodies lying about, but there’s an important rule: if you see something lying on the ground, it can be picked up and used for some purpose. There’s no random junk thrown in just for good looks. Everything has a use.
The designers also used text to communicate useful information. Whenever you pick up something, a short message appears in the text bar at the top of the screen explaining what you’ve picked up. This is an important element: it tells beginners what is going on. It is a common mistake for game designers to get so close to their own designs that they assume that the player will instantly grasp their assumptions. For example, the armor bonus uses a skull as its icon. The skull does nothing to suggest that this is an armor bonus; the only thing that tells you what you’ve picked up is the text message. There are also some special-case items whose function is only explained by the text messages.
To summarize: Doom gives clear, unambiguous, quick feedback to the player. That is one of the fundamental requirements of good interactive design.
Completeness and consistency
Another fundamental rule of good game design is that the game should create a universe that is complete and consistent. The player creates a mental model of the world inside the game, and it is vitally important the he develop confidence in the completeness and consistency of his mental model. There are actually two flavors of consistency: consistency with the real world, and internal consistency.
Suppose, for example, that in a fit of cleverness, the designers had created a "mirror image room" in which your movements were reversed. If you use the mouse to turn right, you actually turn to the left; if you use the mouse to go forward, you actually move backward. Ha, ha, ha, the designers say. Aren’t we clever?
This would be a design disaster, because it is doubly inconsistent. It is grossly inconsistent with the real world, and it is internally inconsistent. The real world never, ever generates such behavior. Moreover, such behavior is inconsistent with previous experience, and it robs the player of confidence in what he has learned. It makes him frightened and tentative, unwilling to trust the lessons he has learned.
An interesting problem comes from the nature of falls in the game. The game model appears to be that you can fall any distance without injury. This is clearly inconsistent with real-world experience. In early playings of the game, I balked at jumping from heights that I intuitively knew would result in injury. But it does appear to be internally consistent.
A more serious inconsistency arises from the functioning of the rocket launcher. On one occasion I was trading shotgun blasts with some distant chaps. I was standing near a corner wall, blasting away with little effect. None of my shotgun blasts were hitting the wall just in front of me. Growing impatient, I whipped out my rocket launcher and squeezed off a round. It struck the wall adjacent to me, and the explosion killed me.
This inconsistency between the behavior of the shotgun and that of the rocket launcher constitutes a design error. Since I as player lack the necessary tactile and visual feedback to see exactly where the launched rocket will go, the design must provide reliable indicators to compensate. The best indicator would be the shotgun behavior, but in this case it was misleading. This is one of the few cases of a clearcut mistake on the part of the designers.
Consistency is enormously important. It encourages a sense of well-being, and suggests that the player can rely on common sense. If the game-world acts the same way that the real world acts, then the player is encouraged to apply his knowledge of the real world in hunches. He will attempt experiments. In other words, he will play. That is the point of a good game, isn’t it?
Ramp
Another rule of good game design requires a smooth learning curve for the game. Every game needs to coddle beginners while challenging experienced players. These apparently conflicting demands are resolved by designing a smooth learning curve of challenge. The early parts of the game are simpler and easier to master, and the more difficult challenges do not come until later. Moreover, the more difficult challenges should in some way build on behaviors that the player learned earlier. There should never be dramatically new behaviors required of the player.
Such good design practice is exemplified in Doom by the handling of secret doors. In the first level of the game, there is a secret door, but it is markedly different in color than the nearby wall panels. It stands out and invites curious examination. In the second level is another secret door but it does not stand out quite so prominently. Other secret doors in later levels are more difficult to notice. However, I believe that the designers carried the process too far. There are secret doors in some levels that are utterly indistinguishable from nearby wall panels. The only way that the player can find them is through tedious testing of every single wall in the level. This is not good design.
Another such example also comes from the first level. If the player discovers the first secret door, he will eventually come to a plaza with a desirable object sitting in the midst of a pool of radioactive water. If the player plunges into the pool, he can acquire the desirable object, but he might suffer injury from the radioactive water. In so doing, the player learns that radioactive water is not necessarily deadly, and can be traversed if one is quick about it. Later in the game, the player is required to traverse radioactive pools in order to complete the level. In one case, the player must jump from a high ledge into the water, run across it, and open a secret door to escape.
The basic idea is simple and clear: start the beginner off easy and carefully build on the user’s experiences. Remember, in every game, the user is learning how to play. That learning experience must be carefully metered to insure that there is always something new to learn without being too much to digest at any time. The player should climb a smooth ramp that never levels off nor offers too steep a slope. Doom does this very well.
Some Final Complaints
I do have a few other criticisms of the design. First, there appear to be a couple of places where the player can fall into a pool of radioactive water from which there is no exit. This is not good design. It’s one thing to die because there were too many monsters and you got shot up fair and square, but a player should never be put in a hopeless position. The defense in this case is that the player shouldn’t have fallen into the water in the first place. I think this a weak defense. A game is not real life; it’s more like the movies. In the movies, when the hero gets into trouble, he always escapes at the last minute through some clever stunt. In a game, the player must believe that, no matter how bleak the situation looks, there’s still a way out, if only he’s heroic enough. Always give the player an out.
My other complaint is with the tricky timing puzzles. In one example of this, you lower a secret door by walking past a point in a corridor and then you have just a few seconds to run to the door and jump through it before it closes. I am sure that with the appropriate input device this is not too difficult. However, I was using a mouse, and despite my best efforts, I found it almost impossible to get through that damn door. I had to make perhaps ten attempts before I was successful. I suspect that the designers did this with a joystick and found it none too difficult. It is very important that an input system be tested with all the input devices for which it is intended. In this case, the mouse simply doesn’t do the job properly, and the designers who failed to take this into account made a mistake.
Conclusions
Doom illustrates the basic concepts of sound game design. As I said earlier, it’s not a brilliant or innovative design; it really is quite pedestrian in design terms. But a beginning designer can learn more from a well-executed basic design than from a flawed cutting-edge design.