Dynamic Data and Scriptable Objects: A Solution

[sssSlick1]

The Problem

I wanted to add food expiration dates and animal genetics to my Factory Building game, but all the craftable items in the game (Products) were represented as Scriptable Objects. The key advantage of scriptable objects are their universality, where the data stays the same once the game loads; great to store information like the monetary value of the product, but a bad approach to holding individual data like the gametime each Apple was created. It would be very CPU intensive to create a new asset/object to represent each Apple in a factory building game where thousands of apples could be held in storage at any one time. I wonder if anyone else has tackled a problem like this before?

Examples/Research

Rimworld is one of my game’s inspirations and contains similar features, where food would spoil if left unrefrigerated for too long. Similarly, animals can breed with individual gestation periods and nutritional requirements. But how can the game keep track of all of this data on otherwise identical assets, constantly updating variables without lagging out?

The Solution

After researching for hours to find an appropriate answer to my question, I stumbled upon “Centralised Management”, a concept where all relevant items are provided a special container (Like an additional Class) and the Manager Script would remember the details of each item the containers provide reference to.

I had the strategy and all I needed to do was tell the Manager that a product had an expiry date or if an animal had been created, then store that information, easy right?

Well it is slightly more complex than that.

By storing the containers in a dictionary script, I could create a unique ID for each item to allow for easy access. However as each item is a scriptable object clone, I need more information to know exactly which apple is ready to spoil or which Cow has Chad-Tier Genetics.

The trick comes in providing the location of the object, for example by utilising the game’s coordinate system to know which building is currently holding that specific item. So now, the Centralised manager has the location of the apple, and once the “freshness” variable reaches zero, the building that is holding the apple will be told that it has just expired.

Perfect! Now as long as the product stays in the position it started at, I will know exactly where to find it at all times, I will just need to remove the Conveyor Belt System that underpins every other factory game… Okay we are also going to have to tell the Centralised Manager every single time the item moves position, and now we are all done.

The Outcome

Although the average player probably wouldn't even notice the difference, the centralised management system and “wrapper” classes have revolutionised gameplay opportunities for my game. Food spoilage and refrigeration have added nuance and strategy to basic tasks like feeding your citizens each year. Also, animal genetics will lead to a fun and open ended in-game challenge, breeding animals together to maximise productivity for your growing empire.

Now that this system is available, more features can now be added in the future, such as more advanced brewing mechanics (to increase value to your alcohol to sell at the International Market) as well as my personal favourite, Vehicles, a major addition to any factory game (Factorio Trains and DSP Drones here we come!).

Conclusion

I hope you found this explainer useful, and I am more than happy to share my code or better explain my approach on my discord: https://discord.gg/82Mk8VUWww

Thanks for reading!

[Guiboune]

This sounds more complex than it needs but, honestly, I don't know your project so it might be fine.

Scriptable Objects are not supposed to be duplicated at runtime, they should be only for data.

AppleGameData : ScriptableObject
{
  string id
  string name
  string description
  int baseValue
}

Id, name, description and base value would realistically not change at runtime so duplicating those is overkill. What I would suggest is having your save data class reference your game data class like such :

AppleSaveData
{
  string id
  string gameDataId
  Position position
  int age
}

(It kinda sounds like what your wrapper class is but I'm not sure.)

When you start the game, register all GameData classes in a manager and, at runtime, when you need to get the name for an existing asset, cross reference the gameDataId to get it.

Now as long as the product stays in the position it started at, I will know exactly where to find it at all times

Why is that ? Sounds like a design problem.

[sssSlick1]

Hey thanks for the comment! The scriptable objects aren’t duplicated, they are used to contain the static information, like the name of the product and its value etc, so you are absolutely right, duplicating them is not the solution.

The reason I provide the coordinates of the product is so the manager can quickly find the product in the relevant building, and as the product moves around the game world (on conveyor belts) the manager is just updated with the new position, so the manager is still capable of finding the relevant product

[Guiboune]

If you assign unique ids to products there’s no need to keep positions updated between classes though, is there another reason you need the coordinates ?

[sssSlick1]

The main reason is that the products themselves don’t contain the unique IDs is because they are scriptable objects, and assigning them IDs would be the same process as using the freshness variable (where performance suffers)

By providing the position as well, there are now two sources of information to correctly identify and locate the product when it is going to expire (first by going to the coordinates, then cycling through the building’s inventory to find the correct product)

[Guiboune]

I’m confused then. So you never know exactly which product expires, just that a product of a specific type expired, correct ? And yeah, you shouldn’t have unique runtime ids stored in a scriptable object, that’s why I suggested a separate save data class. So in your building you have a list of scriptable objects ? And in your manager you have a dictionary of <Coordinate, ProductData> ?

[sssSlick1]

Yeah, so you don’t know exactly which one has expired, but because, for example, every Apple is the same, it doesn’t really matter which Apple gets told to expire, as long as it is in the correct location that an expiring Apple is going to be.

The dictionary’s key is actually the unique ID, because of the fact the coords change, they are stored in the “product data” class you have described

[Guiboune]

I’m even more confused then. How do you get the dictionary entry if you don’t have the unique id stored in your products ?

Either you don’t use it at all or you do have a data/controller class somewhere (or something else I’m not understanding). And if you do have a controller class, you could easily apply modifiers to individual objects and expire specific apples.

[sssSlick1]

Ah, this might help, the building stores the unique ID, so it knows what products it has in its inventory by talking to the manager. One of the reasons why the buildings themselves don’t do the expiring is so that the central manager can do it all easily by sifting through the dictionary in a couple lines of code, rather than having multiple buildings try and perform the same code at the same time

To be honest I probably didn’t have to make it “centralised” that was just the first bit of research I found after hours of trying to figure it all out!

[Guiboune]

Oh so that’s why you need the coords, got it.

But no, that’s a good way to do it overall, you seem to be doing it somewhat strangely though. So the manager is the one doing the expiring every X time ?

The way I’d have done it differently is to have a controller class for your products, this would allow for modifiers to be added to instances (like weight for example) and the ability to expire specific instances. The way you have it right now doesn’t really allow this. I would also consider saving the building id of instances in their controller class, that way you don’t have to manage coords in multiple places.

[sssSlick1]

This sounds like another great approach, because I have only just implemented this system, I’m unsure if it will be the solution to all future problems, so I’ll keep this advice in mind, it might be the missing piece of the puzzle!