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.
New Map and New Code
While progress has been quite slow (because life), I have made the jump from Inform 7 to LiveCode for development. The platform gives me much more flexibility and control. One of the big changes: think of the paths themselves as locations that are automatic pass throughs. This allows so much more customization based on environmental conditions.
Here’s the latest map.
Game Map
Changes are Coming!
This is just a brief update to mark the change from Inform 7 to LiveCode as the HWLN development platform. There are a number of reasons for the change, including greater programming flexibility and the ability to create executable files for multiple devices and operating systems from a single code base.
I’ll be posting code samples soon!
Building Updates
I’ve added the Powell House and Anderson’s Tavern interiors to the main map. Everard’s House will be added next.
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!
Timed Events that Vary According to Location
In the traditional sandbox-environment Interactive Ficton game, there are often puzzles to be solved through the discovery and manipulation of objects found in different locations in the game space. Keys to open locks. Code-breaking devices. Hidden treasures to placate or weapons to defeat enemies. In the Historical Williamsburg Living Narrative, the game play is somewhat different, primarily because the narrative is based on factual and well-documented events involving known historical figures. Entering locked rooms or discovering hidden passages, for example, isn’t as effective a way to advance the story, since the point of the game is to retell a story where the outcome is predetermined. To some degree, the player is more an observer rather than actual agent of change. That’s quite all right though, with interactivity being served by giving the player the ability to experience the story from different perspectives of time and place.
The narrative, then, is the main driver of game play, and in order to experience the game, the player needs to be in certain places at certain times. Unfortunately, it is the sandbox environment that challenges narrative integrity. For example, imagine that the player needs to overhear a conversation between two characters at a particular time and in a particular place. What happens if the player is in an entirely different location far removed when the conversation takes place? Here we see the need to provide latitude for the time and place for the occurence of events. Fortunately, creating a flexible framework to ensure exposure to relevant events is fairly straightforward.
The method is to determine a zone rather than particular location in which narrative drivers may occur, and then the actual event may occur after a particular time rather than exactly at that time. Finally, once the event has taken place, there needs to be a way for the game to track that so the event does not continue to trigger. The following code shows a way to handle this in Inform 7.
Here we see that the event is triggered if the time is after 5:08 PM (and not exactly at), as long as the variable placeevent has not been incremented from its initial value of 0. Once these criteria are met, the actual event occurs differently across six different locations. Finally, when the event takes place in one of two locations with the player there to witness it, the placeevent variable is changed.
This framework allows us to set up event conditions throughout the game (both in time and space), with enough latitude to ensure that the player experiences everything necessary to understand the game. The Historical Williamsburg Living Narrative is built on this foundation.
Inform 7 Extensions: Real-Time Delays by Erik Temple
Here’s a technical question I’m floating around several forums, so I thought I’d post here as well.
My scenario is simple. When the player moves from one location to another, I want a bit of travel description to be displayed before the new location name is revealed. That’s easy enough to do with the following code:
That results in the following output:
However, I want to pause momentarily after the first part of the description, before the location name come up (after the sentence, “Though the path is winding, it keeps heading generally to the south.”) To accomplish this, I’ve opted to use Erik Temple’s Real-Time Delays extension to Inform 7. Unfortunately, I keep getting an error. Below is the full code and the program output:
And here is the output:
The question is, what’s the cause of the Fatal Error? I’ve checked intfiction.org and elsewhere on the Internet, but I find nothing directly relevant. So I’ll put the questions to the readers here, and if anyone has a solution, please feel free to post it here or message me!
Game Navigation Structure Completed…
… for the most part, anyway!
I’ve completed the navigation structure for the game including all the exterior locations as well as building interiors. I’ll publish the release soon for backer downloading. Timing-wise, I’m heading to Williamsburg with the family to spend a week there over Christmas vacation. This will give me an opportunity to do more interior research for more interesting (as well as accurate) descriptions. In the mean time, below is the latest game map.
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.
A Sequential Calendar with Inform 7
The Historical Williamsburg Living Narrative depends on having an internal calendar so that days and dates may be tracked, thereby driving the narrative forward with some measure of historical accuracy. The story begins on April 20th, 1775, and what happens in the early hours of April 21st are key to the story. While Inform 7 has some built-in functionality to deal with the time of day, I haven’t found any functionality around tracking the days that pass. Specifically, I want to be assured that the day and date change when the time crosses midnight.
To deal with this, I developed a little bit of code logic to handle the passage of time from one day to the next. One of the key things I discovered about Inform 7 is that its day marker is at 4:00 AM rather than at 12:00 AM. Once that is understood, writing the code depends on a three-way conditional rather than a two-way version. The following code can be modified for your specific needs:
The code is generic, so you can alter to adjust for your needs. I’m using a version that’s only very slightly modified to meet my game needs.
If anyone has a more elegant solution (or knows of an existing Inform 7 command that might help), please drop me a line!
EDIT: I’m using time spans rather than a specific time (11:59 PM) to check the state because the player character may be asleep from before 11:59 PM to well after.
Historical Williamsburg Living Narrative 