You do not need to understand game servers before you begin. Pick the description that sounds like your game, copy one complete prompt, and let your AI coding tool work through the right tasks in order.
01Does the game end after a match?
02Should items still exist when the player returns tomorrow?
03How many players are together at one time?
04Copy one complete prompt and let the AI follow every stage.
Do not worry about technical names yet. The biggest question is simple: does each game end, or are you building a world that players return to over and over?
This is the lightest online setup. The two players connect, play one match, and leave.
Usually skip matchmaking, parties, public lobbies, server fleets, world areas, and MMO systems. Use the dedicated 1v1 prompt below.
A small group joins a match or co-op session and leaves when it ends.
Keep it match-based. Do not add MMO world systems just because more than two people are playing.
The game still ends after each round, but many players or objects are active at once. Think battle royale or a large battlefield.
A big match is not automatically an MMO. If the world resets after the match, keep the setup match-based.
Players come back later and expect their character, items, money, friends, and world changes to still be there.
MMOs are much harder. First prove that one player can log in, enter one area, save one change, and safely return.
| Simple question | 1v1 game | Small group | Large match | Online world (MMO) |
|---|---|---|---|---|
| Does the game end after each match? | Yes | Yes | Yes | No—the world keeps going |
| Do characters and items need to stay? | Usually no | Only basic progress, if wanted | Only basic progress, if wanted | Yes |
| Can one player host the game? | Usually | Often | Usually not | No |
| Do you need a separate computer to run the game? | Usually no | Optional | Usually | Yes |
| Do you need matchmaking? | Usually no | Maybe | Usually | Often |
| How should you start? | Connect two players | Connect one small group | Build a small match first | Build one small world area first |
The text inside the prompt is technical on purpose. You do not need to understand every word. Paste it into your AI coding tool and let it inspect your project before it changes anything.
Let the AI look at your game and decide whether it needs a small match, a large match, or an MMO setup.
Anyone adding online play for the first time. Start here if you are unsure.
# Classify this multiplayer game before designing its backend
Act as a principal multiplayer game architect. Read the game design, repository, tests, and deployment setup. Do not implement yet.
## Inputs to establish
- Engine and client platforms
- Competitive, cooperative, social, or mixed play
- Players per match, room, zone, and region
- Whether sessions end and what state survives them
- Whether direct P2P, deterministic lockstep or rollback, a listen host, or dedicated servers fit the trust and scale requirements
- Tick rate, latency tolerance, movement speed, projectile speed, and physics needs
- Party, lobby, matchmaking, server browser, voice, chat, spectator, replay, and reconnect needs
- Character, inventory, economy, guild, quest, housing, world-state, and trading persistence
- Expected concurrency now, at launch, and at a realistic growth milestone
## Required decision
Classify the game as one of these, while noting any hybrid needs:
1. Session/PvP multiplayer: bounded matches or rooms that end.
2. Large-session multiplayer: bounded sessions with higher player counts or more aggressive interest management.
3. MMO/persistent world: durable identity and world systems across realms, shards, zones, and instances.
Produce a requirements table with Required now, Later, and Not justified columns. Include authority, direct P2P or listen-host feasibility, signaling, NAT traversal, relay fallback, host selection and migration, transport, prediction, reconciliation, interpolation, rollback or lockstep, lag compensation, lobby and party flow, matchmaking, server allocation, persistence, realms, zones, instances, interest management, economy safety, moderation, observability, load testing, disaster recovery, and estimated operational complexity.
Recommend the smallest architecture that satisfies the evidence. Explicitly list MMO systems that must not be added to a PvP-only game.
## Delivery rules
- Inspect the repository, current documentation, deployment configuration, tests, and existing networking code before proposing changes.
- Preserve working systems and explain every material tradeoff. Do not replace the engine, transport, database, cloud, or identity provider without evidence.
- Choose and document the authority model. A dedicated server or listen host validates client intent; deterministic lockstep or rollback peers exchange inputs, detect desync, and accept the stated peer-trust limits.
- Prefer provider-neutral interfaces around identity, sessions, persistence, realtime transport, matchmaking, hosting, and observability.
- Separate the smallest safe first milestone from later scale work. Do not design MMO infrastructure for a bounded PvP match.
- Add or update architecture documentation, sequence diagrams, failure behavior, security assumptions, tests, metrics, and rollback steps.
- End with changed files, commands run, measured evidence, unresolved risks, and a definition-of-done checklist.You do not have to use Glitch. If you choose it, Glitch can provide useful online building blocks. Your game still needs its own rules and some connecting code.
This page only covers online play. The general guide helps with the rest of the game.