Text Adventure - Engine actions based on dialogues

Question

Building forward my text adventure i stumbled upon how to actually drive the actions that can be caused by dialogs. I wrote the dialogues and the logic around handling them already, but i'm missing a key about how to turn a dialogue into an 'engine' specific action (like spawn item, drop, buy, sell).

My game is absolutely based on JSON therefore even dialogues are stored there:

An Option is what a player can choose by typing one of the defined Keywords for currently displayed dialogue.

Response is what a player sees when option is chosen

Goto is where the dialogue goes next after an option is chosen

Script is nothing more fancy than a list of strings with integers that get mapped into a std::map<std::string,int> and later passed for the execution. Think of it as of flags.

Let's look at the example below - where you could buy something from inn keeper.

In above situation, you can talk to the keeper and choose:

• "1" to buy item "1"
• "2" to buy item "2"
• "back" to get back to previous dialogue (with a goto)

Let's say i want to choose option "1" and it boils down to the design now.

How would you turn that "1" into a real engine action of buying an item?

What i did.

As you might have seen i have defined a Script within the option of the dialogue, this would be just a map (string to int) of attributes passed to an interpreter.

Then the interpreter executes that based on 'action_type' - which is defined in json, mandatory and describes type of action like here:

Some questions then:

1) Is it the valid approach to write my own interpreter - maybe i can use it somewhere else? or i should start thinking about external scripts - which actually require me to focus on adding library and learning it, instead of doing the game itself.

2) Which class should be really responsible for actually executing the script with the data passed from dialogue.

Dialog class itself ?

std::string CDialogue::Process(const std::vector<std::string>& rvArguments)

Npc class handling talk action ?

void CEntityNPC::HandleTalk(CEntity *pFromWho, const std::vector<std::string>& rvArguments)

Command class that handles talk command?

void CCommandTalk::Execute(CEntity *pPlayer,const std::vector<std::string>& rvArguments)

3) Maybe you can think of a different way to handle this situation? Basically a translation of a text(json) data into a game logic.

Answer 1

Brief context: I work on a fairly large LDMud with mostly (but not entirely) hard-coded objects subclassed from a few primary blueprints. I spend some of my time trying to improve our long-term maintainability by refactoring common patterns out of the "content" objects and into the core.

1. You probably don't want to write an interpreter at this scale unless you want to learn how to write an interpreter. I'm not exactly sure what you mean when you say external scripts here, and I'm also skeptical that your scale would make it worth picking up a library unless it's reasonably small/simple/focused.

   I would spend some time pondering what you like about JSON, why you want to structure the game around it, and (briefly) getting a sense of what text-game libraries might be real options for you. If you embed executable scripts in JSON, code and content will no longer be separate, and you'll lose all of the advantages of code in the process.

2. I'm not sure there's a silver-bullet answer here, but I'd probably try to abstract command-handling out into parts so that a number of different entities could handle the command, and then start out with doing it on the NPC. It seems like trying to do all of this work in a dialogue or command class could lead to a lot of complexity accumulating in one place. On the NPC class, you'd be able to have a Vendor or ShopKeeper subclass, for example, if the dialogue needs of the tavern-keeper are sharply divergent from the town drunk.

   I think this gives you a little wiggle room to focus on implementing instances of this functionality in the short run, until you have a better idea of whether it can all collapse into a single common pattern.

Consider (just pseudocode/concepts here):

• Any user input goes through a command router that checks the first word against a temporary command mapping and passes it on to the correct object/function.

• Individual objects register their intent to handle a given command word, adding it to the temporary command mapping.

• Give every object you suspect might eventually care a chance to register commands. Make a dedicated method for this setup/init work, and this method a call on each object you think might eventually want to register a command in a well-defined order. This isn't too sophisticated. A decent order is: everything the player is holding, everything in the room with them, the room itself, and a general command handler. Think something like register_command(name, json_command_description).

• If anything changes, clear this temporary command map and give everyone a new chance to register.

• When the user actually enters a command, the handler might do something like: registered_object->command_name(user_input, json_command_description) or registered_object->do_command(name, user_input, json_command_description)

This standard process for registering and handling commands will free you up to move any specific command around fairly easily, so you can write the command on the most specific object it makes sense on and move it towards the core (generalizing, parameterizing, and pushing messages/paramters out into JSON) later. It also means the JSON command descriptions can differ circumstantially in the beginning, so that common structural patterns emerge from real use.