help with code structure for moddable game.

I am considering building my game as if it was mod. So it gets mod support right from the start, and the game itself would be an API of the sorts. However, I am struggling a bit to think what would be best way to handle some things.

Let's say I can create a new ability like strength, and create a raw (a JSON file) with that ability. Then I create a specie that says the strength of that creature is from 10 to 15.

And then when the creature is created it will select a random value from 10 to 15.

But the question is, would it be best to have a base class that reads from the raw and is instantiated with the info of the raw. And then read by the creature by instantiating another class with the values already set?
Like this:
Hability Raw({"str": "10-15"}) -> HabilityRawClass(strMin = 10; strMax = 15) -> HabilityFinalClass(Str = 13) -> Creature

Or is it possible to handle this with a single class? Like load stuff from the raw and then when loading into the creature it re instantiate or create a copy of the instance with the final value (Which I don't even know if it's possible)
Hability Raw({"str": "10-15"}) -> Hability(Str = 13) -> Creature

Thing is, there will be multiple creatures, the creature in itself will be a raw too, and it will technically instantiate the hability, and load the raw each time the creature is created sounds something that is not performance friendly.

So maybe instantiating The hability class and then copying it and when copying it sets the final value?
Thinking like this I thiiiink the class would be something like:

Code (CSharp):

1. class Hability{
2.     int min;
3.     int max;
4.     int final;
5.  
6.     public Hability(){
7.         Deserialize();
8.         SetMin();
9.         SetMax();
10.     }
11.  
12.    public OnCopy(){
13.         CalcFinalValue();
14.    }
15. }

But again, would be something like that be possible?

 

I siuggest you switch to using asset bundles as mods instead of creating your own system. Then you can have AbilityBehaviour and AbilityAsset in separate projects and edit both with all powers of unity editor.

 

That is not very friendly to modders who don't have access to the original project.

I would be building much of the game using a runtime scripting language. Anything you would want modders to have access to modify.

Also I wouldn't use JSON, as it is not very friendly for hand editing by people who aren't experts in it. I'd come up with a much more generic text format that has much better tolerance for how white space or other structure is used (in JSON, one out of place "{" and the whole file could be trash).

CSV files for example. Easy to implement, easy for any idiot to modify, hard to screw up, and it is common for people to already have software installed for editing these things.

 

If you're willing to support library injections, creating interfaces / decoupling logic might be one of the steps to ensure your code is actually reusable. Providing an interface is way more useful than making thousands of useless JSON files. Also, events and API.

Just built your data / interfaces separately as a library and provide it as a part of SDK. Create hooks that are called at certain parts of the code you'd think may be or will be used from the mod.


Even creating a single code entry point for the custom library is a step forward. People tend to forget how strong C# assemblies are.

 

Oh, I do plan in doing that too.

However assets are bundles which make the need of people wanting to make mods to download Unity, instead of just needing to use, well, notepad to make mods with raws.

Scriptable objects are almost what I need, but, when the asset of a scriptableobj is opened in notepad++ for example, it shows, well, worthless data instead of just the editable data.
Also this:

This is pretty much the reason why want to support raws above all else. In Dwarf Fortress people mod the game with notepad, and think a waste using anything else to mod. I would think not wanting to use anything else a sign of laziness if they didn't create content worth of entire content packs.

I already tested and was able to slip Iron Python into the project. But since performance is a worry of mine in this project I plan to make most of the API inside C#.

I wouldn't use CSV because then the ammount of files needed would increase considerably.

I was planning to use YML, but there's a bunch of libraries that uses JSOn in Unity, so I am torn.

For that I will quote myself: