In this series of posts I'll share my experiences creating an old-style text Adventure game, adapted somewhat for the 21st century. Here in Part 1, I'll review the original Adventure and why it was such a ground-breaking development. Then I'll go over the design of my own game, called Roman Ruins adventure.
In subsequent posts I'll show how this game is implemented for Alexa as a voice skill, and for Twitch as a mini-game extension.
Adventure, the First Interactive Fiction
As I recently blogged, I love games—but mostly retro games. In high school—before personal computers—we were fortunate indeed that Suffolk County owned a
DEC PDP10 timesharing machine and allowed schools in the county to connect to it via teletypewriters over modems. Thus, my first computer experience was this:
No screen, just teletype output on a paper roll. We didn't even have lower-case letters. All pouring out at the dismally slow speed of 110 baud. I'm sure this seems extremely limiting to anyone who is not a baby boomer, but as it was my first computing experience I was all over it. I got my foundation in computing basics this way (and it was far superior to college, where they were still having us punch cards!).
ADVENT, or
Colossal Cave Adventure, was a game that had been developed by Will Crowther and Don Woods for the PDP-10. It had become popular among PDP10 installations and was making the rounds; not on the Internet, but via its predecessor, the ARPANET which had a much more limited audience.
Adventure was different from other computer-based games of the time: it described a world and you the player had to explore it. You decided what to do, and your actions had consequences. Will Crowther had based his Colossal Cave Adventure on actual cave exploration he had participated in. As this "book" unfolded, you the player made decisions that changed the narrative. That's why this is considered the first example of
interactive fiction.
Adventure was one of those "a minute to learn, a lifetime to master" kind of games. You enter text commands, and an English language description told you where you were and what was going on:
You are standing at the end of a road before a small brick
building. Around you is a forest. A small stream flows out
of the building and down a gully.
You typed one or two-word commands to Adventure. For example, you could move around with NORTH, EAST, WEST, SOUTH, UP, and DOWN. There were only a handful of commands to learn.
> EAST
You are inside a building, a well house for a large spring.
There are some keys on the ground here.
There is a shiny brass lamp nearby.
There is tasty food here.
There is a bottle of water here.
Some "rooms" of the adventure contained objects. You could GET or TAKE an object, which would then come along with you as moved to different rooms. You could likewise DROP an object, leaving it in your current room. You could use INVENTORY to get a list of what you were currently carrying.
> TAKE LAMP
Ok.
> TAKE FOOD
Ok.
> INVENTORY
You are currently holding the following:
Brass lantern
Tasty food
Some objects were essential: carrying a lamp might allow you to see in a dark place. Some areas of the game were tough to navigate. Adventure is famous for having ten rooms with an identical description. Upon closer examination, each room has a slightly different description and a careful player can make a map to get through the area. Once that's done, navigation is simple. Another technique is to leave an object in each room.
You are in a little maze of twisty passages, all alike.
As you played the game, you also discovered puzzles to solve and adversaries to deal with. For example, dwarves are troublesome and can kill you or prevent you from moving past them. A novice player might remember encountering food and be tempted to offer it to the dwarf—only to learn something important about dwarves:
> GIVE FOOD
You fool, Dwarves eat only coal! Now you've made him *REALLY* MAD!!
In this manner, by exploring and experimenting, the player learned what was where and what the rules of the road were. There was an artistry in the way places were described: paying attention to descriptions often paid off. Humor and the unexpected were to be found as well.
The limited computer interfaces available at the time didn't hamper Adventure at all, because all the magic happened in your imagination, just like a book.
Adventure Game Derivatives
Adventure Games were a big deal in the 1980s. Several companies produced Adventure games commerically. I remember my brother Lee spending a lot of time with the ZORK games from InfoCom.
Zork III: The Dungeon Master
As the years progressed, there was less interest in the textual Adventure games. Home computers and home game consoles were getting powerful and computer interfaces more sophisticated. The focus was on graphics, color, and sound.
The idea of Adventure Games, though, never stopped being relevant. Many, many games today include similar elements of exploration. For example, the Adventure-style commands are quite apparent in Indiana Jones and the Fate of Atlantis (1992):
Indiana Jones and the Fate of Atlantis
On the original XBOX, I enjoyed Indiana Jones and the Emperor's Tomb (2003). The graphics were sophisticated, the action was controlled with a game controller, and there was a lot of action movement and fighting along the way. But still present were those original ideas from Adventure: a world to explore made up of different rooms; objects to take and use at the appropriate moment; puzzles to solve; and treasure to find.
Indiana Jones and the Emperor's Tomb
I've never played
Dungeons and Dragons myself, but I'm aware that many games today have combined elements of that as well as Adventure. That often means a painstaking amount of detail goes into every aspect of the game. Take a look at how detailed the inventory is in Elder Scrolls V: Skyrim.
Skyrim
Adventure in Modern Times
Adventure in its original form may be little-known to younger people, but it hasn't been forgotten. There's a documentary on the history of interactive fiction games called
Get Lamp on YouTube by Jason Scott.
You can still play the original adventure today. The AMC Halt and Catch Fire site has an area where you can
play the original ADVENT on the web.
You can even play ADVENT
via SMS by texting this number: +1 (669) 238-3683.
Believe it or not, the original textual game format still has a loyal following. There's even new game development going on, such as 2018's
Alias "The Magpie". Adventure has left quite a legacy.
Alias 'The Magpie' being played on Twitch
My Adventure: Roman Ruins
Given all these fond memories, I decided recently that it was high time I created an Adventure game of my own. I thought to start with something very similar to the original Adventure, then find places where that kind of textual interface made sense in modern times. One idea that occurred to me is the popularity of voice assistants such as Amazon's Alexa: the original Adventure game format fits that mode of communication perfectly. Adventure would also make a nice mini-game, for example a Twitch Extension.
I gave myself one week in which to design a game, implement it for both
Alexa and Twitch, and submit them for approval (a second reason I'm doing this is to get experience writing Twitch Extensions). Happily both were approved this morning, which is why I'm starting to blog about them. That being said, I'll readily admit a lot more could be done to extend the game and polish the implementation.
Roman Ruins on Alexa
Roman Ruins Adventure mini-game on Twitch
Game Design
I decided I would write my game in TypeScript (which transpiles to JavaScript). JavaScript can be run in a huge number of places today, including web browsers and Node.js. But before implementing anything specific I would need to design the game itself.
The program code of a textual Adventure game doesn't tend to be very large or complex: when these games were first created, available memory was limited. Minimally, for data you need an array of rooms, an array of objects, and a handful of variables to keep track of your current room and the state of game puzzles (obstacles and adversaries). Commands are simple phrases such as NORTH, LOOK, INVENTORY, TAKE LAMP, EXAMINE BOTTLE, or GIVE FOOD.
Where the real work lies is in the game data. You've got to come up with a world and describe it well with interesting writing. You've got to decide what rooms there are, what directional connections there are between them, and what objects are placed where. You've go to come up with an objective, and there need to be puzzles to solve in order to get to that objective. You've got to craft a narrative that is helpful but not too helpful. Lastly, humor and learning-along-the-way is a hallmark of Adventure games.
For the setting for my Adventure game, I reflected on a
cruise tour of Europe my wife Becky and I took last year for our 25th anniversary. We were particularly impressed with the well-preserved city of
Pompeii. I decided I would make my world the ruins of an ancient Roman city, using what we had seen of Pompeii as a model. Plus, I had pictures of Pompeii which might be useful in some game interfaces.
The first thing I needed was a room map, describing the rooms (places) and how one can move from one room to another. Without giving away too much about the game, below is a partial look at my initial map of ground level. The player would start at the South Gate. By paying attention to descriptions and experimentation, he or she would soon learn they could go north to get to a gladiator's field; then east to reach an amphitheatre; and then north to get to a main road. The main road could potentiall leads to a nunber of interesting areas, such as a Roman house or a temple or a public baths. The player might or might not have noticed a statue to the north of the gladiator field, which might or might not become important later on.
Partial Room Map - Ground Level
Just as Will Crowther used his actual experience exploring caves to guide his world design in Colossal Cave Adventure, I am doing the same by using my visit to Pompeii. The above rooms depict actual places I visited. To be sure, I am not doing a full scale model of the city of Pompeii: it's enormous, and I didn't get to see all of it. Rather, I'm taking the places I did visit and interconnecting them in a similar but simplified way. Using real places allows me to furnish compelling descriptions.
Pompeii, the Inspiration for Roman Ruins
My game would need a mission, some objective. I decided to place three coins somewhere in the city: the player would need to locate a bronze coin, a silver coin, and a gold coin; each progressively harder to locate. Then, the player would need to figure out where to bring each of these coins based on examination and clues they would find along the way.
Game Data
The JavaScript data storage for my rooms (partial) looks like this. First, there are constants for each room which is useful in specific game play code. Next is the array of rooms itself. Each is a JavaScript object with properties for
// Room IDs
const SOUTH_GATE = 0; // Nocera Gate (South Gate)
const PALAESTRA = 1; // Gladiator practice field
const AMPHITHEATRE = 2; // Amphitheatre
const DECUMANUS_EAST = 3; // Decumanus Maximus - east
...
// Room detail
session.rooms = [
{ name: "South Gate", // 0 SOUTH_GATE
visited: true,
arrival: null,
look: "You are standing outside an ancient wall. The ground is covered in white ash. To the north is a gate.",
adversary: null,
env: null,
north: PALAESTRA,
east: null,
west: null,
south: null,
up: null,
down: null
},
{ name: "Gladiator Field", // 1 PALAESTRA
visited: false,
arrival: null,
look: "You are standing in a grassy field that appears to have been long-used for sports or fighting. There are ruins to the north, a wall with an entrance to the east, and a wall with a gate to the south.",
adversary: null,
env: null,
north: STATUE_CENTAUR,
east: AMPHITHEATRE,
west: null,
south: SOUTH_GATE,
up: null,
down: null
},
{ name: "Amphitheatre", // 2 AMPHITHEATRE
visited: false,
arrival: null,
look: "You are in a large amphitheatre with stone seating all around. A door leads west. To the north is a road.",
adversary: null,
env: null,
north: DECUMANUS_EAST,
east: null,
west: PALAESTRA,
south: null,
up: null,
down: null
},
{ name: "Decumanus Maximus East", // 3 DECUMANUS_EAST
visited: false,
arrival: null,
look: "You are at the end of a large east-west main road that cuts across the city to the west. There is an entrance to a large building to the south.",
adversary: null,
env: null,
north: null,
east: null,
west: DECUMANUS_CENTER,
south: AMPHITHEATRE,
up: null,
down: null
},
...
Some of the essential properties for each room include its
name, a previously-
visited flag, special text to add on first
arrival, a
look description for the LOOK command, and where the six movement commands lead. There is also an
adversary variable which tells the game whether some enemy is lurking in the room. Lastly, an
environment variable tracks whether a room has an interesting environment attribute such as being dark: in a dark room you can't see anything unless you happened to bring a light source with you.
Object data is handled the same way: there are constants to make it easy to reference a particular object by name in code, and then an array of objects for each game object.
// Object IDs
const MAX_ITEMS_CARRIED = 5;
const BRONZE_COIN = 0;
const BOTTLE = 1;
const JUG = 2;
const KNIFE = 3;
...
// Object detail
session.objects = [
{ name: "bronze coin", // 0 BRONZE_COIN
room: HOUSE_MENANDER_YARD,
examine: "It is an old coin made of bronze with a horse on its face.",
carrying: false,
disallow: null,
},
{ name: "bottle",
room: HOUSE_MENANDER_ATRIUM,
examine: "It is a bottle of wine.",
carrying: false,
disallow: null,
},
{ name: "jug",
room: SIDEWALK,
examine: "It is an empty pottery jug.",
carrying: false,
disallow: DOG,
disallowDesc: "The dog growls fiercely whenever you approach the jug."
},
...
Object properties include the object's
name, so that you can issue commands like TAKE BRONZE COIN or EXAMINE BOTTLE. There's also the
room the object is in, an
examine description for the EXAMINE command, and a
carrying flag to indicate whether the player is currently carrying it. The
disallow property, if not null, means the object can't be taken because of an adversary.
Although most rooms can be navigated to with NORTH, EAST, WEST, SOUTH, etc., some rooms are initially not accessible or even hidden. It takes puzzle solving by acquiring, transporting, and using objects to get to those areas. To invent some game puzzles, I considered non-intuitive paths to some places; natural obstacles; beasts that might not let you pass; and people that might not let you take something you need.
Game Code
The game code itself is simple. Each of the available commands needs an implementation:
- INVENTORY simply lists each item in the objects array where the carrying flag is true.
- TAKE object checks whether the specified object name exists. If found in the objects array, and in the current room, and not already being carried, the object can be picked up. The carrying flag is set to true and it is now a carried object.
- DROP object works just like TAKE, except it can only be applied to an object with the carrying flag set to true. The carrying flag is set to false, and the object's room property is set to the current room.
- The EXAMINE object command searches for an item in the objects array matching the specified name. If found, and the object is being carried or is in the current room, its examine property is described. Special code allows the player to sometimes examine other things, such as a statue in the room.
- The LOOK command describes your current surroundings. It first displays or speaks rooms[room].description, the general description of the room you're in. It must also tell you if any objects are present. Unless in a dark room without a light source, each item in the object array is described if its room property matches the current room and the carrying flag is false).
- The GIVE object or USE object command does something special with an object in order to solve a game puzzle such as defeating an adversary. Special game code checks for specific objects. With a more sophisticated implementation, these things could be represented in the game data itself but I was umm... lazy in these initial implementations.
Here's the code that implements directional movement (NORTH, SOUTH, EAST, WEST, UP, DOWN). After identifying a direction command, the room object for the current room's .north, .south, .east, .west, .up, or .down property is passed to the moveTo function. If moveTo is passed a null, movement is impossible. Otherwise, the current room is set to the passed room. If the new room object's visited flag is already true, this is a return to a prior room and a full description is skipped; but the user can always request that with a LOOK command. For interfaces with a visual element, a picture for the current room number is shown (unless it's dark and you have no light source). Other functions are called to also describe what's in the room with you.
switch(words[0]) {
...
// Move to a new room
case "NORTH":
case "N":
moveTo(session.rooms[session.room].north);
break;
case "EAST":
case "E":
moveTo(session.rooms[session.room].east);
break;
case "WEST":
case "W":
moveTo(session.rooms[session.room].west);
break;
case "SOUTH":
case "S":
moveTo(session.rooms[session.room].south);
break;
case "UP":
case "U":
moveTo(session.rooms[session.room].up);
break;
case "DOWN":
case "D":
moveTo(session.rooms[session.room].down);
break;
...
function moveTo(newRoom) {
try {
var text = '';
if (newRoom != null) {
session.room = newRoom;
if (session.rooms[session.room].visited) {
text = "You're back at " + session.rooms[session.room].name + ". ";
}
else {
if (session.rooms[session.room].arrival!==null)
text = session.rooms[session.room].arrival + session.rooms[session.room].look + " ";
else
text = session.rooms[session.room].look + " ";
session.rooms[session.room].visited = true;
}
session.location = session.rooms[session.room].name;
session.output = text;
if (isDark())
session.imageUrl = image('dark.jpg');
else
session.imageUrl = image(session.room.toString() + '.jpg');
listObjectsInRoom();
listAdversariesInRoom();
}
else {
session.output = "I can't move that way. ";
}
}
catch(e) {
session.output = "An exception occurred";
console.log("EXCEPTION" + e.toString());
}
}
In designing an Adventure game, one must try to anticipate everything a player might try. For a consistent and enjoyable game, logical conclusions should be honored: if a player went NORTH to get from Room A to Room B, then SOUTH from Room B should lead back to Room A. There can be exceptions however: since the places we're describing are not necessarily rectangular, we don't always have to honor the obvious routes. Twisty passages in a maze may lead the player to unexpected places; and there may be the occasional magical secret door that whisks the player to a completely different area of the world.
A single-level world is not as interesting as a multi-level world. Most of what I'd seen in Pompeii had been single-story buildings. I could surely invent some higher structures, which would allow some UP and DOWN navigation.
What about a subterranean level? That was a mainstay of Colossal Caves Adventure. Thinking back to our trip to Europe, we had also visited underground catacombs (where early Christians buried their dead), which were networks of many underground rooms. I decided this would make for a good subterranean level in Roman Ruins Adventure, with a handful of places that allow one to travel below ground level and back up. Since the real-world catacombs are mysterious twisty places that are hard to navigate, I would design accordingly. I would also require a light source in order to see anything in these rooms.
Frustratingly, our visit to the Roman catacombs visit didn't allow picture-taking. I decided this would be the place for my version of "Twisty little passages, all alike." I have a similar (but subtly different) description for each area, with the same cave image; unless it's dark, in which case everything is pitch black. I know some players groan when they encounter these areas but since my game is a homage to the original Adventure I really do have to have one.
Conclusion
The original Adventure was ground-breaking and has a large legacy of game infuence that continues on to this day. I spent the last week creating my own Adventure game, on a smaller scale. Today we examined some of the game design. It could be a lot bigger: there are only a couple dozen rooms at present. All it will take to expand it is some creative thought and some more game data.
My week of development targeted creating a basic game, an implementation for Alexa, and an implementation for a Twitch Minigame Extension. I completed all that, but I'll admit there could be a lot more refinement. The game could be expanded with more rooms, more of a narrative to discover, and more game puzzles. The implementations could be more polished and there should be more shared code. I likely will return to all of this and take it further at some point, but I am satisfied with this first week's effort. It was an Adventure!
In
Part 2, we'll look at my implementaton of Roman Ruins Adventure for Alexa.
In Part 3, we'll look at my implementation of Roman Ruins Adventure as a Twitch Mini-game.
Next:
Part 2: Alexa Skill
