How Do Text Games Work?

That's a good question. And there are many answers, all of which are correct to some degree, but each of these possible answers will have some factors in common. First, the interface to the game will be a bi-directional, text-only communication channel. This means that the computer will only have text to say what it wants to say and, similarly, the player can only dictate his input with text likewise. Also, there are no joysticks, mice, flight sticks, or light pens. Second, the game will consist of some kind of "universe" whether it is the old west, an apartment building, or a space station. But this universe will consist of geometry, descriptions and rules. The geometry is the actual geometry of the universe, the size and placement of the rooms, hallways, ponds, or whatever. The descriptions are the actual text that can be called on to describe what a location looks like, sounds like, or smells like.

The rules of the game are the things that can and can't be done. For example, you may not be able to eat a rock, but you can eat a sandwich. Once the geometry, descriptions, and rules of the game are in place, then the data structures, algorithms, and software to allow the player to interact with the environment need to be created. This will consist mainly of an input parser. The input parser is responsible for translating and making sense of the player's input. The player will communicate to the game using standard English words. These words may create complete sentences, small phrases, or even single commands. The parser and all its components will break the sentence down into separate words, analyze the meaning of the sentence, and then execute the appropriate functions to make happen whatever the player was asking for.

There is one catch here. The computer doesn't understand natural language and giving it a complete understanding of the English language is a Ph.D. thesis at the very least. As game programmers, we just want to give the player a subset of the English language and impose a few rules about how sentences are constructed. For example, the game you will see later today is called Shadow Land and has a very limited vocabulary. It can understand only the words in Table 14.1.

Table 14.1. The Vocabulary of Shadow Land

Word	Used As
LAMP	Noun
SANDWICH	Noun
KEYS	Noun
EAST	Noun
WEST	Noun
NORTH	Noun/Adjective
SOUTH	Noun/Adjective
FORWARD	Noun/Adjective
BACKWARD	Noun/Adjective
RIGHT	Noun/Adjective
LEFT	Noun/Adjective
MOVE	Verb
TURN	Verb
SMELL	Verb
LOOK	Verb
LISTEN	Verb
PUT	Verb
GET	Verb
EAT	Verb
INVENTORY	Verb
WHERE	Verb
EXIT	Verb
THE	Article
IN	Preposition
ON	Preposition
TO	Preposition
DOWN	Preposition

The vocabulary of Shadow Land is very small, but you would be surprised how many legal sentences can be constructed. The problem is making sense of these constructions using some general algorithm. This process is called syntactical analysis and is very tedious and complex. Entire books have been written on how to perform syntactical analysis, such as the infamous "Dragon Book" by Aho, Sethi, and Ullman. We don't need (want) to make things too complex, so we will force rules on our vocabulary that create a little "language." This language will be the one that the user must abide by when constructing sentences.

Once the user has typed something in and the game figures out what he/she is trying to say, then the game will proceed to bring the request to fruition and the game will output the results. For example, if the player asks to "look," then the game will access the universe database along with the current position of the player. Together this data can be used to print out the general description of the room, which may be static. If there are movable objects within the game, then there is as a second phase of description. The game logic would test to see if there are any objects within the field of view of the virtual character and then print them out. However, when the final description prints out, it must seem fluid and not choppy. For example, the game software should first test if there are any objects in the room and, if so, make note of it and slightly alter the last sentence of the static description to have a conjunction like "and" so that the objects when listed don't appear from nowhere.

As an example, a room may have this static description:

…You are surrounded by tall walls with Roman art hanging upon them.

And let's say that there are moveable objects in the room, such as a plant. Then the computer's response might be

…You are surrounded by tall walls with Roman art hanging upon them.

There is a plant in the East corner of the room.

A better algorithm for printing out descriptions might take into consideration that there is a moveable object in the room and then print the description out like this:

…You are surrounded by tall walls with Roman art hanging upon them and there is a plant in the East corner of the room.

Although the sentence is slightly artificial, rough, and the computer wouldn't know the difference between a plant and a ogre, at least the sentences are somewhat connected together. This is one of the "tricks" in making good text games. You must "work" the output sentences to make them read as if they aren't being printed out from a static database.

Of course, there is more than parsing the text and trying to satisfy the request. The game must have some kind of data structure to represent the universe and the objects within the universe. This representation, whatever it may be, must also have some kind of valid geometrical coherence because as the player moves around, he/she will expect to find a key where he dropped it. This means that many times the universe will have to be modeled as a 2D/3D vector map or cell map so that the player can be moved around in a data representation that has some geometrical relation to the virtual space the player thinks he's in. Next the game has to have some kind of structure that contains the "state" of the player. This could mean his health, position, inventory, and position in the game universe.

Finally, other aspects of the game have to be implemented, such as a goal and the enemies (if there are any). The goal may be as simple as finding an enchanted chalice and putting it somewhere. Or the goal may be as complex as solving some kind of puzzle with a question and answer dialog between the player and some creature in the game. The creatures in the game will be implemented as data structures only; however, these data structures can move around the universe data structure, move objects, eat food, and attack the player (possibly). All these aspects of the text game must be implemented in a way so that the illusion of a real environment is upheld. This means that you should assume that the player can't see the game, but everything better make sense or else!

Let's re-iterate all the components of a text game by studying Figure 14.1. Referring to the figure, we see that there is an input section that parses the player's commands and then tries to execute these commands. The parser only understands a specific vocabulary and, furthermore, the sentences created with this vocabulary are limited by the "language" designed by the game designer. Next there is a set of data structures holding the representation of the universe, the position of the objects, the description strings for sights, sounds, and smells. Also there is the representation of the player and his inventory along with the representation of the enemies in the game. Finally, there are a million or so functions, rules, and little details that make it all work, let's cover a few of them!