General guidance for complex sets of actor FSMs

[Blindsight]

Hey all, totally new to Playmaker and I've done some research along with just diving into making FSMs. Part of me is happy with them, the other is seeing this going wildly out of control and would like some guidance.

As it is I have multiple components on my actor that are responsible for various tasks. To simplify I have the following objects with FSMs on them:

Brain: Overall Planning
 - SightSensor (with collider trigger): managing others in sight
 - AttackRoutine: deals with combat

Then I also have additional objects on the actor for things like Melee range colliders etc.

I've found most of my FSM 'coding' is communicating between all of the different components via set FSM GameObject/Bool & GameObject/Bool changed

I've read a bit about SubFSMs but before I go digging too deeply into them I'd like to ask how people set up sensory-type systems like this (without using globals). I'd like things to be as compartmentalized and interchangeable as possible so I can just swap out the AttackRoutine component for a different one and have it all continue to work as expected.

Any tips are appreciated!

Now off to see if I can basically prefab SubFSMs and specify though a script what SubFSMs to have an FSM create...

[jeanfabre]

Hi and welcome

You are on the right pass indeed. What you call brain, I call "meta" in my projects, and it actually is simply the interface I expose for a specific feature to the rest of the application, other component can rely on the content and variable exposed in all my Metaxxx and I have a stric naming convention to allow for flexible loose referencing when I want to access a fsm av using "Get Fsm XXX" or "Set Fsm XXX".

 my meta fsm are actually only data repositories, they don't perform any tasks actually, I leave that to fsm within that hierarchy of gameObjects. but you can of course put some logic management in your meta to act as a clever interface indeed.

As for sub fsm, it will allow you to reuse logics, and that's very powerful, you will also find that using prefabs will also provide you with powerful and flexible mechanism to provide flexible features.
 
I encourage you to study the game examples I ported to playmaker and for example how the photon network demo was created, this will certainly give you some directions to study and reflect on hopefully.

https://hutonggames.fogbugz.com/default.asp?W880
https://hutonggames.fogbugz.com/default.asp?W928


Keep us up to date with your progress!

Bye,

 Jean

[Blindsight]

Thanks for the reply, examples and encouragement!

I took a look at the examples, but they were a bit too straight forward for what I'm getting at.

I'm looking for any tips to creating a multi-part AI built off of many different FSMs. My current issue is the communication between them all as well as finding them all on the object in the first place. It is easily done, but for each FMS to have to communicate with 2 or more other components it seems unwieldy.

I have a feeling I'm just going to end up writing custom actions to link everything together correctly -- but then start wondering why I'm even using playmaker...

[jeanfabre]

Hi,

 Playmaker will be the glue for your custom actions to perform the desired behavior. So you should write custom actions like Lego bricks. If your custom actions is doing too much, indeed playmaker will not be able to express itself.

What kind of custom action you are thinking of writing?

Bye,

 Jean

[Blindsight]

I already have a few such as checking LOS between two objects and pathing to a given point -- and those are working fine.

I'm certainly doing something wrong though. My issue is with the organization of everything. For instance, I have a character with a weapon. The weapon has an OnTriggerEnter script which controls the hitting of other actors which is all fine and dandy except the trigger may go off more than once when swinging at an actor (due to various reason). "Okay," I say to myself, "so after the first hit I'll just disable the weapon until the end of the swing animation".

But this is pretty bad. My weapon now has to know about the animation duration on the character wielding the weapon. You _CAN_ get the animation dynamically, due to having a string structure for how each actor is built so all of the components are in the exact same location on each of them.

I'm sure I'm just not thinking about this in an architectural way that lends itself to playmaker well. I'd really like some guidance. Right now here is one actor, how the game objects are layered and where the FSMs are:

Code: [Select]

Actor: contains scripts/components for Animations, Controller, Pathfinding, health etc
- Model
- - Body
- - - Arm
- - - - Hand
- - - - - WeaponMount
- - - - - - Weapon: FSM for control damage to those it contacts.
- Brain: FSM containing high logic states (idle, attacking...)
- - Attack Routine: FSM denoting how this actor attacks
- - Sight Radius: FSM Deals with LoS to target and alerts brain if target is in sight
- - Proximity Sensor: FSM dealing with swinging weapon when target is in range

As it is the Weapon needs to know about the animation component,
The Brain needs to know about the Attack Routine FSM,
Attack Routine FSM needs to know about the Controller component,
SightRadius needs to know about the Brain FSM,
Proximity FSM needs to know about the Brain and Attack Routine FSMs.

This would be the opposite of decoupling and really bothering me. I've got to just be thinking about things wrong and would really like some guidance.

Thanks!

[jeanfabre]

Hi,

 ok, maybe you need to apply some kind of "MVC" goodness in there. MVC is not easy to apply within playmaker, but the concept of having a controller that knows everything, and a view that doesn't know anything about the rest is a good thing and it works for me very well.

 so, have a weapon controller, that don't even need to sit in your hierarchy, it can simply leave anywhere ( within reason...). Your weapon gameObject is your "view", in your fsm controller, you will do the dance between all the various elements and dispatch calls from the animation back to the weapon, etc etc.

 At some point, linking stuff together is unavoidable especially in Unity, where it's been designed this way, you drag and rop references everywhere, so you shoudl embrace this actually. and maybe write a controller for your animation, and the weapon controller talk to the animation controller... it may sound too much, but that's actually how flexibilty is achieved, the animation controller creates a gap between the implementation and other element that needs to interact with it.

typical example, instead of your weapon having to "knowi" the wielding animation lengths, your animation controller should fire and event "WIELDED" or something, that any fsm can respond to, and your weapon would actually, then it doesn't matter for the weapon how the wielding animation was performed, it just waits for the event to fire...

does that make sense?

bye,

 Jean