A roadmap for actual mod support

[badosu]

Since I see a lot of confusion about how recoil supports modding and ideas - for true mod support roadmap for BAR on discord - I'll post some information and open discussion on true modding support. I'm not a stakeholder of this effort, but I believe opening the channel and having a reliable reference for the task is valuable.

Overview and current BAR modding support

Just to clarify, there are actual mods and the thing often done in bar via "tweak" modoptions.

A mod is basically some directory that contains a modinfo.lua and some files to overwrite/add to the original game. Being a very simple format, already supported by the content distribution scheme BAR uses (rapid with custom CDN) and friendly for version tracking, makes it a prime candidate, as supported directly by the engine, for modding instead of some ad-hoc implementation.

Here's an example of an actual mod see the modinfo.lua with zk:stable in the list of dependencies. It's a mod of ZeroK, its contents either overwrite or add to the virtual file system tree so modding is very straightforward and simple

The other bit, which are the custom widgets and tweakoptions, the only modding-like feature BAR supports atm is just a hack so players can get something done. Recently @itanthias also implemented tweakscript which is basically allowing units to have their animation scripts tweaked, with the drawback it only supports LUS scripts (Lua Unit Scripts as opposed to BOS/COB format that BAR employs for most units), but this approach only goes so far until you get a mess of exposed inputs that are eval'ed by the game from modoptions - with both maintainability, usability and security concerns.

About engine capabilities

From the standpoint of modding requirements, to what concerns being able to accept changes to the game from a trusted source and running the game with those changes, this is a solved problem as far as I know, there should be no blockers preventing BAR to implement support for true mods as far as engine capabilities go.

The complexity lies in management, curation and distribution of mod packages, allowed to be served via some BAR lobby client and the hosts. This is not a small task, it's very complex and effortful.

Remark: Mutators

I didn't assess the use case for mutators on the analysis of this post, if more information is provided the roadmap could be revised to contemplate them. There is a current engine issue and a hard limit of 10 mutators, this is very likely to not be a relevant issue at early stages of modding support implementation.

An example roadmap

Some sort of curation would be necessary at the initial implementation, this is especially relevant since BAR wants to enforce some "standard of quality", an idea (this is just the strictest possibility for a start):

• Teiserver has a page where admins can manage acceptable mods
• A mod is a modname, a link to a repo and a SHA, e.g. modname:mybarmod repo:"github.com/badosu/mybarmod" sha:123456, mods are always pinned to a version
• The package either BAR builds from this information and publishes to its own cdn, with the SHA tag in rapid e.g. rapid://mybarmod:123456, or is manually built on the first implementation attempts (to reduce implementation complexity, just upload the mod.sdz)
• Somehow spads and lobby clients are aware of this list of acceptable mods, spads has rapid://mybarmod:123456 available in its archive

Requires a multidisciplinary effort spanning multiple projects and configuration files (lobby client, spads, teiserver, BARs rapid CDN and glue it all together).

On mod maintainability

It would be very important for BAR to leverage some versioning scheme for mod dependencies at some point. I am not too familiar with rapid and BARs custom CDN on top of rapid to know if this is alreasy feasible, but to keep things from breaking you'd want one of two:

• Mods have to always keep up with bar changes, because the version of BAR used is always the latest. Pro: simple mods that don't do anything particularly troublesome keep up with the game with minimal maintenance. Con: mods might break often and provide a poor player experience.
• Mods tag the last known supported BAR version, e.g. depends = { rapid://byar:654321 } in modinfo.lua. Pro: mods perform as well as they performed when submitted, don't break with BAR updates. Con: mods that are not actively maintained might lag and show some version of BAR that BAR itself doesn't want to be shown (as part of the "quality standard" thing), mods spam updates where they only change the depends line on modinfo.lua (this might be more of a pro than a con, since in theory the mod maintainer should have tested the mod against that version)

[WatchTheFort]

Regarding mods and BAR version: mods need to always keep up with the latest version of BAR. This guarantees that running multiple mods will be not-impossible (note this doesn't mean it will always be possible). More importantly, it keeps all lobbies on the same version of the game.

[sprunk]

Who verifies whether a mod is kept up?

[WatchTheFort]

The error log.

But really, it is the mod maintainer's responsibility to keep the mod up-to-date.

[WatchTheFort]

Regarding curation, I don't see us curating mods, outside of select mods getting an "official" seal of approval, and some kind of showcase in the UI. The important thing is that the player can browse, install, and configure mods within the application.

[badosu]

Personally I find this stance surprising for the level of control I'd expect for BAR to want to retain. And this is one case that, at least at initial stages of implementation, I'd be extremely careful to allow.

[WatchTheFort]

It is much more important that we implement modding support than that we curate every mod. We have several game modes and tweaks we would convert to proper mods (i.e. evolving Commanders, extra units, Nutty Raptors), so that the initial release has several official mods. We could even ship them with the game, something SupCom did.

[tetrisface]

beyond an mvp it would be useful to specify mod dependencies in an ordered list

[badosu]

I agree, there's one annoying issue that this feature kind of requires dependency versioning.

After an mvp, the first step would be to have perhaps a liberal dependency check (just checks it is required, regardless of version). This is because in the most simple scenario we'd always pull the latest signed off version of the widget, doing differently has a lot of inherent complexity we wouldn't be able to manage early.

The other challenge for "proper" dependency management is that there is no sandboxing that allows different versions of the same dependency available - and it does not make any sense, anyway¹. The only manageable, in the current circumstances, version of the whole thing at the moment is that mods/widgets must track the current version of the game, and naturally dependency versioning is almost² antithetical to this.

So, in summary (as I see it):

• Supporting required dependencies makes sense, not much sense to add it in earlier iterations of the system. Just having in the description, in my experience of other modded games, is mostly enough. If it's not much effort to get it done in the simplest iteration that makes sense (no version tracking, detecting cyclic dependencies) then all good³.
• Supporting known conflicts, same as above³.
• The load is transferred to the widget author, that must ensure their widget is compatible with their dependencies, and maintains the setting appropriately.
• The challenge of versioning check, unfeasible to be able to specify dependency versions imo.

Edit

I just realized I said this in the context of the "widget hub" discussion, which is the embryo of a mod management system. In this case, most remains the same (replace widget with mod). Except for dependency versioning check, which makes sense for actual game mods.

Footnotes

1. I could expand on this, but to keep it short, the requirements of modules in a game are very different of the requirements of modules in libraries for example. ↩

2. Some clever scheme could be devised, but I don't think it's worth the complexity. ↩

3. Mitigating cases that are extremely hard to diagnose by players who don't provide good technical data "this doesn't work", having to ask them, a lot of work and load on contributors. ↩ ↩²

[tetrisface]

I think a releasable implementation would have "game version" as a strict dependency and the rest as a list of unversioned stuff. where maybe the last mod is a "master" that defines the intended game version and all the others will in some way be warned about not targeting the correct game version (if they dont).

I have not tested the "depend" modinfo.lua field table. not sure if that works to load multiple mods/games in addition to the mutators.

or skip as a strict requirement and give the players the option of bumping the game version but with a warning.

[tetrisface]

I have started PRs for these repos:
beyond-all-reason/bar-lobby#487
beyond-all-reason/tachyon#77
beyond-all-reason/teiserver#820