I’ve added the Powell House and Anderson’s Tavern interiors to the main map. Everard’s House will be added next.
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!
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.
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!
… 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.
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.