playMaker

Author Topic: "Global Variables" through automatic messaging  (Read 7432 times)

MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
"Global Variables" through automatic messaging
« on: April 29, 2011, 12:31:30 PM »
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!
--
Breno "MaDDoX" Azevedo
@brenoazevedo

tobbeo

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 186
Re: "Global Variables" through automatic messaging
« Reply #1 on: April 29, 2011, 06:29:47 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.


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

  • Playmaker Newbie
  • *
  • Posts: 25
Re: "Global Variables" through automatic messaging
« Reply #2 on: April 29, 2011, 11:31:32 PM »
- 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

  • Administrator
  • Hero Member
  • *****
  • Posts: 15500
  • Official Playmaker Support
Re: "Global Variables" through automatic messaging
« Reply #3 on: April 30, 2011, 03:41:59 AM »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 3987
  • Official Playmaker Support
    • LinkedIn
Re: "Global Variables" through automatic messaging
« Reply #4 on: May 01, 2011, 10:39:29 PM »
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?

MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
Re: "Global Variables" through automatic messaging
« Reply #5 on: May 03, 2011, 09:40:58 AM »
Quote from: sP0CkEr
- maddox - checking in a "variable" might start to get messy. I like the idea of having a "place" where all globals are defined.
Sorry spocker, but I don't get your point. Why being able to select where do you want to "sample" the global variable from would be messier than having a mishmash of variables in a single place?

Currently just to keep things organized (and it's not a big project or anything) I'm using three "global variable repositories" - gamedata (for "static", balance values), gameflow (for values changed while in-game) and prototypes (stuff that will be instantiated, better than prefabs for a number of reasons). If I could only have one single place to sample variables from I'd be nutz by now, for sure.

Obviously if the "PlayMakerGlobals" component that Alex suggests can handle a number of "sections", accessible, let's say, by different tabs, it'd would work just fine.

Quote from: tobbeo
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.
The whole point in my idea was actually that the value would be duplicated, hence the same name is actually needed :) That's why I've created the multiple "Read vartype" actions which I've posted in the User Actions sections. I think having dintinct local and global variables with the same name (eg.: "playerspeed") would be counter-intuitive and confusing, no matter what graphical or color distinction you use. Remember that you can always "copy" the global variable value to another local variable if needed be.

Quote from: jeanfabre
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.
I don't see that as much of a problem tbh. Having a "local" checkbox in the variables is the kind of thing that only us with a coding background would feel better having. Yet in practice we don't need this type of spoon-feeding since we know what we're doing (most of the time lol), and for non-coders it'd be just another complication.

As you can see, I'm probably just as concerned as Alex to keep the interface as user-friendly and simple as possible as it grows in power.

Quote from: alexchouls
Variables in scope would automatically appear in action dropdown lists.
Nice, I would like the scoped variables to have an unique name (as I've explained above), but that doesn't mean I don't like the idea of a different color or maybe bold styling to make the global variables easily distinguishable from the local ones.

Quote from: alexchouls
Oh, and this component (or one like it) would handle global events too.
Very nice idea, just yesterday I've mentioned to the coders on my team that global event names aren't auto-updated since they're mere string references, it's actually a quite easy thing to mess up and hence error-prone compared to the regular variable/events pull-down selectors - not to mention hard to debug. So although it'd require an additional step to create the global event, it's the kind of thing definitely worth the added step.
--
Breno "MaDDoX" Azevedo
@brenoazevedo

tobbeo

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 186
Re: "Global Variables" through automatic messaging
« Reply #6 on: May 04, 2011, 06:10:59 PM »
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?

Love everything about what you said. I would also really like color coding in PM, even as an option would be fine. I want to be able to tell what kind of variable it is. In fact, I would even love the option to color code bools, floats, ints, gameobjects etc. But that I would strongly suggest as an option as maybe not everyone would like it. I would, I am very visual and I remember colors very quickly. I see blue, I know it's a global variable. I set gameobjects to be red, they show up in red. Unity has this for prefabs (turn blue) which would be awful if they didn't. Would like to see Unity give more color coding options.

As for MaddoX saying he wants the exact same name, I don't really agree personally. I don't want the ability to have a global variable and local variable have the same name. Though color coding would make it not really an issue.

MaDDoX

  • 1.2 Beta
  • Full Member
  • *
  • Posts: 165
    • FluidPlay Studios
Re: "Global Variables" through automatic messaging
« Reply #7 on: May 10, 2011, 07:15:25 AM »
Quote
As for MaddoX saying he wants the exact same name, I don't really agree personally. I don't want the ability to have a global variable and local variable have the same name.

Not sure I've made myself clear. I didn't mean you would be able to have a local variable with the same name of the global variable, it's exactly the contrary - you would not be able to create a local variable with the same name of a 'signed-in' global variable, exactly for legibility and simplicity sake.

The same way you can't have two same-named local variables right now. What's the point of breaking that "rule"?
--
Breno "MaDDoX" Azevedo
@brenoazevedo