Tracking data across scenes

Unity Engine
1

While i appreciate the Unity component model, i have some concerns or questions about how i’m currently migrating my coding style to Unity and wether how i’m doing things is heinous or alright. I write in C#.

First off, i’m a big fan of singletons and the state pattern. When i make games in Flash, i typically have an application state machine with a global state taking input, handling network etc, and several singleton application states that are passed the state machine instance on their enter/exit/update calls.

Forgive me if this is swearing in church, but i want to extend MonoBehavior as little as possible, leaving script components to simple behaviors or initializers. I have spent the last couple of years trying as hard as possible to indoctrinate myself to as much code/graphics independence as possible.

So then, in my mind, it comes down to this; How can i separate the application logic from individual scenes? Here’s how i do it currently. Pardon if it gets rambley, i try to keep it readable :slight_smile:

1. Initialize the game
The first scene to load is practically just an initializer, with an empty gameobject holding an ApplicationInit script component. My Main class (which has the state manager instance) has a static getter (Main.instance()) that is called for the first time here, as well as any external data i want loaded (typically xml, textures, packages etc).

2. Set a state
Once everything has been loaded, Main sets the first of its application states, which all inherit UnitySceneState (with public enter, update and exit methods): Main.instance().setState(SplashScreenState.instance())
When UnitySceneState.enter() is called, it in turn calls Application.LoadLevel for its designated level id.

3. Update the state
So at this point the associated scene has loaded. It contains, again, an empty gameobject with an Updater component. OnUpdate, The Updater calls Main.instance().update() with its GameObject as an argument, which is passed along from Main to StateManager.update(), which again calls its current state’s update method with a reference to the StateManager, giving the updated state access to a GameObject’s methods for instancing etc.

4. Changing the state again
If the player dies, and the state is to change to a game over scene, the game state for that level will simply ask its manager to change to that state as such:

public void update(StateManager manager){
//...other logic resulting in:
manager.setState(GameOverState.instance());
}

Blah blah
I guess this is just repeating state pattern to some of you, but it’s the flow of events from a component on a GameObject to objects existing outside of components that really matters here.

In short, i want to adhere as closely to how Unity handles its updates as possible, while still letting me manage how things are updated, added and removed in code not necessarily in a script component.

How do people in general feel about fitting relatively traditional OOP development methods to Unity? I have to admit a lot of the learning curve for me has been to regain control of how i code. Throwing scripts around feels nice at first but completely hellish to manage after a while.[/quote]
[/code]

2

unity’s architecture is based on components. It is OOP++. think of components as aspects. it is favoring composition over inheritance in a different way.

so instead of having a gameObject’s behaviour as one complete class, we r partitioning that class into smaller more focused, more generic, more reusable components (classes).

if we break down a big behaviour class into 3 smaller, more coherent classes for instance. we now have 3 axese of change through inheritance ==> more control for architecture.

if u want to control updating objects, then write a class (extends monobehaviour) and write code in its update function to manually update sets of objects that implement IUpdatable for instance with the method DoUpdate(). Do that only if u wanna add something with the update strategy u don’t have in unity.

you can create projects in visual studio, have behaviour classes that inherit from others and implement interfaces. then create instances of what u consider as concrete behaviours by adding them to gameobjects.

3

Are you talking about traditional OOP development or about stone age OOP development / procedural programming from good old C++ days as in switch blocks to handle state / event messes?

I prefer Unitys approach, commonly known as Observer Pattern, far above any stone age approaches that are hard to maintain and even harder to extend due to their dependencies, which completely defeat the point of distinct encapsulated functionality units.

You will laugh but it will become exactly the opposite commonly unless you throw a hellish mess at it with dublicate behavior code in different components.
Thats because you will commonly write far less code as each specific encapsulated behavior is its own block and can be assigned to all game objects needing it, independent of the other functionality.

While your approach might seem like a good one to you right now, it has some serious drawbacks:

  1. Be carefull like hell if you intend to use physics or you will get in trouble
  2. You can’t use Unitys gui system at all
  3. You will have serious problems if you intend to use Unitys networking as it bases on components for realtime updates of anything but transform.
  4. When you want to use 3rd party extensions to unity, you will have to invest a lot of time to “destroy them” to the point where they work like your system
  5. Most important: your design actually removes what makes Unity as usefull and easy to develop as it is. You remove any possibility to alter your game at realtime while you test it because you have a hardcoded core mess. Neither can you change values to see their impact nor can you exchange / add / remove components at runtime to alter the behavior elementally.