- Home /
Unique function for each instance of a scriptable object
Hello everyone,
I want each instance of my scriptable object "Biome" to have a unique custom function that (for example) returns a NoiseMap that is used by the world generator. How can I attach unique functions to each of the instance of my scriptable object?
Answer by logicandchaos · Apr 19, 2020 at 04:34 PM
Generally you don't you would make an abstract class and a different different class for each functionality.. but you could try to make a ScriptableAction.
abstract class ScriptableAction : ScriptableObject
{
public virtual void PerformAction(){}
}
Then you define all your actions as ScriptableActions and in your Biome you have a reference to a ScriptableAction.
public ScriptableAction action;
Then you can drag and drop it in for different instances.
Answer by Bunny83 · Apr 19, 2020 at 05:29 PM
Well, depending on what other aspects go into your biome generation you can use even more scriptable objects to act as plugable behaviours. To get a bit more insight I highly recommend this unite talk as well as this older unite talk from Richard Fine.
So your Biom generator could consist of a list of references to other smaller concrete implementations of parts of the generation. That way you can easily setup different biomes by mixing different aspects together. For example MC also has a decorator pattern in place. So that's just a routine / system that applies changes to the already generated terrain. This could mean adding trees, carving caves, distribute ores, adding villages and so on. Of course the more customizable features you want to have the more complex the system gets. However it's much more flexible that way and avoids duplicating code.
Yes in theory you could just use plain old inheritance. However sooner or later you run into the common inheritance issues. For example if you create a "normal overworld" terrain generator and create several subclasses which might just add other features to it, like tree generation for one biome and cacti generation for desert like biomes. Now if you want to create a new seperate terrain generator this is of course possible. However you can not just add the same features you added to your other biomes without copying all the code over. If you seperate each feature into it's own strategy it becomes much more decoupled and flexible. You may want to have a look at the strategy pattern if you have never heard of it. Note that in principle Unity's approach with components follows a similar pattern as the strategy pattern but even a bit more loosely as MonoBehaviours do not use inheritance from Unity's point of view.
Just to provide a little overview what you can do: Imagine a structure like this:
BiomeGenerator
|
+-TerrainGenerator
| |
| +-TerrainGeneratorConfig
| +-TerrainAlgorithm
| +-[List of Decorators]
|
+-[List of postprocessors]
+-BiomeSettings
Each entry here is essentially a seperate scriptable object which has an abstract base class and can have several different implementations. This way you can simply reuse the same config / algorithm / decorator for several different biomes but if necessary you can simply replace any of those parts in the unity editor by a different implementation.
Your answer
Follow this Question
Related Questions
Should I work with scriptable objects like that? 1 Answer
Reference to scene objects from scriptable objects 1 Answer
How Are You Resetting Your Scriptable Objects Between Play Tests? 3 Answers
Memory usage of Sprites in a referenced Scriptable Object 0 Answers
is having a Prefab reference inside a a Scriptable Object legit? 0 Answers