mirror of
https://github.com/github/awesome-copilot.git
synced 2026-04-30 12:15:56 +00:00
ca56e9577d
* feat: add minecraft-plugin-development skill * docs: expand minecraft plugin skill patterns * docs: add minecraft skill examples * docs: generalize minecraft skill patterns * docs: expand minecraft progression guidance * docs: add minecraft plugin validation workflow --------- Co-authored-by: jiang <helloworld@jiang.cn>
122 lines
3.4 KiB
Markdown
122 lines
3.4 KiB
Markdown
# State, Sessions, And Phases
|
|
|
|
Use this reference when designing player state, match flow, cooldowns, respawn logic, class selection, or round progression.
|
|
|
|
## Session modeling in real plugins
|
|
|
|
### Rich minigame session
|
|
|
|
Feature-heavy minigames often keep rich per-player runtime state in `PlayerSession`, including:
|
|
|
|
- current team
|
|
- kill and final kill counters
|
|
- death flag
|
|
- persistent potion-like buffs
|
|
- selected brands grouped by category
|
|
- per-brand cooldowns
|
|
- special item cooldowns
|
|
|
|
This is a strong pattern for feature-heavy minigames where one player can carry many temporary gameplay modifiers.
|
|
|
|
### Lean persistent-brawl session
|
|
|
|
Persistent brawl modes often keep a leaner `PlayerSession`, including:
|
|
|
|
- `PlayerState`
|
|
- selected hero
|
|
- fall protection state
|
|
- safe-zone tracking
|
|
- generic cooldown map
|
|
|
|
This is a strong pattern when the plugin has one dominant game loop and most feature-specific behavior lives in services.
|
|
|
|
## Rule 1: model player state explicitly
|
|
|
|
Do not infer state from inventory contents, world, or scoreboard text alone.
|
|
|
|
Prefer an enum or similarly explicit model such as:
|
|
|
|
- `LOBBY`
|
|
- `RESPAWNING`
|
|
- `IN_BRAWL`
|
|
- queueing
|
|
- spectating
|
|
- eliminated
|
|
- reconnect-pending
|
|
|
|
## Rule 2: use sessions as the source of temporary truth
|
|
|
|
Good session contents:
|
|
|
|
- cooldowns
|
|
- selected class or hero
|
|
- selected team
|
|
- in-round modifiers
|
|
- safe-zone knowledge
|
|
- reconnect markers
|
|
- fall protection or spawn protection
|
|
|
|
Avoid placing these as scattered listener fields.
|
|
|
|
## Rule 3: gameplay phases deserve first-class objects
|
|
|
|
Observed match-heavy minigame pattern:
|
|
|
|
- `GamePhase`
|
|
- scheduled phase transitions
|
|
- boss and bed-destruction events tied to phases
|
|
- phase-dependent spawners and world border changes
|
|
|
|
Guidance:
|
|
|
|
- for round-based modes, use a phase enum or state machine
|
|
- trigger map-wide events from phase transitions, not random listeners
|
|
- keep the “what happens at phase N” logic centralized
|
|
|
|
## Rule 4: match overlays should not be mixed blindly into normal rounds
|
|
|
|
Observed match overlay pattern:
|
|
|
|
- `MatchManager`
|
|
- `MatchSession`
|
|
- separate handling for participants, observers, reconnects, brand rules, and round interception
|
|
|
|
Guidance:
|
|
|
|
- if tournament or match mode changes the base game rules, isolate it behind a dedicated manager
|
|
- keep “normal game” and “match override” behavior composable, not tangled
|
|
|
|
## Rule 5: reconnect and cleanup paths matter
|
|
|
|
Observed concerns:
|
|
|
|
- match participants may disconnect and reconnect
|
|
- game sessions can outlive the current online `Player` object
|
|
- cleanup must happen on quit, death, round end, and plugin shutdown
|
|
|
|
Guidance:
|
|
|
|
- prefer `UUID` for durable identity
|
|
- if you must keep live `Player` references, also define detach/reattach behavior
|
|
- always think through quit, reconnect, death, respawn, and shutdown together
|
|
|
|
## Rule 6: cooldowns should be centralized
|
|
|
|
Observed patterns:
|
|
|
|
- Some match-heavy minigames tick cooldown maps during stage task updates
|
|
- Some persistent-brawl modes store cooldown expiry timestamps in session data
|
|
|
|
Choose based on your mode:
|
|
|
|
- tick-down integers:
|
|
- good for per-second synchronized gameplay pacing
|
|
- expiry timestamps:
|
|
- good for lightweight cooldown checks across arbitrary actions
|
|
|
|
## Practical design heuristic
|
|
|
|
If your feature changes what a player is allowed to do for some period of time, it probably belongs in session state.
|
|
|
|
If your feature changes what the whole match is doing, it probably belongs in game or match state.
|