A party is a play session: an app, a host, a roster, and — once one is found — a server to play on.
Joining and visibility
The four visibility types, who can walk in, and what the roster shows.
Lifecycle
Lobby, searching, ready-up, playing, ended — and what ends a party.
Tech levels
Why some parties show scores as fact and others show them as a guess.
Matchmaking
The filters a host sets, and how a server is chosen.
Integrating a game
What a mod or plugin reports, and what it earns by doing so.
Not a content item
Parties are deliberately not part of the content-item family. They are ephemeral, have no owner-editable long-form body, take no ratings or reviews, and are not part of the granular permission system — so they carry their own small counters instead of writing rows into the shared view, favourite and rating tables.
A party that lasted eleven minutes should not leave permanent rows in five shared tables.
They are also created at play-session rate rather than content-creation rate: a busy game can produce more parties in a month than the site has ever had mods.
Availability
An app decides whether parties exist for it at all, and the maximum party size. Not every game has them.
The one thing to know up front
How much of a party’s state is fact versus inference depends entirely on how deeply the game is wired into us. For a game with no integration, the roster on the actual server is inferred by matching display names against the query server’s player list — and the site flags it as a guess everywhere it shows it.
That is tech levels, and it is the concept the rest of this section rests on.