PlayMaker Help & Tips > PlayMaker Tips & Tricks

Improve your FSM design magic

<< < (2/3) > >>

djaydino:
Hi.
I also like to have more states and transitions that using 'go to state by name'
i have been using that a while but went back from that, when i had to trouble shoot some older project.

All my states are named and many have descriptions as we, so if ever i have to go back to the project a few years later it will be easy to read and find an issue or change something on it.

I do think that run fsm and using templates is a good thing, and the new run fsm on PM Beta looks Promission as it has input and output.

i also mostly use send event by name instead of send event.
I also have a fsm with all the references i need (send events/array maker/easysave/playerprefs keys.

Then on another fsm i will get the needed reference @start and then use the reference for sending events, accessing array lists, reference to save to easysave, etc..
This way if i want to change a reference name i only need to do this in the reference fsm (and on array list component for example)

btw i also recently noticed that you can set categories on templates which makes it easier to find them in the list.
Just select a template in the project window, and you can set a category in the inspector.
you can also use / for sub categories btw.

Other things i also do is color my states to 'group' certain states.

Broken Stylus:
Waveform's methodology obviously breaks the point of a FSM system but if it's not meant to be read by anyone else, then perhaps it's fine. It's a solid example of the potential of the "go to" action.
I think a proper FSM should have classic transitions, but you are going to meat the spaghetti problem sooner or later and it quickly becomes obvious you need to find a way to move the flux around without following visible links.
Typical way is with using local events to return to "zones" in your FSM.
Waveform's alternative is using gotos to do that, but he totally loses visual clues. However, it's his project so he knows what he's doing and it is indeed a great thing that one can go that way, but I would strongly advise against that.

I would just go nuts without being able to follow at least a minimal amount of obvious paths. Those paths have a simple and powerful function: to avoid putting useless (over)pressure on your own mental RAM to remember what every single state does and how it communicates with other ones under the hood.


--- Quote from: Thore on July 08, 2019, 02:42:36 PM ---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.
--- End quote ---

Oh yes, that's sometimes a hard decision to take. It seems silly but I believe the same problem arises in coding; deciding what script will do what, even for very itty things. You want to have a FSM be logical and intuitive, so before you even know it, you start pushing bits of scripts here and there, perhaps wasting minutes or hours deciding if a function should be handled in this FSM or another one, not for efficiency but uniquely for the sake of order. And in the end, when being satisfied where a certain function is handled, it is actually satisfactory because you don't have to search for it beyond what is fairly obvious as to where it should be. So thinking a lot about how to organize and split FSMs is actually not a waste of time to me.


--- Quote ---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.
--- End quote ---

That's an interesting subtopic in itself. I hardly use FSM templates because I don't find them easy to access for data reading and I'm all too worried about them being created and destroyed as objects and therefore leaving an imprint on memory management.
Can they be recycled? Can a given number of FSM instances be pre-cached/pooled?


--- Quote ---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.

--- End quote ---

A tool would have to scan the entire project and its scenes to spot references to events. But since certain actions use text fields as arguments instead of dropdown options with automatically listed references for events or vars, it's harder I suppose to go up the tree and find those little isolated fruits.
It would be veeeeeerrrrrry useful though.

Broken Stylus:

--- Quote from: djaydino on July 08, 2019, 06:56:52 PM ---i also mostly use send event by name instead of send event.
--- End quote ---

Any reason why? Doing so would tend to reduce even more the number of trackable references, right? Unless I get it wrong, Playmaker couldn't see these manually typed references? Or does it keep track of them too now, parsing all string fields in actions known for using events?


--- Quote ---I also have a fsm with all the references i need (send events/array maker/easysave/playerprefs keys.
Then on another fsm i will get the needed reference @start and then use the reference for sending events, accessing array lists, reference to save to easysave, etc..
This way if i want to change a reference name i only need to do this in the reference fsm (and on array list component for example)
--- End quote ---

The anti-Globals inquisition strikes again!  ;D


--- Quote ---Other things i also do is color my states to 'group' certain states.

--- End quote ---

Interesting.
The problem with colours is that a large range of them cannot be used because the text remains white. If text colour could auto change to black (or allow colour to be manually set) or/and also allow outlines/underlines on the text, this problem might be solved.

jeanfabre:

--- Quote from: Thore on July 08, 2019, 02:42:36 PM ---For coding, there are all these best practices that are taught alongside the syntax.

--- End quote ---

I wish it was the case... but after so many years on google trying to find the best way to code, I have to say that I did not found these best practices to be available in any other form than by small chunk of advices spreaded out across forums and videos. Pretty much the same as with PlayMaker or any other complex systems. Even Unity own Learning content material is riddles with various memory leaks, bad coding strategies, etc etc.

 I don't think there is any other way to learn the best practice then by practicing yourself and along the way pick up a vibe and "intuition" as to how to start a feature, where to create flexibility, where it doesn't matter, where to make sure it performs sharply and where it doesn't matter, and always be curious as to how other would have tackled this, and google for it, ask questions, etc...

Only personal experience can encompass this level of expertise.

Bye,

 Jean

jeanfabre:

--- Quote from: Thore on July 08, 2019, 02:42:36 PM ---
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.

--- End quote ---

I don't use template that much, maybe for buttons, panels, and very high level features like that.

 2019 and the new nested prefab makes thing so much easier now anyway.

I use indeed micro fsm a lot, I keep track of it by simply making sure I stick to my strategy on design pattern, then all fsm pretty much look the same, and are expected to perform the same, as far as their responsability, what they could send, what they could want to receive and read, hence the "meta data" fsm, the very descriptive/organized event naming convention, and careful naming of everything, withoitu fear of refactoring should this naming become obsolete and needs refactoring (which happens always, on real world project, where client changes his mind of tells you the key to the project logic mid production...)

Since I went for micro fsm, I realized that  "Divide to conquer" is essential, it works every where, not just in lifef ro good or evile reasons... it works magically for coding. Again, I'll use the Lego analogy, Lego is a wonderful structural guide, make small blocks that you can reuse, like at a prefab level,  but templates, are also part of this.

Yesterday, someone brought me back a book that for me changes my views and sharpened my understanding of coding and how to approach it. I recommend it to everyone, it's meant for project managers, but it's exactly the right level of explanation needed when you are in the blur or want to learn the core of what you are doing.

https://www.amazon.com/Object-Technology-Managers-David-Taylor/dp/0201309947


Bye,

 Jean

Navigation

[0] Message Index

[#] Next page

[*] Previous page