An Analysis of Semiotic Spaces in Adventure Games
This page has come a long way, starting out as a project for a course on interfaces three years ago, being self-published on this site for a couple years, and finally being published in an online magazine here: http://www.strangehorizons.com/2008/20080804/newheiser-a.shtml I've blogged about some of the process and my personal experiences with the genre here, and I've gotten the chance to review contemporary adventure games since writing about the subject, on this site.
This page contains an interesting response to this article written some time ago, and this page contains some further thoughts I've had on the nature of puzzles in adventure games which I'm also working up to a more presentable form.
This page is based on a paper written in the Spring of 2005, talking about the interfaces and underlying source spaces for the adventure gaming genre. The writing is a little technical with some buzzwords thrown in particular to the course, but it's the process of being rewritten, so the writing may vary from casual to stilted)
(Just so you know, semiotic spaces refers to the underlying representation of a system which is conveyed through signs somehow. For example, the underlying semiotic space for the tic-tac-toe game is a 3 by 3 grid of squares marked with X's, O's. or left blank. The underlying interface for most websites is a structure of different related pages, often organized in different types of hierarchies. A source space is the underlying logic behind a system which is conveyed through your interactions with it)
In the case of adventure games, the source space represents some system of puzzles and the user's interaction with them. The interface describes the means by which the user interacts with the puzzles, determines how the puzzle has to be approached, and can even describe its difficulty.
1. The genre of Adventure Gaming
1.1. Adventure Gaming explained
1.2. Adventure Gaming constructs
1.2.1 Adventure Gaming constructs-Actions
1.2.2 Adventure Gaming constructs-Events
1.2.3 Adventure Gaming constructs-Information as an Item
1.2.4 Adventure Gaming constructs-Conversation Trees
1.2.5 Adventure Gaming constructs-Further Abstractions
1.3. Adventure Game Interfaces
1.4. Analysis of Interfaces
1.5. General rules for Adventure Game Interfaces
Adventure Games have been there since the beginning. In 1972, Pong bounced onto the arcade scene, proving that computers were capable of simulating the highly complex and dynamic sport of tennis. It was only four years later that the first adventure game was developed, Colossal Cave Adventure. It was released with no graphics, no real-time interaction, and nothing but plain text to guide you through a complex maze filled with puzzles.
Thirty years later, all sorts of new genres have come into existence as faster hardware has allowed for more complex and involved gameplay, and more stimulating visuals to accompany that experience. But the basic conception of how an adventure game works 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 the structure for the game is almost independent of the medium used to explore that world.
What decades of evolution have done for the genre is refine the interface the player uses to interact with the game. What makes the topic particularly interesting is that the improvements made are largely independent of the technology used, and have gradually evolved in response to user feedback and finding ways to better reflect the conceptual space of the genre. The evolution of this interface is the topic I intend to cover in this paper.
(When it comes to computers, an Interface describes the way in which two different things have to interact. In order to view this web page, your computer received a complex transmission from Google's servers, which it had to decode and render into HTML to display on your screen. An Interface is simply an agreed means by which that transaction takes place, it lets both parties know what they have to do in order to communicate. In designing this web page I used an Interface of clickable buttons letting me select fonts and styles to format the page how I wanted. The same task can (and has) been accomplished in a variety of ways—I could edit the HTML directly and get under the hood and start tweaking things until I get the desired result, I could use an editor like Dreamweaver or FrontPage which tries to set up a whole page for me — and I try to pick whatever Interface will let me get the task done as efficiently as possible.)
For adventure games, the Interface is a way for the user (or player) to tackle the puzzles and explore the world the game designers have laid out. It has to translate somehow into the representation of the underlying "semiotic space" of the game. This paper will chiefly be concerned with what actions or means of control are allowed in the game, and how that interaction affects the puzzles. This is somewhat different than considering the visual task of organizing information on the screen, or how to make use of the mouse or keyboard.
Individual interfaces tend to be owned by the company that made them, but the underlying concept behind that interface may be used in multiple games. For example, many of the classic Sierra adventure games are based on a three verb interface, a concept later used in the third game in the Monkey Island series. The physical interface in terms of how those verbs are accessed is different, but both games feature three ways in which to interact with the world and both share an underlying structure.
Adventure Gaming originated with text based adventures in which you simply typed commands to an interpreter, and has grown to encompass three dimensional simulations of surreal worlds and interactive cartoons brought to life on the screen. As late as 2000, the best selling PC game of all time was an adventure game known as Myst. 1 Adventure Games are unique in the world of video games in that they require very little specialized knowledge to be able to play. Adventure Games generally don't test reflexes or coordination in having you perform complicated tasks, and they don't usually take place in a real time environment where speed is an issue. The most common interface tasks are generally just clicking on and dragging objects, a familiar task to a users of modern operating systems. There are few fatal consequences or dangers for players to avoid and the challenge is meant to be intellectual rather than testing your skill with the system. As a genre it is accessible to a larger number of players than most, and has drawn in people who would not consider themselves regular gamers.
The challenge faced in an adventure game is not based around fighting enemies, building armies, or the usual competitive activities associated with video games. An adventure game is conceptually a series of puzzles which much be solved independently by the user to succeed in a particular goal. 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 neccessary actions are composed of verbs and objects. The player interacts with the world by performing actions on individual objects, using objects with each other, and navigating through the world somehow. In order to succeed 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, and gradually proceed to some winning state. The user is given a set of graphical, verbal, or textual descriptions of the world of the game, and is supposed to infer back to the source space of the programmer. The user needs to deduce what events the game wishes for him to perform to solve a particular puzzle, what actions could conceivably create those events, and what verbs and objects could be used to create those actions.
As a typical example, in one adventure game scenario the player may find himself locked in a room. He or she may perform the actions of examining the room for clues, trying to call for help, searching behind paintings or under rugs until he or she finds a key, which could be used to unlock the door and complete the scenario. The key may also be hidden under a rug which has a table on top of it which is bolted to the wall, so it may require a more complex sequence of interactions to fulfill the task. In an actual instance of an adventure game, such a scenario may be accompanied by movie sequences, dialog, and may be illustrated by animated or three-dimensional interactive worlds, but fundamentally the challenge remains the same—complete a specific task by interacting with all the available objects in some way determined in advance by the programmer, and which the user is supposed to infer.
The challenge of designing the interface is that if it is too easy to infer back to the source space of the puzzle the game will lack sufficient challenge to make it interesting; and if it is too difficult the user could get frustrated and give up. Making actions easier to perform and verbs and objects easier to identify makes it easier to compose actions, but part of the challenge lies in deducing what actions can be performed while the rest is deducing how events can be triggered through actions. Earlier adventure games tend to focus on the first problem, while later adventure games make the first inference simpler and tend to focus on the second problem.
The precise interface of such scenarios and the means in which Adventure Games manage the interaction to these source spaces is what we shall examine next.
The following list represents the relevant constructs in the source space for an adventure game.
World. A world is a set of environments and a mapping for how they connect to each other through the navigation action.
The World is the source space of all environments which are available for a particular game. Intuitively these are individual areas the player may visit, usually well separated and well defined for the convenience of the player. The user may perform a navigation action on the environment to move from an environment to another connected one in the world.
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 room which was discussed earlier, which may contain rugs, paintings, or other objects which could give clues to the player 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 can not interact with individually or directly is not considered an object. This interaction may 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, or “Verb Object” is an action.
Sample verbs we will cover in more detail later are examining, using, and talking to particular objects. A verb simply specifies a way in which an object can be interacted with.
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, either providing feedback and information, changing the state of the program, or winning the game.
An event can be as simple as displaying a message describing an object the user chose to examine, designating that the user has opened a door, or concluding the game after the user has completed all tasks. The state of the program can be a set of variables particular to each object or some record of what tasks have been completed or not.
Player. The player is the avatar of the user, 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, and which 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.
There are a few prototypical actions which should be considered in more detail. Parser or text-based adventure games frequently have a nearly unlimited set of verbs to work with since the user can type anything, but mouse or point-and-click-based adventure games prefer to use a set with fewer verbs and it is useful to generalize the interaction into a few categories.
Navigation is what allows the user to switch environments. It transitions from one environment to some other connected one. Navigation to particular environments may be disabled until some event is completed and some events may cause the user to switch environments without ever navigating there directly.
Navigation can be done by using a directional pad to control the character's movement similar to most avatar based video games, or a point and click model where transitions to other areas are clearly indicated.
Examining an Object-[Verb (Examine) Object]
In the early days of adventure games the only way to get any information about the game whatsoever was to use a Verb to examine a particular environment or object, and read a description as text. Since the advancement of graphical adventure games, the need for explicit narrative explaining the game has diminished; but a good deal of modern adventure games choose to allow the user to examine a particular object or environment to get a description. This can be done to get clues about what actions would be possible upon an object, to provide colorful commentary by the protagonist, or to set the scene and mood by having a narrator describe it.
Some adventure games included additional verbs such as “smell”, “taste”, or “read” to gain more information about a particular object. For most games this is just generalized to a single “look” command.
Using an Object-[Verb (Use) Object]
Most solitary interaction with a particular object can be generalized as “using it.” Early parser-based adventure games provided a large number of verbs to distinguish between actions that can be performed on an object by itself, 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".
Generalizing all cases of using an object into a single verb has its advantages in avoiding redundant choices, but it also has the consequence of eliminating similar actions such as pushing, pulling, opening, or even interacting with an object before putting it into 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, which can sometimes contain objects of all shapes and sizes. Items can also be interacted with in the context of the inventory: a book may be read once you take it, boxes may be opened, etc. In order to keep the inventory from being cluttered by the end of the game with all the items relating to any puzzle that has been completed, the game is often designed to “use up” items or have the inventory emptied of useless junk at a few key points in the game.
Using an Item-[Item Verb (Use) Object]
This is again a generalization of all the ways an item may be used by the player with an object in the environment or another object in the inventory. Unlike the other actions this one 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 more difficult inferences of adventure games.
Talking to an Object/Person – [Verb (Talk) Object (Person)]
A Person is a particular type of Object on which the talk action can be used. Engaging in the talk action frequently leads to conversation trees or more complicated forms of interactions, such as asking questions from a set, telling information to a person, or asking them for help. Conversation topics may appear as a result of specific events, and events may 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, running a pre-scripted dialogue, or allowing the player to provide or request information about particular topics.
Saving/Loading the game –[Verb (Save/Load)]
Saving the game simply allows the player to save the state of the game and allow it to be loaded later. The save action is not necessary to complete the game or interact with the system, but it allows the player a way to leave a game and return to it.
A few typical events which need to be understood are described here.
Starting the game
This simply places the game in some default state and gives control of the player to the user.
Winning the game
This occurs when the player has completed all necessary events to win. Frequently the game prints out some ranking or score based upon what optional events the player completed, plays some congratulatory sequence, and terminates the program.
Death of the player
When this occurs the player has no choice but to either perform a load action, call an event to restart the game, or quit the game altogether. All other actions are disabled and the game is left with no way to reach a winning state. Some adventure game players consider this state to be an inconvenience to reach, so modern adventure games will frequently give the user a way to return to the state the player was in prior to “dying.”
In the previous list, the concept of an inventory which stores items was briefly discussed. In the earliest adventure games an item being in inventory simply served as a flag that some chain of events had been completed. A player might visit a police officer to pick up some crime scene photographs, and then be able to show the photographs to a suspect to learn more about the case. The player takes the photographs and puts them into the inventory, and uses the photos on another character to prove to the game that he's already visited the police officer and can proceed with the next event.
But this chain of events could be handled differently. Suppose instead that the player talked to the police officer to learn about the crime scene and was then able to question suspects directly just by talking to them without any sort of inventory middleman involved with solving the puzzle. In this case, completing the chain of events is dependent upon the information obtained by the character rather than an object in inventory. Once the player's character has the relevant information he can proceed with the puzzle.
In this context, information can be viewed as a sort of implicit inventory object. After the player talks to the police officer, he learns about a crime scene. Rather than representing that knowledge as an explicit object in inventory, it is represented internally to the game and is implicit in the player's further interactions with the game.
Another example would be having the player learn a password to get into an exclusive club. The player could be given an inventory object with the password written on it he uses to get in the club, or the player could simply be told the password and his character would then be able to enter the club at will. The advantages to this approach is that it serves as a more realistic simulation of problem solving, and simplifies the actions necessary to complete a task the player already understands.
Information can be considered as an internal variable or an implicit item in inventory that flags whether the player has completed a certain event or not and allows the player to complete other events. Information can obviously be used indirectly as well. In another analogy to the password example, the player might just read the password written on the wall and be asked to type in a password to get into the club. In this structure, there's nothing to prevent the player from doing events out of order if he's already completed the game or simply guesses the information correctly. Considering information as an item is more likely to be done in a game when it is necessary to force the player to perform certain events in order.
Information is often gained by examining certain objects, such as reading books. Conversations with other characters may lead to new information; after the player interrogates a suspect he may learn that a snake was seen at the scene of the crime and the player will then be able to ask other characters about snakes. And certain events may lead to the player gaining information, such as visiting the scene of the crime and seeing some tire tracks, which might allow the player to begin investigating cars.
Information can be used to trigger events, as when the player knows the password and can proceed into the club; it can be used to trigger interactions with other characters, as when the player learns about a crime and can interrogate suspects. Information in the literal sense is obviously used to interpret what's actually happening in the game and what needs to be done next. A character may tell the player that there was a man wearing dark sunglasses at the scene of the crime, but that information may not be strictly necessary to solving a puzzle from the game's point of view, it just serves as a hint to the player. Information from the game's point of view can simply be used to flag events completed and allow the player to interact more naturally with the game without having every event be based on the contents of his inventory.
In the simplest case, interaction with an in-game character can simply be linear. If the player chooses to talk with a character in the game, a scripted conversation occurs which might trigger an event. This conversation may be different if you talk to the character more than once, depending upon how far the player is into the game or what information he possesses; however, this leaves the player with only one option for conversation or interacting with characters in the game.
Another alternative is to have a sub-interface for conversations based around individual conversation topics. Rather than just choosing to talk to a person, you choose to talk to them about a particular subject, which may relate to a piece of information obtained in the game, and may lead to other conversation topics being revealed.
A few typical abstractions from the source space of the system are discussed here.
An un-winnable state is one in which there is no possible way to trigger the event to win the game.
An un-winnable state may occur if the player does something which renders some action impossible to perform, such as where the player loses or simply fails to obtain some item in his inventory which is necessary to complete the game. Trying to prevent such states from occurring makes things easier for the player, but may limit the scope of the game by making it necessary to revisit older environments or prohibit certain actions.
One measure of the complexity or challenge of a game is the set of possible actions or states the game may be in.
If the game is composed entirely of events directly related to individual actions, the set of possible ways to trigger an event will be: [All possible Verbs*All possible Objects*All possible Items]
This is basically “polynomial” and may be small enough to be solved by brute force in some cases by a particularly persistent and frustrated player. The challenge and reward of the game is being able to reduce the space of all theoretically possible actions to the ones which appear to be reasonable, and inferring from those which ones would be necessary to trigger a certain event or complete a certain task. The graphical information, dialogue, and clues provided by the system provide ways to solve this problem and allow the user to tackle the complexity by inferring a solution rather than trying all possible actions. A particularly bad adventure game would be one where the set of possible actions and events don’t make intuitive sense, or where the user finds some action or event that is impossible, but which he/she believes would be a better solution to a particular puzzle. Some games provide hints to the player or allow multiple actions to trigger an event and solve a puzzle in order to avoid these problems.
In addition to the challenge of composing an individual action to trigger an event, some adventure games require you to perform a number of actions in sequence to solve a puzzle, making the complexity equivalent to [Actions]^N, which is [Verbs*Objects*Items]^N as before.
A more complicated setup used in modern adventure games is one in which each Object has a state associated with it that is changed by actions performed by the user, and an event is triggered by a set of objects being left in a particular state. In this case the complexity of possible actions needed to trigger an event becomes: [All Possible States^(All Possible Objects)]
This can grow to be exponential very quickly and some modern adventure games use similar techniques to design problems that are virtually impossible to solve by brute force or simply trying combinations until something works.
Parser based interface
The first adventure games were in the days before graphics, sound cards, and before most video games themselves existed in the form we know them today. The input to the program was simply a console with a text parser. The user would type to the game in sentences consisting of verbs and objects recognized by the game and the game would perform some action as was appropriate.
This interface probably fits the source space the most closely by directly representing the verbs as “verbs” and the objects as nouns. Despite the additional layers of graphical abstraction and the ways in which the elements of adventure gaming have been made simpler, the genre has generally maintained the same source space.
Because of the nature of a parser based game, where you have to have your commands interpreted by what the programmer thinks you will say in a particular case, the challenge and complexity of the game often centers on finding the right verb and noun to express a desired action. It is also considerably more difficult to trigger a desired event by simply trying combinations of verbs and objects if you have no idea what verb could be used.
The names of the objects are usually made explicit in the descriptions given by examining objects and environments, so the challenge is mostly restricted to identifying what verb corresponds to an abstract action you wish to perform, and figuring out what abstract action will you give the desired event. Events and actions were very closely tied so usually the challenge is simply determining and composing the correct action.
From our earlier formula, the main focus for the complexity is in the number of Verbs possible. [All possible Verbs*All possible Objects*All possible Items]
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 with done by LucasArts™ with the SCUMM™ engine. It simplified the parser interface by extracting a general list of verbs they 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 an individual verb and apply it to an object in the game, or right clicking on a particular object would select some default verb. Inventory objects could be combined and used with other objects by the use command.
Another problem that was simplified by this engine was identifying which graphical elements were relevant for gameplay and which were not, as an object would be clearly identified with a string of text by hovering the mouse over it. The interface greatly simplified identification of gameplay elements both in terms identifying verbs and objects, so actions were easier to identify.
One of the consequences of simplifying the set of possible actions was that the puzzles would be correspondingly easier to figure out if there are 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*All possible Objects*All possible Items]
Point and Click Interface with three Verbs.
A more generalized interface developed by Sierra™ 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 between these choices was done by right-clicking to alternate between 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 and so there was 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, the games generally become more complex to compensate for this, and made use of larger inventories and longer puzzles. [All possible Verbs*All possible Objects*All possible Items]
These two interfaces improved the interface 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 with their later titles and chose to go from a list of verbs to three generalized choices, while still making use of their earlier system for clearly identifying objects in the graphical space. One later Sierra game also combined the Talking and Using verbs into a single choice which would respond differently for people or objects. Some games in the genre also chose to present the user with more choices after "using" an object to allow them to specify more precisely what they want to do. (such as opening, breaking, or shaking a jar)
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 and getting clues or information, and for other objects it could represent using it or adding it to the inventory. The main difference between this and previous interfaces with more verbs is that it tended to combine the Examine and Use verbs by providing information about an object as you attempted to use it, and of course the way in which you used an object was no longer ambiguous at all.
Another bit of simplicity introduced to the design is that actions themselves and combinations of items could be made less unambiguous. 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.
Another way the designers compensated for reducing the challenge in identifying actions was by triggering an event as a result of a set of actions in sequence. So instead of the possible choices being represented by Actions=[Verbs*Objects* Items] it could be [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 possibilities of reasonable actions and reasonable length of the sequences to be performed, but such formulations added another level of complexity to the problem of figuring out possible events based upon possible actions.
Point and Click, single verb, no inventory
One of the most well known style of adventure game interfaces is that popularized by the Myst ™ series. In these, the entire interface to the game was represented by a floating hand which controlled navigation, interaction with objects, and examination of objects. Furthermore, the games in general maintained no inventory which could be used to represent combinations between objects, although the user could in some cases hold one 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 just relating events to actions, rather than both relating events to actions and actions to objects and verbs. The way to trigger an event typically becomes performing some set of actions in sequence to assign a state to a set of objects in order to trigger an event.
For example, one final 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 task of the user 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 and locating certain elements on a grid and correlating symbols with colors.
As mentioned before, the complexity of determining events from actions in this case would be [All Possible States^(All Possible Objects)] and grows exponentially with the size of the problem, and would be difficult even for a computer to enumerate in many cases. The user has to be able to observe patterns, correlate information, and figure out a combination for a problem that would be utterly unmanageable by “brute force” or continuously trying possibilities.
For games in which the problem of inference to the source space is based upon generating events by identifying particular actions, the problem is essentially one of lateral thinking, thinking of all the ways in which objects could combined or be used in relation to each other. The user infers some desired event and tries to think of a way to cause that event to occur by “blending” the space of two objects together and creating some action. In some cases the actions necessary may be 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 choose to not tie events to actions directly but to a sequence of events, or base an event on the states of a set of objects which can be altered through actions of the player. In this case the problem is often about finding some pattern which satisfies a particular puzzle, where the number of possible patterns is far too many to enumerate. 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 connect two objects in the source space or have the user form some blend to relate them, the user must detect some pattern or combination which is generally revealed mathematically or logically. Examples of this include puzzles similar to activating a circuit by flipping switches directing flow to different areas, or 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 examples of both kinds of puzzles, some which are inventory based and involve blending and combining things to create events, and some of which are state and pattern based, usually requiring some logical deduction on a puzzle.
The trend towards the latter kind of puzzle is probably at least partially explained due to its greater complexity in terms of possibilities for generating events, and the desire to create more challenging games. But steering towards greater mathematical complexity is not the only way to create an interesting or challenging puzzle. In the real world relating things to each other and thinking of all the ways to creatively combine ideas often 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 between objects may increase and there may be a return to focusing on lateral problem solving over linear.
The direction in which the genre seems to be moving is towards more complex problems which defy enumeration and simple trial-and-error, and which 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, and 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 blending objects and source spaces to find a solution is to make puzzles more open-ended and the interactions and verbs allowed more complex rather than less. For example, to put out a fire, the user may 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, and may 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. Interaction between objects and coming up with ways to blend them is more complicated than can be represented by a simple cross-product between the sets of possibilities, so the challenge should be allowing the complexity in the game to grow closer to that of the real world, and make puzzles more open-ended, permitting a variety of possible solutions rather than restricting it to generating a specific action.
The advantage to simplifying the interface is that understanding how to do an individual action becomes much simpler. From the user’s point of view they should have to work at understanding the solution of 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 able to be identified uniquely. For the standard point and click interface there may be no way to address this problem of allowing for both simplicity in composing actions and robustness in the set of possibilities, but other interfaces may be better suited as we will discuss later.
In general, the interface and structure of the game should be designed in such a way as to avoid a state in which there is no way to make progress or complete the game. A trivial way to do this is to allow the game to backtrack or go back a few steps if a fatal choice has been made or the player caused some event resulting in death, but in some cases this may represent a significant restriction on the structure of the program. In the case of inventory-based puzzles it means that unless all environments are strongly connected by navigation, the player may be able to reach an area and be unable to make progress or solve a puzzle due to missing an item. Many games are designed for non-linear exploration and allow the player to backtrack precisely for this reason, but in some cases it is preferable to limit the set of reachable environments to simplify a puzzle. Design choices like this may restrict the possibilities for the game but it makes things much more manageable from the user’s point of view if the principle is followed.
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 in relating events to possible actions, rather than being confused with the interface and not being able to specify an action which the user already understands abstractly. The puzzles themselves often have to be complicated or counter-intuitive 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 can not be performed.
A common problem in Adventure Games is that if the player is unable to solve a particular puzzle, gameplay can freeze for as long as the user is stuck. One technique to avoid this problem is to make a large number of the puzzles optional, or allow them to "opt out" after a certain period of time. In the example of the locked room from earlier, the player could choose to lie down in the bed and give up searching and fall asleep, only to be woken up by someone else searching the house later. In a game that operates in a real-time system where days pass over the course of a game, a puzzle may have a certain time limit during which it can be completed, and after that point it may simply expire and allow the game's plot to proceed. One of the consequences to this would be to improve replay value since most players wouldn't be able to solve each puzzle or complete each event the first time through, and the game would still be flexible enough to support that. The game could also branch out into multiple story paths or endings depending upon which tasks the player succeeds in completing. In this view, the completion of a puzzle affects the development of the game, rather than being a bottleneck for allowing gameplay to proceed.
Obviously, in addition to their puzzles and semiotic spaces, adventure games are often played and enjoyed for features such as lush environments, memorable characters, compelling plots, and wit and senses of humor included throughout the game, but such topics are beyond the scope of this paper. Having a manageable interface and understanding the source space and the nature of the puzzles of the game is orthogonal to the game features listed above.
Adventure Games represent an interesting example in semiotic spaces, where the goal is to infer a desired solution from the information presented in the game, come up with a way to reach that solution, and be able to perform the necessary actions. The challenge comes in making this inference sufficiently complex to be rewarding and enjoyable, but direct and logical enough to be solvable. Whether the inference requires a creative leap of lateral thinking or a logical relation of information represents two kinds of puzzles that have evolved and are often featured in modern games. A good deal of games prefer to focus on the latter problem since it is less ambiguous, but coming up with more ways to represent creative possibilities and interactions is a fertile area for growth, and more closely related to the way people naturally think about problems. Designing games requiring both logical and creative inferences tests more aspects of intelligence and should allow the games to appeal to a wider audience.
Adventure Game interfaces have evolved in a way to make the allowed actions simpler and less ambiguous. Removing ambiguity and making them easier to compose is a positive development, but the possible interactions allowed need not be simple. In the real world, we understand the actions we can perform with different objects quite well but for any two objects there are an enormous number of blends we can form between them. Representing this complexity of interaction through gameplay elements in a manageable form is a difficult task, but not an infeasible one. In the simplest case, a sufficiently detailed physics model would allow for very complex interactions with the objects in the model without the programmers ever having to specify what those actions might be or the users having to form actions through combinations of verbs and objects. Modeling an actual locked room with all the possibilities a real one would have would let the user come up with solutions which might surprise the programmers themselves. The challenge will be in developing such a model which allows for more open-ended creative thinking while still making the puzzles interesting and rewarding.
Such a method would essentially change the semiotic space of the game and make it so actions are no longer necessarily composed of a finite set of verbs and objects but interaction is handled more generally. First Person Shooters and games with more complicated interfaces frequently have physics-based puzzles or more open-ended problems to solve. Some of the challenges in trying to adapt adventure games to a more complicated interface that allows more actions to be specified and performed would be on the usability of the system, controlling the actions permitted to solve a particular puzzle, and dealing with actions that could have negative consequences or leave the player in an un-winnable state. The more actions that are allowed and the closer that the game space reflects the real world the more complicated it would be to use and to specify the puzzles and permitted actions to solve them. Similarly, the more options the users have, the harder it is to keep them from ending up in a state where they have no options which would allow them to progress. And given the state of artificial intelligence, handling interactions with game characters representing people seems unlikely to ever approach real world complexity.
One way to get around some of these problems would be to develop an interactive world where the characters are all represented by users themselves freely interacting, and one in which the programmers can be constantly tweaking the system to allow more options and possibilities as the users explore the choices and ways to interact with the world. Such a model would be a further departure from the classic view of an adventure game a set of puzzles to solve in isolation, but given the success of online play for other genres it may be a direction worth pursuing.
Developing a broader and more general interface sufficiently simple to be easy to use and sufficiently complicated to allow interactions not necessarily conceived in advance by the programmer is a daunting task, but one which the technologies of today should be able to deal with. Modern adventure gaming has made good progress in representing complex logical and mathematical puzzles. The challenge for the future should be in representing lateral thinking puzzles which may have multiple solutions and require leaps of creativity rather than logical deduction. Adventure Games have come a long way since being represented by textual descriptions and combinations of verbs and nouns, and they have a ways to go still. Understanding the basic assumptions and choices made in the underlying semiotic space and their consequences is essential to continuing to evolve and improve the interfaces for the genre.
 Examples of text or parser based games include Mystery House™, developed in 1980 by Sierra™. Later parser games also included graphical aids to make identification of objects simpler and eventually allowed right-clicking on the graphical space to identify an individual object similar to using a verb to examine it. A parser game available online with enhanced graphics is based on The Hitchhiker’s Guide to the Galaxy, at the url: http://www.bbc.co.uk/radio4/hitchhikers/game/zclient.v7.swf
 The SCUMM™ engine using fixed lists of verbs was developed by LucasArts™ in 1987 and was first used for the game Maniac Mansion™. Maniac Mansion Deluxe, a freeware remake of this game featuring the interface is available at http://people.freenet.de/lucasfangames/maniac/games_eng.htm
 The three verb Sierra™ interface referenced was developed by Sierra™ in 1990 and was first used for the game King’s Quest V™. Freeware versions of games featuring this interface can be downloaded from http://www.agdinteractive.com/
 Examples of the single verb interface referenced include King’s Quest VII™ developed in 1994 by Sierra.
 The Myst™ interface mentioned was developed by Broderbund™ in 1993 and first used for the game Myst™ . The interface has largely continued in its present form up to a sequel released in 2004 with additional enhancements made to navigation, and built in support for collecting and recording information found in the game by taking pictures or writing notes.
“History of Myst” Published in the Tiscali.Games Journal.