koobas.hobune.stream
Modular property/interaction system
I'd like to make a game that's modifiable in-game by users, where they can create items of all kinds and add properties and interactions to those items. Kind of like in-game mods.
Items have properties/interactions such as Temperature, WaterWetness, Damage, Right Click, Left Click, etc. You must be able to create new types of properties/interactions and they must be addable to items, all at runtime. (For example you may want electricity in the game, and want certain items to have a charge property. You may want something to happen when you hold shift and click, and add that interaction detection to items.)
They are called by some other item or input, such as a flamethrower, water, a drill, mouse clicks, etc, that may pass parameters such as value change over time (heat up or cool down, get wetter or drier, etc) or gameobjects (something passes through a detector and the detector decides what to do/not to do based on the specific gameobject's properties (for example a detector is triggered and it only sets of an alarm if the gameobject that triggered it has a property "organicLife" or if it's temperature is greater than 20)).
Normally this would be achieved by pre-existing functions and variables, but obviously that wont work for a user modifiable system.
I plan to have some kind of simple drag and drop "if [this or this] and [this < this] then [that] and [that * 2] and [that + this.value]" GUI.
At the moment I'm looking to save all of this data in JSON files.
I don't know if I've described this particularly well, it's a bit tricky to write down in words. If you do understand, what's the best/most efficient way to achieve this system?
You may get better responses if you provide some scripts that are you are trying to implement.
You're looking at a lot of functionality. Absent more information (like the scripts that @OrionGamesInc suggested you provide), all we can do is give you general advice.
My advice is look at the design patterns indicated by the features you suggested.
You want a modding system. That implies a plugin framework. Plugin frameworks generally indicate the Visitor pattern. So definitely look at that.
You want to add a little language built around the if this, then that concept. The little language you want to build indicates the Interpreter pattern. If this, then that-type languages also imply that you need ways to stack rules with precedence. That indicates the Chain of Responsibility pattern.
It seems like you need some kind of event model, which indicates the Observer pattern. That one is rarely looked at deeply because, like Iterator, an implementation is pretty much built into C#. However, understanding the motivations behind the pattern might lead you to choose another implementation. Worst case scenario, you learn something and then decide to just go with .NET events or Unity events.
It won't hurt to learn more about other patterns or just to look for the essential problems you have and hit up Google to see if there is a known pattern around that kind of problem.
All that said, I would urge you to carefully consider the vastness of your undertaking. Not that it's not a cool idea. It is a cool idea.
t's the kind of cool idea that can turn into a rabbit hole for you. I've seen a lot of people get sucked into the idea of creating the meta-thing rather than the thing, itself. They get so focused on giving their customers the ability to configure their product that they never get around to putting any actual functionality in that product.
That's not just the case for games, mind you. You pick a problem and I bet you can find a meta-solution that, in it's attempt to solve every problem solves nothing.
Don't get me wrong. I'm not saying "don't build an extensible, mod-able game". I'm saying "don't get so focused on mod-writers that nothing is left for the core features".
Probably all stuff you've already heard.
