Advice on FSM for 3RD Person navigation and animation

[yezzer]

Hi!

I've made a few things with Playmaker, and I think it's absolutely fantastic, and pretty intuitive too.

I'm making a 3RD person ARPG style thing:



..and I'm wondering what the best practise is to construct the FSMs to control the player and NPCs. Each character has between 10-30 animations.

Would you advise one for dealing with the logic, and a separate one for dealing with the animation graph? Or combine them into one huge - perhaps unwieldy - FSM?

Currently each character has one FSM for controlling everything, but I'm wondering if it's a better idea to separate them before I get too involved in creating something that's going to be a pain to pick apart later.

Or is there some other way? Any advice is greatly appreciated..!

[Edit: i initially posted this in the wrong forum, moved it to here. whoops!]

[yezzer]

A bit more info:

My current GameObject hierarchy for a character looks something like this:
- CharacterGO ('empty', only has navmeshagent, collider, rigidbody, and current FSM)
  - CharacterModelGO (animations)
    - Mesh, rigging etc from here on down

I was wondering whether to have the logic FSM attached to CharacterGO, and the animation controller FSM attached to CharacterModelGO, and to send events from the logic FSM to the animation FSM.. but after reading this, I wonder whether a sub-fsm might be useful?

http://hutonggames.com/playmakerforum/index.php?topic=1366.0

[jeanfabre]

Hi,

 you can go a long way withotu going for sub fsm. I suggest you tackle this when you will have more confidence into the right design patterns in playmaker,

It doens't reallc make a difference where you will put the logic, since fsm can communicate with each other.

 I for example, tend to create a "META" fsm, to hold variables, and then have fsm spreaded around my hierarchy for my player that all get and set varaibles in that meta fsm.

This way, external systems ( ennemies, environment) only have to interact with the "META" and not care about the implementation within the player hiearchy

 I even go into creating a emtpy gameObject just to hold this "meta", then what ever of the type of player or agent, I stick to that structure and know I will find a meta fsm that I can query with a common api I will have defined.

 bye,

 Jean

[yezzer]

Do you have any examples of suitable design patterns for PlayMaker? I've been coding in object oriented languages for many years, and am familiar with many design pattens, but it's taking a while for PlayMaker to 'click' in my head..

[jeanfabre]

Hi,

I wanted to start a section on design patterns, but really I quickly realized that studying the provided samples is really about design pattern...

So, I would suggest you go through the playmaker samples, and possibly the m2h game ports I did, they are simple and really hilite how playmaker can be used on simple cases.

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

http://www.hutonggames.com/tutorials_game_design_with_playmaker.php

Bye,

 Jean

[Red]

Personally, i'd go with the "many FSM's" route... you can make them able to communicate with eachother rather easily with the "get/set fsm" actions and the "event" actions. it might take a hit on processing since you're going to have more FSM's active but to me it seems like a worthy sacrifice for ensuring that you don't get lost and lose track of what FSMs are doing what.

though, be sure to name the FSMs appropriately... i've made the mistake of just using the default naming conventions and it was a nightmare to untangle all that.

p.s. the game looks boss btw!