1.8 final release?

[joepalos]

Any idea on when 1.8 is coming? Been "coming soon" for so long now...

[play_edu]

+1

[jeanfabre]

Hi,

Yep. There is still a lot to fix and test. So I would simply not expect it any time soon. at least not this month I guess.

 Bye,

Jean

[wheretheidivides]

Could you make sure one can change the names of global variables??

[sebaslive]

Could you make sure one can change the names of global variables??

This would be helpful BUT also, a suggestion that has been passed on to me to help your game run faster is to not use global variables. But I agree with your changes

[jeanfabre]

Hi,

 Who told you it would be faster? using global variables has no impact on performances. At least, I have no hard evidence with a profiler. Too many global variables is a sign of bad design, and you should avoid it of course, but do not create performance issues.

as for renaming global variables, I'd like this to be included but it's unlikely I am afraid, maybe Alex is working on it, but I don't think it's currently in beta.


 Bye,

 Jean

[wheretheidivides]

"Too many global variables is a sign of bad design, and you should avoid it of course, but do not create performance issues."


I get where you all are saying this, but...there are things that NEED to be global.  Some things should be global and some should be local.  I have a big list of global variables because they need to be used in different FSMs in different scenes.

[jeanfabre]

Hi,

 This is not the only way to carry out data from scene to scene. You can flag a GameObject as "dontdestroyOnLoad", tag if "MyGlobals" and on each scene fsm can find gameObject using this tag, and then use "Get Fsm XXX" to get to the various local fsmvariables on that GameObject.

 This technic is the preferred technic if you have large feature that persists over your game, like score manager, progress, player manager, etc. Moreover, I usually send a global event with the "global" data I want to set and let this manager deal with storing and maybe saving it either online with complex internet protocoles or trigger a series other actions necessary everytime this particular value changes. If you think in terms of Global, then there are also global actions to take, and so combining all of this into a proper Manager will make everything a lot simpler and flexible.

 PlayerPrefs is also a great way to make data persists throughout your game with the added benefit of persisting between sessions too, so that's powerful too, mandatory actually for, things like saving the best scores or current situation to resume properly on the next session. But PlayerPref should only be get and set few times, not in the gameloop as this is not as fast as built in variables in PlayMaker.

 And then you have global variables. Sooo simple to implement!! so yes, totally make use of them, they are here for that, but just don't go crazy with them. It's important to keep sanity.

 Bye,

 Jean

[sebaslive]

Awesome post Jean, thank your for telling us your workflow. There should be a thread with just master workflows that are pinned for people to see because this is truly gold.

[wheretheidivides]

This is not the only way to carry out data from scene to scene. You can flag a GameObject as "dontdestroyOnLoad", tag if "MyGlobals" and on each scene fsm can find gameObject using this tag, and then use "Get Fsm XXX" to get to the various local fsmvariables on that GameObject.

 This technic is the preferred technic if you have large feature that persists over your game, like score manager, progress, player manager, etc. Moreover, I usually send a global event with the "global" data I want to set and let this manager deal with storing and maybe saving it either online with complex internet protocoles or trigger a series other actions necessary everytime this particular value changes. If you think in terms of Global, then there are also global actions to take, and so combining all of this into a proper Manager will make everything a lot simpler and flexible.


Do what now???  I don't follow,

[jeanfabre]

Hi,

 Well, you'll be using this manager throughout your features around your game.

For this, you'll be using "Get fsm xxx" targeting this manager and you'll be getting whatever value from it.

So let's say we have a score manager. and we dont' want this to be a global. so we have a "__SCORE_MANAGER__" gameobject, with a "Score Manager" fsm, with a variables "Score".

 everytime your player pick a star, you will fire an event "PLAYER / PICK / STAR". you broadcast it, you don't care of anything else. the star destroy itself and it doesn't care about scoring.

 the "Score Manager" fsm catches this "PLAYER / PICK / STAR", and add 10 to its score variable. then it fires a event "SCORE / HAS UPDATED", and you PASS the score value to the event data. now your UI text showing the score can catch this and update. it simply gets the int value from the event info and update the text.

no global involved, everyone sticks to its purpose and doesn't care about how other managers features work.

If you have an fsm that was just created and did not get any events and needs to know the score. it can simply find the "__SCORE_MANAGER__" ( best using Unity tags, and do it once only for each fsm). Then use GetFsmInt targeting the fsm and variable on that gameobject.

just one more note, on the star pick up. you can go all the way and have many different stars with different weight for scoring, one would socre +10, but another one could score +50. don't hardcode this in the score manager, instead two solutions:

1: pass this value in the event "PLAYER / PICK / STAR" then the score manager check for that and adds whatever what passed with this event.
2: The star send that event "PLAYER / PICK / STAR". The score manager catches it and get the gameobject who sent this event and use "getFsmxxx" to get what ever values it needs from the star GameObject.

 The second approach is SOO powerful, because if you create strict conventions between objects, you can then interface with them. if you agree that each pick up items will have an fsm named "Pickup" with a "score" int value, then your game can grow and have more and more different pickup items, the score system will work and do not care about the diversity of pickups.

If you can master this kind of dance, you'll be creating very rich systems in no time.

Bye,

 Jean

[wheretheidivides]

Very interesting.  Seems logical.  Maybe I'll try that out sometime.

However, the 1 big advantage of global variables it that you can't be on any scene building it and everything works.  You don't have to start on a bootstrapper, go though the menus and all to get to the level you are working at.  Also, it's a lot simpler to implement.  It's good we have options to choose which way to do things.

[jeanfabre]

Hi,

 Yep, globals makes it a lot easier on that front.

 For keeping data and make it survive scenes loading, I use "singletons", a prefab that I set to "Don't destroy on load", and I tag it with a unique tag for that specific manager so that it's easy to find it just by tag when something needs it. This way I have actually a global manager, which not only store data but also do work and dispatch actions throughought the game.

Bye,

 Jean

[polygon]

Hi,

are there any news regarding the final release for Playmaker 1.8? 

Best regards,
Daniel

[mweyna]

Bump.