Online worlds and participation
Online mechanics connect individual contributions to shared state, participation timing and explicit commitments between players. Each overview separates player actions, state changes and alternative rules. Examples are hypothetical design scenarios, not claims about a named game. A prototype check states an observable question for the next iteration. Existing detailed references remain separately linked from the direction map.
No matches
Change your query or reset the filters.
Mechanics and variants
1Persistent worlds and shared server progressOverview and example ↗Persistent worlds preserve changes between sessions, making individual actions part of shared server state and history.4
Mechanic variants
- Shared projects accumulate contributions across sessions.
- World recovery limits irreversible depletion.
- Permissions define who can alter an object.
- Logs identify causes of important changes.
Design example. Players build a bridge in stages and a later participant sees the completed route. Prototype check: Test event redelivery after disconnection so one action changes a shared resource only once.
2Guilds, clans and long-term collective goalsOverview and example ↗Guilds connect participants through shared permissions, supplies and long-term projects across different participation schedules.4
Mechanic variants
- Roles grant limited management permissions.
- Storage separates personal and shared supplies.
- Projects show contributions needed by category.
- History makes reward allocation transparent.
Design example. One group gathers materials in the morning and another completes a shared construction that evening. Prototype check: Test member departure, leadership changes and access to prior contributions under the group's stated rules.
3Raids and multi-stage group coordinationOverview and example ↗Raids divide a large objective into phases with distinct responsibilities, connecting execution to recovering a shared plan after mistakes.4
Mechanic variants
- Phases change threats and priorities.
- Assignments establish specific responsibilities.
- Role handoffs cover a removed participant.
- Debriefs explain causes of shared failure.
Design example. Two participants pass a charge along a chain while others hold routes to a central device. Prototype check: Test distinctions between personal errors and network delay and recovering a role after a disconnect.
4PvP, duels, team battles and mass combatOverview and example ↗Competition distributes objectives and defeat conditions among players, with team formats shaping coordination and personal risk.4
Mechanic variants
- Duels isolate two sets of decisions.
- Team objectives value support beyond personal score.
- Large battles split into local tasks.
- Matchmaking uses the mode's stated parameters.
Design example. A team wins by linking objectives despite trailing in individual eliminations. Prototype check: Test counterplay availability and clear explanations of shared outcomes across different participant contributions.
5Battle royale and shrinking play areasOverview and example ↗Shrinking safe areas force movement and increase encounter density, connecting looting to predicting a future route.4
Mechanic variants
- Warnings reveal the next safe region.
- Out-of-zone damage limits delay time.
- Variable starts change available loot.
- Ally recovery creates an additional risk objective.
Design example. A squad abandons a rich depot because the route to the next zone crosses an occupied bridge. Prototype check: Test next-zone reachability from valid current positions and boundary visibility over different terrain.
6Asynchronous competition, ghosts and messagesOverview and example ↗Asynchronous participation preserves one player's result or message for another to encounter at a different time.4
Mechanic variants
- Ghosts replay a completed attempt's route.
- Messages provide limited location clues.
- Challenges publish reproducible conditions.
- Deferred turns support responses across sessions.
Design example. A player leaves a jump ghost so another can compare takeoff timing in a later session. Prototype check: Test rule-version compatibility and message constraints, including deleted or unavailable replays.
7Player markets, gifts and tradingOverview and example ↗Player exchange transfers resource ownership under agreed terms, connecting trust to transparency and atomic settlement.4
Mechanic variants
- Trade windows require confirmation from both parties.
- Gifts are distinct from expected reciprocal payment.
- Markets reserve goods until order completion.
- Trading limits preserve a reward's intended role.
Design example. Players confirm ore for a tool and changing either item clears both confirmations. Prototype check: Test simultaneous cancellation and disconnection so items and currency cannot duplicate or disappear between participants.
8Seasons, events and world changesOverview and example ↗Seasons change participation conditions for a stated period while events add shared goals and observable world changes.4
Mechanic variants
- Rulesets create new versions of familiar tasks.
- Shared objectives aggregate participant contributions.
- Season transitions state what progress survives.
- Event returns offer access to absent participants.
Design example. A flood season opens boat routes and player-built levees change the final map. Prototype check: Test late entry and period transitions with advance visibility of retained progress and reward availability.
9ARGs, transmedia and play beyond the applicationOverview and example ↗Play beyond an app connects fictional materials and different channels into a verifiable chain of challenges and reveals.4
Mechanic variants
- Documents contain clues to another material.
- Channels reveal different story fragments.
- Shared archives preserve participant discoveries.
- In-game substitutes support unavailable external steps.
Design example. A fictional site and audio recording provide code halves while an in-game archive preserves both. Prototype check: Test completion when an external resource disappears and clear fictional boundaries without requiring contact with uninvolved people.
10Battle passes, in-game stores and monetizationOverview and example ↗Monetization sets paid-content conditions, while stores and passes connect prices to known content and unlock sequences.4
Mechanic variants
- Direct purchases grant a described item.
- Passes unlock reward tracks under stated conditions.
- Subscriptions provide access for a stated period.
- Cosmetic bundles change appearance without hidden power.
Design example. A season pass shows contents and duration beforehand while earned items remain after the season ends. Prototype check: Test full-price clarity, duration, retained items and returning to play without a daily obligation.
Sources and examples
Sources support particular techniques or methodology, not every family variant. Design examples and mechanic combinations are illustrative.
- Steamworks: Multiplayer
Primary documentation of multiplayer-session infrastructure. Guild, market and season designs below are editorial alternatives, not Steam-mandated rules.
CC BY 4.0 · gamemechanics.pro contributors