The recent release of the fourth edition of Graham Nelson's Inform Designer's Manual has occasioned no little excitement in the IF community. There were several reasons for the hubbub: for one thing, Inform programmers substantially outnumber TADS programmers (there's no official count, but the ratio of Inform games to TADS games in the last few competitions has been heavily skewed toward the former), and the new manual plugs some holes that had plagued writers working with the previous version. Even writers who don't use Inform and don't plan to have found the manual worth perusing.
The manual is also notable, though, because it goes beyond merely documenting Inform and offers some thoughts on game design that aren't specific in any way to Inform. Graham's musings on game design are well worth having, of course; the games Graham has written would have assured him a hallowed place in the IF community even if he hadn't written Inform. It must also be said, however, that most of the section on game design is identical to Graham's "Craft of Adventure," originally written and posted to rec.arts.int-fiction in 1995, and that most of the updates are examples from more recent games, not actual from-scratch assessments of what goes into good game design. To some extent, of course, this is to be expected: the medium is still largely what it was in 1995 (and in 1980, when Zork I was released). But there are some aspects of game design to which the analysis gives what might be described as short shrift -- often because things have changed since 1995 -- and I think it's worth looking at a few of those elements. Specifically, this article discusses the role of the player character, or PC, as it relates to game design, and the nature of the games that tend to be produced when the PC is fully developed.
First, though, a qualifier: the relevant section of the Designer's Manual did not purport to be a comprehensive assessment of every important aspect of game design. It does cover many of the most important topics, and it's the lucidity and thoroughness of its treatment that makes any omission notable. To the extent that chapter of the manual is criticized here, then, it's a victim of its own success.
(This section contains mild spoilers for Little Blue Men and non-spoiler discussion of Plundered Hearts, Varicella and Music Education.)
The Designer's Manual explains that, in IF, there is a "triangle of identities": the player (the person sitting at the keyboard), the protagonist (also known as the PC, the person controlled by the player's commands), and the narrator (the voice explaining to the player what's going on). The description of the relationship between player and PC focuses on the question of characterization: to what extent is the PC a person with an identity of his/her own, as opposed to the alter ego of the player? The manual cites Infocom's Plundered Hearts, in which the PC is a girl in a specific historical setting with a reasonably well developed background, in contrast to Zork, where there is no attempt at characterization. From there, the discussion segues into the extent to which the "beliefs and abilities of the protagonist" drive the action, and from there into a brief discussion of magic. Characterization is an important consideration, but there's more to characterization than simply having a backstory: once the designer has decided to give the PC an identity, other considerations arise. One way to make a PC's persona especially vivid is to give him fully written conversation statements (as in, translating ASK FRED ABOUT WANDA into "Can you believe what Wanda said about you, Fred?"); Adam Cadre's game Varicella did a particularly good job of this, not only translating the ASK/TELL commands but giving the player three different "tones" that would vary the way the character phrased the statement or question.
One of the key factors in designing a PC is the question of motivation. When the PC is a cipher, the player can generally assume that the relevant objective is "poke around and solve any puzzles that come along," but when the PC has an actual identity, that makes less sense (unless the PC has an identity of "adventurer" or some such thing, which rather defeats the purpose of giving the PC a persona). If the PC has a real objective in mind, the designer needs to connect the puzzles with that objective somehow; some degree of looking around for objects or information that might help reach the goal is acceptable, though proportionality is important here. If the PC is trying to scrape up cash to buy lunch, breaking into a home to find cash isn't within the scope of something the player can realistically be expected to try.
Often, the PC's goals change over the course of the game -- there might be an initial task that leads to a larger, more important goal. In such a case, the designer needs to ensure that the player is aware of the shift; the 1999 competition entry Music Education elicited complaints because the initial goals were to feed the parking meter and practice the saxophone, but the game went on after those objectives were achieved with no indication of what the PC's new motivations were. Problematic in a slightly different respect was Little Blue Men, from the 1998 competition, in which the PC was expected to act in some fairly antisocial ways, and the player was given only minimal hints at the reasons for the antisocial behavior. Another common motivational problem arises when the designer forces the player to solve a puzzle in order to learn something that the PC would logically know -- like, say, his last name. Mimesis matters in PC characterization; most players don't expect the PC's behavior to be wholly realistic, but if you give the PC an identity, his knowledge needs to fit.
The crux of the motivation problem is that the designer is trying to both make the PC a person in his own right and an IF player, with, presumably, the behavioral tendencies, of both -- a marriage that's hard to reconcile. Typically, the PC's motivations give the game a framework, and it's presumed that the IF player instincts can be given free rein within the framework, but even if that's the assumption, the lines need to be drawn somehow; the designer may need to tell the player, one way or another, "Okay, it's time for you to play magpie and go poke around," or convey that that sort of behavior is no longer appropriate.
This article copyright © 2001, Duncan Stevens