Skip to content

The Sharing Tab & The Modules Format — feature tracking (stack #8411) #8412

Description

@keithharvey

The Sharing Tab & The Modules Format

Feature tracking for team-sharing modes, the economy data-plane boundary, and the modules format. The design writeup below is carried over from the original PR (#5704), where the full QA and design discussion history remains readable.

Review & merge: the modules stack

Sharing now ships as one PR on the modules stack: #8463 — modules · multiplayer 2/2: sharing v2, expressed through the mode grammar. The content is the same feature, re-expressed on the module runtime (modules/sharing owns its lib, policies, economy boundary, gadgets, widgets, modes, specs, and types) and de-noised (~44% of insertions in the old chain were formatting). Review path:

Superseded: the 7-PR file-partitioned chain (closed 2026-07-26)

The old chain was rooted on fmt-llm behind the type-migration stack (#8395#8398); sharing v2 is rooted on master via the modules stack instead.

Note

The earlier plan used a single merge-vehicle PR (#5704, later #8406) with the split PRs as review-only satellites. That plan is superseded by native stacked PRs: #8406's head was the identical commit to the sharing/05-game-modes-export tip, so both merge-vehicle PRs are closed and the stack itself is the merge path. Each split PR is file-partitioned — every file appears in exactly one PR in its final form. Regenerated deterministically by just bar::sharing-split.

Outstanding QA / open items

Carried from the #5704 checklist (all shipped items checked there):

  • C++ unit tests on the waterfill functions?
  • Design point still open for feedback: pre-tax resource threshold fills on overflow (by design — you are not taxed on redistribution transfers; audit-dashboard ledgers added to make this verifiable). Community thread ongoing.

Related work

📚 Stacked split— review bottom-up

Each PR merges into the one below it; together they reproduce the sharing_tab branch (bar one intentional change — index.lua lazy-loads the mode helpers).

The idea

Full architecture & rationale — controllers, policies, the Waterfill solver, and the policy DSL it unlocks — is written up in Beyond-All-Reason#8018: Game Controllers & Policies. Short version:

The engine stops being the economy authority and becomes the economy data plane for team redistribution. It keeps measuring (income, pull, expense, per-frame excess) and exposes that state through an API. A registered synced-Lua controller pulls a snapshot on its own cadence, runs redistribution, and writes back its own economy stats directly. Unit transfers, team giveaways (GiveEverythingTo), and /take are replaced by game-side gadgets; native overflow sharing is the one piece behind a flag — nativeExcessSharing = false hands it to the Lua controller.

On top of that boundary, sharing is configured by modes — named presets that set, lock, and hide the individual modoptions. The lobby (Chobby) presents them; the game enforces them. Each modoption stays cardinal (one knob, one behavior) so modes compose them freely.

Modes

Enabled (default) — all sharing on, no tax. Today's game, unchanged.
image

Disabled — no unit or resource sharing
image

Easy Tax — anti-co-op preset. Taxes resource sharing, assist, and resurrection; gifted eco buildings are stunned and mobile constructors build-delayed, so you can't dodge the tax by handing over production. /take runs on a stun delay.
image

Tech Core — tech levels gate what you can build; you raise your level by constructing Keystone buildings. Unit sharing and resource tax both scale with tier (e.g. constructors become shareable at T2; tax eases as you climb). /take runs on a 60s delay for Resource buildings (the Take Delay Category in the screenshot below).
image

Customize — every knob editable; roll your own policy.

Note: This is the one mode that preserves the previous mode's values when switching to it, so you can switch from tech core to customize and customize will behave exactly like tech core.

For players and mode developers, Customize provides a lot of benefits for this design:

  1. Removes a lot of complexity from the other modes, allowing us to hide/lock the opinionated mode without impacting customization of any new capabilities those modes may bring to the table.
  2. Lets people roll their own fully customizable mode, if they want.
  3. Gives us all the knobs needed to prove that each diverse mod option is actually orthogonal during testing.
  4. Lets users intuitively understand how this works under the covers and that the individual mod options are the implementation details for each top-level mode.
image

Other changes

  • Geo/Mex upgrades fixed (credit Hobo): the unit-sharing filter now lets "Utility" (resource) buildings transfer, so you can upgrade an ally's mex. Could become its own toggle later (Try to merge master into gl4cus #1040), out of scope here.
  • /take moved into the game (was engine-native), which is what enables the delay/category take modes above.
  • Invalid-unit feedback: units a mode disallows show in tooltips and highlight when you hover an ally in the player list.

Demos

LLM usage

Tons of AI usage, but this started on much earlier models so I really had to beat it into shape and the code is clearly my style of decompositional functional programming, and that doesn't happen accidentally.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions