The title must not be quite clear, let me try to explain what I talking about
In games I often have a lot of different game entities which are basically described by a set of default values. For example I can have a set of Weapon objects which are describe by an ID, power, level, locked etc. Those values are the default weapon state. During the game the player may be able to upgrade/change those values, for example unlocked a weapon, or increase its power etc.
I usually use SO to describe and store that kind of entity because it’s basically just data with no logic. What I was wondering is how do you/would you manage the player weapon state ? SO can’t be saved at runtime and even if it was I don’t want to lose the default configuration. So I usually create wrapper class which is initialized with a config object (SO) and will copy all values that can potentially change during the game. That’s all.
This approach works but it force me to create/instantiate a new wrapper class for each “configuration” I need to track modification during the game. I was wondering how other dev manage that type of situation.
Thanks.
ps : I used Weapon example but it could be totally a different things. Like default player property values, or game situation context etc.
Using SO’s as wrappers around POCO’s which contain the actual data, is definitely a best practice. It keeps a proper separation between your data and Unity which makes merging/loading/saving data from multiple sources much easier.
With that approach you can also group like data into a single SO. You don’t really need/want an SO per POCO.
This makes it very easy to say manage static data in Unity, then export it all out for the server which might not be Unity. And at runtime not having to load all that static data from the server, it’s there on the client.
Your ‘instance’ data can then be the same class you use for the static data. Or you can separate the two having a version of the class that only holds what’s different per instance. I generally use the same class as the default starting point, and treat an instance only version as a potential optimization down the road.
As an example, on larger projects I have kind of a standard approach to data now.
I have a StaticData class that’s independent from Unity. In my case actually defined in a separate project outside Unity.
In Unity I have a Catalogs SO. Which contains links to 5-10 other SO’s that group data by category. These SO’s just have references to POCO’s or lists of POCO’s.
Catalogs in addition to having the references, has a method to copy all of the data in the SO’s to the StaticData class. And to serialize/save it to the filesystem so the server can pick it up.
For multiplayer games, at runtime I access all the data via the StaticData class not the SO’s. This is to ensure both client/server are actually working from the same data, and it provides a flow that enables patching data without having to create a new build.
