PlayMaker Help & Tips > PlayMaker Tips & Tricks

Improve your FSM design magic

(1/3) > >>

waveform:
I have seen lot people FSM looks like



or



The Fsm looks bad, fuzzy and very complicated.

That's why I have to write this topic to fix it

Cant wait anymore? Here we go:

1.
Improve switchs:
improve switchs is very important thing, people probably get lost then it comes a huge number.

Bad example:



to improve this need "go to state by name" from ECO system

Good example:



more exampel



2.
Use "Action sequence" to improve "Compares" and "tests".
im pretty sure compares and tests is probably the most used actions in your project, it ends up with a lot states, this`s not you wanna to see right?

let fix it.

Bad Example:



Change it to:



Example 2 :



3.
Reduce events use.
I have seen people use events for any thing and every thing, it end a huge number  of events to make project very difficult to debug and manage.

improve events use by reuse same event over and over again, it require a good namn such as: 0(for false) 1(for true or finnish).

if use unity events:



FSM setup:



4.
Split large FSM to templates
It hapend a lot times, people make a large FSMs for something like, inventory, loops. and it makes hard to debug
what i want to say is: just split it to templates and add finnish action endof the FSM.

nest fsm:



finnish state:



5.
use templates +  "run fsm" to toggle FSMs and nest FSMs.
Stop use a lot FSM componnents to toggle things, it will make inspector lag and difficult to find FSM.

Bad Example:



Turn it into:





Walk setup:



Jump setup:




Example for NPCs:

jeanfabre:
Hi,

 I am sorry, but I strongly disagree with you on this. While perfectly fine, your solution remove an entire section of visual scripting benefits, namely being able to visually follow what's going on even when not running and understand complex/dynamique sequences.

I am actually in favor of what you describe as not good fsm layouts, in many ways. to me they look fine and I am developing exactly like that myself. If I had to comment and critic the fsm you showed, it would be that they take too much responsability, and not because of their actual layout. To me, them layouts are perfectly readable and make sense with good naming conventions and clear sequencing/positioning.

I never use the go to name by state action, unless if by design I wanted a dynamic link to begin with, with is the case in 0.1% of all the cases I encountered in almost 9 years working with PlayMaker. One clear case is matching a mecanim Graph. I made an addon on the ecosystem which lets an Fsm have its state activated based on a mecanim graph. That scenario and its variants is fine.

The other cases, is when you clearly have spaghetti code, but in that case, I always recommend to split in multiple FSM, instead of going for linkless state transitions. Else I recommend to use local events as global transitions ( transition above the state).

Do you understand that your solution means less information in the end for the developer? I am not sure for your solutions that it's intuitive and clear. What if you end up with multiple cascading switch states, your fsm will make no sense very quickly because you won't be able to track down the path of execution easily.

Also, it's a very bad habit to not name states properly, in your cases, you lean states like "State 1" "State 2", and that's not recommended neither. Maybe you could share real fsm that your use in your projects? that would make more sense than making mock ups.

I hope you don't get mad at me for being straight on that topic :) but I think it's important to get feedback on this.

 Bye,

 Jean

waveform:
Hi Jean
thanks for the quick reply
2 years ago, i using 100% playmaker for my project,and decided to deprecate it, because the fsm is too complex to read and almost imposible to debug.

my old FSM looks similar to this image:





Afterthat I started learning code, and feel reading code is actually much easier than watching FSMs.

I got a new understanding of playmaker, I no longer use it as the core system, it`s more just a tool for assisting code, i also improved my FSM design to looks more similar to code, it works very well for me

my most complex FSM in current project





it looks very clean because everything is nested and splited


--- Quote from: jeanfabre on July 08, 2019, 09:14:25 AM ---Hi,

 I am sorry, but I strongly disagree with you on this. While perfectly fine, your solution remove an entire section of visual scripting benefits, namely being able to visually follow what's going on even when not running and understand complex/dynamique sequences.

I am actually in favor of what you describe as not good fsm layouts, in many ways. to me they look fine and I am developing exactly like that myself. If I had to comment and critic the fsm you showed, it would be that they take too much responsability, and not because of their actual layout. To me, them layouts are perfectly readable and make sense with good naming conventions and clear sequencing/positioning.

I never use the go to name by state action, unless if by design I wanted a dynamic link to begin with, with is the case in 0.1% of all the cases I encountered in almost 9 years working with PlayMaker. One clear case is matching a mecanim Graph. I made an addon on the ecosystem which lets an Fsm have its state activated based on a mecanim graph. That scenario and its variants is fine.

The other cases, is when you clearly have spaghetti code, but in that case, I always recommend to split in multiple FSM, instead of going for linkless state transitions. Else I recommend to use local events as global transitions ( transition above the state).

Do you understand that your solution means less information in the end for the developer? I am not sure for your solutions that it's intuitive and clear. What if you end up with multiple cascading switch states, your fsm will make no sense very quickly because you won't be able to track down the path of execution easily.

Also, it's a very bad habit to not name states properly, in your cases, you lean states like "State 1" "State 2", and that's not recommended neither. Maybe you could share real fsm that your use in your projects? that would make more sense than making mock ups.

I hope you don't get mad at me for being straight on that topic :) but I think it's important to get feedback on this.

 Bye,

 Jean

--- End quote ---

jeanfabre:
Hi,

 Thanks for clarifying.

I would however still be careful if someone new to Playmaker reads your post, because I do not think that this is the most effective use of Playmaker by far, however, this is where Playmaker excels and is border line genius: Indeed it is flexible to be used in different ways, such as how you described it.

Bye,

 Jean

Thore:
Superb topic! I guess one take away is that there’s currently an expertise or tutorial gap for advanced Playmaker designs. For coding, there are all these best practices that are taught alongside the syntax. Playmaker takes care of the syntax, but the rest is still pretty important – and a bit missing.

I early on avoided large christmas trees of FSMs and split them up into units that make sense on their own.

I triangulate between three requirements: (1) keeping the FSM as small and containted as possible doing one clearly identifiable role (2) as little dependency as possible, and (3) while also avoiding redundancy.

In the first point, The “role” is either a mechanic or its representation, but not both, which I keep separate.  I currently work on input mechanics and try to keep them separate as well, but it’s not trivial. For example, the jump currently listens for a bool in another FSM. The Jump FSM itself applies the force, but does not contain anything about sound, animation or particles (“effects”). It only sends off an event that it’s now currently jumping to yet another Effects FSM which then sets everything to look and sound right.

I am curious about Jean’s super atomistic designs, especially how can I keep track of FSM dependency. It sounds you (Jean) use a thousand FSMs, handling miniscule tasks. How do you organise things? How am I going to remember in a few months that some mechanic is composed of three FSMs? How do I keep them syncronized? How do I organize the templates? I find templates a complete hassle at the moment, but eventually need them once I scale up.

One thing I ignored as a newbie, but learned to love are using paths on FSM names (e.g. Input/Jump) and global events, but there lies another danger. And while we are it, is there some way to talk to FSMs without going over a string for Send FSM? Occasionally I needed to refactor, but then every naming breaks and I have to sift through everything to update send to actions. Normally, in Unity, renaming does not break references.

Navigation

[0] Message Index

[#] Next page