The world inside our adventure game is very simple, containing only three locations. Let’s first create a top-level variable, *nodes*, to contain descriptions of the locations that exist in our game:

(defparameter *nodes* '((living-room (you are in the living-room.
                            a wizard is snoring loudly on the couch.))
                        (garden (you are in a beautiful garden.
                            there is a well in front of you.))
                        (attic (you are in the attic.
                            there is a giant welding torch in the corner.))))

This variable contains a list and description of our three locations. In essence, the *nodes* variable basically gives us a way to find a piece of data associated with a lookup key. In this case, the key is the name of the place (living-room, garden, or attic), and the data is a text description of the scenery at that place. This type of structure is called an association list, or alist for short (alists are covered in greater detail in Chapter 7).

One thing is rather unusual about the definition of this *nodes* variable: Even though it contains descriptions of the various locations in our game world, it does not actually contain any text strings. Since Common Lisp has a string datatype, we could have written descriptions using quotes. For instance, we could have written "You are in a beautiful garden. There is a well in front of you." Instead, we use more fundamental datatypes—symbols and lists—to encode this information.

Why wouldn’t we just use strings? As I mentioned at the beginning of this chapter, the manipulation of text is not really a fundamental computing concept. In this game, we’ll manipulate the messages displayed to players based on their interaction with the game world in complicated ways. For most real-world programs, the information you’ll generate as output (such as HTML, PDFs, or even richer graphical formats) will probably be far more complicated than just simple text.

By keeping your source data structures free from assumptions regarding the output format from the start, your coding can take full advantage of your programming language. Since the easiest things to manipulate in Lisp are symbols and lists, most experienced Lispers will try to focus on these datatypes in the design of their software whenever possible. So, we will stay away from strings in our design. (In the next chapter, we will translate these lists and symbols into properly formatted text.)