SwitchesBy experience I can say that, actually, the first switch example is very appropriate.
I did try GoTo solutions in several FSMs over the years, to limit the drawing of links, but I find that no matter what, they make the reading more confusing. The reason being that entering Playmaker, you know what to expect. I would sometimes forget about the GoTo implied linking, so it was a hassle more than a freeing power.
By default you expect to see a link or a Global event black box. Even using descriptions in the states didn't cut it. Besides, there's no way to trace the GoTo "event" easily, these transitions are invisible to a Playmaker's user.
As said in another thread, I'd rather have the ability to make some solid links to be dotted or dashed in cases they'd be considered optional (like in a GoTo) and have mouse-placed discs to control the path followed by links and their bending, and also be able to group links so they run parallel to each other, like you do in IT when grouping physical cables in servers or behind computer desks.
The mess of links is due to Playmaker's rigid convention regarding local links: entrance is done by the left, exit through the right. The exit direction can be changed though, it's preferable sometimes to do so. Transitions can also be moved up or down to avoid crisscrossing links.
Logical diagrams normally allow links to exit a node left, down or right usually, with the first node being at the top.
In your "more" example for switches, with a reformed convention, you could have four parallel lines (links), slightly spaced, coming from the bottom of the state "Check", then they would split into two groups, two going to the left into "Frog" and "Elf", two to the right into "Wolf" and "Necromancer". It would look particularly clean in 'circuit' display mode.
I remember also suggesting a condensed display for FINISHED so we could also stack states when the structure is fairly simple (as
here), instead of having these spaces between states and these links and arrows leaving and reentering the stack.
Action sequenceThere is nothing "bad" about the first example. It should actually be the display choice followed by most users and it's far clearer.
That does not mean I do not use sometimes the cheating option that allows for an early exit within a state (FINISHED or else), but I try to keep these choices to cases where the gain is really meaningful.
True/False, Yes/No, Success/Failure, etc. are really very helpful and you do not need to enter a state to see what's going inside.
For these types of states that do such binary comparisons, I'd strongly suggest using some colour scheme in positive/negative cases, with green colour for the positive outcome and some red for the negative one.
When there's a neutral, so-so third option, use yellow.
Your third example could make use of "Use transition event" set to True at the bottom of the action stack, it would allow you to have both True and False transitions exiting the state.
Overall, the parent/child Graph View displaybwould really be better if right where the template FSM's name is located, a ’Parent>Child' would appear, with 'Parent' being interactive and taking you back to said parent, the one that launches the Run FSM, and 'Child' obviously being the template, like a deep link.
EventsI 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.
There is indeed a severe lack of transparency on the management of events and the data or properties they can carry. Alex replied positively to this remark a long time ago and seemed to agree that events related tools should be expanded upon. I just hope the PM guys have not forgotten about this, especially since I experienced annoying cases when events had issues being carried over to other FSMs or even lost all data and nothing could be collected on the other end.
So there is definitely a good argument to make in limiting,
sometimes, the use of events.
Now, the solution of forcing the flow into a given state in a GoTo way from a component (like a button) is an interesting choice but in some of my setups that would have been impossible because I needed to control the ability to receive events. Besides, GoTo-like solutions don't leave much traces in the FSM log so perhaps someone should do this only if your FSM is really begging for clarity and you won't go back into it anytime soon, so it can stay like that forever, or because nobody else will need to take a look at it.
This would not be so much of a problem if states had a little indicator that they were targeted, either by an event, a GoTo flow-sender or simply an action in another FSM keeping an eye on where the flow currently is in another observed FSM.
A bit more self-awareness would certainly help, especially since those little symbols, whatever they would be, would double as menus showing the list of targeting FSM:State:Action(s).
TemplatesI unfortunately have never found enough evidence about the management of memory regarding spawned FSMs and I have always been a little bit suspicious of some potential clogging down the line.
Nevertheless, they're rather useful but here again, using a specific colour for states that use Run FSM would be advised.
I still prefer to use several FSM components, although Unity isn't meant to be used that way and it would be better if PM could group them. Basically there would be just one big meta FSM component or proxy containing all other FSMs.
Right now what is annoying is how Unity expands or collapses all components and I wish I could control the setup and fix it at once for a given game object without seeing all my carefully arranged Inspector be reset.
This may be solved by simply opening a new tab and locking each Inspector for a specific FSM but that's so much extra work instead of being able to expand or collapse FSMs' content.
