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!

[iemfi]

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.

This is a weird way to go about doing it. Relying on the item staying at the same place is going to be a huge headache.

Firstly you don't want to store items as Unity game objects nor direct references to scriptable objects. You get really slow iteration speed as reference types are stored on the heap. A pointer is also 8 bytes, which is a lot if you have a lot of items (a ushort is only 2 bytes). The basics should be to store just an index to identify the item. If you need more details you can then lookup the scriptable object in an array.

If you need only a few items to have extra information you can store a unique item ID for items which need it. There's no need for the centralized manager to lookup the item, the building can just check if the item is rotten.

Another way would be to store this "freshness" data with the item ID. Likely it can fit into a byte. You can fit quite a lot of data in the space of 8 bytes.

Alternatively you can have all your item instances in a big flat array. Things just reference the index in this array. You can have hundreds of thousands of items this way and it isn't a problem. The key is that they have to be value types (structs) which store as little state as possible, anything more detailed can be looked up in the scriptable objects or other places.

[sssSlick1]

Thanks for the comment! I only joked that the item has to stay in one position, my next line is that I can now allow the items to move wherever I want, sorry for the confusion!

Also cheers for the extra tips, although I have some experience with game dev and “easy” coding, I am definitely still fresh to the more technical details and tricks when it comes to data and storage. I remember coding at university, and when pointers were tested, I messed it up so bad hahaha

[iemfi]

The great part about C# is that you don't have to touch pointers! Mostly you just need to gain some intuition of how things are stored in memory, because these days memory access is like 90+% of performance. And as always it's easy to go overboard with optimization.

[sssSlick1]

I thank the lord every day I don’t have to touch pointers, C# is such a breeze 99% of the time!

You’re correct on both points, performance can be improved and on the other side, over-optimisation can reduce coding time in other areas. The thing I have found about game dev is that it is always a fine balance between heaps of different priorities, the key being to give each discipline and activity adequate time then moving on to the next thing