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

Discussion and feedback on Construct 2

Post » Thu May 22, 2014 6:29 pm

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?
B
11
S
4
G
1
Posts: 159
Reputation: 1,803

Post » Fri May 23, 2014 12:51 am

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

http://upload.wikimedia.org/wikipedia/e ... ements.png
B
100
S
33
G
16
Posts: 1,204
Reputation: 16,865

Post » Fri May 23, 2014 1:24 pm

@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.
B
11
S
4
G
1
Posts: 159
Reputation: 1,803

Post » Fri May 23, 2014 2:12 pm

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.
Don't see the fnords and they won't eat you!
B
79
S
17
G
12
Posts: 323
Reputation: 11,850

Post » Fri May 23, 2014 7:11 pm

@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).
B
11
S
4
G
1
Posts: 159
Reputation: 1,803

Post » Sun May 25, 2014 4:22 am



good article thanks! I'm making a rogue-like as well! or at least modified roguelike...
B
100
S
33
G
16
Posts: 1,204
Reputation: 16,865

Post » Sun May 25, 2014 5:27 am

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
B
110
S
28
G
280
Posts: 4,487
Reputation: 156,566

Post » Tue May 27, 2014 12:59 pm

@rexrainbow That looks interesting, but how does it handle picking? I have lots of instanced sprites, and picking can be quite tricky.
B
11
S
4
G
1
Posts: 159
Reputation: 1,803

Post » Tue May 27, 2014 2:04 pm

@yttermayn

What is you mean picking? Could you provide an example?
B
110
S
28
G
280
Posts: 4,487
Reputation: 156,566

Post » Thu Jun 05, 2014 6:26 pm

@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
B
11
S
4
G
1
Posts: 159
Reputation: 1,803

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 4 guests