Introduction

What makes a game a game? A game is fundamentally some system of rules, filled with variables that determine outcomes in response to choices made by one or more players. Most video games represent some real-time engine, a system of rules describing the ways in which the player moves through the world, interacts with it, and frequently finds ways to kill things with flashy lights and pretty explosions. Designing an action game is about tweaking those rules and the game's basic physics to make it challenging and interesting. This article is about a different genre of gaming: one that is less a problem of real-time physics and more to do with puzzle-solving and creation; less about creating an interesting general system for the player to toy with and more about specifically scripting everything the designer wants to happen. It's less about creating an interactive reflex-rewarding world, and more about telling a specific story.

Colossal Cave Adventure (1976), variantly titled just Adventure or ADVENT, became the archetype and namesake of the adventure game genre.

The adventure game is one of the oldest forms of video gaming. The genre's first game, Colossal Cave Adventure, came out in 1976, just four years after the release of Pong. The player of Colossal Cave Adventure wandered through a system of caves with only textual narration to explain what was happening. The only method of interaction was typing commands. No graphics, just blobs of text thrown at the user, who replied by typing text in an attempt to specify what to do next.

Thirty years later, all sorts of new genres have come into existence as faster hardware has allowed for more complex and involved gameplay, as well as more stimulating visuals to accompany that experience. However, the concept of adventure games has remained fundamentally unchanged. Colossal Cave Adventure could be remade today into a glitzy three-dimensional world while keeping the nature of its puzzles and exploration intact. The underlying puzzles and structure of an adventure game are scarcely affected by hardware and almost independent of the engine used to explore the game world.

The adventure game Myst (1993), by Cyan Studios, was the bestselling PC game until 2002.

Adventure games probably had their heyday so early in the evolution of personal computers because, for a while, telling an interactive story with puzzles and (later) colorful visuals was among the most impressive things a computer could do. Many mainstream adventure titles followed Colossal Cave Adventure—and one of them, Myst (released in 1993), remained the bestselling PC game until 2002. The worlds have changed from simply being described through text to being portrayed in 2D or 3D simulations, with casts of voice actors and musicians bringing them to life—all while remaining conceptually similar to the earliest games.

What decades of evolution have done for the genre is refine the user interface. The genre's improvements are largely independent of the technology used and have gradually evolved in response to user feedback and designers' efforts to make the puzzles clear yet challenging. The evolution of that interface, alongside an explanation of what an adventure game fundamentally is, will be the focus of this article.

I will use the term interface to represent the method a player employs to interact with a game, in understanding/solving its puzzles and exploring its world. I specifically mean an interface in the abstract sense: what actions are allowable for interaction with the game? This is a separate issue from the physical interface: how are those actions conveyed by the visual information on the screen or how does the game make use of the mouse or keyboard to perform those actions?

Although a physical interface is often proprietary, the underlying abstract interface might be copied by competing games. For example, many of the classic Sierra adventure games are based on a three-verb interface: examining, using, and talking to things in the world. The three-verb interface was later duplicated in the third game of LucasArts' Monkey Island series. The physical interface differed but the three abstract ways of interacting with the world were the same.

Defining an Adventure Game

An adventure game is a series of puzzles, solved by interacting with discrete elements in the game world, usually in a way that does not depend on reflexes or real-time concerns. Adventure games, unlike most video game genres, require very little specialized knowledge to play. Generally, the most common physical interface tasks are clicking on and dragging objects, familiar tasks to users of modern operating systems. There are few fatal consequences or dangers for players to avoid and the challenge is meant to be abstractly intellectual rather than testing skill with a specific game system. As a genre, adventure gaming is accessible to a larger number of players than most and has drawn in people who would not consider themselves regular gamers.

The challenge in an adventure game is not based on fighting enemies, building armies, or the usual competitive activities associated with video games. Rather, the player has to figure out what the designers were thinking when they built the game and follow some script of events in order to win. These events are activated by actions the user can perform and the necessary actions are created by the player executing a particular command on a particular object in the game world. The player interacts with the world by performing actions on individual objects, using objects with each other, and navigating through the world. To progress in the game, the player needs to find a particular sequence of events or combination of actions which trigger other behaviors and events in the world. Gradually, those events lead to some winning state. The user is given a set of graphical, verbal, or textual descriptions of the game world and is supposed to figure out exactly what the programmer expects him or her to do.

As a typical example, the player might find himself or herself locked in a room. He or she may perform such actions as examining the room for clues, trying to call for help, and searching behind paintings and under rugs. Under one rug, the player might find a key, which could be used to unlock the door and complete the scenario. The key might even be hidden under a rug atop which is a table that is bolted to the wall—so a more complex sequence of interactions might be necessary to fulfill the task. Such a scenario might be accompanied by movie sequences and dialogue, might be illustrated with animated or three-dimensional interactive worlds, but fundamentally its challenge would remain the same: complete a specific task by interacting with the available objects in some way determined in advance by the programmer and which the user is supposed to infer.

The challenge of designing an adventure game is this: if it is too easy to infer the solution to the puzzles, the game will not sufficiently engage the user—and if it is too difficult, the user could get frustrated and give up. One common interface improvement is to simplify the process of composing actions and making the necessary tasks more obvious. However, since part of the challenge in an adventure game is figuring out what to do next, it's a fine line to walk.

Adventure Game Constructs

To further explain the structure of adventure games and the components that determine their interfaces, this next section outlines the fundamental puzzle design concepts of this genre.

World. A game's world is a set of environments which are connected by some navigation action.

A world is simply the top-level description for the game itself, a set of all locations the player can visit.

Environment. An environment is a set of objects.

A particular environment is a set of objects which the player can interact with or examine. One example of this would be the previously-mentioned locked room, which might contain rugs, paintings, or other objects which could give the player clues or be used to escape.

Object. An object is an individual game element with which the player may interact using a verb.

An object is simply a unit in the game which is identified individually and which the player can perform some action upon. Any element of the game the player cannot interact with individually or directly is not considered an object, simply background material. This interaction might include simply examining the object, using it, talking to it, or using any other verb to interact with it.

Verb. A verb is a means of interaction with objects. A verb combined with an object forms an action, such that "Verb Object" is an action.

Sample verbs, which I will cover in more detail later, are examining, using, and talking to particular objects. A verb simply specifies a way the player can interact with an object.

Action. An action is something which can trigger an event. An action can be a verb on its own, a verb and an object, or an item, verb, and object.

An action is a valid combination of a verb with some objects. It is important to note that not all combinations will be valid. Trying to talk to a rock or eat the sun will likely not be valid actions, unless the programmer specifically designates them as such. The programmer determines in advance what combinations of verbs and objects designate valid actions and creates events to respond to those.

Event. An event is the way in which the program interacts with the user: by providing feedback and information, changing the state of the program, or ending the game.

An event could be as simple as displaying a message—which might describe an object the user has chosen to examine, indicate that the user has opened a door, or conclude the game after the user has completed all tasks. The state of the program could be a set of variables particular to each object or it could be some record of tasks which the player has completed or not.

Player. The player is the user's avatar, capable of generating actions and possessing an inventory.

The player is the user's hook into the system. It can compose any possible action using verbs and objects and has an inventory associated with it.

Inventory. An inventory is a set of items.

The inventory contains all items collected by the user, which provide an additional means of interaction with the world.

Item. An item is a special kind of object associated with the user. An item can be used with other objects to create an action: "Item Verb Object" is an action.

In the case of the previous locked room example, the player may perform some action to find a key. One possible action upon finding the key is to add it to the player's inventory, which generates an event to add it to the inventory set. The player can then use the key with other objects in the room to try to generate a valid action, such as unlocking the door with the key.

Actions

There are a few basic actions which should be explicitly identified:

Navigation [Verb]

Navigation is what allows the user to switch environments. It causes a transition from one environment to some other connected one. Navigation to particular environments might be disabled until some event is completed. Some events might cause the user to switch environments without ever navigating directly. It might be handled by a directional pad to move a character or a point-and-click interface to explicitly switch screens.

Examining an Object—[Verb (Examine) Object]

Early adventure games contained only one way to get information about the game world: use a verb to examine a particular environment or object and then read a description as text. Since the advancement of graphical adventure games, the need for explicit narrative explaining the game has diminished but many modern adventure games still allow the user to examine an object or environment to get a description. This could serve one of several purposes: yielding clues about what actions the player could perform on an object; providing colorful commentary by the protagonist; or setting the scene and mood by having a narrator describe something.

Some adventure games include additional verbs such as "smell," "taste," or "read" to enable the player to gain more information about a particular object. For most games, these are just generalized to a single "look" command.

Using an Object—[Verb (Use) Object]

Most interaction with a single object can be generalized as "using it." Early parser-based adventure games provided a large number of verbs to distinguish among actions that can be performed on a single object, such as lifting a rug, burning a rug, eating a rug, or wearing a rug. Point-and-click adventure games frequently choose to simplify the interface into a single verb, which just represents all the ways an object can be used. Objects in the inventory can also be "used."

Such generalization has the advantage of eliminating redundant choices but it also has the consequence of eliminating similar but different actions—for instance, pushing, pulling, or opening a heavy box before attempting to put it in inventory.

Adding an Object to Inventory—[Verb (Get) Object]

This simply generates an event which converts the object into an item, removes it from the environment, and adds it to the inventory. This is frequently generalized as simply "using" an object as well.

In most games, the player is assumed to have an inventory of infinite capacity, sometimes containing objects of all shapes and sizes. The inventory itself can be an environment for interacting with items: a book may be read once you take it, boxes may be opened, and so on. To keep the inventory from becoming increasingly cluttered, games are often designed to "use up" items or have the inventory emptied of useless junk at a few key points.

Using an Item—[Item Verb (Use) Object]

This is again a generalization of all the ways the player may use an item with an object in the environment or another object in the inventory. The possibilities for this type of action can be composed as a cross-product of all the possible items in an inventory and all the possible objects in the environment. Figuring out what items, verbs, and objects compose valid actions is one of the main challenges of many adventure games.

Talking to an Object/Person—-[Verb (Talk) Object (Person)]

A person is a type of object on which the "talk" action can be used. Engaging in the "talk" action frequently leads to such forms of interaction as asking questions, telling information, or requesting help. Conversation topics might become available as a result of certain events and conversely events might be triggered by conversations. Different interfaces handle the talking action in different ways: by giving the player a list of things to say as choices, by allowing the player to enter a description of a particular topic, or by running a pre-scripted dialogue.

Further Abstractions

Implicit Information

While many adventure games make managing an inventory and acquiring the right items the central task which indicates progress in the game, some adventure games mark the solution to a puzzle and allow the player to move forward without relying on some inventory object as a flag. For example, if the player completes a task which involves receiving a secret password to get into a club, the game could represent that directly by giving the player an item which has the password written on it, implicitly by assuming that the player's character now knows the password and can automatically state it upon request, or explicitly by asking the player to type in a password. This last method might have the quirk of letting the player skip a sequence of events if he knows the password from playing the game before. Some games use inventory objects as the sole means of triggering events and advancing in the game but it's equally possible to avoid them altogether—to trigger things by information internal to the game's state or information entered by the player.

Unwinnable States

An unwinnable state is one in which there is no possible way to trigger the event to win the game. An unwinnable state might occur if the player does something which renders some action impossible to perform—for instance, losing or simply failing to obtain some item which is necessary to complete the game. By trying to prevent such states from occurring, the designer can makes things easier for the player. However, this approach might introduce constraints on the player or the game world: for instance, prohibiting certain actions (such as dropping a necessary item) or leaving navigation links to older environments, where necessary items might still lie.

Adventure Game Complexity

One critical distinction between adventure games and most other genres is that every interaction has to be explicitly pre-scripted by the designer. Every meaningful combination of items or proposed method of interaction has to be laid out in advance: there's no way to generalize the behavior of using a pet rock with any number of objects in the world, other than giving a default response to say that action isn't possible. However, the designer, as storyteller, might need to consider what information the game should present in response to the player's fiddling around. For instance, the game could encourage the player in a different direction when he or she attempts an incorrect approach to a puzzle.

One consequence of requiring everything the game does to be explicitly plotted out is that adventure games can drive the player to attempt to solve them by brute-force fiddling, particularly if the puzzles are non-intuitive. A player might try all available verbs with all available objects—a task made easier in point-and-click games which use fewer verbs—or even all combinations of items with each other. The difficulty of the latter task depends on the size of the active inventory and available objects in the world.

Several methods can prevent gameplay from descending into frustrated, repeated clicking. The game can provide clues and sufficiently intuitive puzzles so that the player doesn't feel stuck and forced to make progress by essentially cheating. Some games, such as the Phoenix Wright series, penalize the player for guessing at random rather than thinking through a puzzle. Others make events more complicated to trigger, by requiring a sequence of actions or by making events dependent on a large number of player-controlled variables in the game's state.

To illustrate some of the interface choices made in the past and the effects those have had on game design, it will be useful to look at the genre's evolution.

Adventure Game Interfaces

Sierra OnLine's King's Quest (1984), like many early graphical adventure games, retained the text-parser interface.

Parser-Based Interfaces

The first adventure games emerged in the days before graphics or sound cards, when video gaming was an obscure niche hobby. Your sole means of interacting with the game was a console with a text parser, where you could type combinations of verbs and objects that the game would hopefully recognize as a valid command. Avid gamers would occasionally spend hours—huddled over a keyboard with a thesaurus—trying to figure out whether they were supposed to push/shove/roll that boulder/rock/stone, balance on top of it, eat it, or anything else in the realm of possibility, out of which usually only one phrase would produce any useful result.

This is, in a sense, the most open-ended adventure game interface, since the designer and player are not restricted by the number of verbs that can be displayed in a menu or actions that can be represented through point-and-click activities. The puzzles in this system generally can't be cracked as easily by brute force of trying every object in relation with every other object, since you also have to specify the means of interaction. Moreover, having to compose simple sentences also happens to be the interface which most closely resembles the underlying logical structure of such games. Despite the additional layers of graphical abstraction and the ways in which the elements of adventure gaming have been simplified, the genre has generally maintained the same underlying abstractions.

The challenge of a parser-based game often comes down to figuring out what verbs or means of interaction the game is looking for. Figuring out what objects are permissible to interact with is a simpler task, since the names of the objects are usually made explicit in the descriptions given by examining objects and environments. After figuring out what verbs allow you to compose valid actions, the challenge becomes figuring out what actions lead to a desired event. That inference tends to be a simple one, however, since in parser-based games events and actions tend to be very closely tied for the sake of simplicity.

Considering that the task of composing an action comes down to selecting a combination of verb, object, and item, the challenge in a parser-based game is most strongly tied to figuring out the correct verb to specify an action. [All possible Verbs x All possible Objects x All possible Items]

With Maniac Mansion (1987) and the underlying SCUMM engine, Lucasfilm Games made its debut in point and click.

Point-and-Click Interface with a Fixed List of Verbs

One of the first generalized interfaces which attempted to free the player from the constraints of a keyboard and parser was created by Lucasfilm Games (later renamed LucasArts Entertainment) in the form of the SCUMM^[1] engine. The SCUMM engine simplified the parser interface by extracting a general list of verbs that the designers believed to be sufficient for most gaming scenarios. The canonical list included elements such as "push," "pull," "give," "open," "close," "walk to," "talk to," "look at," "pick up," "use," "turn on," and "turn off." The mouse could be used to select a verb and apply it to an object in the game. Alternatively, right-clicking on a particular object would select some default verb. Inventory objects could be combined and used with other objects via the "use" command.

Another problem that this engine simplified was identifying which graphical elements were relevant for gameplay: an object would be clearly identified with a string of text whenever the mouse cursor hovered over it. Since the interface greatly simplified identification of gameplay elements in terms of both verbs and objects, actions were easier to identify.

A result of simplifying the set of possible actions was that the puzzles would be correspondingly easier to figure out since there were fewer possibilities to try. The designers generally compensated for this by increasing the number of items you could hold in your inventory and increasing the size and complexity of the games. [All possible Verbs x All possible Objects x All possible Items]

King's Quest V (1990, though the 1992 CD version is shown here) contained the first implementation of Sierra's three-verb point-and-click interface.

Point-and-Click Interface with Three Verbs

A more generalized interface developed by Sierra OnLine (later renamed Sierra Entertainment) restricted the set of possible verbs to three choices: examining an object, using an object, and talking to a person. Items could be used with other objects as before. Switching among these choices was done by right-clicking to alternate among these verbs and whatever inventory object was last selected. One disadvantage of this system compared to the LucasArts one was that objects were not always clearly identified graphically or descriptively, leaving some ambiguity about whether an object had any possibilities for interaction.

One consequence of simplifying the interface is that it takes away more of the burden of the user to think of what actions to perform and how to relate them to verbs and objects. As before, to compensate, the games generally became more complex and made use of larger inventories and longer puzzles. [All possible Verbs x All possible Objects x All possible Items]

These last two graphical interfaces changed the concept of an adventure game by making the focus less on determining how to compose a particular action and more on inferring what action would be needed to generate a particular event. In addition, the number of possible actions was often diminished, simplifying things further.

It is interesting to note that LucasArts eventually copied some ideas from the Sierra interface in designing a game (The Curse of Monkey Island) with the same three verbs rather than a longer list. However, this game still made use of LucasArts' earlier system for clearly identifying objects in the graphical space. One later Sierra game (Quest for Glory V) further reduced the set of verbs to two: examining an object or interacting with it (which could mean taking an item, talking to a person, or using an object). To avoid generalizing every possibility of using an object into a single category, some games in the genre took the additional step of presenting the user with a list of choices on how to use a particular object (such as opening, breaking, or shaking a jar).

The interface in Sierra's Torin's Passage (1995) typifies single-verb point and click.

Point and Click, Single Verb

Still later adventure games chose to reduce the verb space by only allowing one possible action for a given object. For a person this could represent conversation, for some objects this could represent examining it for clues, and for other objects it could represent using it or adding it to the inventory. The difference between this and two-verb interfaces is that "examine" and "use" verbs became combined, such that information about an object was provided as the player attempted to use it.

Another simplification introduced into the design is that actions and valid combinations of items were made more easily identifiable. Interfaces were frequently designed so that the cursor would be grayed out if, when the user tried to hover a particular item over an object, there was no way to use them together. This meant that combinations of items and objects which represented valid actions could be more clearly identified. Once again, this made the games simpler to use but less challenging in some respects.

To compensate for reducing the challenge in identifying actions, designers often required the player to trigger events by a set of actions in sequence rather than a single action. Thus, instead of the possible choices being enumerated by Actions=[Verbs x Objects x Items], the sequence could be enumerated by [Actions^N], where N is the number of necessary actions to complete an event. The complexity of such a sequence is still more polynomial than exponential, however, since you have a limited set of reasonable actions and reasonable sequence lengths. Still, such formulations added another level of complexity to the problem of figuring out possible events based on possible actions.

Point and Click, Single Verb, No Inventory

One of the best-known styles of adventure game interfaces is that popularized by the Myst series. These games represented the entire interface with a floating hand which controlled navigation, interaction with objects, and examination of objects. Furthermore, the games usually maintained no inventory for representing combinations between objects, though the user could in some cases hold a single object at a time.

The consequence of this interface is to make actions wholly unambiguous from the user's perspective. The user can detect with a mouseover whether an action can be performed on an object. The challenge of inference for the user, then, becomes simply relating events to actions, rather than both relating events to actions and actions to objects and verbs. The way to trigger an event is typically by performing some set of actions in sequence to assign a state to a set of objects.

For example, one end-of-game puzzle in the Myst series involves placing five out of six differently colored marbles in a 25 x 25 grid. Without knowing anything else about the problem, there would be over 563 trillion possible solutions. The user's task in figuring out the solution becomes more challenging and presumably more rewarding. The user needs to infer the desired state by observing clues and game elements which relate to the source space of the problem—in this case by observing a map of the island, locating certain elements on a grid, and correlating symbols with colors.

The complexity of determining events from actions in this case would be [All Possible States^(All Possible Objects)]. Thus, the complexity grows exponentially with the size of the problem and in many cases would be difficult for even a computer to solve by brute force. The user must observe patterns and correlate information to figure out a combination for a problem that would otherwise be utterly unmanageable.

Hybrid Interfaces

While point-and-click adventure gaming is currently the dominant style, there are a few variations on this method of gameplay. Some point-and-click adventure games such as a (yet-to-be-released) freeware remake of Sierra's Quest for Glory 2 have also included a parser—in this case for the conversation system, while using a three-verb system for the rest of the game. This means that while all the possible means of interaction with ordinary objects are explicitly specified, all the possible conversations are not. Thus, the player must form a much more precise concept of what he wants to do in the conversational part of the game.

Certain recent adventure games, such as Sherlock Holmes: Nemesis (2008) from Frogwares Game Development Studio, offer a great challenge by requiring the player to search a continuous 3D environment instead of discrete, fixed scenes.

Some adventure games break the genre conventions altogether by introducing real-time elements such as combat, to which your success at solving puzzles might merely contribute. Moreover, from parser games onward, adventure games have typically been divided into discrete environments —a representation of the world as separate areas or rooms you transition between rather than as a continuous environment like first-person shooter games typically use. Some of the recent Myst games have featured a continuous rather than discrete method for navigation. While such adventure games do still occasionally "lock" the player into a given view or area to solve a puzzle, they otherwise change the way the world is explored and divided up.

Analysis of Interfaces

For games in which puzzle-solving entails identifying particular actions that will generate events, the problem is essentially one of lateral thinking. The user infers some desired event and tries to think of a way to cause that event to occur by using the available objects in some unusual way. Sometimes the necessary actions are ambiguous or difficult for the user to infer, so later interfaces do more to clarify the range of possibilities at the expense of making the possible space of actions smaller and the puzzles simpler.

More complicated puzzles might not tie events directly to actions but rather to a sequence of actions or a set of objects' states that the player's actions can alter. Then, the problem is often about finding some pattern which satisfies a particular puzzle, where the number of possible patterns is far too many to solve by brute force. One frequent complaint about such puzzles is that they are generally more logical and mathematical in nature. Rather than requiring a leap of creative thinking to find some connection between the elements of the world, the user must detect some pattern or combination which is generally revealed mathematically or logically. For example, many games contain puzzles that are analogous to activating a circuit by flipping switches to direct the flow. Another stock puzzle is decoding a foreign numbering system to get a numerical pattern. These kinds of puzzles require linear thinking rather than lateral and can make the game seem more like a logician's paradise than a creative fantasy world.

Many games feature instances of both kinds of puzzles: both inventory-based puzzles, which involve some combination of items to trigger events, and state- or pattern-based puzzles, which require some logical deduction to solve.

The trend towards the latter kind of puzzle is probably due to its greater complexity, in terms of possibilities for generating events, paired with designers' desire to create more challenging games. But steering towards greater mathematical complexity is not the only way to create an interesting or challenging puzzle. Often in the real world, relating things to each other and thinking of ways to creatively combine ideas poses a greater challenge than logically working through some known problem. As games and simulations grow more complex and open-ended, the possibilities for interactions among objects might increase and there might be a renewed focus on lateral problem-solving over linear.

General Rules for Adventure Game Interfaces

The genre seems to be moving towards more complex problems which defy enumeration and simple trial-and-error and instead force the user to make some complex inference which demonstrates a high degree of intelligence and presumably gives greater satisfaction and bragging rights. Such puzzles generally have to be more logical and mathematical so that the solution can be unambiguous. Moreover, the puzzles often involve recording and logically correlating information to map the elements of gameplay to the solution.

One way to avoid the common pitfalls of games based around managing inventories is to make puzzles more open-ended and the allowed interactions and verbs more complex rather than less. For example, to put out a fire, the user might be allowed to throw water on it, stomp on it, throw a rug on it, or run away and call the fire department. Each of these solutions should require more thought than simply combining different objects. A solution might, for example, require the user to physically pick up the required object in the game and position it in a way to make clear his or her intention. Real-world interaction between objects is more complicated than can be represented by a simple cross-product, so the challenge should be allowing the games' complexity to grow closer to that of the real world—to make puzzles more open-ended, permitting a variety of possible solutions rather than restricting the player to generating a specific action.

The advantage to simplifying the interface is that the process of performing an individual action becomes much more transparent. The user expects to work at understanding the solution to the problem rather than understanding how to use the interface to get to that solution. The disadvantage is that making actions easily identifiable limits the number of actions you can perform by requiring each of them to be uniquely identifiable. For the standard point-and-click interface, there might be no way to address this problem of allowing for both simplicity in composing actions and robustness in the set of possibilities. Other interfaces might be better suited.

As with most interfaces, actions the user is expected to perform frequently should be intuitive and require as few operations and as little time as possible. More complex problems and puzzles should require the user to make the connection abstractly through relating events to possible actions, rather than being confused with the interface and unable to specify an action which the user already understands abstractly. The puzzles themselves often have to be complicated or counterintuitive to make them a challenge but the challenge should be in the conceptual space of the game, not in the interface itself. The interface should clearly map desired actions to performable ones and make it clear what actions cannot be performed.

A common problem in adventure games is that if the player is unable to solve a particular puzzle, gameplay can stagnate for as long as the user is stuck. One technique to avoid this problem is to make a large number of the puzzles optional. Alternatively, the game could allow the player to "opt out" of a given puzzle after a certain period of time. A player in the locked room could choose to lie down on a bed, give up searching, and fall asleep, only to be woken up by someone else searching the house later. A game that operates on a real-time system might assign a puzzle a certain time limit, after which it might simply expire and the plot would proceed. A further benefit of optional puzzles would be to improve replay value, since most players wouldn't be able to solve every puzzle or complete every event the first time through. The game could also branch out into multiple story paths or endings depending on which tasks the player succeeds in completing. This way, the completion of a puzzle affects the development of the game, rather than being a bottleneck that determines whether gameplay proceeds at all.

Obviously, in addition to their puzzles, adventure games are often played and enjoyed for features such as lush environments, memorable characters, compelling plots, wit, and humor—but such topics are beyond the scope of this article. Having a manageable interface and understanding the nature of the game's puzzles and their complexity is a problem worth pursuing on its own.

Footnote

[1] SCUMM is an acronym: Script Creation Utility for Maniac Mansion (with Maniac Mansion being the title of the first game to use this engine).