4 replies to this topic

[dechorus]

Heya,

I'm making a sort of graphic adventure game with dialog trees and the like. Sometimes, a conversation can go down different paths depending on actions you've taken or choices you've made previously in the game.

The way I do this "check" is I've made an abstract Condition class with the abstract method "conditionMet" - then all of my different conditions override that method. To give an example: OwnInventoryItemCondition inherits Condition - it has 2 variables: Item name, and number. The conditionMet function will be something like: return Inventory.hasItem(itemName, itemNumber).

I store an instance of OwnInventoryItemCondition in a list of conditions associated with any particular dialog option. For example, after clicking on and talking to somebody - an option to hand them 6x carrots would only display if the condition for it was met. Otherwise, only the other default choices would display.

The problem is I now have so many different condition classes, and serializing each individual type to XML means I have to declare them all individually for serialization, which doesn't seem right.

I'm asking for any comments on my current implementation, and suggestions for possible better ones. If you've done a similar kind of game, I'd love to hear the way you've implemented this. Thank you all for reading!

[Kylotan]

If serialising the XML is a problem, then use a different serialisation system. You shouldn't change the way your code is organised just because your serialisation is a bit tricky.

Another approach is to define the conditions via scripts rather than lots of different condition classes, and each script can then be serialised as the same thing, ie. a lump of text.

[WreckSector]

In my game (much simpler than yours it sounds), I have conditions that determine whether a character says X or Y when you click on them. My implementation was very simple. The main character has a set of string tokens, and in a script file, my condition looks like "(PersonName).HasToken(SomeTokenString)". During runtime, when I check this condition, I parse that condition string, find the person, and see whether they have the token listed in the condition.

How come you are finding you have so many condition classes? Other than checking inventory items, are you finding you want to check many other things as well?

[dechorus]

If serialising the XML is a problem, then use a different serialisation system. You shouldn't change the way your code is organised just because your serialisation is a bit tricky.

Another approach is to define the conditions via scripts rather than lots of different condition classes, and each script can then be serialised as the same thing, ie. a lump of text.

Ah yes, I'm looking into ways of doing this. Rather than storing an object of X_Condition, the string "return ...(boolean statement)" would work wonders. I'm coding this in C# - surely there's a way to run a string as a line of code(?)

In my game (much simpler than yours it sounds), I have conditions that determine whether a character says X or Y when you click on them. My implementation was very simple. The main character has a set of string tokens, and in a script file, my condition looks like "(PersonName).HasToken(SomeTokenString)". During runtime, when I check this condition, I parse that condition string, find the person, and see whether they have the token listed in the condition.

How come you are finding you have so many condition classes? Other than checking inventory items, are you finding you want to check many other things as well?

Yes, my way does seem plenty more complicated! In fact, one of my conditions is to check for a token in a similar fashion to your way Only my conditions are not exclusive to checking those. An example of conditions I have are:
Checking if the profile is Male or Female. return Profile.Sex == "M"
Checking for a token (basically a string / int key pair). return TokenValueEqual("TokenName", Integer) - or return TokenValueGreaterThan("TokenName", Integer). These can be dynamically made during runtime. I use this for most things, such as checking quest states and character states - ("LISA_FEELINGS", 0) - which is basically my implementation of the bioware romance system.
Check inventory. (already given an example)
Check current location.
Check who's in your party (Is Lisa in your party? Then play her sequence. Else, skip).
and etc.

Tokens are easy to persist as they are simply string/int pairs.

I'm really starting to believe that rather than having and storing Condition objects, I ought to simply store the scripts.

Thanks for your input so far!

[crancran]

If serialising the XML is a problem, then use a different serialisation system. You shouldn't change the way your code is organised just because your serialisation is a bit tricky.

Another approach is to define the conditions via scripts rather than lots of different condition classes, and each script can then be serialised as the same thing, ie. a lump of text.

Ah yes, I'm looking into ways of doing this. Rather than storing an object of X_Condition, the string "return ...(boolean statement)" would work wonders. I'm coding this in C# - surely there's a way to run a string as a line of code(?)

Yep there is but I am not aware of this inside C# (albeit I'm not a C# developer). You could always look into a scripting language like Lua and place all your scripting conditions inside Lua scripts and bind those to your C++ objects. The benefit here is obviously that you can easily modify/extend the lua scripts at any point without recompile of your code and additionally, you can easily serialize/encode the scripts to deter modifications to your logic. In a client-server scenario, often these types of behaviors are kept server side in scripts where the encoding or modification concerns are unnecessary.