Mod Support Planning and Design (Patreon)

I thought it might be interesting to sort of "design out loud" as I'm working on the mod support system, and provide this as some patron-only content. If this sort of thing interests you, feel free to chime in, but I'm providing this mostly as entertainment for the interested.

Developing a mod support system requires three parts, as I see it:

1. We need some sort of compiler that takes user generated files and turns them into a type of datafile that can be read by the engine. For this I will use JSON, compressed to base 64. I'll also give these files a custom file extension to dissuade users from trying to hand-edit them.

2. We need a system within the engine that "reads" the files, and unpacks all the JSON data, then checks the data, and safely adds it to the game's internal data. The design of Succubus Stories is very data-driven internally. Here are some examples from the game's source code of the structured data used for various parts of the game:

The point is, adding new things to the game can be as simple as adding a little bit of data to the game, and the engine will do the rest, mostly. Mod support will be based around adding this sort of structured data to the game, not around custom scripting. Custom scripting may or may not be a part of mod support in the future, but for now, I mostly want to focus on letting players add and replace data.

Adding data to the engine is fairly straightforward, the engine needs to look in a specific folder near the executable, say "mods", and grab all files with the appropriate extension. It will then attempt to read all those files in order, decompressing them, checking the data for errors or issues, then, if it's valid, merging the data in the mod into the appropriate data already in the game.

3. I want to create a user-interface and toolchain for users to make mods. This is the trickiest part, and the last I will work on. Adding mod support is easy enough, but I want users to be able to write their mod data in a human-editable way (probably Twee), test and edit these mods in an easy manner, and be able to compile them for sharing with the click of a button.

Once the mod tools and mod support are done, I also need to document the engine, which will be its own kind of special hell, I'm sure.

What kind of modding will be possible?

Here's a handy table I made:

Note that this table represents my aspirations, don't take it as a given that I'll achieve everything I want to, but right now, my goal is to have most repeatable-content aspects of the game be moddable; that's events, activities, scenes, and actions in encounters. Things that are easy to allow mods for, like perks and traits, are also included.

So what's the plan?

Step 1 is to create a compiler that turns Twee files into JSON and then eventually base 64. Once I've finished that, I need to create a specification for how these Twee files will represent certain kinds of structured data used by the engine, then work on a parser in the engine itself to handle the mod files. None of this will be super hard, but it will take time and require lots of thorough testing, and this is what I plan to spend the next little bit working on.

Once mod support is in the game, I'll probably start releasing some patron-only "mods" to you guys to test out the system. Working on the actual mod tools will probably be a long process, but for the technically-minded, I may provide the mod compiler in some form, maybe as an NPM package so users who are interested can experiment with it.

We'll talk more about the design of the tooling itself when I get that far. Until I nail down a spec of how I want to handle all the data, I can't really move much on the user-side tools.

Conclusion

I will continue to provide updates on how this all is going over the next few weeks, and indeed over the next few updates as mod support takes shape.