Part 2. Keep it Generic and Scriptable Objects

Now to show you how I apply these principles and what methods I use , I would like to use a case study from my game Fathom’s Found. In the game you can conduct scientific research by sampling different materials and seeing how they react to each other. Objects can also be sources of radioactivity or oxygen which the player can also detect. The materials will change and react under certain circumstances.

However it did not start this way, at first the system only needed to do one thing. Something needed to be a source of oxygen and the player needed to be able to detect the oxygen levels. Seeing as how this was for a playtest I quickly cobbled this system together.

It was made up of two simple scripts: an OxygenSource and an OxgygenDetector. The source was a simple trigger collider which added any detectors that entered it to a list and the detector then counted up all the values to display the current oxygen levels.

From here this part of the game expanded and it became clear it would require a more complex system, the first step was to make the existing system generic. This meant that OxygenSource became Source and OxygenDetector became Detector and they both gained a property variable to determine what it was a source of.

This is where I employed scriptable objects. Instead of comparing strings or creating an enum I made a scriptable object class called property in which I could store the property name and any other variables that might be relevant. I could then make a runtime set of all the properties. This lets you add or remove properties from the project tab in unity very easily. It won’t matter if a property gets added or scrapped, in fact you won’t even have to concern yourself with that because if you add a createassetmenu at the top of the property class your designer can create and edit them without needing to touch any code.

Part 3: https://cosmicsentinelstud.wixsite.com/website/post/part-3-case-study-replace-dictionaries-with-serialized-classes