Playmaker Forum

PlayMaker Help & Tips => PlayMaker Tips & Tricks => Topic started by: Jim W on July 09, 2011, 10:41:48 AM

Title: Best Practices
Post by: Jim W on July 09, 2011, 10:41:48 AM

I'm an experienced programmer, but have not done that much using FSMs.  I'm trying to find some good resources on how to best integrate multiple state machines (in the context of playMaker).  Specifically I'm looking for high level thoughts on how to structure the variables and events when dealing with communications between lots of FSMs.  I've looked at many of the examples but it seemed that once things get more complex, more thought definitely needs to go into the overall structure (what FSMs are responsible for what, how to best break apart the responsibilities of each FSM, naming conventions, etc). 

Anyone want to contribute any thoughts?

Maybe suggest a good ultra complex playmaker example that shows off these best practices?

Or a good FSM book/paper that focuses on some theory that can be applied to playMaker?

Thanks for any help.
Title: Re: Best Practices
Post by: jeanfabre on July 11, 2011, 01:09:05 AM
Hi Jim,

 The biggest pitfall is loose coupling in my opinion. Since it's all pretty much about events, building big projects really call for maintaining good and accurate informations and documentations about who is responsible for what. That's currently my biggest time consuming factor when I need to debug or edit a fsm or feature.

The second big issue when projects get bigger and bigger is refactoring. Currently with 1.1 you need to be extra careful and really name your events, variables, fsm names and everything playmaker related as unique and meaningfull as possible. Do not settle for a variable name or fsm name that doesn't accuratly represent its goal and behavior, cause when it's growing, it will be difficult to change the names you used so far on existing fsms. Spend the time to properly desing amd make the required changes while you do it, if you post pon, you will likely have to stick to it for the rest of the project, else you will be in for bad headache to debug changes because of loose coupling.

Since it's all very visual, I use plain english for  state names, events and variables. Much easier when you get back to a fsm you build few weeks ago. you can grasp it's behavior just by reading out the various states and events.

Avoiding big fsm is the key also, each fsm should be responsible for a very specific task and not try to do-it-all, that will just not work in the end. So cut down a huge and complex feature into several chunk and maintain a system to disable enable a particular fsm ( like Maddox does I believe), or maintain a logical start up routine to know if an fsm should carry on its task and behavior or no.

 Communication between lots of fsm is tricky on big projects because of the loose coupling factor. I tend to designate a "broker" fsm that receives global events and then dispatch to its own black box of fsm and features underneath ( doesn't need to be in the same hierarchy, but likely).

 I do the same with variables. I maintain a "metadata" fsm that only host variables for a specific behavior and feature, and have other related fsm get and set to that metadata host, then several fsm can share common variables. It sometimes requires you to write a custom action to allow it to access fsm variables instead of its own, but since you are experiences in sciprting, that will be trivial, ask for help on this forum, and you will get custom action if you need some starting points or example to get you going. "metadata" might not be a the right wording for your project, think of it like a "data host" or "data central"

 Basically, it's very much an metaphor of how nature does it, animals are made of organs, and you should be able to replace one without altering the behavior and good functioning of others: replace the hart with a mechanical pump and it's fine. If you keep that in mind, then you increase stability and maintainability, but it's bloody hard to do it proper, I give you that :)

Hope that helps you :) from my experience, I found in playmaker an amazing solution for big projects, it is by design a lot easier to design complex behaviors and modify them. That's really something your should not fear as long as you are aware of loose coupling implications and refactoring. Note that 1.2 will adress and provides solutions for this and really goes into the right direction for big projects maintainability.


Title: Re: Best Practices
Post by: Jim W on July 11, 2011, 11:08:16 AM
Thanks Jean,

I knew there were some serious changes to the way things will work in the next version of playMaker.  I suppose I should wait until that comes out.  Until then, I'll sit with some paper and think through some of what you've laid out.  Expect more questions.. :)

Thanks again.

Title: Re: Best Practices
Post by: jeanfabre on July 11, 2011, 02:21:20 PM

 You can see the 1.2 features, and bug fixing list here: (

Events are easier to work with , especially during refactoring, that's massive. Then the fsm view get a real treat with some better view management and you can follow the active state automatically and other coolness.

 But really, I suggest you get down with the current version as the main workflow and habits you'll get with your trials and errors will be helpful even on the next version. The principle behind the thinking process is identical. tA lot is changing to ease the workflow, but the basics and what makes playmaker such a great tool remains ( of course !).

 More questions always welcomed :) Make sure you also study all the examples provided, they really give useful insight and while maybe not complex, really shows how things can be laid out and can be applied to larger scale systems.