Shared Variables in Unity

Today I published No Such Studio: Variables on Unity asset store. As the name suggests, this package let’s you create named variables that can be accessed from any script. This post will explain how the package works. It helps with some repetitive Unity tasks you encounter as a developer when dealing with shared variables. You need to know Unity’s component system and programming to use the asset.

Background: Accessing Variables from Other Components in Unity

Finding other components and calling methods on them is a common part of coding a Unity game. A typical Unity script has parts like this:

This enemy controller script adds to user coins when the enemy dies. The current code works for small projects. What if on top of the UI, we have a database that saves the current state of the game and a achievements class that checks whether the user has unlocked a new achievement because of the new coins? The code explodes in size if we keep doing the same thing:

Note that any code that wants to change coins would need to include the same setup and update code as above. Say we had a LevelManager class that would give coins at the end of the level. That class would need to have a copy of almost exactly the same code as above. Here are a few other typical places that user’s coins could change:

1. login
2. a friend accepts their invitation request
3. watching an ad
4. unlocking a new achievement

Imagine having to do the same amount of work for each of the above components. That would create a lot of repetitive code!

Hopefully this simple examples makes the case for needing a more robust and efficient way for managing shared variables.

To look at it in a more schematic way, each variable has:

1. Consumers: components that read and write its value. EnemyController and LevelManager on top of Database, UIManager and Achievements are consumers of coins variable in our example.
2. Listeners (Observers): components which listen for changes to the variable. UIManager, Database and Achievements are listeners for the coins variables.

Listeners are almost always Consumers too!

This pattern of multiple changes happening as a result of a value change is a well known pattern in programming. Events are a common pattern for dealing with that. Here is our above example written with an event for the coins variable.

Note that the consumers (EnemyController and LevelManager) now need only find the owner of the variable. That is easy with singleton pattern as is assumed above.

Note that similarly listeners (Database, UIManager and Achievements) need only find the owner of the variable and register with its event.

Using events the code becomes cleaner and more untangled. EnemyController no longer needs to know about all the listeners for the coins variable like UIManager and Achievements .

Events deal with the problem of wanting to do multiple tasks as a result of a variable change. However there is quite a bit of setup needed for each variable. Each listener needs to register for the event for each variable they are interested in. The sample code above is for a single variable named coins. What if we had score, user_name, user_exp, user_items, etc. etc.?

No Such Studio: Variables

Who should use it?

No such studio’s Variables asset streamlines the process of creating observable variables and listening for changes to them.

If you are a programmer and find yourself:

• Fixing Component references in Unity Editor or setting up events often
• Dealing with errors that arise from null references and references to destroyed components

then this asset is going to be a lifesaver.

If you don’t know programming and are using visual scripting assets like Bolt and PlayMaker, you don’t need this asset. They already contain observable variables in one form or another.

How it works?

With No Such Studio: Variables asset, you can use named variables from any script in your project. You need to create variables with unique names in VariablesSrouce components as part of setup.

After that, you can set and get variable values like this:

Note that the methods are static and you don’t need to hook up any component references or events! It all happens behind the scenes.

Editor Inspector for VariablesListener component

If you want to listen to changes to a variables, you can use the VariablesListener component.

Editor Inspector for VariablesService component

VariablesService component is the central hub for all the variable sources and listeners. It let’s you inspect all variables in your scene both at runtime and edit time in Editor. This makes debugging any issues with variables easy to track down.

All variables in No Such Studio: Variables have a string type for simplicity. You can however use any serializable type using extension methods that come with the asset:

Pros & Cons

Here are the benefits of using No Such Studio: Variables:

1. No need to setup any component references and events! As long as we define the variable in a VariableSource component in the scene, any code can access it!
   This means no more dealing with null or destroyed GameObjects, Components or events.
2. In cases that a variable is not declared, no exceptions will be raised. VariablesService prints out log messages for such cases, but won’t cause an exception.
3. No Such Studio: Variables asset creates events internally for each declared variable and invokes the events when the corresponding variables change. So the code is as efficient as it gets!
4. No coding required for shared variables functionality.

While this asset helps with cleaning up code and keeping things organized, there is one drawbacks when using it:

• No compile-time type safety! Using string type for variable names and their values could cause errors at runtime. Watch out for misspelled variable names!

You can learn more about the asset and more advanced use cases like creating custom VariablesSource classes on the documentation website.

Happy coding!