Archive
The Problems with Paths
Navigation is a fairly straightforward process in Interactive Fiction, and it can be implemented in a number of ways, depending on the authoring system you are using. With Inform 7, which is a powerful yet relatively simple plain-English system, you can create a path between two rooms very easily;
The Library is room
The Parlor is south of the Library.
The code above immediately creates a room/location called Library. The a second room is created in a relative position, south, from the first room, and the second room is call Parlor. Since Inform 7 manages the room relationships, when executing the above snippet will have you “starting” in the Library, and you will be able to go south into the Parlor, and then north again back into the Library simply by typing “south” and then “north” in the automatically provided prompts.
This is one of the advantages in using Inform 7 when creating your game, as the system manages all location relationships (among other things). In this way you can create a fairly complex geographical space which to explore, without having to do a lot of work setting up variables, arrays, conditional statements and so on.
Unfortunately, this kind of high-level ease comes at the price of less granular control and flexibility over what can be done in the program. One of the functions that Inform 7 does not provide (without creating extensions) is the ability to think of paths between map locations as “locations” themselves, with their own descriptions and attributes. Additionally, paths should have different descriptions based on the direction of travel. Using an typical programming language this can be implemented straightforwardly through the use of arrays.
In order to add this and other functionally to the project, I decided to move the program from Inform 7 to the LiveCode language (an open source version is available). I selected LiveCode because of it’s robust built-in text processing functionality, which means the parser that I build can easily identify words and phrases without having to do any character counting. LiveCode is also loosely typed, so I can deal with variables much more easily.
Using LiveCode, I’m able to conceptualize paths as locations, yet I’m able to have the program “pass through” without stopping or identifying the paths as specific places to stop or break the action. This means I can leave one building to cross the street to the entrance of another building, and action can take place in the street along the way. Consider the mini-map below.
There are two locations here. Location 37 which is west of Location 19. There is a path between the two, which you may assume is bi-directional. So if I were in Location 37 and typed “east” as my command, I would be taken to Location 19. It might look something like this in my display:
You are in Location 37.>> west
You are in Location 19.
Certainly I could change the description of Location 19 to include a little bit of travel observation, such as:
You are in Location 37.>> west
You walk across the rough grass to Location 19.
But this introduces more programming complexity. First, what if I could enter Location 19 from the north and the south as well? At that point, adding the path description into the location description would not make sense.
Instead, in LiveCode I am able to create another array that keeps track of path descriptions and other attributes. I can use the format:
aPath[x, y, z]
Where aPath is the array name, the variable x is the initial location and the variable y is the destination location. The variable z can be used for a number of attributes such as the path description, path status (if there is an open or closed door), etc. For example:
aPath[37, 19, 0]
would signify the path description when moving from Location 37 to Location 19, and reversing the direction would yield a different description:
aPath [19, 37, 0]
There is quite a bit more that can be accomplished with this separate path designation, including allowing players to find or leave objects on paths, encounter non-player characters, experience different weather conditions, and find barrier puzzles that need to be solved. From my point of view, it’s much easier to manage this through LiveCode (or any other high-level language) rather than using Inform 7, which makes certain assumptions as to how Interactive Fiction should work.
Narrative Variation in Interactive Fiction
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!
Latest Williamsburg Game Map
I’ve been working on updates to the building interior locations. This map reflects the latest navigation scheme. I’ll have the next playable release available to Kickstarter backers up shortly.
Latest Playable Release – HWLN12
This report recently went out to all of the game Backers on Kickstarter. The actual download location is available only to the Backers.
**********
Greetings, Backers!
I new version is available for download at [URL HIDDEN]. Included in the .zip archive is a map of the locations.
A quick word about the map: where you see the location names highlighted in blue, the blue portions indicate a shortcut in the game navigation system (meant for speedier play testing only). For example, on the map is the “Military Encampment” location with the word “Military” in blue. When you are playing the game, type “xmilitary” at the cursor and you will be immediately taken to the Military Encampment. This will work for any of the locations in blue.
A big “thank you” goes to backer Vivianne D. for her work on the navigation code in Inform 7. Now when you type “dir” at the cursor, the game will display all possible directions (unless specifically hidden) based on room relative location definitions. Previously, I had been hand coding all those directions.
Otherwise, changes in this version are not major. Cleaned up more descriptions, added some detail, etc. Feel free to play it and let me know what you find.
In an upcoming release I will be publishing a guide that provides a listing of the possible commands.
Hap
Interested in getting started with Interactive Fiction?
If so, this primer by Andrew Plotkin will give you an introduction. The handy-dandy reference card is especially helpful.
Latest Playable Version
A quick update: there is a new playable version of the game available for backers of the original Kickstarter project. Here’s what I shared in a message to the backers (removing the access instructions for the actual game).
This version includes some minor navigation/map description updates. The main change here is in the addition of some non-player characters (NPCs).
The NPCs are implement in a very basic capacity, and they are not in their final game locations. Dialog is limited, but you can test them out using the “ask [character] about [noun]” format. You will find:
- a farmer – in the Palace Green. You can use the command “ask the farmer about Anderson’s” when you encounter him to see what happens.
- a cordwainer – ask him about shoes when you find him.
- George Wythe (no dialog)
- Thomas Jefferson
- Patrick Henry
For Jefferson, Henry, and the farmer, there is additional dialog, but I won’t say here. It’s not likely you’ll be able to guess what to ask them about (though if you know Williamsburg histry you may be able to figure it out). Don’t worry about that, as the context of the game events will give you clues/hints.
In the meantime, if you do playtest (or even if you don’t), feel free to let me know what kinds of things (nouns) you might ask about and expect to get some sort of answer. Your feedback will give me good player’s perspective.
More NPCs will be added, along with greater dialog vocabulary. Other considerations will be making dialog dependent on time of day, location, and even what the player may have learned from other characters or in discovering certain things about the environment. NPCs will not be “stuck” in the same location, and the time of day will determine where they are.
The Game Begins: First Screens
Progress on the Historical Williamsburg Living Narrative continues. Three plot-level releases are planned: a walk-through version focused on the Williamsburg physical layout, an exploratory version including interaction and discovery with historical characters, and narrative version that is constructed around the removal of the gunpowder supply from the magazine.
The following two screenshots represent what the player will first encounter regardless of the version of the game being played. First is the pre-game opening screen that appears before the player provides any input. As you can see, it sets up a little bit of the story framework by providing some background on the player character and context on how he comes to be in Williamsburg.
The second screenshot depicts the description the player gets the second time this location is visited. (The first version of the description has some additional information and is displayed as soon as the player presses the Space bar at the intro screen.) As you can see, the command “see” was entered after the text description. The way the HWLN game is being implemented, graphic images will be provided at many locations; however, in order to display the images, the player must enter the “see” command at the prompt. The images themselves are based on my actual photography of Williamsburg.
A Starting Screen
While I’m doing Glulxe testing, I thought I’d take one more screen shot of the game, this one all text. This is right after the game intro screen comes up, and the player presses the space bar to get into the game proper.
You’ll notice the first command issued by the player is followed by more descriptive text. “More” is a custom command I’ve added to the system that displays more detailed information about the location surroundings. Ultimately, it’s all to help the player make sense of the game.
Graphic Enhancement to Traditional IF
The Interactive Fiction I grew up on (starting with the Scott Adams text adventures that I got in cassette form for my TI 99/4A computer) was all text based. No graphics at all; just two-word phrases that eventually turned into more sophisticated Infocom game sentences, but still words only. In fact, one of my favorite computer game ads was the Infocom print ad that said something to the effect of “We stick our graphics where the sun don’t shine,” and then there was a picture of the human brain. Pretty clever, and you can see it here.
One of the characteristics that makes Inform 7 so appealing as an IF development environment is that it allows a person to rapidly put together an IF game in the form of those old Infocom games: a pretty robost parser that allowed for sentence input. However, Inform 7 has made a number of improvements to the output it produces, compared to the earlier Infocom games. One of those improvements is the ability to integrate graphic images into the Inform code for display when someone plays the game.
I’ve decided to take advantage of this feature during development of the Historical Williamsburg Living Narrative. I’ll be using the photographs I have taken of Williamsburg, and I’ll have the photographs changed into a more comic-like illustration. Below is a sample of the Capitol Building already having gone through the image processing.
As you can see, the photograph has been altered to appear as more of an illustration. I’ll do this for all of the photographs to be used in the game. Please share your thoughts: do you like this approach to Interactive Fiction? Or does IF need to be more “old school”?
Historical Williamsburg Living Narrative 