Text adventure games

The earlier text adventure games were very primitive and had a very limited vocabulary, generally limited to moving in various directions (NORTH, SOUTH, WEST, EAST), item management (INVENTORY, GET, PUT, USE) and a few other words for more specific actions.

Over time, game became more and more complex, up to the point they would try to understand natural language, allowing for sentences with subjects, verbs, adjectives, and sometimes even allowing complex commands in the same input (ex: “TAKE THE SWORD AND PUT IT INSIDE THE STONE IN THE ROOM”).

Melbourne House’s The Hobbit is a good example of this tendency.

Personally I think it was a mistake, because the more advanced the system the more you need to support alternate ways of mentioning something, and you often ended up stuck in trying to express your intent instead of performing the action you wanted to do.

Point and Click games

Point and Click adventure games had to reduce the list of possible actions so they would fit on a fix list of actions on the screen, like here in this screenshot of Maniac Mansion:

And similarly in Zak McKracken And The Alien Mindbenders:

Eventually people realized that you could use the context to present a restricted list of possible actions, like here in Monkey Island 2:

Day of the Tentacle uses a similar system:

And no, it was not only Lucas games which decided to go for this choice structure, here is a screenshot from Fester Mudd: Curse of Gold released in 2013:

And a last example, Simon the Sorcerer:

The bottom line is, many of the best in genre game, games that people have been playing and replaying over the years, games which have been remastered on modern systems… have all stick to this simpler system of contextual operations, so maybe going back to the basics in a pure text parser game is a good idea.

Encounter 1983

The original version of Encounter supported the following vocabulary:

• Directions: N, S, E, W, U, D
• Verbs: LOOK, INVENTORY, EMPTY, GET, DROP, THROW, KILL, HIT, MAKE, CLIMB, QUIT, SIPHON, LOAD, READ, BLOW, EXPLODE, HOTWIRE, STEAL, LOST, SHOUT, PANIC, HELP, JUMP, OPEN, RUN

Most of these keywords don’t really do anything other that printing some funny messages like “Let’s keep it legal” when trying to steal something, “It’s no use shouting HELP” when calling for HELP, “I’m too tired for athletics” when trying to RUN or JUMP, or “I’m inclined to agree” when entering PANIC.

The thing is, the game is still extremely rigid in what it expects, and I would have never thought about using the SIPHON (or SYPHON, both are supported) word to get the petrol out of the car.

Encounter HD

For my new version of the game I decided to reduce the list of keywords to the minimum:

• Directions: N, S, E, W, U, D
• Verbs: LOOK/INSPECT/EXAMINE/SEARCH, TAKE/GET, DROP/PUT, OPEN, CLOSE, THROW, USE, READ, COMBINE

That’s basically limited to directions, plus 9 possible actions.

I’ve added a few variants but they do the same thing: There’s is no difference between using TAKE or GET, the result is the same.

The consequences are multiple:

• The documentation of the game can be reduced a lot more
• The player does not have to try to guess how to interact with the game
• Instead of spending time developing a “rock solid” interpreter, the time and memory can be spent on actually make the game content interesting

It is not uncommon to add complexity to make something more interesting or challenging, but complexity in the wrong place just adds frustration.

The game of chess has only 6 different pieces, and the game of draught only one (two if you consider the stacking), and despite of that these games are quite rich, with different openings, strategy books, etc… adding more pieces would not necessarily make the games more interesting.

What I’m doing instead of adding more action words is to try to add more value to each of them.

I do have OPEN and CLOSE, and in the game you now have (so far) five different items that can be open and closed: A fridge, a medicine cabinet, a mysterious locked metallic panel, a weapon cabinet and finally a heavy curtain possibly hiding something.

Similarly the original game had a CLIMB command to handle some special cases where you would have to go up and down using a ladder or a rope. I originally implemented this but that was just adding complexity for no particular reason.

Instead, the player now have to USE ROPE or USE LADDER, which will automatically add UP and DOWN possible direction if they were used at the proper location, and when that happens, the rope or ladder is actually visible on the screen.

I’m currently on the fence for the THROW instruction, I may just remove it and have the player use USE instead.

So there you go, simplicity can often be a virtue, and complexity built by combining simple elements is often more rewarding: LEGO had it right all along!