The Universe is a small free asset that performs a very simple task; it handles all your managers for you.
You will never have to setup a manager in a scene again! The moment you derive from the Manager class, the tool creates a prefab to host your instance. In the editor, you can press play on any scene, and the Universe loads all your managers for you.
Because your managers are all at the same place, outside of a scene, you can modify them with ease. You won’t need to update any scene with your changes!
Since your scenes don’t requires to be “setup” anymore, it also means they are lighter and faster to load. Every scene just work!
I’m cringing while I’m writing this, but can you please give a real-world example of how I as a budding Unity dev, might use this Universe Asset with my projects? I’m trying to wrap my head around this and hope you can help me along.
Thanks!
Sure, don’t worry, people have been using Unity in a specific way for years, and I’m bringing a different way of doing things. It took people I work with some time to get used to it too.
Let’s take a Sound Manager, right? You need one to play sound, track which one is playing and remove those which are done. It’s also useful to keep track of a playlist of music. There’s no point adding or removing such manager, you always need one around. Similar to a save game manager, there is no point in creating/destroying one, it should always be there. Another example would be a game-state manager; in which scene are you, in which menu, etc. Or a localization manager, a network manager, a webservice manager, a camera manager, etc. All the game logic that make no sense to ever destroy once your game is running, that you could access at any time, and that they might require hold data or need to have access to an update loop.
Unity itself is also loading game-wide managers; you can see them in Edit > Project Settings menu. Unity’s Input Manager is loaded when the game loads, and it is never destroyed. Sadly, we don’t have access to creating our own one the same way Unity does.
So far, I’ve seen two ways how projects would usually handle this issue;
You are required - in the editor - to load a specific scene so that the game would load and work properly, before being able to load your own scene in order to test it. It usually means you cannot easily create a new scene and simply press play, you have to make the game know which scene you want to test. It means every time you want to test your scene, you have to load another one first.
You are required to setup a number of GameObject - maybe prefabs - that hold the game logic in the scene you are trying to test. Not scripts that are related to your scene, but script that would handle game-wide logic. In this case, it means every scenes are required to hold a copy of those logic. They are usually singleton that destroy themselves on awake if there’s already a instance in existence. It also means those copies can break if someone add or remove a new manager.
The Universe adds a third way of doing things;
All your game-wide logic derives from Manager. In any scene you want to test, you press play, and that’s it.
What happens behind the scene; there’s a script - called Universe - that loads all existing Managers on startup using Resources.Load. It does it by reflection, and if there is not a prefab to hold your new manager, it creates a new one in Resources/Universe. In the editor, there’s a tool that the moment you press play, it checks if there’s an existing Universe instance, and creates you a temporary one if there isn’t.
It means testing a new scene for your game doesn’t require any setup anymore. They just all work.
There isn’t really any performance hit. If you were using the singleton pattern by placing managers in all your scenes, your scenes will load faster by not having those objects in them.
You don’t really have to setup anything… The only step is to derive from Manager like this;
public class LocalizationManager : Manager<LocalizationManager>
And… that’s it. You’re now guarantied that this Manager exist in your game.
As for my experience, we have a few games shipped using this methodology. So far it works great. It’s good to reduce boilerplate code. It means our designers can make new scene on the fly without having anything to setup. It also means that if I need to change some value in one of those manager, all their prefabs are at the same place, so it’s easy to edit.
It also - slowly - pushed people towards uncoupling their inner behaviour from their scenes. For example, our cameras are now in prefabs, and they are instantiated at runtime. So once again, we are not placing those directly in scenes.
I used to working with video game engine that offer this hierarchy level for managers, so I was quite surprised when I came to Unity and found out there was nothing for it. It’s actually the first tool I wrote because I found it completely insane to have to perform any maintenance on scenes to make them work.
Yes, I can see how it would be much easier and time saving to simply have to create the “camera” (for example) one time for the whole game, instead of recreating it for each scene.
Correct me if I’m wrong, but as I try to wrap my head around your very great, detailed descriptions, I think that it works like this: The main “universe” manager is loaded, and remains loaded during the whole game, so that you don’t have to switch scenes? (Meaning, no “Unload scene into nothingness” and “Load a new scene” ? ) But rather the game IS the Universe Manager and “scenes” are somehow loaded unloaded on the fly to work with the already loaded and ready cameras and other resources within “Universe”?
Well, I wouldn’t have worded it that way, but pretty much. It makes scenes what their name implies; a spatial structure of data representing a specific visual context. In other engine, they would call that maps or levels.
In a game, you usually have macro and micro logic loops.
A pressure plate, is obviously a micro logic loop, it’s self contained and requires spatial data, visual, collider, trigger and so on. It may also interact with other object in its general vicinity; such as opening a door when we step on it. It makes sense to have this one attached to visual objects in scenes. However, the moment I get to the next level, it has no business to stay around in memory.
The main game state manager which deal with in which level or which menu you are, is an obvious macro loop, it should start when the game start, and stop when the game stop. It’s not self contained and interact with many pieces of the game, load scenes, instantiate player or invoke menus. This one makes no sense to have it floating around in a scene since it has no logical connection to one.
It usually make sense to handle those two differently; their lifespan and their scope is different. Other video game engines usually offer this kind of hierarchy.
Then there’s the “in-between”, like a game camera or a player character. They interact with the current loaded scene, but they are not part of one. We usually go in a way like this;
public class PlayerManager : Manager<PlayerManager>
{
public Player player;
public Camera camera;
public Player SpawnPlayer(Transform transform)
{
GameObject playerGO = GameObject.Instantiate(player.gameObject, transform.position, transform.rotation) as GameObject;
GameObject cameraGO = GameObject.Instantiate(camera.gameObject, transform.position, transform.rotation) as GameObject;
cameraGO.GetComponent<CameraBehaviour>().SetTarget(playerGO);
return playerGO;
}
}
and
public class PlayerSpawner : MonoBehaviour
{
private void Awake()
{
PlayerManager.Instance.SpawnPlayer(transform);
}
}
Player and Camera are both prefab I connect in this manager. When I reach a scene where a player is needed, it get created at the right spot. We have independent pieces and we assemble them for the current context.
This kind of loose coupling means at any time I can modify how the player or the camera behave for the whole game without any modification to any scene. It also means what the player is - its definition - can change. I could have customization logic in that “SpawnPlayer” function, where a player is built piece by piece to how the user likes it. I could also spawn weapons and equipments. We have a game like that, where a similar manager loads a collection of ScriptableObject that represent the definition of different parts, patterns and colors that can be used to create a new character.
Keeping thing ordered usually makes everything easier.
Once again, thanks for the great explanation. This is starting to be more clear to me, and I’m happily awaiting the news that the AssetStore has it available.
Isn’t it just warning about containing “scripts”? Asset store warns a lot of things aren’t compat but they work okay.
This extensions literally is a couple of well thought-out files. Let me go drag it in and check
LightStriker! I’ll be your FIRST customer to buy this tool, if you make it! What a pain it is to track down those error messages! I totally agree! Keep me informed and money’s coming your way!
DaikonForge’s free “Missing Scripts” tool might help with these errors, but they may not have kept it up to date. Could still be worth a try though…
