koobas.hobune.stream
Game organisation - persistent game logic and state
I’m starting to build a prototype of a game and I’m wondering how to structure the project. So far my unity projects have been single scene tests, so I’m now thinking about how I would go about expanding and scaling a game spanning multi scenes and systems.
My main question concerns how to share game logic among various scene given Unity’s script-component system. I understand in other game engines it is possible to have a ‘main’ entry point for scripts which can serve as a means to call procedures which control game logic which persist throughout the gameplay loop – e.g. managing player input, changing scenes, etc.
There are probably a range of ways to implement this within Unity, but are there any best practices? I was thinking of implementing a main prefab which is present in every scene. This would contain a hierarchy of GameObject and components which would manage the game logic.
Some suggestions...
Keep your initial and run time persistent data (over scene changes) in Scriptable objects. You can refer from there the the actual GameObjects (not in serialized way) or Prefabs (and vice versa trough hook component you need to make). This way you can also destroy GameObject (like store it to inventory) and instantiate it with runtime values stored in Scriptable object (like taking it out of inventory or in scene change). You can also extend from here to build save load system quite easily. There is some coding to be done for sure but this way its pretty generic. https://docs.unity3d.com/Manual/class-ScriptableObject.html, https://unity.com/how-to/architect-game-code-scriptable-objects.
Also try to steer way from centralized controls like GameManager etc (that usually use singleton patterns and Object.DontDestroyOnLoad) and try use patterns that don't create strong dependencies. Check how to use delegates to create service subscription / event based services. If you need some centralized control then, instead of GameManager, build EventManager as a place to subscribe event listeners and fire events (this don't need to be Monobehavior derived, but independent static class or SO)
Referring to your example about managing player input. You can have that GO and component created in every scene separately (it can have common prefab and have instance in every scene).. If it's controlling some objects in the scene you can refer to those via scriptable object or fire events that the interested objects are listening..
All in all there's tons of material, tutorials, opinions about theses patterns in the net and I know only few of these patterns.. so above is just my 5 cents.. Hope you get things started (and also finished)!
