Text-based Adventure-Game Engine

I wanted to create some kind of generic text-based adventure-game
engine to see if I could build an interesting puzzle out of it.

The idea was to define a mini-language to be able to define the
adventure in a file and provide sessions of play like:

`You are at the entrance of a temple. Type temple to go in.
> temple
A strange statue is in the middle of the room. 4 doorways goes out.
The south one goes back to the outside. The north, east and west ones
goes to dark rooms.
> south
You are back at the entrance of the temple.
> temple
A strange statue is in the middle of the room. 4 doorways goes out.
The south one goes back to the outside. The north, east and west ones
goes to dark rooms.
> statue
The statue is held with heavy chains and seems to be the only thing of
interest in this temple. Appart from the doorways to the north, south,
east, and west.
> north
You found a green gem in this room. Yay! The only option here is to go
back to the main room.
> temple
> main
> room
> main room
You are back in the main room and the green gem starts glowing near
the statue. The doors to the north, south, east, and west are still
opened.
> east
The only remarkable thing here, beside the door to the main room is a
tiny fountain in the wall.
> fountain
You found a blue gem in the fountain. You can head back to the main
room.
> main room
You are back in the main room and your 2 gems are brighter near the
statue. The doors to the north, south, east, and west are still
opened.
> west
An empty room with 3 walls and a door to the main room.
> wal
> wall
Upon closer inspection, one of the wall revealed an opening containing
a red gem. Quick! To the main room.
> main room
You are back in the main room and you feel all your gems pulsating
together near the statue. The doors to the north, south, east, and
west are still opened.
> statue
You approach the statue with the 3 gems and the chain entangling it
start removing themselves. You got everything you needed to extract
the statue out of

Don't conflate links and rooms

The biggest flaw I see is that room names and the links between them use the same identifiers. This is particularly problematic with directional indicators, such as north, south, etc.

Let's say we have the following room:

[Throne Room]
An elaborate description of a throne room.
There are passages going [north], [south], [east], and [west].

We have a room to the north, so let's add that. Since we named it north above, we have to call it north here:

[north]
You are in a long hallway.
The hallway continues to the [north].
To the south is the [Throne Room]

This seems simple enough -- you can go back to the throne room or keep going north. But north here links back to itself. So we have to use a different name. So we do this:

[north]
You are in a long hallway.
To the north is the [north hallway].
To the south is the [Throne Room].

Ok, we've solved that problem. Now we add the north hallway:

[north hallway]
You are in a long hallway.
There are rooms to the east and west, but they are locked.
To the north is the [north north hallway].
To the south is ... [north]?!?

As you can see, there are two problems here:

• We have the rather silly name of north north hallway.

• We have the ridiculous situation where north is south.

Now, one could argue that this problem is easily solved by using "better" names. But I would argue that "good" names are difficult to come up with -- especially with a large map with many generic areas. Even in this small example, how would you come up with "good" names for the various hallway segments? You could number them (hallway1, hallway2, etc.), but I would not consider those "good" names from the player's perspective.

The solution is to separate the name used to activate a link from the name of the room it links to. For example, you could use the form [name|room] to indicate that the user can type "name" to go to "room". Here's how we might write up our simple example:

[Throne Room]
An elaborate description of a throne room.
There are passages going [north|Hallway1], [south|...], [east|...], and [west|...].

[Hallway1]
You are in a long hallway.
The hallway continues to the [north|Hallway2].
To the [south|Throne Room] is the [Throne Room]

[Hallway2]
You are in a long hallway.
There are rooms to the east and west, but they are locked.
The hallways continues to the [north|Hallway1] and [south|Hallway3].

Other Features to Consider

Here are some other features you might want to consider. Even if you don't add them now, start thinking about how you would extend the engine to support them in the future.

• Object descriptions. It's a lot more interesting if you can not only find an object, but if you can "examine" it as well. Good descriptions can add a lot of depth to your game.

-
Object interactions. Let the player "do something" with an object. This opens the door for interesting puzzles. For example:

• Get the bucket

• Fill it with water

• Use it to douse the fire blocking your path

You could have these actions happen automatically. I.e.,

• Player stumbles into the room with the bucket => they automatically pick it up

• Player stumbles into the room with the water => if they have the bucket, it is filled with water

• Player stumbles into the room with the fire => if they have a bucket of water, it is doused

The player is very passive in all this, though, so it isn't very interesting. Now consider the following interaction:

• Player enters room with bucket; ignores it.

• Player enters room with water; ignores it.

• Player enter room with fire; gears start turning

• Goes back to water; hmm, if only there was a way to carry this ... aha! the bucket!

• Player goes, picks up the bucket, fills it with water, and douses the fire!

This type of interaction keeps the player involved in the game. Rather than passively "stumbling into" the solution for a puzzle, they take an active role in making key observations and applying them to form a solution.

Consider using an existing parser

As you add more features, you might find that maintaining your own language and parser for it takes of time that could be spent actually implementing the features. You might want to consider using an extensible format for which a parser already exists. XML would be a good candidate here, although there are other formats as well.

StackExchange Code Review Q#147479, answer score: 3