playMaker

Author Topic: High Level Playmaker Best Practices  (Read 5077 times)

stvbabb

  • Junior Playmaker
  • **
  • Posts: 66
High Level Playmaker Best Practices
« on: March 28, 2018, 04:51:07 AM »
*I hope this isn't a dead horse topic, but I've been looking for a while and I'm only getting certain parts of this topic. Maybe it would be nice to have a larger and more complete overview? If this already exists, please just let me know.*

Hello,

I have a question regarding game design and Playmaker; what are some of the core best practices I should know about using Playmaker, especially as projects grow and get more complex? Playmaker and Unity have both gotten better and better, and in my current project I'm using Playmaker for lots of things, as well as some c# where it's more suited.

What really basic guidelines should people be following? Are there even guidelines?

Any thoughts? Any new ideas? Personal experiences that would help?

I've done some research and seen a previous post or two (Read lots of reddit, Unity Q&A answers as well, but those tend to be less helpful);

https://hutonggames.com/playmakerforum/index.php?topic=429.0

http://hutonggames.com/playmakerforum/index.php?topic=14483.0

If I've missed some posts or valuable, links, I'd love to read those as well.

Thanks,
Steve


jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: High Level Playmaker Best Practices
« Reply #1 on: March 29, 2018, 08:16:34 AM »
Hi,

Basically...   :P

- Don't over use global variables for everything and anything, this is bad design practice, look up 'Metadata' on the forum, I explain one way of dealing with common variables used throughout a big feature and many fsm.

- Design first, optimize later, make it work, then worry about performances, the other way around is too much pain.

- iterate VERY often, always publish at least once a day if you are full time, missing out a bug for too long is painful to debug.

- use Github or bitbucket ( coupled with SourceTree client) to host your project, it's never a good thing to rely on zips for backups... it sucks, use a proper code repository.

- Cut down your project is small chunks, they must work individually, think of your project as a Human Body. It's made out of very distinct organs, each replaceable, heart can be swapped with a mechanical pump, brain with a computer :o  skeleton by plastic or else. Apply the same principle to your project: Nature made it so far isn't it? 'Object Oriented Programming' actually was an attempt at simulating Nature when it was designed.

- Don't attempt your dream project on your first attempt, set yourself achievable goals, and reach them patiently ( one by one or in parallel, to change your mind, else you go nuts...)

- Fsm wise, never fear using several Fsm for a single feature, I often resort to three fsm just for a simple character control, one to move, one to rotate, one to jump, so for more complex designe, this will increase, and it's a good thing, divide and conquer approach allows your project to grow better and stay sane.

- ALWAYS NAME ALL YOUR EVENTS, VARIABLES STATES, FSM  GAMEOBJECTS. it's critical, describe as much as you can, use colors ( I always use red for error state landing, with a breakpoint, so any error I catch will trigger the debugger).

- Do not fear starting from scratch a feature, it's a lot more productive than trying to fix something badly started. It took me many years to realize this, now I am ok to bin entire chunk of codes or sections, just because I know a better way, and it's needed for the sanity of the project. Trying to fix the unfixable is a waiste of time. Plus you gain practice, as you already know what you want, and so you'll be faster and sharpen your development skills.

- use '/', in your names for events, it helps organizing them in the drop down menus.

- Always ask on the forum if you are not sure, we are here to help, sharing your issues and struggle is beneficial for everyone, you because you get a chance to solve your issue, others will be able to benefit from your struggle and solution, and to the one who provided the solution, it helps being sharpen skills, by having to explain it.

- Higher level project handling will likely require scripting. It's a good thing, you can write editor scripts that increase your workflow, speed up your designs and needs, so as you want to increase the complexity of projects you want to handle, you need to prepare yourself for learning c#, do this by simply looking at PlayMaker actions, just read them, don't try to do one, just try to understand how it's done. One day, you'll have a need for a custom action, ask us, we'll likely provide, and take this opportunity to learn something out of this, and even try to rebuild it yourself, or do a series of custom actions around the one provided ( to cover more of the features you want to control). This process can take up 1 or 2 years, then you are fine with simple coding, and Unity will reward you with the best possible solution you can dream of to realize your vision. Period...


Bye,

 Jean

stvbabb

  • Junior Playmaker
  • **
  • Posts: 66
Re: High Level Playmaker Best Practices
« Reply #2 on: March 30, 2018, 07:12:29 AM »
Hi Jean,

Thanks for this!!! Very cool to post such a thoughtful and thorough explanation. I will refer back to this often and I'm going also to try to create a Google dock that is shareable so others could potentially have a easy to see spot for stuff like this.

Again, thank you so much. It's a big help!

Cheers,
Steve

djaydino

  • Administrator
  • Hero Member
  • *****
  • Posts: 7615
    • jinxtergames
Re: High Level Playmaker Best Practices
« Reply #3 on: March 30, 2018, 01:56:21 PM »
Hi.
Maybe i should make a wiki page from this?  :)

stvbabb

  • Junior Playmaker
  • **
  • Posts: 66
Re: High Level Playmaker Best Practices
« Reply #4 on: March 31, 2018, 02:19:52 AM »
Hi djaydino,

I think that would be awesome. Jean really comes through with these amazing posts and solves so many issues for people, it would great it if was documented and easy to access to new and older users a like. Maybe even a search for best practices in the eco system could let the user download a simple readme or include it with Playmaker some how?


Here is a link to the first pass on the Google Doc:
https://docs.google.com/document/d/1FDi1lfaH7BX9Tnv1ouZhBnkYwYNUbxG2sFx-SfUbDDc/edit

I set it share with everyone and it should also be editable by everyone.


Thanks,
Steve
« Last Edit: March 31, 2018, 03:13:07 AM by stvbabb »

jeanfabre

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: High Level Playmaker Best Practices
« Reply #5 on: April 02, 2018, 03:11:05 AM »
Hi.
Maybe i should make a wiki page from this?  :)

hi, yes, that would be great indeed.

 Bye,

 Jean

Gua

  • Beta Group
  • Sr. Member
  • *
  • Posts: 309
    • Andrii Vintsevych
Re: High Level Playmaker Best Practices
« Reply #6 on: November 13, 2020, 08:15:36 AM »
- ALWAYS NAME ALL YOUR EVENTS, VARIABLES STATES, FSM  GAMEOBJECTS. it's critical, describe as much as you can, use colors ( I always use red for error state landing, with a breakpoint, so any error I catch will trigger the debugger).
Ha... I've worked with Playmaker for more than 5 years. Shipped multiple games including pretty complex and successful games (like Witch Hunt). And most of my VARIABLES STATES look like this


And it never bit me in the ass, cause playmaker logic is so easy to read. I do make an expectations sometimes, but 90%+ of my FSMs look like this  ::)

I do hoverer name my fsms, variables and global transition events properly.
« Last Edit: November 13, 2020, 08:19:16 AM by Gua »

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: High Level Playmaker Best Practices
« Reply #7 on: November 13, 2020, 12:13:35 PM »
- ALWAYS NAME ALL YOUR EVENTS, VARIABLES STATES, FSM  GAMEOBJECTS. it's critical, describe as much as you can, use colors ( I always use red for error state landing, with a breakpoint, so any error I catch will trigger the debugger).
Ha... I've worked with Playmaker for more than 5 years. Shipped multiple games including pretty complex and successful games (like Witch Hunt). And most of my VARIABLES STATES look like this


And it never bit me in the ass, cause playmaker logic is so easy to read. I do make an expectations sometimes, but 90%+ of my FSMs look like this  ::)

I do hoverer name my fsms, variables and global transition events properly.

I would honestly NOT recommend not naming states. If anything, do not hesitate to use the 'comment' action or add a description in the state's description field.

Using a color scheme for states is very useful too, and you can use a lighter and darker version for things like get/set for example. You'll have to do your own tests because link colors or text are not always readable though (I wish there were much more options and control in the color system, it's very raw right now).

Do not hesitate to have a big "Tests" Game Object acting as a big folder, wherein you'll create plenty of children G.O.s to try specific actions, with each G.O. named intuitively. It's useful to quickly check on the behavior of some actions. Then leave comments once you have gathered enough information about said actions so you can always quickly return to them later on, notably with a quick search in the search field.

Do not hesitate to do builds just to see if there are no bad surprises, especially if you include third party plugins and SDKs.

Fat Pug Studio

  • Beta Group
  • Hero Member
  • *
  • Posts: 1294
    • Fat Pug Studio
Re: High Level Playmaker Best Practices
« Reply #8 on: November 17, 2020, 11:25:41 AM »
- ALWAYS NAME ALL YOUR EVENTS, VARIABLES STATES, FSM  GAMEOBJECTS. it's critical, describe as much as you can, use colors ( I always use red for error state landing, with a breakpoint, so any error I catch will trigger the debugger).
Ha... I've worked with Playmaker for more than 5 years. Shipped multiple games including pretty complex and successful games (like Witch Hunt). And most of my VARIABLES STATES look like this


And it never bit me in the ass, cause playmaker logic is so easy to read. I do make an expectations sometimes, but 90%+ of my FSMs look like this  ::)

I do hoverer name my fsms, variables and global transition events properly.

This looks like one of those "Blueprint nightmare" screenshots. Use global transitions inside FSM's with lots of states to avoid this kind of mess :)
Available for Playmaker work

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: High Level Playmaker Best Practices
« Reply #9 on: November 20, 2020, 04:16:30 PM »
Indeed it's a little tentacular. I'd loathe reopening a project with such FSMs.  ;D