PlayMaker News > General Discussion

High Level Playmaker Best Practices

(1/2) > >>

stvbabb:
*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:
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:
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:
Hi.
Maybe i should make a wiki page from this?  :)

stvbabb:
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

Navigation

[0] Message Index

[#] Next page