# Variable Variables in unity using JavaScript?

I'm working on a custom built save system for a project a friend an myself are working on. Currently all variables that are saved to file, are stored as static variables in a global variables script file. The current save system involves running through each variable individually and saving it a line on a document, completely hard coded and very annoying to expand upon with new variables and elements in the game. I've decided to look into serialization of the global variables file, however static variables are not serializable. My solution is to use a getter and setter function, that is called instead of the direct GV.whatevervariable, that we currently use.

Ive been looking for something that allows me to store a variables name inside of another variable and then call it.

for example, say the variable in the GV script is A , the function would look like

static function getter(vget){
return GV['vget'];
}
var A : string = "testcode"


where the call code would look like:

 var stuff : string = GV.Getter("A");


the problem with this though is that I keep getting "system.type does not support slicing" I currently cannot think of any other way to do this, and would really prefer not to hard code a getter and setter for each variable.

• P.s. I read something about eval and alert but I wholeheartedly don't understand a thing about that. So if thats your suggestion, an in depth explanation of how exactly that does what I need it to do would be much appreciated. Nov 9 '14 at 10:02

I don't quite understand why you need to do this, but seems like a convoluted way to retrieve values.

I assume that you need to retrieve both the value and the name of the variables in order to serialize and deserialize.

I think it would be easier to make the variables non static and just handle them like usual (maybe you could use some kind of singleton to handle this) but since I am no expert and don't fully understand your problem, lets try an alternative.

What if you store the variable name-value in either a Dictionary or an array of arrays? Then you could use an Iterator to access every value in the Dictionary/array easily.

That would be the most flexible solution since you only would need to add the pairs key/value into the dictionary, having the flexibility to add/remove variables at will.

• the reason i can't just use non static variables is because i cant access a non static variable from another script file. i thought about using arrays, and will definitely look into this, but being able to work with what i have already would be the best thing for now. reason being, theres hundreds upon hundreds of references using the current set up that would all need to be changed. the system i'm working to create is to access (read/write) the variables and information from outside the global variable script. then i can have all the variables simply serialized. Nov 9 '14 at 14:52
• to explain a bit better: i'm trying to access any given variable from an outside script. this is impossible when using non-static variables as they cannot be accessed from another source without a getter and setter function. (not that i'm aware of) the solution i'm looking to create involves calling one of those functions using the variable as an argument, that function would then gather the information from that variable within the global variables script, and either change it, or return. note that i cannot serialize static variables. which is why they must be non-static. Nov 9 '14 at 14:56
• As I said I´m no JS expert, but can´t you make the variable class a singleton and make all the variables public? Not the best option IMO, but you seem reluctant to try alternatives. On another note, you said that changing your code now would be very hard. Think about it, would you like to expend some time now to make your life easier in the future, or do you want to continue walking a painful path all along? You should take a look at refactoring, otherwise your code will become messier and messier until at some point it will become hardly usable. Nov 9 '14 at 19:23