Documentation menu

Manifest & config

hive-game.json tells the network how to size lobbies and load your game. Config is a typed Java class operators tune from the dashboard.

Not built yet, this is a design preview. This feature isn't in the current SDK. Nothing on this page resolves against a real build today, so read it as the planned design. It ships alongside the Hytale beta.

Two files describe a game to the network. hive-game.json is the manifest - fixed facts the network needs to register, size and route your game. The config class is the per-network knobs operators tune at runtime.

hive-game.json

The manifest sits at the root of your game jar. The network reads it to register the game, size the lobby, and boot a fresh instance whenever one fills.

hive-game.json 
{
  "id": "skywars",
  "name": "SkyWars",
  "genre": "match",
  "engine": "hytale",
  "main": "net.example.SkyWars",

  "minPlayers": 2,
  "maxPlayers": 12,
  "countdownSeconds": 20,

  "arena": {
    "world": "skywars-map-1",
    "spawns": "Player_Spawnpoint"
  }
}
FieldMeaning
idthe serverType / world type matchmaking routes by - must be unique on your network
namedisplay name shown in lobbies and the dashboard
genrematch or party - picks the lifecycle (match / party)
enginehytale or minecraft - which adapter this jar targets
mainfully-qualified class that extends MatchLifecycle / hosts the party
minPlayersplayers needed before the countdown starts
maxPlayerslobby capacity; also what matchmaking treats as “full”
countdownSecondslobby countdown once minPlayers is reached
arena.worldthe GameWorld template to instantiate per match
arena.spawnsthe marker type the genre reads for spawn points

minPlayers / maxPlayers / countdownSeconds are exactly the numbers matchmaking’s start-aware routing uses to fill lobbies top-down - declare them here and the routing follows.

Party rounds

A party game lists its micro-game pool instead of a single arena. The host rolls from this pool each turn:

hive-game.json 
{
  "id": "blockparty",
  "genre": "party",
  "engine": "hytale",
  "main": "net.example.PartyHost",

  "board": "party-board-1",
  "turns": 12,
  "rounds": [
    "net.example.rounds.FallingFloor",
    "net.example.rounds.HotPotato",
    "net.example.rounds.CoinRush"
  ]
}

Typed config

Per-network settings are a plain Java class - no annotations, no schema file. The network loads it, validates the types, and hands it to your instance. MatchLifecycle<SkyWarsConfig> is generic over it, so ctx.config() is fully typed.

SkyWarsConfig.java 
public final class SkyWarsConfig {
  int chestRefillSeconds = 120;
  boolean doubleJump = true;
  int coinsPerKill = 10;
}

Read it straight off the context:

SkyWars.java 
public void onStart(MatchContext ctx) {
  if (ctx.config().doubleJump) ctx.players().forEach(this::enableDoubleJump);
}

Manifest vs. config - which goes where

A simple rule keeps the split clean:

  • Manifest = facts the network needs before your code runs - how to register, size and route the game. Fixed per build.
  • Config = knobs your game reads at runtime. Tunable per network without a rebuild.

The field defaults in your config class are the starting values; an operator overrides them from the dashboard, scoped to the server type so every server running this game shares one config, and the network passes the resolved object to every new instance. You never parse a file or read an environment variable - you read typed fields. See Config for how the dashboard groups and publishes this.

Next