I am rather new to unity (and game development in general) therefore I am not sure how do approach some of the challenges in the best way. The techniques and pattern I am used to in enterprise application development (in Java) do not work or might not be the best way to solve the problems at hand.
The game I am working on has several “views”, basically fancy menus. It does not have a player to move around. Think about “Vermeer” or “The Clou”.
So I have state that needs do be present in every “view”. I have read about several techniques that could handle this but I wonder what is the best or at least which are the pros and cons.
-
Each "view " is a scene
-
Create a static object containing state and access it from every scene
-
Persisting and reloading the state in every scene
-
Create only one scene
-
have multiple cameras, each associated with a “view”
-
Have one camera and activate/deactivate objects based on the active “view”
In a Java application I would use a framework that provides dependency injection (like Spring) and create a singleton that holds the state. Then I would inject this singleton where ever needed.
What is the unity-way to approach this? Which of the approaches is best regarding performance or maintainability?
I created an application with Unity that has several different views - a “main menu,” a “settings” page, and finally a simulation page. All of this was done with panels. I’m sure something similar could be used in your case.
Are you specifically trying to make an adventure game? That’s what games like the ones you linked (the second anyway–not sure about the first) are called. If so, there is probably a Unity framework for setting that up. I don’t know for sure, but there’s almost certainly one out there.
No it is not an adventure, I just mentioned The Clue, because it also has these “views”.
The game is more a business simulation like Vermeer (another example would be Black Gold)
I thought about creating scenes for main menu, settings and game, since those do not share too much info (if at all). Main menu is stateless. Settings might be just an overlay, not sure yet.
The game however has several views that share a lot of data, basically the entire world state. That is why I wonder how to best implement this.
I don’t think there is any right way or specific Unity way for doing what you’re looking for.
You could consider a combination of activate/deactivating gameobjects such as UI windows and panels, and leveraging layers. You can assign all gameobjects associated with a specific “view” to one or more layers. Then when the player switches to that view, you enable those layers on the camera and disable layers associated with other views. Or you can just have different cameras with their layers preset, and activate/deactivate cameras depending on the view.
The advantage of using layers instead of deactivating gameobjects is those gameobjects continue in an active state even when they are not displayed by any camera. All their scripts are running as usual, they are still moving around the game world if that is something they do, everything they would do on camera continues as normal even though the player may be viewing completely different information in another view.
If there are gameobjects that are not UI related (like viewing a 3D game world), you can isolate them from interacting with other non-UI objects from other views by simply locating them in a completely separate area of the scene. Your camera for that view would then be located near the objects it is intended to display, or you can teleport the camera to the correct location for that view.
If your player frequently shifts between these views then I probably wouldn’t do them with different scenes. Depending on how much is really in your scenes, there is small but noticeable lag when switching scenes the traditional way. That can be alleviated with the async scene loading features, but now you’re adding complexity to something that seems like it should just be simple. You’re also going to have to build a system specifically for maintaining game state between scenes, which while not difficult, is yet another probably unnecessary hassle and another place where you can introduce hard to notice bugs (such as if something gets lost in the transition under certain conditions, but doesn’t when you haven’t switched views recently).
I like to keep scene changes to things that are not done in the middle of gameplay as much as possible. Intro splash screen? Its own scene, fine. Main menu before starting the game? Another good one for its own scene. Changing levels within a game? Perfect for its own scene as it is a natural place to put a small break in the action. Switching between viewing different information while in the middle of the game? Ehhhh… I’d avoid scene changes.
As far as something like a settings or options menu that you may want accessible from several different scenes, my favorite approach is to instantiate a settings singleton gameobject with DoNotDestroyOnLoad at the launch of the game, where it loads in previous settings from somewhere like playerprefs, and then any scene that allows the player to access the options menu just instantiates an option menu prefab which just talks to that settings singleton.
1 Like