playMaker

Author Topic: Problems I have found with PlayMaker using it as a Visual Scripting tool  (Read 3889 times)

ramones

  • Playmaker Newbie
  • *
  • Posts: 42
Hi!,

I think everyone in the forums will agree that main strength of playmaker is State handling through FSM. I like it a lot when I use it this way to prototype high level logic. The problem comes when I try to use it as a Visual scripting tool and mainly when I want to start reusing logic blocks. An example could be a state I have in my IAP FSM  called "Has enough money". This just call a custom  action that fires a "Yes" event if there's money to buy a product and "No" otherwise. The problem here is that I allways have to wrap this action into a state but it is not really a state, it is a piece of logic that has an output. Things get worse when I need to use this action more times in the FSM and have different event targets. I have to create another state and rename it something like "Has enough money 2", "Has enough money 3", etc... Really feel a bit like I'm forcing the tool to do someone it wasn't meant for.

Has anybody found himself in this situation? Has Anybody managed to solve this problems? Any tips would be greatly apreciated.

Cheers.

PolyMad

  • Hero Member
  • *****
  • Posts: 545
Mhhh not that I'm using PM since centuries or that I'm a pro coder, but basically I think it's probably your approach that is "wrong".
Maybe you should rethink the logic of that part of code.
No offense intended, I may be totally wrong  ;D

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Hi,

SubFsm, introduced recently is a perfect example of that kind of pattern. create a subfsm, and call from various states, you will avoid duplication of logic.

 When you face this situation, and don't want to use sub fsm, it means that you need to wrap that logic into its own fsm, with an interface and all. So instead of having that logic you will reuse in various fsm inside each of these fsm, call another gameObject responsible to do just that ( or another fsm on that gamObject).


In that case where you need to do the same "if" in the same fsm on different states, then it is indeed necessary to have redundant states, doing the very same check but on different branches of the fsm state flow. that's fine, and I do that all the time on complex fsm, I usually avoid add "1", "2" to the state and prefer adding plain spaces, so your state name is "Is it true", then if you duplicate that, you will have "Is it true " ( notice the space at the end of the sentence", this way my fsm stays clean.

in your case, I think it's the last case, where you will need to check for a boolean value in various places, nothing wrong with that ( but one could argue that maybe you should have more fsm and split your logic into smaller chunk that you call or instantiate only when needed, but that's really something to study on a per case bases)

Does that help?

bye,

 Jean
 

Lane

  • Administrator
  • Hero Member
  • *****
  • Posts: 2511
  • Mender of the past
    • Cleverous
I think you need to look at your approach to the problem.

I did the money check thing by just making the buttons for buy/build fill variables with the proper information(not the best method, a db would be best) for that item and then having a generic fsm workflow compare those variables against the variables i assign as a cost for that item. When it's done its a bool by either having enough money to buy or not, so just bool test and flow to where you need it.

Modular design is extremely useful. If you find youself copy and pasting fsm's, states and action sets then you should try to find a way to optimize that system rather than digger yourself into a deeper hole with a bunch of duplicate stuff you have to maintain.
« Last Edit: April 27, 2013, 03:31:22 PM by Lane »
Products by Cleverous
|| Vault Core : Database
|| Vault Inventory : Multiplayer Inventory
|| Vault Attributes : Character Stats
|| That Hurt! : Dmg Floaties
|| Quinn : 3D

ramones

  • Playmaker Newbie
  • *
  • Posts: 42
Thanks a lot for all the answers.

I think main prob is that as a experienced programmer I want to bring the same functionality of "methods/functions/procedures" to PlayMaker. I really try to encapsulate common set of states, etc... and save them as templates and then call with RunFSM action, etc... but I think I will have to change my mind a bit on how to organize things in a FSM.

Again, thanks for all the insights.
Cheers.

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Hi,

 Yes, you will have to adjust few "patterns", and as far as I am concerned, there is not coming back from playmaker as soon as I can picture in my mind, an event based system, playmaker WILL outperform scripts anytime at this. But as soon as I have some hardcode algo, like inverse kinematics, or data heavy lifting, then a combination of scripts, playmaker and few custom action to bind them together is the winning combination. Do't try to do everything purely with playmaker, there is a sweet spot to find, and for sure, it requires some experimentation because this is kind of "new ground" with very little documentation you can find on how to mix visual event based programming with conventional scripting...

in short, you are welcome to share your thoughts and findings on that matter :) it's very much needed, and I think we will soon be able to extract some common design patterns

bye,

 Jean