What is the best way to keep track of scene meta information?

Questions & Answers
1

This is a game where basically every scene is a room with doors to other rooms. I’m trying to come up with an elegant way to describe features about a room that I can access from code. Pieces of information that don’t necessarily belong to any of my existing GameObjects. Specifically what brought this issue to mind is background music for a room. Instead of a special doorway that triggers new music, I’d prefer that transitioning rooms itself triggers a check to see what music should be playing. So the room has to know what its own BGM is so the audio manager can query it. Then if I decide later I want different music, I can quickly change that property. But I can see further use cases for things like:

  • Defining the subarea of the room in order to change certain visual effects
  • A switch for whether the room is “dark” and requires a lantern
  • That room’s “position” in the world map

Basically, I’m trying to think of these pieces of information as properties of the “room” or “scene” asset, but I’m not sure how to best connect the information and the room.

I could create a “RoomInformation” prefab in the hierarchy, make a scene template, and a script with that information as a MonoBehaviour. But this is really just a struct in concept; it doesn’t deserve a whole MonoBehaviour or a GameObject. I’d have to search for and find the object when a scene loads (or use a static reference to the current scene’s copy), and you wouldn’t be able to check the properties of any other room except the one you’re in.

I could create a struct and a dictionary within the game state and then populate it from a config file, but that’s probably too far removed from the actual scene itself. It’s not obvious except through documentation or domain knowledge that properties of a room are dictated by some text file somewhere. It also means referring to things like audio clips by name instead of serialized fields.

I could create ScriptableObjects which conceptually represent rooms and use them as wrappers to refer to scenes when transitioning via doors or teleports. This feels closest to what I want to do, but the hierarchical relationship seems to be going the wrong way. The properties of a scene keep a reference to the scene, but the scene itself has no “ownership” of those properties. And, this reference is only a string, which means misspellings and filename changes can cause issues. Though I suppose that’s always the case with scenes in Unity.

To be clear, this is not a question about keeping information/music alive between scenes. I’m looking for the best solution for storing information relevant to a scene as a whole, but not any object within it in particular.

2

There is nothing saying you need to manage your game state or the bulk of your game logic using unity or unitityesque paradigms.

You can do that the normal C# way and use Unity only for things that are explicitly the domain of the game engine. i.e. anything that involves rendering the game and getting user interactions.

You want a room with properties just create a class that has the shape you want and instantiate it and manage it yourself and however you want.

You could attach it to a game object if you want but even that isn’t necessary.

I think one of the biggest problem I see here is a product of people thinking they have to write literally every part of your game entirely inside Unity. Or that every part of their game is a Unity concern or the concern of a game engine in general.

A recent Unity project I wrote only had a single code based gameobject in it which was used as a delegate of the MonoBehaviour events and as an easy reference the rest of the hierarchy. But other than that all the code had little to nothing to do with unity. The reason I did that was to make Unity play nicer with DI and as you cant instantiate monobehaviours (and I wanted constructor based dependency injection) that was how I solved it.

The scene loading was handled by reading in a JSON configuration file which downloaded the assets needed to create the scene dynamically. Note it wasnt a game but this could be applied to games too. The serialisation and deserialisation logic took a few days to plan with my colleague (mostly because it was a rewrite of an existing project which was badly written and lacked any documentation) and then a couple of minutes to write it wasnt particularly involved but gave us more control over our application.

TLDR; .NET is great it does a lot of stuff and there are tons of great C# libraries out there, not to mention C# is a great language. Dont be afraid of not leaning on Unity.