Gameplans: Modularity of Mods

Gameplans: Modularity of Mods

Modular Mods

I want Mods to be as tiny as Possible, so that Modpacks consist out of a few hundred mini Mods that only add one Item or so.
Larger Mods will just specify all the Mods they depend on and how those dependent Mods interconnect with each other.
Here an example: You have a Mod that adds Paper, something many Mods will obviously need, so what does it actually add?
It will add Sheets of Paper in 4096 different Colors, in all the “DIN A#” Sizes of Paper and in Customizable Sizes too, all in 1 Pixel thickness (1/32nd of a Meter, yes that is 3cm thick if you stack it). That is all you need for the Paper itself.
Ofcourse there is more primitive Types of Paper, added by OTHER Tiny Mods, which can use the base Paper Code and make things like Papyrus (the Paper Type, not the Font nor the Skeleton).
Binders, Folders, Books and similar will compress the Full Pixel Thickness of Paper down to a more manageable Size, which will result in them making more sense to actually be used.
There ofcourse can be Books as a tiny Mod, but said Mod will require writing Utensils to be useful and not “Decoratively Empty”, which can yet be another Mod, one for Pencil, one for Ballpoint Pen, and ofcourse one for Feather and Ink Jar. (4096 Colors Support is part of the Base Game and required for pretty much all Mods)
Most people dont want to specify all those tiny Mods themselves, so there will be a general “Office Supplies” Mod, that adds all those tiny Mods together to make one Bigger bundle.
One thing that can be possible is that you have written Paper, but no writing Utensils installed to make them. This can be used for making Scenarios by writing to a Paper, uninstalling your Writing Utensils of choice and then nobody can possibly edit Text in Letters and such.
Another thing would be Letters, sure you can have an Envelope Mod, but no Mail System, nor Stamps, so you still have to manually deliver the Envelope to someone. Envelopes in particular would be available in all the “DIN B#”/“DIN C#”/Custom Sizes too ofcourse.
There is ways to fold Paper to make the Letter itself into an Envelope, which was an old technique to save on Paper. This Method of folding and the corresponding “Written Sheet of Paper folded into Envelope” would be a separate tiny Mod that requires Envelopes and written Sheets of Paper. It would also be dependency/part of the “Office Supplies” Large Mod.
Writing on other Stuff using other ways will also be separate Mods, so Stone Tablets, Signs and such can exist too ofcourse, without having to do Pixel by Pixel editing.

Decided to make a Modularity Example for Mods using Office Supplies such as Paper. XD


While I’m generally a big fan of that I could imagine a compatibility nightmare stemming from that. At least if you allow different modules to implement the same thing in a different way.

Let’s say I want to make a different electricity system that for some reason considers phase and reactive power.
Would that mean I have to make a second copy for every electrical device in existence, or could all these tiny mods just add my new electricity as an alternate mod dependency (once they are compatible)


The Machine itself would consist out of multiple Mods too, and the Power System could be a general Mod for interfacing with things that send and receive Power, but the Electricity System would be the actual thing handling the Power transfer. And there would ofcourse be ways to specify what kinda Power something is, not that you power something electric with rotational Power or something. This also opens up “Universal Power” as a System.


Thats exactly why I chose phase and reactive power as an example. They need information from the machine that does consume the power to work properly, so the machine would need some patching to work in that system.
But I figured that might be some weird edge case that shouldn’t happen too often for more sane mods.
(Not here to critizise your system, I love it, just trying to break it to help you find problems)


You are making an open-source game, so why not simply develop the game in a modular fashion instead of making a dedicated modding API?


Because if things like Data Packs are possible, people with less coding experience can do Stuff! :smiley:


How are you going to load mods? Is the launcher going to apply binary patches and cache various “builds” of the game (1 build cached per “modpack”)? Are you going to implement a script engine and deal with mods at runtime? Are you going to do a text/json based runtime thing like Minecraft’s C++ variant? Are you going to have mod users actually recompile the game when they install mods?


WASM is currently planned. Binary Patches sound kinda dangerous in some cases but might be doable. And the Launcher would be the primary Menu of the Game unlike Minecraft which has Launcher and Main Menu at the same time. Though a running Game would still have Menu capabilities ofcourse for options and such.

Unless I have the Launcher pop in the foreground whenever you wanna change Stuff that cant be done as easily ingame, making it essentially a two Windowed Game. But for that I would need to consult @OvermindDL1 again, because I am not sure if this approach would be Genius or Jankius.

As for recompiling the Game, that sounds very painful, and I have end user experience with a Game compiling before a Map Launches, and it was not nice to waste 5 to 10 minutes waiting on each Map launch as opposed to once per Game Launch.


I’d just piecemeal in things as much as possible, encourage mods to be ‘tiny’ but depend on others. You could have a few focus on code related features, a lot focus on data features (that use the code to do stuff in game, standard ECS bit), etc… Lot of compat then too.

1 Like