koobas.hobune.stream
Storing variables in a separate script
Hi!
I'm cleaning up my code, and realize I have a bunch of options. Here is the situation: I have an object which can have 3 different behaviours, coded in 3 different scripts. So far, changing behaviour means adding the new script, passing on a bunch of variables, and destroying the now unneeded script. Would it be bad practise to store all these variables in a "properties" script that would be cached first thing when a new script is loaded?
I'm an OOP rookie, loving it so far but sometimes baffled by the fact that there are so many ways to do things...
Thanks for your advice!
There are several ways to do this. The most basic and easiest way would be to create a singleton object manager that holds the static variables for all the behaviors, and hold all these values for all three different scripts rather than sharding them out in each script, just as you suggest in your question. So no, this is actually a normal practice, it's not bad to do this. If anything, it's more efficient to do so, because you're programming in an "Object Oriented" manner, passing information to and from objects that are set to do a specific job that you intend them to.
Caching copies of a script is fine and dandy, and sometimes you have to do this based on the situation, but for this scenario an variable manager singleton would be a better choice.
I'm also a programming novice, and once you get further down the line in programming you'll discover that there are more and more options for doing something like this, and much more efficient ways about handling these events.
This is where class inheritance starts to arise, when you need to manage objects that are similar in type and share a lot of the same properties. This is referred to as a base class. An example would be an "Animal" as a base class, and a sub-base class that extends from Animal would be Reptile, or Mammal. So in code thoughts, this class would be declared as:
public class Reptile : Animal{}
And further down the line:
public class Lizard : Reptile{}
There can only be one base class, but there are several tiers of inheritance that all extend from the base class. So, in future cases you may want to use this ( as it's considered one of the core principles of object oriented programming and .net in general ) and study it. A good starter link would be:
http://www.csharp-station.com/Tutorial/CSharp/Lesson08
or any of there links on that site are good places to start learning about this.
Another way you handle these changes in variables would be delegates, events, and actions. Prime31 has some pretty good basic tutorials on getting you started with these:
http://www.youtube.com/user/prime31studios
Look for the videos with 'coding tips' in the titles, specifically the tutorials on extensions and actions, as well as the Linq tutorials which shows examples of creating delegates, events, and listeners.
Thanks very much for the detailed answer. I'm using UnityScript though, not C#, so I guess no delegates for me yet... About the variable manager singleton, is it doable in UnityScript?
Yep it is, look at jahroy's answer for that below this comment.
Look into ScriptableObjects.
They allow you to store all kinds of data, they get serialized, and they don't have to be attached to GameObjects. You can assign them to your scripts like variables, too.
Thanks! I'll check it out, but unsure if they'd be suitable for my current problem: I need some of these varaiables to show up in the inspector (basicaly, I have "soundObjects" so when I add one to the scene, I specify in the inspector its audioClip as well as other stuff, which 2 different behaviours need to access...)
You can definitely edit ScriptableObjects in the Inspector.
We use them to hold all the configuration data for or GUI (for example the size and location of our buttons).
This way we can edit all the data in the Inspector and keep a separate instance of the GUI Data Object for each platform we want to build our game for.
When we switch platforms, we just switch the gui data object assigned to our GUI controller to match the new platform.
It would depends by what scripts these variables are used.
If a variable is used only by a single script, you should alway store it in that same script. Other than uneedlessly calling for another script.
But if a lot of different scripts depends on them, it could be a good idea. As long as you comment in the scripts that need these variable, where to fetch them.
Also, if a variable is constantly relied upon by numerous scripts. A good practice is to call them as "static", as it make them freely available to any scripts in your build.
Well, my vars cant be static (they are properties of an object class of which many instances coexist). And the idea is to store in a separate script only variables shared by the different behaviours, so behaviour specific vars wouldn't be cached for nothing.
