Trees can be useful for this sort of thing - it'd be a 'decision tree', in AI parlance. Gives you a lot of flexibility that statically coded if's etc. don't have. (Warning: code below is almost certainly horribly broken.)

What you need to do is have some kind of data structure to represent a given decision. Say for example your entity is considering its own statistics to make a decision:

class Enemy {  int stat_a, stat_b, stat_c;  friend class DecisionNode;  DecisionNode* strategy; // the enemy's state}

Now you make normal strategy objects to represent plain states (flee, attack etc.) :

class DecisionLeaf : public DecisionNode {  enum { FLEE, ATTACK, ... } action;  action a;  // etc.  void operator() (Enemy * parent) {    // Cause the Enemy to do something according to 'action'  }}

And now we need other types of DecisionNode to handle the 'logic' cases:

class ComparisonNode : public DecisionNode {  DecisionNode* lessThan;  DecisionNode* equal;  DecisionNode* greaterThan;  int threshold;  Enemy::int& type; // provides an offset to the Enemy data member to use.  // I'm pretty sure something like this exists but I don't really know how the  // syntax needs to work.  // etc.  void operator() (Enemy * parent) {    int parents_value = parent->type;    // Do the comparison, select a child and invoke it    if parents_value < threshold  { *lessThan(parent); }    else if parents_value == threshold { *equal(parent); }    else { *greaterThan(parent); }  }}

The idea is to make an object that encapsulates the concept of the comparison and dispatch.

Quote:Original post by nikdo
Hey ZahlMan,

thanks a million for your post. It helped me a lot. I really appreciate you taking your time and writing up all that code. You consistently post good answers. To you these things are probably obvious at this point, but to the rest of us it always isn't so and hence help such as yours is primordial.

Thanks. I sure hope noone expects my stuff to compile and work right, right off, though. ^^; (I really should just download and set up a C++ compiler...)

Quote:1) I imagine the class that's missing from your code, DecisionNode is simply an interface ABC - something like so:

class DecisionNode{

void operator(Enemy * parent) = 0;

}

virtual void operator() (Enemy * parent), is more or less what I had in mind, yeah. You might find a use for other stuff in there, I don't know. Note the brackets; you need the empty () to specify which operator is being overloaded, and then the arguments go in a second set.

Quote:2) in your class Enemy, where you have the line DecisionNode* strategy; - does this represent the root node for ONE particular state, or does the resulting nodes represent all the states? It seems it represents one state only (yes, your tree nodes can definitely end up calling different DecisionLeaf that represent different states).

What I am getting at is that should I have one strategy (or tree) PER ENTITY STATE? Or should I have one tree for ALL entity states?

The 'strategy' is the root node for an Enemy instance's current "brain". You have conceptually one tree per Enemy, although you may be able to share them in some cases ("hive mind"?) You can change the trees at run-time according to whatever criteria. You might for example set up some prototype trees to represent various sorts of "behaviour" (or "emotion"? Hmm...), and then have each Enemy link to the root of one of these (and at intervals, possibly change that linkage). The entire tree represents a strategy; each node represents just a step in the decision-making process.

Quote:I was trying to see how I could have one tree for all entity states and I am not sure if it is reasonably feasible. First I'd still have to draw it out on a paper and see if you can even arrange all the states in one tree or if the states are not simply on the same level and hence necessitate different tree for each. Furthermore, I'd have to wrap the nodes into a tree class to ficilitate depth-first searches, since the first thing would be to search for the right state node and start executing from there.

You don't "search" the tree; you "execute" it. Each node is a callable object. The leaf nodes implement the 'primitives' of entity behaviour; internal nodes select one of their children and invoke it. Thus, to cause the entity to do something, you just invoke the root node; it invokes one of the children, and so on recursively until a child node is reached, which then makes the entity Do Something(TM) (by acting through an interface which the entity exposes to the nodes - for illustration purposes I chose to just make it a friend class, so you could do anything).

The trick is in building the trees, really. :) Really advanced AI might involve tweaking trees on the fly according to what seems to be working or not working (genetic programming), by substituting nodes in the tree (or just changing the threshold values in those nodes).

if you really know how deep the tree is (i.e in your case 3), why use a tree?, you could use a neural net with only 3 layers. Also instead of programming in the runtime data, you could read it in from a generated data file (xml?).