How to program a text adventure in C

by Ruud Helderman <r.helderman@hccnet.nl>

Licensed under MIT License

19. Conversations

One of the most difficult parts of writing an adventure is to come up with challenging puzzles. Puzzles must be difficult, but without being illogical. If your game demands the player to unlock a door with a towel, fine. But then at least give the player a clue. It’s no fun brute-forcing your way through a game, having to try every combination of object(s) and verb until you find something that matches the author’s obscure sense of logic.

Clues can be hidden in descriptive text. This text may come out unannounced, for example as you enter a location (“A hollow voice says PLUGH”) or run into an actor. But it also makes sense to let the player actively search for clues by examining objects and talking to non-player characters. Obvious advantages are:

• It gives the player a sense of being actively involved in the story. In a detective story, examining the crime scene and interrogating witnesses and suspects should play a vital role in solving the mystery.
• It is a natural way to split descriptive text into smaller chunks, and serving the information in an on-demand fashion to the player. This prevents a waterfall of (unsolicited) information at certain (fixed) points in the game.

Conversation with non-player characters can add a lot of depth to a game. Clues given may help you or hinder you. Some examples:

• When entering a town, the locals may be able to tell you how to earn money, where to find food, or how to sneak into the castle. The more focused the inquiry (referring to a relevant item, location or actor), the more focused the information returned. Like in real life, it’s all about asking the right questions.
• Information gathered from different sources may be interrelated or contradictory. The baker may have given you some useful gossip, but what if the goldsmith told you the baker is actually a notorious liar?
• The player may need to ‘encourage’ actors to spill their guts. Either with a friendly gesture (is there some item they need?) or by force. An actor’s willingness to supply (valid) information could be implemented by certain ‘psychological’ properties, rating their loyalty or fear towards the player.

Conversations may go a lot further than just asking for information. Some suggestions:

• Allow the player to give commands to other actors, for example: “Tell giant to break door with axe.” So rather than taking action yourself, you could try and find a ‘specialist’ to do the job. Whether or not other actors will obey your commands, might depend on the effort you have put into building a certain relationship with them.
• Allow the player to pass information back to other actors. You may not be strong enough to push aside a pair of guards, but it might help to use a little lie to spark a conflict between them.

Of course, these more advanced forms of interacting with actors demand a pretty sophisticated conversation engine. A recommended read is Dynamic Conversation Engine Concept by Luke Bergeron. I found this to be incredibly inspiring. The article has been removed from Scribd, but fortunately the Wayback Machine still has a copy:
https://web.archive.org/web/20100409073709/http://www.scribd.com/doc/17682546/Dynamic-Conversation-Engine-Concept

Talk

In our little adventure game, we will try to keep it simple. We will implement a very straightforward ‘talk’ verb. It allows the player to talk with an actor about some topic. The topic of discussion can be any object: an item, a location, even another actor. In its most elaborate form, you could give every actor their own opinion about certain topics. That requires a matrix of possible reactions; one for every combination of actor and object.

In a big adventure, such a matrix could be huge, making it extremely time-consuming for the author to come up with a witty response on every attempt from the player to engage in conversation. Furthermore, a huge number of combinations could easily turn into just another brute-force puzzle, where the player feels forced to interrogate every actor about every possible topic.

To keep it maintainable, you may want to cut down on the number of combinations. Here are a few ways to do so.

• Eliminate actors from the matrix. Some actors may be unable to speak (e.g. animals), not willing to speak (enemies), or both (monsters). Those actors do not belong in the matrix; a single uniform response per actor should suffice. (“The dog replies: woof woof woof.”) An exceptional response to one particular topic could be handled in a hard-coded way. (“When hearing the word ‘rosebud’, the dog starts to growl.”)
• Eliminate objects from the matrix. For many (or even all) objects, you may want to supply a single response, to be returned by every (talkative) actor. (“You get the advice: do not fight with the guard!”) Again, if there is an exceptional answer, to be given by a particular actor, then that can be hard-coded. (“The tour guide says: do not forget to pay the guard!”)
• Group actors. Instead of giving every individual its own column in the matrix, use ‘categories’ of actors. There may be many different villagers, but if they all share the same basic knowledge about the majority of topics, then this will save you a lot of duplicate entries. Again, exceptions to the rule can be hard-coded.
• Multiple smaller matrices. Suppose the game is set in a big world where the player roams from village to village. Villagers may not be aware of items, locations and actors in other villages. Giving each village its own matrix, eliminates all the irrelevant cross-village combinations. (A mathematician might refer to this approach as a block diagonal matrix.)
• Sparse matrix. All the previous approaches had one disadvantage: there is no structural solution for exceptional combinations of actor and object (that one actor to give the player the essential clue about that one object). But there is an alternative to 'hard-coding' the exceptions: put these combinations in a separate sparse matrix. Such a matrix would typically be implemented not as a two-dimensional array, but as a list of tuples. Covering exceptional cases only, the list should be relatively short, which helps to keep it compact and maintainable.

To keep things simple, we will stick to a single response per object, given by any actor the player will talk to about that object.

As always, we also need to make object.awk aware of the new property, and specify a default value.

Adding a new command ‘talk’ to the parser:

As many times before, we introduce a new module to implement the new command:

Function getTopic is implemented in one of the existing modules:

And if you cannot talk your way out of a difficult situation, then there is always the option to use physical force. More on that in the following chapter.

Next chapter: 20. Combat