[C#] Behaviour trees a different way

[!@^^@!]

I came across a nifty article on codeproject i thought i'd share with all of you:

And Now for XAML Completely Different - CodeProject

The reason i think this is interresting is because it doesn't take much imagination to see how we can let MS do all the hard work for us and build behaviour trees in XAML by exposing the different node types (Selector, sequence, action, condition etc)

Hell it shouldn't even be too difficult to write a designer interface for behaviour trees this way if you use WPF and some simple type conversion from the various behavior tree node types into shapes or explore the possibility of extending the visual designer in VS or blend.

Anyone else have some ideas for good usages of this?

And for those not knowing what a behavior tree is: Understanding Behavior Trees*—* AiGameDev.com and Behavior Trees for Next-Gen Game AI (Video, Part 1)*—* AiGameDev.com

----------EDIT----------

Okay so I finally found some time to wrap this together and tie it up neatly which resulted in this kind of XAML:

<Root xmlns="clr-namespace:XamlBT;assembly=XamlBT" xmlns:d="clr-namespace:TestBT;assembly=TestBT">
    <Root.Child>
        <Sequence>
            <ExecuteMethode Function="{StaticMethode d:Program.Test1}" />
            <Selector>
                <InverseCondition Status="{StaticProperty d:Program.B}" />
                <ExecuteMethode Function="{StaticMethode d:Program.Test2}" />
                <ExecuteMethode Function="{StaticMethode d:Program.Test3}" />
                <ExecuteMethode Function="{StaticMethode d:Program.Test4}" />
                <ExecuteMethode Function="{StaticMethode d:Program.Test5}" />
            </Selector>
        </Sequence>
    </Root.Child>
</Root>

The above example can simply be constructed by calling Root.LoadFromFile("Test.xaml"); and the call evaluate() on the returned root object at every frame...

There are a few things to take in note with this solution: It's very simplistic, doesn't seperate conditions and branches/leafs for coding simplicity, it's NOWHERE near as clean or well coded as Apoc's behavior tree project, there's no context support (yet) and it doesn't support calling methodes with paramters (also yet, might implement that later) but it might be usefull for someone who's looking to get started with behaviour trees...

Download: Filebeam - Beam up that File Scottie! (Sorry about it not being an attatchment but mmowned wouldn't accept it so i gave up after 4 reuploads)

[XTZGZoReX]

While the idea may sound good, carrying it out is not at all easy nor pretty. XAML is absolutely fugly when your code grows. Maintenance would be hell.

[!@^^@!]

You're probably thinking about the XAML generated by VS or blend which yes is fugly and hard to read but that was never ment to be read just like winform designer code wasn't meant to be read either... Secondly just as you would with more complex VMMV applications, it's possible to split the XAML/tree into multiply files which also helps resuseability

As for the difficulty of coding, it's actually quite easy because you don't need to deriver your node class from any specific class or interface to enable usage of it in XAML, it simply accepts any CLR type with a public argument free constructor (version 4 even supports constructors WITH arguments) so i'm pretty sure it's even possible to reuse Apoc's BT project although it's probably not very XAML friendly and would look fulgy...

I'm at least working on an implementation of it right now where it's as XAML friendly as possible and my only issue so far has been that i didn't quite know the best way to connect the actions and conditions to static properties or functions without requiring ugly and bloated XAML

[schlumpf]

So your idea is to write a bot using scripts which then call the real functions via some API with using some framework? Where exactly is the new thing here?

[!@^^@!]

I never claimed it to be anything new or exciting, i was merly pointing out the usefullness of the XAML parser microsoft is maintaining for us because from how i understood Apoc's BT it would either be hardcoded or require quite a bit of work (de)serialize

[XTZGZoReX]

Look, the idea of having code in XAML is on par with this: X++ Language Programming Guide

While it may seem all fancy at first, it is not maintainable at all. Sure, if you're a single developer and no one else is gonna maintain your code, go for it. But you can't assume that every .NET programmer has expertise in XAML; it's a language/syntax intended for UI programming. Assuming anyone knows it is like assuming anyone knows SQL, which is obviously not the case (hence why we have LINQ).

[!@^^@!]

Ok I think we're talking past eachother here because the whole coding in purely XAML was just a side note and a bad idea at best, the main focus is still the behaviour tree which with all due respect can't see how would be less maintainable this way.
I apreciate your feedback though and yes i do agree that not everyone knows XAML but again this was meant for behavior trees, not coding a whole bot with a few core API's for mem reading and what not...

Also i cleared up the main post to clearify this...

[!@^^@!]

Updated first post with source code if anyone is interrested...

[amadmonk]

Behavior trees are simply a way of building scriptable, composable behavior code without writing your entire AI in a scripting language. The idea behind them is that you have native code that is executed as leaf nodes in the tree, and then you use the tree mechanism -- whatever mechanism you choose, the IEnumerable thing that Apoc & co. are using, an XML/XAML interface, whatever -- to compose and reuse the logic elements.

It's not a BAD idea, but it's also got some really unnecessary assumptions built in, one of which is that you have to write your AI in compiled code! With a WoW bot, we have this lovely, powerful scripting language -- Lua -- at our disposal, which obviates the number one reason for using BT's in the first place (composing native code without requiring compile changes).

As far as using a XAML processor, I'm not sure exactly what the complaints are; XML is a fairly natural way to express BT's. The only thing you're missing is a UI designer (since I assume that none of the existing designers would work), but that shouldn't be too hard to create. You could probably even get it to integrate into Visual Studio. As long as XAML lets you cleanly do inter-document references (I'm not 100% up to speed on the syntax) so that you can reference sub-trees from within a BT, it should be a natural fit for behavior tree design work. I certainly don't see that using XAML would be any more cumbersome from a maintenance perspective than any OTHER way of expressing BT's; I'm curious why folks are claiming that.

[!@^^@!]

Thanks for the feedback amadmonk, I appreciate it

You actually gave me an idea with the lua thing, which is that executing lua directly from a node could be kinda usefull... As for the complaints about XAML, i think they were directed at my silly idea of doing stuff similar to the codeproject article and implement something like this:

<Main xmlns="clr-namespace:MarkupScript;assembly=MarkupScript">
  <!-- This little script shows some basic usage -->
  <Main.Variables>
    <Variables>
      <!-- Define some variables with and without default values -->
      <Variable Name="UserInput"/>
      <Variable Name="RandomNumber" Value="{Random 9}"/>
      <Variable Name="InputPrompt" Value="Enter a number:"/>
      <Variable Name="NumberOfGuesses" Value="0"/>
      <!-- Define some expressions to show what they are usefull for. -->
      <Expression Name="TooSmall" Value="{LessThan Left={Get UserInput}, Right={Get RandomNumber}}"/>
      <Expression Name="Match" Value="{Equal Left={Get UserInput}, Right={Get RandomNumber}}"/>
    </Variables>
  </Main.Variables>

  <!-- Define a simple function to get the users input since this is used twice -->
  <Main.Functions>
    <Functions>
      <Function Name="GetInput">
        <!-- Set the value of the UserInput variable by calling Input expression -->
        <Set Variable="UserInput" Value="{Input Prompt={Get InputPrompt}}"/>
        <Increment Variable="{Ref NumberOfGuesses}"/>
      </Function>
    </Functions>
  </Main.Functions>

  <!-- Output some text to the user -->
  <Echo Text="I drew a number in the range of 0-9. Try to guess it!"/>

  <Call Function="GetInput"/>

  <!-- Loop while the user input does not match the random number. Match is a boolean expression (s.a.) -->
  <While Condition="{Not Value={Get Match}}">
    <!-- If we get here the number does not match. Output some text to the user -->
    <Write Value="The number is too "/>
    <Write Value="{Choice Condition={Get TooSmall}, Match=small, Else=large}"/>
    <WriteLine Value=" Try it again!"/>

    <Call Function="GetInput"/>

  </While>

  <WriteLine Value="Congratulations. You've got it!"/>
  <Write Value="You did it with "/>
  <Write Value="{Get NumberOfGuesses}"/>
  <WriteLine Value=" guesses."/>

  <Pause/>

</Main>

which i later edited out because it honestly was kinda stupid...

I don't think it's possible todo "inter-document references" without writing a class like this:

public class LoadSubTree:Contracts.ISingleChildNode
    {

        public LoadSubTree(string path)
        {
            _child = Root.LoadFromFile(path);
        }

        #region Implementation of INode

        public bool Evaluate()
        {
            return Child.Evaluate();
        }

        public string Name { get; set; }

        private string _type;
        public string Type
        {
            get
            {
                if (string.IsNullOrEmpty(_type))
                {
                    _type = GetType().Name;
                }

                return _type;
            }
        }
        #endregion

        #region Implementation of ISingleChildNode

        private INode _child;
        public INode Child
        {
            get { return _child; }
            set { throw new InvalidOperationException("Child is loaded from file, DO NOT SET in XAML!"); }
        }

        #endregion

        [ConstructorArgument("path")]
        public string Path { get; set; }
    }

And yes writing a designer for this should be fairly simple, I don't know with integrating it directly with the visual studio designer or blend though, It's most likely possible but could potentially lead to a lot of headaches, especially considering how bad the VS wpf designer is

[amadmonk]

Well, inter-doc references are critical if you want composability (which is pretty important since it's one of the key tenets of BT's). It's much nicer to be able to write one XAML called "AttackBehavior.xaml" and another one called "LootBehavior.xaml" and reference them both in "main.xaml" -- than it is to have to keep EVERYTHING in "main.xaml"; that would, I'd agree, be a nightmare of maintainability.