Game Flow & GUIs

MiniModes gives you a consistent, guided flow from

party → teams → settings → game → results

This page explains that flow and the shared GUIs you plug into when building or configuring games.

It’s written for:

• Server owners who want to understand how games feel from a UX perspective.
• Extension developers who want to hook into MiniModes’ flows instead of reinventing them.

---

High-level game lifecycle

At a conceptual level, every MiniModes game follows the same shape:

1. Party forms (or the player’s automatic solo party is used).
2. Leader picks a game from the /minimodes GUI.
3. MiniModes validates the request (party size, leader, existing games).
4. Optional pre-game steps:
   • Team selection GUI
   • Settings voting GUI
5. Game instance starts in a managed world.
6. Players play, optionally adjusting runtime settings.
7. Game ends with winners/summary.
8. Rematch or Mashup can kick off the next round.

Each stage uses shared components from the core plugin so:

• Players see familiar patterns across totally different games.
• Extension authors can focus on game logic, not UX plumbing.

---

1. Party system: the foundation of game flow

MiniModes assumes everyone is always in a party:

• If you’re not in one, the plugin transparently creates a solo party.
• A party has:
  • A unique ID
  • A leader
  • A set of members (leader + invited players)

Key commands (simplified):

• \/party create“ — starts a new party (usually implicit).
• \/party invite <player>“ — invite others.
• \/party accept <player>“ — accept an invite.
• \/party leave“ — leave the party.
• \/party kick <player>“ — leader removes someone.
• \/party list“ — shows members.
• \/party rematch“ — replay the last game setup.
• \/party mashup <start/stop>“ — start/stop endless random games.

Why parties matter for game flow

Every game flow in MiniModes is described as:

“Run this game for this party using these settings.”

That means:

• Membership drives eligibility (e.g. 2–4 players required).
• Leader drives control (start games, change settings, launch Mashup).
• Leaving/disbanding a party triggers clean-up (rematches, mashup sessions, GUIs).

This is the backbone of everything that comes after.

---

2. Game selection GUI (/minimodes & /mm)

The game flow starts from the Game Selection GUI:

• Opened via:
  • \/minimodes“
  • \/mm“
• Shown title: typically “MiniModes — Select a Game”.
• Content: all games discovered from loaded extensions.

Each game appears as an item with:

• Name and short description
• Min/max players
• Status / requirements for your current party, e.g.:
  • ✅ Ready to start
  • ❌ Too many players (needs 2–4)
  • ❌ Only the party leader can start this game

When the leader clicks a game:

1. MiniModes checks:
   • Is this player the party leader?
   • Is party size within [min, max] for that game?
   • Is anyone in the party already in a game?
2. If checks fail, the GUI shows feedback and doesn’t start the game.
3. If checks pass, MiniModes progresses into the pre-game flow.

As a game developer

Your extension:

• Registers metadata (name, description, icon, min/max players, Mashup compatibility).
• Does not need to implement its own selection menu.
• Can trust that by the time your game is started:
  • You have a valid party.
  • Player count fits your constraints.
  • No one is already bound to a conflicting game.

---

3. Pre-game: teams → settings → start

Many games need a lobby-like phase before they truly start:

• How should the party be split into teams?
• Which map or layout should we use?
• How long should the game last?
• Should special rules be enabled?

MiniModes standardizes this with two shared GUIs:

• Team Selection GUI
• Settings Voting GUI

Not every game needs both. A 1v1 duel might skip team selection entirely.

Pre-game ordering

A typical flow:

1. Party + game chosen.
2. ✔️ Team Selection GUI (if the game is team-based and requires it).
3. ✔️ Settings Voting GUI (if the game declares pre-game settings).
4. ✔️ Game engine instantiates the match with resolved teams + settings.

From the developer’s perspective:

• You declare what your game supports (teams? configurable settings? voting?).
• MiniModes decides which GUIs to show and in which order.
• Your game receives a finalized configuration object to start from.

---

4. Team Selection GUI

The Team Selection GUI is used when a game involves teams and wants a pre-game decision about how to form them.

Typical capabilities:

• Split the party into two or more teams.
• Show available team slots (e.g. Blue, Red, Spectators).
• Provide fast modes like:
  • Shuffle evenly
  • Keep friends together
  • Manual assignment

Player experience

1. When a team-based game is selected:
   • MiniModes opens the Team Selection GUI for all affected players.
2. Everyone can see:
   • Which player is currently on which team.
   • Any countdowns or prompts (titles/messages).
3. Typically, only the leader or designated controllers can:
   • Change teams for others.
   • Lock in the configuration.
4. When the decision is finalized:
   • Teams are stored.
   • The game moves forward (often into Settings Voting next).

Extension developer perspective

You provide:

• Supported team structure:
  • Number of teams, colors/names, capacities.
• Rules:
  • Whether players can change their own team.
  • Whether the game requests auto-balance before start.

MiniModes:

• Handles all the GUI logic (inventory slots, updates, countdowns).
• Passes your game a resolved team allocation.

---

5. Settings Voting GUI

Some games allow players to vote on settings before the match:

• Map selection (Desert, Forest, Random).
• Round duration (Short, Standard, Long).
• Extra rules (e.g. “Double Jump: On/Off”).

The Settings Voting GUI provides a synchronized, shared inventory UI that the entire party sees.

Key properties

• Real-time: votes update the GUI for all viewers.
• Shared view: every party member sees the same menu, with current leading options.
• Game-driven: each game extension defines:
  • Which settings are votable.
  • What options each setting has.
  • How to resolve ties (majority, random among top, fallback default).

Player experience

1. After team selection (if any), MiniModes opens the Settings Voting GUI.
2. Every party member can:
   • Click on setting items to vote for options.
   • See visually which option is leading.
3. The GUI keeps a countdown or similar progress indicator.
4. When voting closes:
   • The winning options are locked in.
   • MiniModes builds a finalized settings object for the game.
5. The actual match starts using those settings.

Extension developer perspective

You define:

• A set of settings descriptors, for example:
  • map: [Desert, Forest, Random], default Random.
  • roundTime: [{label: "5 min", value: 5}, ...], default Standard.
• How a chosen option maps into your game’s configuration.

MiniModes:

• Renders those settings into a voting GUI.
• Tracks per-player votes and resolves them.
• Passes you a resolved configuration when starting the game.

---

6. Runtime Settings GUI

Some games support changing certain options while the game is running. This is handled by the Runtime Settings GUI.

Typical command entry points:

• \/mm game settings“ — open the in-game settings interface.
• Optionally via items or triggers within your game.

Rules and behavior

• Everyone can view, but only the game/party leader can change values.
• Only settings explicitly marked as runtime mutable in the game extension:
  • Appear as interactive controls.
  • Can be toggled mid-match.
• Others are displayed as read-only state.

UX specifics

• Supports pagination when many settings exist.
• Common interactions:
  • Left/right click to cycle through options.
  • Shift-click to reset to default (if supported).
• When a value changes:
  • The GUI refreshes for all viewers.
  • The game receives updated configuration or callbacks.

When to use runtime settings

As a game author, consider runtime settings for:

• Quality-of-life toggles (e.g. scoreboard visibility).
• Dynamic rules that are safe to change mid-match.
• Debugging / admin overrides in dev builds.

Avoid runtime mutability for:

• Core balancing parameters (health, damage) that can break fairness mid-round.
• World generation options that cannot be safely applied on the fly.

---

7. Game commands & leaving/spectating

While the GUI drives most of the flow, players still interact via commands once the game is live:

• \/mm game leave“
  Leave your current game and return to the appropriate safe location.

• \/mm game spectate <player>“
  Jump to another player’s current game instance as a spectator.

• \/mm game stop“ (leader only)
  Ends the current game gracefully using the engine’s shutdown flow.

• \/mm game win <players>“ (leader only)
  Explicitly mark specific players as winners and finish the round.

These commands plug into the same GameManager and lifecycle that the GUIs drive.

---

8. Mashup mode flow

Mashup mode turns MiniModes into a continuous playlist for a party:

• Started by the party leader with:
  • \/party mashup start“
• Stopped with:
  • \/party mashup stop“

When Mashup mode is active:

1. MiniModes looks at:
   • All loaded game extensions.
   • Those marked as Mashup-compatible.
   • Those that support the party size.
2. It picks a game at random (avoiding repeats where possible).
3. If the game supports settings:
   • Settings are usually randomized automatically, without a voting GUI.
4. It starts a new round when:
   • Your party has online members, and
   • Nobody is currently in a game.
5. At each new round:
   • Players may get fall-damage protection or similar safety measures while spawning.

From the UX perspective:

• Mashup mode skips some of the manual selection UIs (like Settings Voting), to keep the flow snappy.
• The /minimodes GUI is still available if players want to exit the autopilot and choose specific games again.

---

9. Putting it together (examples)

Example A: Simple duel game

• Teams: 1 vs 1, no team selection GUI needed.
• Settings: Map and kit selection via pre-game voting.
• Runtime settings: None.

Flow:

1. Leader picks “Duel” from /minimodes.
2. MiniModes validates 2-player party.
3. Skips team selection (teams are implicit).
4. Opens Settings Voting for map and kit.
5. Starts duel with resolved settings.
6. Players can \/mm game leave`or`/mm game spectate“ others once done.

Example B: Team-based, configurable mini-game

• Teams: 2 or more, requires team selection.
• Settings: Map pool, round duration, special rules.
• Runtime settings: Allow toggling scoreboard visibility mid-game.

Flow:

1. Leader chooses “Team Arena” from /minimodes.
2. MiniModes confirms party size (e.g. 4–12 players).
3. Opens Team Selection GUI:
   • Leader assigns teammates.
   • GUI shows countdown; leader locks teams.
4. Opens Settings Voting GUI:
   • Party picks map and round length.
5. Game starts in a managed world.
6. During play, leader opens Runtime Settings GUI via \/mm game settings“:
   • Toggles scoreboard visibility; changes are broadcast to all.
7. Game ends; party uses \/party rematch“ to replay with the same teams/settings.

---

10. How to design your game around the flow

When planning a new MiniModes extension, think in terms of hooks into these flows:

1. Before game start

   • Do you need teams?
     → Use the Team Selection phase.
   • Do you have configurable options?
     → Expose them to the Settings Voting GUI.

2. During the game

   • Are there safe, non-breaking toggles?
     → Mark them as runtime mutable for the Runtime Settings GUI.
   • Do you need quick admin or debug controls?
     → Consider adding extra settings that are only visible with certain permissions.

3. After the game

   • Do you produce results that Rematch can reuse?
     • Party composition
     • Teams
     • Settings
   • Ensure your end-of-game logic updates the engine so \/party rematch“ works smoothly.

By aligning your design with MiniModes’ standard game flow and GUIs, you:

• Give players a familiar, polished experience across every game.
• Offload a lot of repeated UX and state management.
• Keep your own code focused on the fun and unique parts of your game.

---

Where to go next

Create an Extension

Learn how to declare game metadata, settings, and team structures so MiniModes can wire your game into these flows.

Commands & Reference

See the full list of player and admin commands that interact with games, parties, and GUIs.

Mashup & Rematches

Dive deeper into how MiniModes automatically chains games together for your parties.