Game AI: Implementing a behavior tree in C2. Thoughts?

I am just dipping my toes now into writing AI for my game's mobs, and after writing several behavior states, have reallized the need for better organization. After reading about AI architectures, it turns out that a solution I was cooking up is already a thing: behavior tree. Has anyone else written some behavior tree AI stuff in C2? Specifically, I'm looking for the best way to implement it in C2's event->action structure.

Thoughts?

do you mean having multiple behaviors that are linked by similar nodes or integration points?

http://upload.wikimedia.org/wikipedia/e ... ements.png

jobel That looks similar, but applied to train systems. I'd prefer to stay in the realm of games. This is the article that explains it better, and in text that is large enough to read http://intrinsicalgorithm.com/IAonAI/2012/11/ai-architectures-a-culinary-guide-gdmag-article/

Multiple behaviors that are chosen by a single chunk of decision making logic, aka. the "Soft Taco", is what I'm going for. I don't think I will need anything more complicated at this point.

I started working on a behavior tree plugin quite a while ago, but finally gave up because of various issues. The biggest issue i had was dealing with game states, and the complete lack of structure in the variable stack of objects. The variable stack, specifically instance variables, are not hard coded at design time, so when you have more than 1 instance variable in an object, there is no way to reliably reference that variable at run time.

Perhaps things have changed, or perhaps i was just ignorant of how to effectively access the variables, but i finally gave up. I'm sure rexrainbow would have some useful input into this, since he's created a Finite State Machine plugin.

Wastrel Thanks for the reply. I think things may have changed, but I can understand your frustration. It took me awhile to figure out exactly how to get the correct variable from one of several instanced objects. Because I am writing a roguelike where everything is procedurally generated, it's become a necessity to understand the picking system (this is probably where you had trouble also).

http://intrinsicalgorithm.com/IAonAI/2012/11/ai-architectures-a-culinary-guide-gdmag-article/

.

good article thanks! I'm making a rogue-like as well! or at least modified roguelike...

The behavior tree looks like to separate the decision logic outside the transition actions.

My fsm plugin/behavior used this architecture already, you might reference my document of these plugins.

http://c2rexplugins.weebly.com/rex_gfsm.html

rexrainbow That looks interesting, but how does it handle picking? I have lots of instanced sprites, and picking can be quite tricky.

Yttermayn

What is you mean picking? Could you provide an example?

rexrainbow Construct 2's event based system depends heavily on what they call "picking". In the structure of Condition->Action, you choose which objects are affected by the Action from within the Condition part of the event. That is called "picking". IE: If you have a bunch of objects that are all instances of the same object, and you only want to affect certain instances, you must "pick" those instances in the Condition part of the event. Say you have a bunch of enemy sprites that are randomly placed on the map, but you don't want any to start on top of the player's base. You could have an event that says in the Condition portion "on creation of enemysprite", (this picks only enemy sprites that were just created), followed by "enemysprite overlapping playerbase", (this picks only enemysprites which are overlapping the player's base, filtered out of the batch who were just created). Then in the Action portion of the event, you could say "enemysprite destroy". Only the enemy sprites which were just created AND who happen to be overlapping the player's base will get destroyed. You can think of the conditions as ways of filtering or weeding out those objects that you don't want the Action to apply to. Only the objects which meet ALL the requirements in the Condition will be acted upon. This is what is meant by "picking".

Here is the relevant manual section: https://www.scirra.com/manual/75/how-events-work

Uh, I mean that why you need picking in you AI struct? Is it something special? Sorry for the mistake.

rexrainbow Oh, heh. I was wondering how you wrote a plug-in without understanding picking. My AI blocks have to work with am entire family of mobs, with multiple instances of each family member who may be in totally different situations.

Thus the need to pick particular instances based on the instances circumstances; they won't all be doing the same thing. Not sure if I am answering your question or not.

If I was to try to use behavior tree arch, it seems to me that I would have to separate the condition portion, which contains the picking, from the action. But maybe that's just me not seeing how to make it work. Anyway, that's why the initial question.

Yttermayn

You are right.

My fsm behavior maintains a state variable for each instance, and one instance could have more then 1 fsm behavior, they work individually.

Just see the sample capx in the document.

rexrainbow Ok, I am intrigued by your plugin. It may be too late to use it for this particular project because my AI as it is is nearly done as far as the overall structure is concerned, just need to polish the states. However, there is another project I might try to use it for. So I ask, since I hope to release and sell my games someday, are there any strings attached to the use of your plugin? If so, what are they?

Nothing need. Just tell me the link of your game, heh.

I had made another fuzzy plugin for game AI, but I still could not use it well.