W.U. 11: Behaviour Tree Traversal Display

Here’s a video where the A.I.’s behaviour tree traversal is inspected. I decided against watching a traversal as it happens because of performance reasons and instead, the game records traversals and you can watch them after they are recorded.

Advertisements

W.U. 10.1: Behaviour Tree Decorators

I’ve properly changed the HasSufficientStamina hack into decorators instead:

The “enough stamina to” decorator essentially turns the action it decorates into a condition, stifling it from actually doing the action and just querying the amount of stamina it costs to do. It then accumulates that stamina cost (among siblings in the sequence) in another variable and check if the unit has enough stamina to match the accumulated cost. If not, it returns failure.

I wanted the decorator shapes to look nice when stacked on top of each other, so this is how I designed them to look like:

Here, a bunch of (test dummy) decorators are in the Retreat sequence, and a few more are in the health check condition.

Modding Options

So for modding support, I’m running the options through my head.

1. Mono dynamic code generation
? Mono/.NET allows to compile code from within code, via the Code DOM compiler
? so the idea is to let modders create C# code and the game will compile those
? compilation results in either a compiled DLL file which will be loaded, or stored in memory. if you don’t save it as a DLL, you’d need to recompile the user’s C# file every time the game is run (not really a problem)
+ possible to let end-users create C# code, code that will run just as fast as the C# code in the game
– potentially allows end-users to cheat the single-player game by editing values or forcing commands on the game, similar to Game Genie
– potentially encourages end-users to share DLL files to each other, an avenue for a security breach on a user’s PC
– won’t work on web or mobile versions as they are sandboxed environments that do not allow compiling during runtime

2. KopiLuaInterface
? a Lua interpreter written purely in C#
? modders will make Lua scripts
+ a completely sandboxed environment, users will not be able to write malicious code
+ will work on web versions
+ will also work on mobile versions

– running a Lua script is slower than running a C# script. even slower since KopiLua is slower than the standard Lua1

3. LuaJIT + LuaInterface
? Unity (via Mono) can load a DLL of compiled C/C++ code (native code)
? modders will make Lua scripts
+ a completely sandboxed environment, users will not be able to write malicious code
+ runs faster than KopiLuaInterface, even faster than standard Lua with Just-In-Time compiling
+ can work on mobile versions with a little extra work
– will not work in web builds as they are sandboxed environments that do not allow loading of native DLLs
– works only on Unity Pro
– running a Lua script is slower than running a C# script1

LuaJIT is a no-go only because I have no Unity Pro.

Mono is the fastest for this situation, but it also has more potential to create malicious code. I’m only targeting Windows standalone so a web or mobile version is irrelevant for the moment. But if I ever decide later on to move some stuff into web/mobile, then mods made in C# won’t work, and that’s a loss.

So I’m going to use KopiLuaInterface for mod scripts.

When I get Pro, it’ll finally be possible for me to load native DLLs. It will likely be possible to convert what I have to use LuaJIT instead, at least, when making the standalone/mobile version of the game. If ever a web build is released, it would just fallback to using KopiLua. The nice thing is end-users’ Lua scripts will work regardless if the game is using LuaJIT or KopiLua.


1: The speed difference between Lua and C# should largely be trivial depending on what the Lua scripts do and what it is used for. Scripts shouldn’t be executed in tight loops, but for handling events, they’ll be fine.

W.U. 10: Basic Attack AI

Here I have the enemy A.I. spamming the Lunge attack. UPDATE (2012Aug18 1540 PHT): It turns out my enemy A.I. was erroneously allowing the enemies to Lunge even when they didn’t have enough stamina points to do so. This has been fixed.

One thing to note was that it was starting to become a pixel hunting process for me to get the proper place to move to for an attack, as I suspected. This was why I wanted to make an attack preview where you see a ‘ghost’ of your unit doing the attack before you confirm the command. The ghost’s attack would highlight which units will get hit from the attack.

I also need a better stamina cost display.

Now, about the A.I., here’s the behaviour tree used for the enemies in the video:

It goes basically like this:

  1. Retreat if I need to
  2. Find nearest enemy
  3. Check if I still have enough stamina to get near him and attack
  4. Do the actual attack if I can
  5. Just close in if I can’t move and attack in the same turn

(I really wouldn’t need to add that additional check in the third step because of the way behaviour trees work. But it’s there because I plan on adding more to the tree.)

One thing I did not anticipate the A.I. to do, was that after they attack, they spend time backtracking to the proper range to do the lunge attack, so they’d be in the right position come their next turn. I was surprised that the A.I. was that clever, and yet, all it did was follow the instructions I gave it. And there it was in step no. 5 (i.e. close in if I can’t attack yet). Its just that I didn’t realize it would also do that immediately after an attack.

Editor

As for the behaviour tree editor, I was thinking of making the display look more like a folder layout, given the cramped space it needs to be shown on.

Here’s how that kinda looks like:

And here’s how my initial trial on the code for that looks like:

The purple, stretched hexagons are selectors, while the large rounded boxes are sequences. Sequences are allowed to have different colors for easier recognition.

Selectors arrange their children vertically, and sequences arrange theirs horizontally.

The white hexagons are conditions, while the white boxes are actions.

Watching Traversals

With my goals for modding support, I want to be able to show a behaviour tree in-game, so I made sure to use plain GUI code and not EditorGUI. With that I can show tree traversals as they happen. This is meant for debugging.

Stamina Cost Check Hack

The “CanLungeNow?” is a special (i.e. hack) type of sequence that I was forced to make. It basically accumulates the stamina cost of its children actions and returns failure if the A.I. agent (the unit) does not have enough stamina to do all those actions. I’m in the process of redoing it with decorators instead.

Static Tree

I designed my trees so that multiple agents can traverse one tree simultaneously. This means I can have only one tree that powers the A.I. of multiple units. While my game is turn-based and wouldn’t need such a feature, I may, however, add squadron units who will move and act together (goblin horde units).

This means nodes in the tree do not keep information themselves. Whenever they want to store information, they store it in the A.I. agent. If a node returns `Running`, it stores that state in the agent, not in the tree. Its stored in a hashtable, so they can put anything they want.

If a leaf node doesn’t have parameters, it might as well be a static class! If it does have parameters, those are most likely never changed during runtime. There could be a rare case for a need of an action that edits the tree it is in (self-learning A.I.?).

Flattening A Tree

Using Mono’s dynamic compilation features (allowing code to compile code), I can convert a behaviour tree from what it is right now, a bunch of classes arranged in a tree, to just one class with selectors and sequences converted to a bunch of nested if-else-if chains.

Most likely the leaf nodes (actions and conditions) need to stay as classes, but at least tree traversal will surely be faster, because there is no tree to traverse anymore; traversal is hardcoded for the most part. This is most likely what AngryAnt’s Behave library does as well.

W.U. 9: Retreat Behaviour

(Finally gotten around to making my screen recorder work at tolerable speeds. The sound also works though its really just recording from a microphone. Its also registering properly as 720 HD on YouTube now.)

Here is a demo video of the retreat behaviour, although it takes quite a while (i.e. multiple turns) until they figure out where to really go. I suspect once I start using influence maps this will work better.

W.U. 8: Behaviour Trees

That screenshot right there means the fundamentals of my behaviour tree library is working.

As a side effect of me using unit tests, I made the code output a debug text of the whole tree when traversing.

This is all only the framework though. The next things to do are add more meaningful actions and conditions (like Retreat, Charge, Snipe, AmISurrounded, AmIDying, et al), and then make a visual editor for this.

Again, I’m storing the data in JSON format. Here’s an example:

{
    "__type": "BehaviourTree.Root, Assembly-CSharp",
    "Label": "Root",
    "Remarks": null,
    "InheritsFrom": null,
    "Children": [
        {
            "__type": "BehaviourTree.Selector, Assembly-CSharp",
            "Label": "Sel1",
            "Remarks": null,
            "Children": [
                {
                    "__type": "BehaviourTree.Sequence, Assembly-CSharp",
                    "Label": "Seq1",
                    "Remarks": null,
                    "Children": [
                        {
                            "__type": "TrueCondition, Assembly-CSharp",
                            "Label": "Scond1",
                            "Remarks": null,
                            "Children": null
                        },
                        {
                            "__type": "TrueAction, Assembly-CSharp",
                            "Label": "Sact1",
                            "Remarks": null,
                            "Children": null
                        }
                    ]
                },
                {
                    "__type": "BehaviourTree.Sequence, Assembly-CSharp",
                    "Label": "Seq2",
                    "Remarks": null,
                    "Children": [
                        {
                            "__type": "TrueCondition, Assembly-CSharp",
                            "Label": "Scond2",
                            "Remarks": null,
                            "Children": null
                        },
                        {
                            "__type": "TrueCondition, Assembly-CSharp",
                            "Label": "Scond3",
                            "Remarks": null,
                            "Children": null
                        },
                        {
                            "__type": "TrueAction, Assembly-CSharp",
                            "Label": "Sact2",
                            "Remarks": null,
                            "Children": null
                        }
                    ]
                }
            ]
        }
    ]
}