Behavior tree designer tool problem

[!@^^@!]

Hi again mmowned! I'm in the process of writing a Behavior tree designer application that will analyze a compiled c# class library with reflection and extract methodes to be used for drag and drop designing...
However I'm having some trouble figuring out the best way to export the created behavior tree, basically I'm not sure whether i should make a Wrapper class that contains an enum with the node type and a string/Type (or what i need to "map" the function from the analyzed dll file) and then use the CodeDom to compile another lib and provide a loading class OR create an xml file and put the object generation onto the loading class...
both ways seems like a lot of trouble and therefor I'd like to hear if anyone have a better suggestion

[Seifer]

If you're interested in sample code, look up TreeSharp on Google Code. It's Apoc's BT.

[!@^^@!]

I already took a look at TreeSharp and it's too complicated/advanced for my likings so I coded a simpler behavior tree myself so that's not the problem at all, it's the methode of persisting the created behavior tree im having trouble with...

For example, my node looks like this:

 public class Node : INode
    {
        public Node(Func<Result> condition, Func<Result> action)
        {
            Condition = condition;
            Action = action;
        }

        public Func<Result> Condition { get; set; }
        public Func<Result> Action { get; set; }

        public Result Run()
        {
            var condition = Condition();

            if (condition == Result.True | condition == Result.Sucsess)
                return Action();
            else
                return Result.False;
        }
    }

The problem here is how to transfer the two Func<Result> delegates from the analyzed dll, on the top of my head i can figure out two ways: Store the name and save it in a xml structure and analyze the dll again inside the bot and create an instance of the class and map the functions that way OR serialize the whole shit but that would require the external classes to be marked for serialization...

[caytchen]

Actually, marking these things as serializable won't do you any good, since you can't serialize functions. I'm kinda at a loss of words here since I don't really understand your problem. Yes, using Reflection costs a shitload of time, but you can't avoid it anyway. Just analyze all the plugins/modules at start and find types inside the assemblies that implement INode, make a list of these types and use their name as an identifier for later instanciation.

[!@^^@!]

Actually you can serialize Func<T> : http://stackoverflow.com/questions/3...delegates-in-c

And i'll give it a shot to see if I run into the same problems as the guy on stackoverflow

[XTZGZoReX]

Actually you can serialize Func<T> : http://stackoverflow.com/questions/3...delegates-in-c

Delegates are indeed serializable. However, if the type which holds the method the delegate encapsulates (damn, this sounds weird) is not marked as serializable, you will get an exception (most likely when attempting to call the delegate - not sure if you'd get it as soon as you try to serialize. I think this depends on what exactly you're doing).

[Apoc]

You'll need to implement your own attributed XML/Binary reader/writer to get the functionality you want. And the TreeSharp BT is actually incredibly simple once you understand how BTs work. If you don't, then you shouldn't even be messing with a designer yet.

[!@^^@!]

I do get your implementation Apoc (I think at least), im just not very fond of the whole Enumerator way of execution, I'd rather just do like this:

 
    public class Sequence: INode
    {
        public Sequence(IEnumerable<INode> nodes)
        {
            _nodes = new List<INode>(nodes);
        }

        private List<INode> _nodes;

        public List<INode> Nodes
        {
            get { return _nodes; }
            set { _nodes = value; }
        }

        
        public Result Run()
        {
            foreach (var node in _nodes)
            {
                var result = node.Run();

                if (result == Result.False | result == Result.Fail)
                {
                    return Result.Fail;
                }
            }

            return Result.Sucsess;
        }
    }

[Apoc]

I do get your implementation Apoc (I think at least), im just not very fond of the whole Enumerator way of execution, I'd rather just do like this:

 
    public class Sequence: INode
    {
        public Sequence(IEnumerable<INode> nodes)
        {
            _nodes = new List<INode>(nodes);
        }

        private List<INode> _nodes;

        public List<INode> Nodes
        {
            get { return _nodes; }
            set { _nodes = value; }
        }

        
        public Result Run()
        {
            foreach (var node in _nodes)
            {
                var result = node.Run();

                if (result == Result.False | result == Result.Fail)
                {
                    return Result.Fail;
                }
            }

            return Result.Sucsess;
        }
    }

That is basically how TreeSharp works, except that it supports returning Running, which allows you to pick up the tree where it left off. Your implementation only supports full tree searching each 'Run()' call.

[!@^^@!]

aha then it's more clear to me what exactly you're doing does that function have any particular use in bots? I can't think of any right away and I've never gotten very far with my own because I'm a lazy bastard :3

[Apoc]

aha then it's more clear to me what exactly you're doing does that function have any particular use in bots? I can't think of any right away and I've never gotten very far with my own because I'm a lazy bastard :3

Depends on how you design your logic. You could keep a specific Selector in the 'Running' state until your toon leaves combat. Which avoids having the tree re-pulsed when it really doesn't need to be.

There are many situations where it's useful.

[!@^^@!]

Aha I see, it's a pretty damn smart way of optimizing i must admit however i just got an idea... What about using XAML for the behavior tree? have a look at this for reference: And Now for XAML Completely Different - CodeProject ... I think it just might give me what i need

[Xarg0]

also if you intent to implement purpose based behaviour you'll need this kind of selector, it is actually not intented to be optimization but to define behaviour more clearly, so you can follow a specific branch in your tree until you either reach your goal or something else happens that would cause to stop trying.
For example if you're building a behaviour tree for a certain boss fight and this boss mob got a phase where you'll have to only dogde stuff, you'll want your behaviour to stay in the dogde boss crap branch.

[!@^^@!]

Hmm I see but it doesn't makes the behavior more clear, just more complex because now you'll have to debug what causes it to exit the state too early for example... IDK to me it at least appears more complex without adding something you couldn't do without it, but again it might be because i never coded a bot driven by a behavior tree...

Though i could see myself implementing the Running status for a whole other reason: async nodes... having those could be pretty useful for pathfinding, for example start generating the next segment of the path when we've reached a certain % of the path depending on it's length and maybe an estimate on how long time it will take.

[audible83]

first of all, make the graphical editor so you can play a bit with it, once you play around with it, all suddenly comes more clear how you can enter behaviours and use them efficiently.
While it is at first glance a bit more abstract than a straight cut FSM its much easier once you do more than just fishing.
Examples like Boss fights, one behaviour tree for each level, one for elite enemies and one for changing behaviour tree till whats appropriate...

Good luck, its loads of fun