Hi,

i'm writing a dialog system (first serious attempt) and came to a point where i want to make it more 'unspecific'.

Each dialog currently has options to specify requirements (List of DialogRequirement objects) for it to be a selectable option, which consist

of a target (enum - npc, player, world) and a type (enum -state, logEntry, etc) and a few value fields (int, float, string). When checking the requirements

i select the target based on the enum value and pass the requirement object to it. Targets implement an interface (IDialogRelevant) with bool ValidateRequirement(DialogRequirement) and use the value fields for the check.

The problem i have is that the requirement has these value fields (int intValue, float floatValue ..) that are bad to read and easy to implement wrong in the DialogRelevant entity and also the RequirementType enum too tied to a specific type of game (the requirementType enum currently has things like QuestLog for example).

What i would want is it to be extensible , like new requirement (sub)classes which then could (and should) be more specific.

What i thought, but am confused about is generic interfaces, or an abstract generic baseclass.

(But if, how would i 'connect' these to the specific requirement target and pass the required value and what way should i do it, and wouldn't i have to typecheck and cast these before passing them to the specific target as i have to store them in a baseclass type field?)

i'm using unity (c#) and already have a visual interface ready to build the dialogs, but want it to be open to the requirement types that the user can implement, like i think giving them a Draw() method would be the way (as there's currently only this one requirement object i just inlined the drawing of it).

How would i design it?

I hope you can understand what i mean.

I see, my explanation wasn't that good and it seems missing some information. Each entity that needs dialogs has the dialog component that holds all dialogs for that entity. If the player requests dialogs, the code checks the each root element of the dialogs for its requirements. This means, foreach DialogRoot (and subsequent dialogoptions: if at that point), i pass the dialogrequirements to the entity the req. is targeted at, for it to check them, because i currently have no idea how to kind of externalize them (i hope that word describes it better). In the end, i want to enable the user to create custom requirements specific to his game (and maybe the validation methods, if those are needed?), for example like Requirement_HasItem that i can use in my system without hardcoding them or having a big allround requirement class with all value types as fields and an enum that defines how the values should be handled (what i currently have)

If you want a fully extendable requirement, I don't see any other choice but to let a derived class or a user-supplied class handle the exact requirement checking (and likely, you want to provide some of these for common types, like "has item"). The simple reason is that you are never going to be complete. It's trivial to think of crazy extensions like "you can only talk to me if the weight of your items together is a prime number".

Storage of required items and checking requirements are two different things, and you can do each independent of the other, if you like.

For example, you could have a derived class inspect the environment for checking the requirements (it would need an API to do so), or it could give an object to the central storage that checks on behalf of the derived class. You could even have completely separate check class hierarchies, which can be extended, that the dialog sub-class "magically" knows about.

I'd just pass in a list of strings that can be defined by the game developer.

Strings can be things like "VistedMagicalCity", "AquiredMcGuffin", "KilledByAGrue", "CurrentlyHasKeyItem"

If that's not enough flexibility, then just make the "requirement" be a script that must return true.

@Alberth

The idea of passing check objects sounds good. I guess that would mean i still keep the base requirement class with the valuetype fields which the specific check object then takes the ones it needs from, kind of like an adapter?

@Servant of the Lord

For the strings idea, it seems to me that this means logging all game events in this string format. And that means checking the inventory for example for an item would become a search for "PickedUpItemX" or the surrounding system has to know which specific events to log as a certain keyword which i feel could be a too strong requirement for the system. And to your script idea it sounds to me like you mean it in a similar way to these check objects, no? (if i understood these correctly)

For the strings idea, it seems to me that this means logging all game events in this string format. And that means checking the inventory for example for an item would become a search for "PickedUpItemX" or the surrounding system has to know which specific events to log as a certain keyword which i feel could be a too strong requirement for the system. And to your script idea it sounds to me like you mean it in a similar way to these check objects, no? (if i understood these correctly)

For the string idea, I meant that the quest makers (or whomever) create invisible textual "keys" that unlock branches of the dialog. These invisible keys can be given to the player by scripted situations in the game world. It is simple and straightforward.

For example, not every item is going to be used for quests. Depending on your game, I'd guess that less than 1% of all your items will be quest items. So instead of making your dialog system know about the existence of items, just make the items be able to contribute textual keys to the dialog system.

For a quest item called "Super dragon crystal", have a field in the item editor where you can add "HAS_SUPER_DRAGON_CRYSTAL". Any item where that "quest item" field is left blank, doesn't bother contributing to the dialog system.

If a quest requires the player to have visited the Lonely Eagle Tavern, make the "onEnter" script for that map call SetQuestKey("VISITED_LONELY_EAGLE_TAVERN");

If this isn't flexible enough for you, then (instead of the other suggestion) just take the leap to make the dialog system be aware of your scripting environment, and make your Dialog Requirement just be a script that returns true or false if that requirement is met.

I understand now, thank you for these suggestions.

Unfortunately, no matter what the dialogue system's situational check is going to be uber specific to your game. Not all games feature the same mechanics or quest styles, so each game really needs to make their own checks.

Currently, the way I have mine mapped out in design, is by using a Tree based structure, with each node allowed to accept conditional arguments. This conditional argument on it's own has absolutely no functionality. It only accepts bools. Now Lua has a very nice feature of allowing a variable amount of arguments to be passed through, which makes the process real easy for me, but you can do the same with C# without it looking as clean

That means we can build very generic function arguments. Here's what my arguments look like:

Dialogue.checkGlobal(DataTable, enum operation, items . . .) DataTable would be my global game data table. ENUM operation tells if I am ANDing or ORing all this data. AND requires all to be true. Or immediately returns true if one is true.

Dialogue.checkParty(PartyTable, enum operations, characters...). This checks to see if certain characters are in your party. Returns true if yes.

Dialogue.checkQuestStage(QuestTable, int stage);

ect.

There are also a few nodes whom soul purpose is to gather information for randomization.

A party of 8 exists. Four entered a dungeon, Leo, Neshar, Omally, and Drivilla. But at the time of a trigger, only three are within speaking range. We check to see if each one of the branches are allowed to be ran based on those three. Build an array. Then randomly select a branch to traverse. End result, characters when they enter dungeons.

The tool is built using Javascript and HTML, and it outputs two files. JSON for reloading. LUA for the game.

The dialogue system may also need to be able to trigger events in the game. In my case, it does. In the middle of a dialogue, a cleric or a thief may be able to give out hints. And the game needs to highlight those, or write to a journal.

I know that it has to be specific to the game, and i hoped to build a system that becomes specialized at the point where the user created his game specific requirements (and/or implemented the associated (generic?)interfaces for the entities).

I currently also have a kind of trigger system, not as sophisticated, but involved entities (npc, player, world context) can be notified when a dialog option is selected. AND'ing and OR'ing of the requirements is also already in there. It's just the way the requirement is structured that currently botheres me. But i will see what i can do with all the suggestions i got.