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)
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.
Okay, so you are doing core development in Rust and deploying to WebAssembly. You’ll have a launcher program that is either a separate window (does WASM support multiple “windows”?) or an overlay.
Let’s see if I can push you to lay out a more detailed plan. This is all planning-stage - you don’t have to commit to anything final - but the lack of progress is depressing. Hopefully if I get you to write more details down, it will be easier for you to actually implement something.
Pretend I’m a mod author. Would you tell me what it’s going to look like for me to develop a mod for Mechaenetia? What tools will I use, will you publish an API, is there a protected or core functionality scheme, what language(s) do I work in, how do I distribute?
.
(You say binary patches might be an option for mod distribution, by which I assume you mean patches to either .wasm files or some wrapper executable.)
What will it be like, from the user’s perspective, to run mods? Can you walk me through the process of finding, downloading, installing, and running a mod?
Just like real depression issues i have right now. I’m feeling demotivated a lot this year, and last year too for that matter.
1a. “normal” Modders will just use WASM to “script/code” things according to API and edit csv Files for their Worlds/Entities/Blocks/Items, with maybe some sort of png->basicmodel mapping (each square being a layer as if the Item was 3D printed).
1b. More advanced Modders should be able to do patches to the actual Rust Code to add completely new functionality.
2a. You know how Factorio handles Mod downloads? Something similar to that but in the Launcher instead of inside the Game. Preferably with some sort of Tag system so searching is easier.
2b. There will be a central curated Online List of downloadable Mods that the Launcher will show you by default. You will also be able to add more of those Online Lists from 3rd Parties too, similar to how Ad Blocker Lists work. Each Downloadable Mod will have its own simple Webpage (with a predefined Text format, I am not gonna let HTML or Javascript happen there) that is shown when you select the Mod. Obviously I will add a lot of quality of Life things, so you can just copypaste a List of Mods you want into the thing and BOOM you got a Modpack that is gonna be downloaded right away.
2c. Installing Mods is quite literally dumping them into the global mods Folder and enabling them in the Launcher for your selected Modpack. You dont need to have multiple copies of the same Mod (nor symlinks) if you just want 2 different Modpacks with shared Mods.
2d. And Mods themselves are supposed to be tiny and easy to bundle, so you can update specific Parts of your Pack if needed instead of a stupidly huge Mega-Mod like GregTech. (yeah I actually hate the way I ended up making GT a giant Mod, but I cant modularize the System anymore)
WASM is more for a Sandboxing the Mods purpose, so simple Script-ish Mods that are too complext for csv Files can do stuff without touching too much Stuff. Also pretty much everything can compile into WASM so you can select a Language easily.
@OvermindDL1 suggested that to me for a language to have Mods in, since it is the most versatile.
WASM requires a virtual machine. Are you planning on implementing that yourself (maybe with the help of a library) just to sandbox mods, or are you deploying the entire game to WASM?
For an exact answer to that I need to learn more about WASM as I go. Though a lot of Parts of the Game will be Rust Code for efficiency reasons ofcourse.
I see. Maybe you didn’t know, but apparently Rust can compile into WASM. So having everything go to WASM is an option too, but you would need to use an additional library if you want your game to be an executable and not a browser game.
I think what those games do is they implement/embed the Lua runtime environment (or a subset of it). If I’m not mistaken Lua provides a C/C++ library that does just that. Maybe something similar exists for WASM.
I found this “WASMER” repository which is probably what you would want:
Because WebAssembly is sandboxed, memory must be copied between the host (your Rust application) and the Wasm module. Upcoming proposals like WebAssembly Interface types will make this process much easier, but it is still a work in progress.
