PlayMaker Feedback > Feature Requests

"Global Variables" through automatic messaging

(1/2) > >>

MaDDoX:
Many have asked for - and even Alex himself mentioned that he wants - "Global Variables" inside PlayMaker. The thing is that there aren't only upsides for Global Variables, and I'd like to discuss it a bit here before proposing my idea.

Tthe fact is that there's something to Global Variables that stinks (as in "code smell", I'm sure Alex know the definition :)) to OOP (object oriented programming) coders. I consider myself anything BUT a hardcore OO coder, I've graduated in Computer Science when OO was still a novelty so I have a much more procedural approach to things, but I recognize the OO advantages - I also recognize its many disadvantages, something that most coders which grew up in these OO days fail to do, thinking it's some sort of silver bullet.

One of the nice things about OOP is "encapsulation", which's basically making sure that the variables which only have to do with one logic block are never "exposed" (accessible) from outside. This helps a lot in reducing clutter and making things consistent, basically each logic block becomes a black box which only reveals what it takes and what it gives back as it does its thing.

This is great, back in the day when local variables didn't exist things were such a hairy mess. But since nothing in life is for free, we now have the problem of knowing what each of these parameters do and what type they are, and how to transfer the parameters between the code blocks. 

PlayeMaker so far has dealt with this beautifully with its easy-to-use "set event data" and messaging actions, so I'm very concerned on how to keep these user-friendliness without losing the encapsulation advantages. Thus my proposal is:

- Have "Global Variables" as an implicit concept. You'd basically have a new tab in the variables section where all these "global variables" could be accessed from. In practice wherever they're created they're actually "hosted" - that's the single place where the value is stored. Any other FSM which "checks in" the variable will have a local variable with the same name and type automatically created.

- Whenever you access (writes) the checked-in global variable in an action, in practice PlayMaker wraps up a set event data and messaging to its host FSM. Likewise, whenever it reads from this global variable, PlayMaker performs an under-the-hood get FSM vartype.

This way things would be easy and transparent for us developers, without breaking the encapsulation concept and keeping the variable consistent across all FSMs. Opinions/Comments welcome as usual!

tobbeo:

--- Quote from: MaDDoX on April 29, 2011, 12:31:30 PM ---
- Have "Global Variables" as an implicit concept. You'd basically have a new tab in the variables section where all these "global variables" could be accessed from. In practice wherever they're created they're actually "hosted" - that's the single place where the value is stored. Any other FSM which "checks in" the variable will have a local variable with the same name and type automatically created.


--- End quote ---

This has been my thinking (without much programming knowledge) and I think would be a very smooth and user friendly way to handle it. I know this is a "duuurrr" but of course the name internally must have a prefix or code so that you don't accidentally have duplicate local variables interfering with global variables and get them confused. Maybe have global variables show up in a different color when you work with them in your FSM so you know you're working with a global variable and not a local one.

sP0CkEr:
- maddox - checking in a "variable" might start to get messy. I like the idea of having a "place" where all globals are defined.

- tobboe - i like the difference in color idea.

one thing that has occured to me in this topic is that dont we already have an out of the box way of handling this in PM today? we can create a game object that can be used throughout the entire life of the game as long as we do not destroy it when loading new scenes. cant we just send messages to that object to update variables already, or read them too?

that being said, a way to easily access frequently used variables is still a very good idea IMHO.

- spocker

jeanfabre:
Hi,

 I don't see anything terribly wrong in having a reasonnable amount of global variables. At some point in your system you'll need a central repository to maintain your game status. It starts smelling when you abuse this and start storing everything and anything as "globals". It usually happens as you get bored building nice code and/or need to build something fast ( when clients deadline is now set to yesterday type of situation...).

I like Maddox idea, and I would also welcome the ability to declare a local variable public or private, very much like in scripting, that is an excellent way to properly set up boundaries and smart encapsulation. Making a variable visible in the inspector is one thing, but being able to access all variable just because you have a fsm reference is where potential mess lies.

 To have global variable, I currently maintain a meta data fsm that act as a global variable repository, and I have as many meta data fsm as I have "organs" or high level feature in my application. each smaller component able to access what they want without duplicating. It basically do nothing but just store variable and also treat them, organize them. Some variable are set and get by other fsm, som are set via events because they need processing or further events dispatch on change.

We also should be able to register for variable changes ( not just future global ones) , that would be utterly powerfull!!!! no more "everyframe" checks for a boolean change and stuff like that.


Also, coloring, and visual clues start to severely lack in my opinion, so I agree with Tobbeo, we need some ways ( even if it's only available as prefs under an advance tab or even as a config file somewhere so you don't even have to bother with cluttering the pref interface Alex :) )
 

Bye,

 Jean

Alex Chouls:
My current plan for Global Variables is to have a PlayMakerGlobals component (similar to the meta data fsm approach Jean described). You could have multiple components in the scene, and you set their scope as either global to the scene or to the game object the component is on (and maybe children). This makes it easier for multiple FSMs on a game object to talk to each other (a common scenario) without cluttering up the whole scene. But if you have a few scene wide globals, you can do that to. Variables in scope would automatically appear in action dropdown lists. If you select a global variable, the UI will show a link to the relevant PlayMakerGlobals component (similar to the little target icon in the Unity inspector).

I'd also like to have actions that save/load the state of a PlayMakerGlobals component. So instead of a bunch of PlayerPrefs, you can just say Save/Load Globals and point to the component.

Not sure if I explained it well :P, but that's the plan... it feels like a good fit with Unity's scene/game object/component approach, and should work well with prefabs etc.

Oh, and this component (or one like it) would handle global events too.

Thoughts?

Navigation

[0] Message Index

[#] Next page