Architecture

Conduit is a stack of eight Fabric mods. Each one publishes its own Maven artifact, declares its own fabric.mod.json, and depends on only the layers below it. There are no circular dependencies.

The dependency stack

┌───────────────────────────────────────────────────┐
│  Your game mod                                    │  ← application
├───────────────────────────────────────────────────┤
│  conduit-arena                                    │  ← lifecycle
│   hub · lobby · instance pool · /conduit          │
├───────────────────────────────────────────────────┤
│  conduit-prefab · conduit-fx · conduit-spectator  │  ← supporting
│  conduit-world · conduit-instance                 │
├───────────────────────────────────────────────────┤
│  conduit-render                                   │  ← UI
│   screens · labels · 3D displays                  │
├───────────────────────────────────────────────────┤
│  conduit-core                                     │  ← foundation
│   teleport · session · stash · perms · config     │
├───────────────────────────────────────────────────┤
│  Fabric API · Minecraft 26.1.2 · Java 25          │
└───────────────────────────────────────────────────┘

A higher layer depends on every layer below it. Lower layers know nothing about higher ones.

Module responsibilities

conduit-core

Configuration, permissions, safe cross-dimension teleport, the player session manager, the inventory stash, the per-player state map. No rendering, no game-flow, no client code.

conduit-render

Server-authoritative in-world UI. Screens, labels, 3D block displays. The server sends typed payloads; a small client companion mod renders them. Vanilla clients fail the canSend check and are silently skipped, so mods are responsible for chat / entity-based fallbacks when those players need to interact.

conduit-world

Per-instance WorldSettings snapshots (time, weather, mob-spawning, keep-inventory). The void biome + empty chunk generator used by every instance dimension.

conduit-instance

On-demand runtime dimensions — RuntimeDimensions.create / release build and tear down a fresh world per match instead of claiming from a fixed pool. One accessor mixin reaches the server’s level map; everything else is public API + Fabric events.

conduit-spectator

Custom spectator promotion/demotion that avoids vanilla gamemode-switch crashes and tracks the previous gamemode + spawn position for safe restoration.

conduit-fx

Presentation helpers — Countdown for chat sequences, PlayerBossbar wrappers, Effects macros for particle and sound bursts.

conduit-prefab

Authored scene system. Define a chunk of world content as JSON (blocks, screens, labels, named zones), spawn it at runtime with variable substitution, despawn cleanly.

conduit-arena

The full hub-lobby-instance orchestration. InstanceManager pool, permanent hub world, LobbyEngine state machine, the Game abstract class with phase lifecycle, /conduit operator commands.

Two game architectures

Conduit recognises two patterns of game mod via the GameKind enum:

• SINGLETON — the game lives wherever the operator runs /your-mod start, with no instance pool or lobby. Best for simple command-driven mods. Depend on conduit-core + maybe conduit-render. You probably don’t need conduit-arena.
• MULTI_LOBBY — players walk into a hub, queue in a lobby, get teleported into a fresh instance dimension for each round. Best for arena-style games with concurrent matches. Depend on conduit-arena (which pulls in everything).

The GameKind enum exists so the framework can branch on which pattern you’ve registered, and so docs can tell you which features apply.

Mixins kept minimal

Conduit reaches for Fabric API events first and drops to mixins only where no event exists. The shipping set is small — a couple of accessors (EntityAccessor, MinecraftServerAccessor, MinecraftServerLevelsAccessor), the in-world-UI click capture, the runtime-dimension level-map access, and a few cosmetic End-gateway / world-gen tweaks.

That matters for portability: Fabric events are stable contracts across Minecraft versions, while mixins bind to specific class + method signatures that move on each update. The fewer mixins, the cheaper each port — so they’re treated as a cost to minimize, not a default tool.