Party games

A host that rotates a lobby through a series of micro-games - Mario-Party style. Each micro-game is two methods.

A party game is a host: one persistent lobby that moves a fixed group of players through a board and a rotating series of micro-games, tallying coins along the way. The host - board movement, turn order, the “pick the next micro-game” roller, camera transitions and coin payout - is written once for you. You write the micro-games.

The host vs. the rounds

The genre splits cleanly:

• The host (the genre) owns the shape: whose turn it is, moving pieces on the board, rolling the next micro-game, awarding coins from each result, and returning everyone to the board between rounds.
• A round (your code) owns the rules of one micro-game: spawn the players, run it, and report who placed where.

So adding a micro-game never means touching turn logic or payouts - you implement one small interface and register it.

A round is two methods

RoundMinigame is the whole seam. onStart sets the round up through the ports; onEnd returns a ranking, which the host turns into points, scoreboard updates, stats and coins automatically.

public final class FallingFloor implements RoundMinigame {

  public void onStart(RoundContext ctx) {
    ctx.world().markers("Floor").forEach(ctx::arm);   // arm every floor tile
    ctx.players().forEach(p -> p.teleport(ctx.spawn(p)));
    ctx.countdown(3);                                  // "3… 2… 1… GO"
  }

  public RoundResult onEnd(RoundContext ctx) {
    return RoundResult.byLastStanding(ctx.players());  // ranking → coins
  }
}

RoundContext

Mirrors MatchContext, scoped to one round: players(), world(), spawn(p), scoreboard(), a Scheduler for the round’s loop, and countdown(seconds). The same portable PlayerHandle / GameWorld surface applies - see Ports & portability.

RoundResult

A round ends by returning a ranking. The host reads it to award coins (more for a better placement), update the running scoreboard and record stats. Build it the easy way or supply your own order:

The mapping from placement to coins is the host’s job and is tunable per network from the dashboard, so the same round pays out consistently across every game that uses it.

What a real party game looks like

GINCo’s Byte Crashers (a shipping Hytale party game) is exactly this shape: a board host that rolls through a pool of micro-games. Mapped onto the seam, its rounds are nothing more than onStart + a RoundResult:

The genuinely engine-specific parts (detecting who is on which color, fall detection under a broken floor) are normal Hytale ECS systems the game writes itself, reached through the escape hatch. The host, scoring, coins and board return are the genre’s.

Registering rounds

The host needs the pool of micro-games to roll from. List them in the manifest’s rounds block (see Manifest & config), or register at startup:

rounds.register(new FallingFloor());
rounds.register(new HotPotato());
rounds.register(new CoinRush());
// the host shuffles and rolls from this pool each turn

Economy

Coins are first-class: the host credits them from each RoundResult through the Economy port, and balances persist in player data. A board shop or end-game ranking reads the same balances - you don’t track currency by hand.

Start thick, extract later

A party game’s micro-games are often mechanics-heavy - custom physics, a bespoke detection loop - and that’s fine. Don’t reach for portability up front: write the first party game’s rounds straight against your engine (the escape hatch is there for the native long tail). Pull a shared, cross-engine round framework out of working code only once a second game would reuse it.

Next

• Manifest & config - declare the round pool and coin payout.
• Ports & portability - the engine seam and escape hatch.
• Match games - the other genre.