- 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.
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.
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.
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.
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.