I was introduced to the Colossal Cave Adventure game in 1980 when I got my first “real” job at an engineering company. The game was one of the installed pieces of software on the company’s Data General Eclipse mini computer. Soon after I started working there (spending countless after hours with coworkers exploring twisty passages), I purchased a TI 99/4A home computer, and I discovered Scott Adams’ series of text adventure games. Of course, I played them as quickly as I could get my hands on them. When I got my first IBM PC, I also got my first Infocom game (Deadline), which introduced me to a more sophisticated parser – to go with the greater computing power – and the idea that Interactive Fiction was more than simply text-based puzzles to be solved. The narrative was an integral part of the game experience, so the way in which things were described was just as important as the rooms that could be explored or the objects that could be examined. As the Infocom games came to tell more complex stories (anyone remember A Mind Forever Voyaging?), the narrative gulf between the new games and Colossal Cave became quite evident.
Working on the Historical Williamsburg Living Narrative, I am keenly aware of the need to provide narrative variation throughout the game, and it is especially important for continuity in the player’s actions. For example, when coming to a particular location for the first time, it makes sense to describe the experience:
“You approach the castle with a sense of awe at the scope. The walls tower over you as you slowly approach the massive iron gates. The construction effort for the outer walls alone must have taken years!”
While the above text might make sense upon first reading, seeing the same text over and over would greatly diminish the sense of reality and continuity in the game environment. Fortunately, Inform 7 provides built-in coding constructs to handle these situations.
The simplest situation to deal with is in visiting the same location multiple times. Inform 7 allows the application of conditionals that track the player’s location history:
[if unvisited]Write initial description here.[end if]
[if visited]Write subsequent description here.[end if]
While this takes care of a majority of situations, there are times when you may want to alter a location description based on whether or not the player has already visited a diffent location in the game. Let’s look at a situation based on a section of the actual game map.
For this illustration, we will focus on what is happening in the Capitol building desriptions. The Capitol is one of the main structures in Williamsburg, and it has appeal to the player character as part of the storyline. Accordingly, there should be some sort of acknowledgment of this in the description when the player encounters the Capitol. Using the [if visited] and [if unvisited] constructs apply only to the actual game locations, and this can be problematic in situations where there are more than one entry pont.
Notice that there are two entry points for the Capitol: the “Capitol Entrance” and the “Capitol Rear Entrance.” When the player first reaches either one of these locations, there should be a sense of excitement at seeing the Capitol. However, both locations need to “know” if the player has been to the other location, otherwise both the descriptions will portray that first-time sense of excitement, and that will be very narratively inconsistent.
Typically, the Inform 7 code might look like this:
The Capitol Entrance is a room.
“[if visited]This is the Capitol Entrance. You have been here before.[end if]
[if unvisited]You have never been to the Capitol before! Amazing![end if]
The problem with this approach is that the player could have already come to the Capitol from the Capitol Rear Entrance (and indeed even walked right through to the Capitol Entrance), which would make this description sound quite out-of-touch! Fortunately, Inform 7 gives you the ability to filter location descriptions based on what other locations have been visited or not visited. Something like this would be a start:
The Capitol Entrance is a room.
“[if visited]This is the Capitol Entrance. You have been here before.[end if]
[if the Capitol Entrance was not visited and the Capitol Rear Entrance was not visited]You have never been to the Capitol before! Amazing![end if]
[if unvisited]You have never come to the Capitol from this entrance.[end if]
There are three possible states represented above:
- The player has been to the Capitol before, and it was through this entrance. Therefore, there should be no initial reaction to entering the Capitol itself, or to encountering this particular location.
- The player has never been to the Capitol through this or the other entrance. All the “surprise” should be expressed here.
- The player has never been to this location, but the player has entered the Capitol through the other entrance. There should be the first-time reaction to this entrance but not to the Capitol itself.
You can begin to see the potential complexities in building a consistent narrative when dealing with a fairly complex game structure. There are many locations with multiple entry points, and the same process will need to be considered when encountering people or even objects for the first versus subsequent times. There are any number of ways to keep track of the narrative flow, and my primary tools are maps and spreadsheets. This, however, just scratches the surface of considerations for the location descriptions. Think about how descriptions may change depending on what other non-player characters have been there first, the time of day, or even the weather.
Clearly, we need to build a game timeline and make use of the appropriate variables as we move forward.
Note: As I write this entry, my family and I are in Colonial Williamsburg. (Yes, I am doing game material research while I’m here…) We will be enjoying Christmas dinner in Christiana Campbell’s Tavern (on the far east side of the map). So from my family to you and yours, may you have a very Merry Christmas and a Happy New Year!
One of the great joys of playing Interactive Fiction games is in the discovery and exploration of the physical space or actual play environment of the game. Years ago when I played the Colossal Cave Adventure for the first time (on the Data General Eclipse computer at the office after hours), I delighted in drawing maps for all the locations and paths that were available. When I got to the maze area, where room exits looped back into the same room, the value of the mapping process became very clear. Those skills were well utilized as I grew into the Scott Adams adventure games, and later the collection of games from Infocom. Sketching out the location boxes with their associated path connections became second nature as a necessary Interactive Fiction player skill. (I am often surprised when I teach Interactive Fiction to college game design students, how few of them already know or readily develop the map-making skill set.)
Developing maps for IF is a slightly different process, though, that requires more than drawing boxes with interconnecting lines. There is the idea of location scale and relative size in IF games, and the developer needs to make some important decisions before committing to computer code. Locations are not all uniform in size (when we imagine our settings), and logical layout is not the same as physical layout. When dealing with fictional settings, there is some latitude for interpretation (though the good designers have a very clear picture of their environment before starting to code). However, there is no room for creative interpretation when attempting to recreate historical settings with absolute fidelity to the historical reality.
That’s our situation with the Historical Williamsburg Living Narrative. A large part of the questions could be framed around geographic granularity: as we build the maps, what is the smallest unit of measurement we should be using? (A square yard seems reasonable, actually.) There will be the typical Interactive Fiction flex in the maps; for example, walking down one side of a street may result in more “stops” along the way than walking up the other side. That would have much to do with the buildings or other pathways located on each side. But the point is, we need to make consideration of the space or area that needs to be “reserved” for game locations in which action may (or may not) take place.
I’m making my sketches now, and that will be one of the first pieces of the game that will be ready for review (we may even put that up on Playfic for people to try out). Do you have any suggestions regarding map making? Is that something you enjoy doing? If you’d like to contribute in some way on this (or any other) piece of the project, please drop me a line.
And don’t forget to check out the Historical Williamsburg Living Narrative Kickstarter project.
The screen shot above is from the Infocom game Hitchhiker’s Guide to the Galaxy (based on the series of books by Douglas Adams). I was a big fan of the Infocom games “back in the day,” and having also read the Hitchhiker’s series, I especially enjoyed this one; at least after I figure out how to put the Babel fish into my ear. Infocom was a company that specialized in what they termed “Interactive Fiction,” that is, text adventure environments written in sophisticated prose format. (Infocom was the company that produced the Zork series of games.) There are a number of reasons that Interactive Fiction is an ideal game format for the Historical Williamsburg Living Narrative project, which I’ll cover in later posts, but now I’ll just briefly cover a little of my own history with the format.
My first encounter with text adventure games (before they were called Interactive Fiction) was back in the fall of 1980 when I got a job with a communications engineering company. The company ran a Data General Eclipse minicomputer, and one of the programs on it was the original Colossal Cave Adventure program written back in the late 1970s. Several of us in the office would stay quite late to sit in the terminal room and explore the virtual world, asking each other for help when the puzzles were particularly challenging. We all spent a fair amount of time typing one- or two-word commands at the cursor hoping we were on track to unravel the puzzles sprinkled throughout the game. Soon after that, I purchased a Texas Instruments TI-99/4A computer, and I was delighted to find a whole series of adventure games by Scott Adams.
It was late in 1981 when I acquired my first IBM PC that I also got my first game for it: Deadline by Infocom. Infocom has developed a natural language parser was also able to “understand” short sentence input rather than simply two-word phrases. It was then that my taste for text adventures, that is, Interactive Fiction grew to the point where I began to write my own. The language available to me on my PC was BASIC, and I wrote thousands of lines of procedural code to build my games. Over the years I’ve used BASIC, Pascal, C, C++, Lingo, Java, and even LISP to build my games, and I’ve continued to experiment with my own parser systems and Interactive Fiction scenarios.
Several years ago, I discovered the Inform software (currently Inform 7) development system. Inform is an environment specifically design to author Interactive Fiction. The language of Inform is set up to support the conventions of Interactive Fiction, which makes it easier to program these types of game. For example, if I wanted to set up a space where there was a Kitchen and a Dining Room, with the Kitchen to the north, I would enter into the Inform 7 engine simply:
> Kitchen is a room.
> Dining Room is a room.
> Dining Room is south of the Kitchen.
At that point, when I run the program I find myself starting out in the Kitchen location. If I then type “s” (for south) at the prompt, I see that I have moved into the Dining Room–and I can type “n” to move back to the Kitchen. Of course, the Inform 7 programming environment supports much more than moving around virtual locations, but the exciting thing is that it takes care of the programming underpinnings while the author/programmer can focus on the logic of the game itself. That is very appealing. One can relatively easily create objects to be manipulated, characters with which to interact, and so on.
The simplicity of the Inform 7 development environment is one of the reasons I’m excited about using it to develop the Historical Williamsburg Living Narrative. I’ll be able to develop and implement my “map” of Williamsburg fairly quickly, and building in the location descriptions and character interactions will be a lot easier than it was when I used more general programming environments. That means I’ll be able to spend much more time in building narrative depth into the game play, and that’s ultimately what makes the Interactive Fiction format so engaging, even though it’s only text on screen. Sometimes graphics gets in the way of imagination; Interactive Fiction is the perfect way to drop the reader into the action of the story and really bring the words to life.