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.
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.
Revised Game Map
I’ve revised the game map slightly from the last published version. In this new map, there are some altered and additional paths between locations. Also, several of the buildings (represented by red squares) have interior rooms, providing more locations for exploration. These buildings are marked with the light blue circle around them. This map is being implemented in version 11 or the test program. I’ll have that version published soon for the HWLN Kickstarter backers.
Streamlined Williamsburg Map
In my last blog post (Fun with Maps) I discussed the complexities around map development for Interactive Fiction, especially given the design tension between maintaining historical accuracy and fostering engaging gameplay. During my most recent trip to Williamsburg last September, I found that the Colonial Williamsburg Foundation helped address the map dilemma by issuing a simplified version of their visitor map. This is the visitor map that is currently being published (along with the daily events in the colonial city area).
I took this map and eliminated the extraneous information based on the actual game and story requirements. That gave me a very clean map from which to work. You can see that this map provides a layout of the relative positions of buildings, the streets they are on, and distance information.
Using this clean map, I marked the positions of the buildings and other navigation junctures that would be needed in (this version of) the game. Then I connect the locations where I wanted pathways, so that I could visualize the compass headings to use in terms of game commands. (You can see the blue lines connecting the red and green squares.)
Finally, I pulled the background out in order to have the unadorned map to use in building navigation functionality within Inform 7.
The red boxes represent buildings or structures that have further navigation within, while the green boxes are simply outside locations. Using this map, I was quickly able to create basic navigation in Inform 7, and I am using the map as a location checklist for the location descriptions. (Additionally, I am creating the logic in Inform 7 to handle multiple stops at the same location, and requests for more information regarding locations.
In addition, this map allowed me to visualize some navigational shortcuts to help with the flow of the game. For example, I’ve created a custom command “street” that functions at many of the building locations on the Duke of Gloucester Street (that’s the main street running from the College of William & Mary in the west to the Capitol Building in the east). When a player is at the entrance of one of those buildings, using the “street” command will take the player to one of a number of unmarked positions on the Duke of Gloucester Street, between the two cross streets that apply to the building where the player is. From the unmarked position, the player can see the buildings up and down between the cross streets and choose to navigate directly to any of them. These unmarked positions on the Duke of Gloucester Street are not accessible through standard compass-direction navigation.
Within the next week or two, I’ll have a robust version of the game navigation completed in Inform 7 and available for download to the original Kickstarter backers.
Fun with Maps
Maps are essential to many Interactive Fiction games, especially those that involve activity in various locations. Interactive Fiction game maps that deal with real locations, however, are challenging to implement, as there is a trade-off to be had between realism and playability. If the design is meant to represent the physical layout with utmost fidelity, the details of the map can potentially slow down and frustrate game play as the player is forced to move from one seemingly meaningless location to another in order to get to the desired destination. It’s similar to the counterpoint between a flight simulator and a flight game–the realism of a true simulator can be very boring, unless it’s the simulation itself that interests you.
Likewise, the conflicting visions of the HWLN: is it a simulation of the physical layout of Williamsburg as it was in the months leading up the signing of the Declaration of Independence, or is it a game about the events taking place during that time? That conflict plays itself out everytime I return to the map and struggle with the appropriate level of detail to include. I’ve been wanting the game to be both, but that may not be the wisest choice for the HWLN as a game.
Part of the challenge was addressed in part by the new daily maps published by the Colonial Williamsburg Foundation for visitors. The new map (show in the picture above) is actually a streamlined version of an earlier visitor map which you can view here. The older map is much more detailed, and perhaps in the Colonial Williamsburg Foundation’s thinking, it was not as user friendly. Whatever the case, the new map gives me a good template for a more streamlined game map, on which I am currently working and will implement at least initially in Inform 7.
So for the sake of playability, I’ll work with a less detailed map. But at some point, as an exercise in modeling an accurate picture of history, I’ll return to the “high resolution” version in order to satisfy my inner purist.
Historical Williamsburg Living Narrative 