While preparing some blogs to discuss things like my decision to use a text parser for command input, the oversimplification of the adventure game interface, and a demonstration of our hybrid interface, I started thinking about all of the different verbs used when playing interactive fiction. Because when you really get down to it, the real heart of an adventure game -- aside from the salient features like writing, story, and characters -- is arguably the verbs.
My impression is that the vast majority of commands in IF are limited to a few categories, like movement or examining. But once you get beyond those common actions, you find the jucier verbs, the ones that seem to have a larger impact on advancing the game and the story. Verbs like PUSH, PUT, WEAR, TURN, or BREAK. And then the rare verbs, the ones that are used maybe once or twice in a game, but have a specific purpose and impact. Like DISLODGE, SUMMON, or ARREST.
But how often are these verbs used in a typical game, and how many of these jucier verbs are there, really?
That's actually a complicated question, for a number of reasons. The main issue is that the frequency of verb use is highly dependent on individual game design, as well as the person playing the game. The frequency of verb use is very different when you compare an experienced IF player with an inexperienced one, and playing style is important, too (I tend to overuse LOOK, EXAMINE, and INVENTORY, for instance -- who knows why, I think it just gives me a sense of "buying time," so to speak, which is silly since IF is turn-based). And it's also very different if you compare a relatively short game, such as those in the annual IF Comp, with a more full-length game.
But in an attempt to initially explore this question, I've decided to take the relatively easy and straightforward route: I downloaded the published walkthroughs for three games entered into the IF Comp in the recent past, and compiled a breakdown of the verbs required for each. Note that these walkthroughs are not necessarily fast solutions -- they include commands that are technically unnecessary for solving the game, but which provide a more complete experience of the game for players who follow them. Still, these are by no means game transcripts, so they don't really reflect the typical use of verbs that one might expect from players. As such, I expect there is a significant underrepresentation of verbs such as EXAMINE, LOOK, SEARCH, ASK, and INVENTORY, among others.
The three games I decided to look at are Floatpoint (by Emily Short), The Elysium Enigma (by Eric Eve), and Tales of the Traveling Swordsman (by Mike Snyder). Below are the breakdowns from each of these games. In order to avoid any spoilers, I chose to leave the graphs unlabeled, and to erase the labels of the least common verbs. I have also grouped together all movement verbs into one group, which includes the compass directions, plus verbs like IN, OUT, ENTER, EXIT, and UP and DOWN.
What to take from all of this?
Well, not a lot, really, given that it's a very small, very biased sample. That said, I think it's no surprise that movement commands and EXAMINE make up a huge chunk of the verbs. But it's interesting that, once you get beyond that, it can be pretty variable, which I think is largely a reflection on game design. It's pretty fascinating that if you look at the top 10 verbs beyond movement and EXAMINE, they are quite different between games.
What I find most interesting from this is the surprisingly large number of verbs included in the walkthroughs for these games. The totals ranged from 34 up to 65. Granted, not all of these are verbs (such as the responses YES and NO), but it's still a surprising range of input. And that doesn't necessarily account for synonyms.
Of course, many of these verbs act on specific objects, and many of those actions are, generally speaking, the only important actions one could perform on those objects. So in theory many of these verbs could be replaced with the generic "use" verb, or a simple context-sensitive menu, as is often done these days in graphical adventure games to simplify the interface. It's more efficient, and players don't have to think about what specific action they want to perform. Plus, it eliminates any "guess the verb" frustrations.
Still, many of these verbs don't act on objects, and provide a deeper level of interaction with the game world. And I think there is definitely something to be said about forcing the player to think about -- and explicitly state -- what he or she wants to do next. Figuring out what to do, not just how to do it, can be part of the challenge of an adventure game, and I think it's something that is missing from today's simplified interfaces.
Many people might respond with a "good riddance", and perhaps that's how most people feel since the market has shown that the simplified interface has been quite successful. But just as I believe there is a role for text output in a graphical adventure game, I also believe there is still a role for text command input, to potentially broaden and deepen the player's experience.
I should state that, with Vespers, we really will have more of a hybrid interface. Movement, of course, will be handled as with many typical FPS games, and many other common commands will be able to be entered quickly, either via the mouse or a single key. That will eliminate a lot of the typing, but it will certainly leave a considerable amount.
Will people see it as a benefit or a barrier? Who knows. That's all part of the experiment. It's one of the things I like about being an indie -- you're not just forced to design to the lowest common denominator.
Oh, and I suppose you might be wondering about the text version of Vespers. Here's the breakdown. Fewer verbs required than some other games, but still a pretty good number. Plus, the walkthrough leaves out a few verbs, and there are also three different walkthroughs, so others might be slightly different.
February 9, 2008
A Verb Analysis in IF
Subscribe to:
Post Comments (Atom)
15 comments:
"The vast majority of commands in IF are limited to a few categories, like movement or examining."
As in real life, you first need to acquire the pieces of the puzzle, THEN solve it (read roughly as "LOOK, MOVE to a new location" repeat). Beyond that, physical actions aren't that varied
"Figuring out what to do, not just how to do it, can be part of the challenge of an adventure game, and I think it's something that is missing from today's simplified interfaces."
If you're talking about the one-size fits all USE interface, I agree.
On the other hand, a text interface allows for multiple actions, but has a far greater failing. It doesn't communicate to the gamer the extend of the "player character's" skill set.
To make it clearer, the gamer might know about CPR, and how to perform CPR, but he doesn't know whether his in game persona, the "player character", has the same knowledge and skill set. In a text interface, whether the "player" knows CPR, alchemy or any other method to save a life is equally probable, and the gamer is expected to find which answer is correct through trial and error. And trial and error is NOT FUN. See, unlike DOS, games don't come with a manual that lists all the commands.
You can certainy work around this, by designing your game more intricately and nudging the gamer towards using insight to figure out what skills the "player" has, but that's added design time with little benefit.
Instead of trying to "figure out" which skills you have, a process you don't go through in real life unless you're suffering from Alzheimer's, it's far more entertaining to spend your time considering the possible ramifications of your actions. This is where the context sensitive drop down menu comes in.
Reaching ARREST through trial and error is one thing, favoring ARREST over KILL or IMPRISON is a different beast altogether.
"Reaching ARREST through trial and error is one thing, favoring ARREST over KILL or IMPRISON is a different beast altogether."
That's a really good point. You want to give the player all their options as much as possible unless it's game-breaking, but you want to avoid the use-everything-on-everything design.
Just looking at these graphs gave me an idea -- instead of a context-sensitive menu, what about a verb wheel, where spinning the wheel and selecting a pie slice drills you down to other similar verbs? There's a name for this kind of interface I can't think of right now.
The programmer of Goo (IGF finalist) is working on something like that, called d@sher. You might want to take a look at the forum thread over at TIGForums http://forums.tigsource.com/index.php?topic=960.0
I'd be satisfied with a simple menu, though.
Excellent points, thanks both of you. I appreciate the comments.
You know, this really embarks upon a discussion that I wanted to get to eventually in the blog, but since you've brought it up I'll go ahead and put something together for this week. In brief response, though, I think it's fair to say that the statement "trial and error is not fun" is not universally applicable. Here's why I think that.
What I think you're getting at, when you describe the process of "trying to figure out which skills you have", is the "guess-the-verb" problem for which many adventure games are known. But really, this consists of two types of phenomena:
1. the player has found something he believes to be important, but he's not sure what to do with it, and
2. the player has found an object and wants to do something specific to it, but can't figure out how to get the parser to understand what he wants to do.
The second phenomenon above is what I think most people mean when they talk about "guess-the-verb" problems. The first one is what I feel is more directly related to puzzle design.
Sometimes, the action the player should perform is something out of the ordinary, whether that's an unusual verb (ARREST) or even a magic word (PLUGH). This is an important special case, and what is often referred to as the "concealed verb" problem. And I think there is a strong argument that full disclosure -- whether that's via a verb listing or a drop down menu -- can be detrimental in those cases. I'll go into that in more detail in the blog.
But as to your comment that "games don't come with a manual that lists all the commands"...actually, I think that's not altogether true. Many IF games do include a list of the possible commands used in that game, and adventure games that use graphical icon-based command selection or context-sensitive drop down menus accomplish precisely that.
I would definitely agree, though, that there is an important distinction between figuring out to use ARREST and choosing it from among different options.
"there is a strong argument that full disclosure -- whether that's via a verb listing or a drop down menu -- can be detrimental in those cases"
I don't see how you can sell that argument at all. In real life, you already have "full disclosure" of your skills.
If you have the power to ARREST someone, you already KNOW you have this power. There's nothing to disclose!
You don't spend any time thinking "What should I do now? I better try actions that seem relevant, like STAB. Oh wait, I can ARREST people. What have I been thinking for the last 5 minutes?"
You instead think "Do I arrest him now, or let this play out?"
Searching for which skills you have only happens if you have a neurological problem.
This isn't a parser flaw as you list it. It's an interface design flaw.
Actually, I would call that a game design flaw, not an interface flaw. I definitely appreciate your position, but I think you're taking a very narrow position on a topic that is not necessarily so cut-and-dried.
I think one of the issues is that you are focusing on what you call "skills"; that is, those actions that are available as defined by the background of the protagonist but which are not necesssarily "common" verbs. If the protagonist of a game is a police officer, then it makes little sense to hide the fact that ARREST is a possible verb to use in a situation. I have no particular argument with that. If someone wanted to implement a disclosure system -- such as, in IF, a "verbs" command that shows all possible verbs in a game -- you could include ARREST in that list. Hiding the fact that the player can use ARREST just creates an unnecessary puzzle that players obviously don't appreciate.
I do, however, disagree with including a verb list such as this is, and that if you are designing a game that includes a relatively obscure verb (for IF at least) such as ARREST, you can (and should) design the game such that this option is made clear to the player. It should be fairly obvious, or at least logical, that the player can try ARRESTING the individual at a particular point in the game, and it's really not that difficult to do. Not all authors do this, and not many do it well, but it's a sign of good authorship talent.
But the issue of concealed verbs and full disclosure extends beyond just the domain of "acknowledged skills," and I think there are fairly convincing circumstances where full disclosure of possible actions is not always desirable. Including these actions in a verb list, or in a pop-up or drop-down menu, removes much of the analytic part of the game. It can spoil puzzles with options that are logical but that the player hasn't thought of yet.
Take, for instance, the BREAK verb. In real life, nobody has to disclose to you that you can break all of the different objects around you. But you can certainly devise a game puzzle that relies on the player deducing that he must break a certain object to solve the puzzle. So if you have a system, say in a graphical adventure, where you can click on an object to produce a drop-down menu of verb options to act upon that object, do you include BREAK as an option for every single object in the game? Or do you just include it on the object that needs to be broken in order to solve the puzzle? And by doing that, aren't you basically giving the puzzle away?
As an example, consider a game that has a note hidden inside of a fancy porcelain statue. The only way to get the note is to break the statue, and you may not provide clues to the presence of the note inside the statue until later in the game. Do you automatically include BREAK in all of the drop-down options for that object, even from the very beginning of the game? If you do, you give away the fact that it needs to be broken, perhaps well before you've provided clues to that effect, and the puzzle is ineffective. Unless you provide BREAK as an option for every single breakable object in the game, and that becomes excessive -- do you provide every possible verb for every object? If the player responds with, "Well damn, I didn't even realize I *could* break the statue!", the point is that it's not necessarily logical (in real life) to walk into a room and try breaking everything to find out if there are any goodies inside of them. Yet, it's a "skill" we all have.
In most IF engines, a relatively common command such as BREAK is defined by default, so if an IF game included a full disclosure of verbs, BREAK would appear on it, and this wouldn't necessarily give away a puzzle such as above -- that, to me, is one of the advantages of an IF parser over graphical interfaces. However, what of puzzles that use more obscure verbs, but in a similar fashion? What about STAB? What if a game has designed a puzzle where you are facing an enemy, and your only defense is a pencil in your inventory. In real life, nobody has to tell you that you can STAB somebody with a pencil, but does that mean it becomes an option in the drop-down menu at all times with all NPCs? And if it's only with the enemy NPC, that really eliminates any of the challenge of the puzzle, doesn't it?
And then, what about a verb like SING? I can think of only one IF game that has ever implemented a SING command. You could easily imagine a puzzle solved by SINGING in the right place at the right time. Nobody has to disclose to anyone in real life that you can SING. But if you want to devise an IF game that requires the player to deduce that he needs to SING to solve an important puzzle, including SING in the full list of verbs available in the game would certainly go a long way towards giving that away. And how would you do that in a purely graphical game? You can SING just about any time in real life -- would you include SING in a pop-up or drop-down menu in every location in a graphical game? That wouldn't be a very creative puzzle. "But my protagonist is a singer, of course she would think of singing as an option!" a player might respond. But then, that's the goal of good writing and design -- make the player aware of the protagonist's skills, and let the player deduce when, where, and upon which objects to use those skills.
Then you have the whole subject of magic words. Plenty of games use magic words as solutions to puzzles -- granted, they often aren't the best puzzles, but still -- and part of the puzzle involves first, figuring out that there is a magic word and what it is, and second, figuring out where/when/upon which object to use the magic word. If you include the magic word in the full list of verbs, that destroys a big part of the puzzle. But even if you create a system that leaves the magic word out of the list until you discover it in the game, you're still left with a situation -- at least in a graphical game -- where you either put the magic word in the drop-down list for every location or object, or only those upon which the word will operate, and that destroys the other part of the puzzle.
This argument extends well beyond "searching for skills", and make no mistake about it, there is no one solution that works best for every player. You can call this an interface flaw, but there are flaws in every system, including ones that always fully disclose. In my opinion, the critical thing is good puzzle design and good writing. When done well, puzzles like these can be very satisfying. When done poorly, they can suck and make players resentful.
I'll go into this in more detail in the blog.
Hi Rubin:
I'm El Clérigo Urbatain, an IF author and user, Spanish.
I'm quite excited about Vespers 3D so I want to make an interview to you for SPAG and SPAC (spanish webzine about IF). Please contact me when you can and we will talk about the interview, at urbatain at gmail dot com
Thanks a lot and good work!
Urbatain
"Take, for instance, the BREAK or STAB verb"
Simple physical actions (BREAK, STAB, MOVE, JUMP) should be embedded in the physics engine. Higher level functions / skills (ARREST, SING) can't be represented through the physics engine, and should be accessed through a drop down menu.
"Would you include SING in a drop-down menu in every location in a graphical game?"
You can create a SKILLS button that allows the player to perform skills (SING, DANCE, GESTURE, CLIMB, SWIM, around 30 such skills). That way each skill is defined as a possibility, and yet hidden among it's kin.
I think there's merit to your suggestions, but I also think there are advantages and disadvantages. Embedding physical actions like those into the physics engine presumes that one has a robust physics engine to work with that can accurately handle these actions, and for many indie projects (ahem) this is an issue. And creating physical representations of actions isn't always the simplest or most fun method of implementing those actions, particularly if players end up having to spend time fiddling with the physics to get the action just right (when they would rather it just do what it's supposed to do).
A drop-down menu with 30 skills doesn't come across to me as a particularly well-conceived interface I'd enjoy playing with, particularly if many of them are added just as red herrings.
And you still have the issue of special, unique verbs, like magic words, which wouldn't necessarily fit a solution like this.
A drop-down menu with a list of 30 skills like that would really be no different than a parser with an avalable "verbs" command, listing all of the possible verbs in a given game. And I would still contend that a verb list -- whether from a "verbs" command or a drop-down menu -- is a trade-off: the player gets to know all actions available at all times, avoiding any frustrating "guess-the-verb" pseudo-puzzles, but at the expense of the author being unable to devise clever puzzles that require the player to creatively deduce actions outside of the normal range.
As one individual once noted: "IF is, I believe, enriched by the fact that some puzzles require
non-obvious actions, and some non-obvious actions require special verbs."
I agree, and I think that, in many cases, putting those special verbs in a list (verb list or drop-down menu) can destroy a big part of the fun of these games by eliminating much of the need for analytical thought.
After some discussion on ifMUD we came up with 5 games that use SING as part of a "winning walkthrough", although 2 of the games would be considered minor works.
Lots of games support SING since it's part of the Inform default library, also meaning more thoughtful authors at least try to customize the message.
Having a visual list of verbs to choose from is essentially how things worked in Maniac Mansion and a few other old LucasArts (SCUMM engine) games. The idea works wonderfully, but games like Babel and Galatea would completely lose their power with such a verb system. Having a menu, because of the problem/feature of unique verbs for certain circumstances, would tend to limit the interface (if good game design were to remain intact.) I think both approaches work wonderfully when handled well, though many players will validly prefer one interface to the other.
WRT bigbosssnk's remark:
You can certainy work around this, by designing your game more intricately and nudging the gamer towards using insight to figure out what skills the "player" has, but that's added design time with little benefit.
This I disagree with. There's a lot of IF technique that has developed around ways to nudge the player toward understanding his range of available actions, so it's not as though one has to completely invent methods from scratch; and on the other hand, figuring out what your key interactions are going to be and teaching them to the player often makes for a much stronger, more focused design.
A good point, Jason. My scope of IF experience is not as broad as it should be, but thanks for pointing that out.
And I agree with you, valzi. Although some have argued that placing limits on the number of possible actions, with the player aware of them all at all times, makes the game world seem artificial. It comes down to a matter of choice.
"Rendering simple actions requires a robust physics engine, and it's only fun depending on implementation"
Every FPS and it's spin-off have a robust enough physics engine to handle STAB, BREAK, etc. Even open-source projects can handle it. As for implementation, you are free to script any event that isn't handled easily (like breaking the vase if you punch within a reasonable distance).
"A drop-down menu with 30 skills is ill conceived"
I'm not talking about a Windows style drop down menu. A clean interface is important.
"Red herrings can obfuscate the important skills"
Don't use red herrings. SKILLS should be relevant to at least one puzzle.
"Unique verbs, like magic words, won't fit"
Start with a closed skill set and expand it. Learn new skills as you go.
"some puzzles require non-obvious actions, and some non-obvious actions require special verbs"
This doesn't prove that some puzzles require special verbs. The connection is too vague.
"A verb list is a trade-off between full skill disclosure and ability to deduce actions outside the normal range."
This "normal range" changes according to the gamer's real life experience. A singer will always want to SING. A thief always try to STEAL. A correct design avoids this stochastic approach by grounding the set of your actions on certainty.
"One doesn't have to invent methods for conveying possible actions from scratch"
You can forgo the added design time altogether, and focus more effort on game-world manipulation.
"Figuring out what your key interactions are going to be and how to teach them to the player often makes for a much stronger, more focused design."
True, but you're talking about informing the gamer HOW to use an interaction mechanism. I'm talking about informing the gamer WHICH interaction mechanisms he has at his disposal.
"As for implementation, you are free to script any event that isn't handled easily (like breaking the vase if you punch within a reasonable distance)."
I'm not disagreeing, and in Vespers I do just that. There is the opportunity to BREAK an object, and as long as you're within a reasonable distance, the command works. It's just not embedded within the physics, so to speak. There is no swinging of an object and checks to see if that swing contacts its target. For anything other than crude approximations, you would need a pretty good system. For this type of game, that kind of implementation is unnecessary. If this was a combat game, it might be.
"I'm not talking about a Windows style drop down menu. A clean interface is important."
It's certainly important if you're going to consider that many actions, and I think it would be a challenge to do so. But as mentioned, it really comes down to personal preference; some people prefer clicking on an action from among 30 buttons, while others prefer to just type it in.
"This doesn't prove that some puzzles require special verbs. The connection is too vague."
It was a quote, and not intended to prove anything. I've seen enough instances where unique verbs were used in creative and effective ways to know that disclosing these verbs would eliminate what some people believe is an important part of playing IF: the sense of discovery that comes with creative problem solving. You've made it clear that you believe that problem solving should not involve a thoughtful testing of the verb space. That is your preference, as it is for many individuals. For others, that's part of the challenge and the fun.
To quote another individual from a couple of years ago, "It's not an ideal of IF that the player knows the entire set of possible actions, or even the entire set of verbs, although that may well be the ideal of several things which are not IF. Rather, the ideal is that when the player thinks an action should work, then the action should work. Ideally, the player should have an intuitive feel for what is possible and what is not, a feel which develops as he explores and interacts with the game. This offers a much deeper and more engaged participation in the game world than what is possible in the SCUMM system. The player develops insights about the game, discovers how to interact with it. The best such experiences I've had in IF would not work if all the possible actions were given up-front."
Some of us who like IF think this is a virtue. Some people (particularly those who don't like IF) think it's a shortcoming. A lot depends on how well crafted the game is. In any case, this is an argument that has existed for some time; there is no one correct side, there is only personal preference.
Post a Comment