PlayMaker Help & Tips > PlayMaker Tips & Tricks

Improve your FSM design magic

<< < (3/3)

Thore:

--- Quote from: jeanfabre on August 19, 2019, 02:47:12 AM ---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, ...
--- End quote ---

Can you give an example how :) or walk through a mechanic? Or maybe you did that already, and could you provide a link?

jeanfabre:
Hi,

For micro fsm, check out the 2d platformer sample, it uses this technic.

https://hutonggames.com/playmakerforum/index.php?topic=11881.msg55471#msg55471

For nested prefab, It's not really related to PlayMaker per say, and I don't have any samples using the new nested prefab yet.

As for prefabs and reusable templates on complex project, check out the meface sample on the ecosystem.

https://twitter.com/JeanAtPlayMaker/status/968773939630571520

Bye,

 Jean

Twood:
It's an interesting topic.

Personally I'm of the style where I started with spaghetti FSM where I needed them, but I did get visually frustrated dealing with the larger ones. I think people have different levels of visual tolerances and large FSMs I would find myself wishing it was easy to just hide transition lines for a minute, or group by folders or something. So I understand why some people switch to trying to design to minimize complexity.

But in my opinion these are helpful too: Conditional Expression action. You can easily do multiple kinds of checks in one spot with the AND / OR operators instead of worrying about bugs in multiple actions/states. The live error checking on it is also REALLY cool. Really nice for games with "deeper" mechanics under the hood.

Another good thing is templates as has been mentioned. They keep from putting too much of the FSM on one screen, which is great sometimes.

I'd also add though, look at some of the data options if you've got a lot of variables, so you don't have to search all over in the editor. Setting up XML for your game and having your own easy to work with database might appeal to you, and will probably just take you an evening or two to figure out.

Those are my 2 cents on workflow anyway, having use PM a lot this year

Broken Stylus:
Switches
By 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 sequence
There 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.


Events

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

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


Templates
I 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.

Broken Stylus:
It's possible that most new users to Playmaker would expect this to be already implemented.
There is a bit of irony right there in PM's logo featuring an Asiatic symbol but not allow the ordering of its own states in a purely and strictly vertical fashion. >:}
The only confusion I can see thus far is that users would have to remember that it would not be exclusive to Global Transitions anymore. Perhaps the style of a GT's link should be slightly modified to become truly exclusive then instead of simply being black. A black link can also be done manually for any transition.
Perhaps a GT's link should be thicker, or undulating, or look like how motorways are shown on maps?
Logically, a downward link could only apply to the last transition in a state's transition stack, but it would also not need to be limited to the FINISHED system transition.
This reminds me that I talked about it elsewhere, at other times.


--- Quote from: Broken Stylus on October 27, 2021, 01:14:25 PM ---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.

--- End quote ---

The downward link paves the way for more options. In the quotation above I refer to an older thread I posted:
On the purpose of displaying the FINISHED transition
It is obvious that once you can align states vertically, you could gain even more space by stacking them like Lego boxes, with no space in between.
So I'll link to an even older thread which contains this same suggestion plus a few other ones, just in case:
Vertical transition link + auto-align + stacking
I spoke of vertical links, aligning states (that's mostly a UI option for the sake of graphical prettiness) and stacking states.

More people should come here and second this.

Navigation

[0] Message Index

[*] Previous page