mirror of
https://github.com/github/awesome-copilot.git
synced 2026-04-30 20:25:55 +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>
121 lines
3.5 KiB
Markdown
121 lines
3.5 KiB
Markdown
# Maps, Heroes, And Feature Modules
|
|
|
|
Use this reference when building map systems, rotating arenas, class systems, kits, or modular gameplay features.
|
|
|
|
## Map patterns from real plugins
|
|
|
|
### Per-game map-instance usage
|
|
|
|
Observed traits:
|
|
|
|
- per-game map instances
|
|
- allowed map filtering through configuration
|
|
- gameplay objects tied to the active map instance
|
|
- match mode can constrain which maps are used
|
|
|
|
This works well for isolated match instances where each game owns its world and objectives.
|
|
|
|
### Persistent battlefield map rotation
|
|
|
|
Observed traits:
|
|
|
|
- one active combat world at a time
|
|
- source maps copied into temporary active worlds
|
|
- old worlds unloaded and deleted after rotation
|
|
- rotation warnings broadcast before swap
|
|
- spawn leaderboards refreshed after rotation
|
|
|
|
This works well for a persistent shared mode where the world rotates on a timer.
|
|
|
|
### Sky-island arena map usage
|
|
|
|
Observed traits:
|
|
|
|
- one game owns one copied map instance
|
|
- teams are assigned to configured island spawn locations
|
|
- chests are grouped by island, middle, or center role
|
|
- countdowns control cage removal, game start, refill timing, and game end
|
|
- visibility and chat are scoped to players in the same game instance
|
|
|
|
This works well for SkyWars-style modes where every match needs isolated islands, loot, spectators, and cleanup.
|
|
|
|
### Dungeon-node map usage
|
|
|
|
Observed traits:
|
|
|
|
- one game owns a lobby map plus temporary combat or event node maps
|
|
- route choices are generated from stage metadata
|
|
- players vote or confirm before advancing
|
|
- each combat node owns its wave queue and active mob set
|
|
- old node maps are unloaded only after players move to the new map or lobby
|
|
|
|
This works well for PvE roguelike, dungeon, wave, or boss progression plugins.
|
|
|
|
## Guidance for map architecture
|
|
|
|
- Per-instance minigame:
|
|
- use a `GameMap` owned by a game object
|
|
- Shared rotating battlefield:
|
|
- use a `MapManager` with one active world plus a rotation timer
|
|
- Temporary copied worlds:
|
|
- always teleport players out before unload
|
|
- clean folders after unload
|
|
- reapply gamerules after world creation
|
|
- Sky-island match:
|
|
- group spawn and chest locations by team or island role
|
|
- reset cages, inventories, scoreboards, and spectators per match
|
|
- Dungeon or route-node mode:
|
|
- treat every node as a temporary stage with explicit load, enter, clear, and unload steps
|
|
- keep mob ownership tied to the game, not just the world
|
|
|
|
## Class and hero system patterns
|
|
|
|
Observed class-system traits:
|
|
|
|
- `HeroRegistry`
|
|
- `HeroService`
|
|
- definitions grouped by theme
|
|
- hero tier progression
|
|
- hero skill config and handler
|
|
- selector GUI separated from assignment logic
|
|
|
|
Observed minigame power-selection parallels:
|
|
|
|
- brands and special items function like modular player powers
|
|
- selection limits and categories are explicit
|
|
- match rules can constrain available choices
|
|
|
|
Guidance:
|
|
|
|
- keep definitions separate from runtime assignment
|
|
- use registries for discoverable content
|
|
- store unlock rules and tiers in data, not hardcoded listener branches
|
|
- separate:
|
|
- what a class is
|
|
- how it is selected
|
|
- how it is applied
|
|
- how its active skills are triggered
|
|
|
|
## Feature module pattern
|
|
|
|
Good candidate modules for separate packages:
|
|
|
|
- map rotation
|
|
- hero or class system
|
|
- item powers
|
|
- boss systems
|
|
- match rules
|
|
- shops and GUIs
|
|
- scoreboards
|
|
- progression
|
|
|
|
Do not merge all these into one listener or one “game utils” class.
|
|
|
|
## Practical heuristic
|
|
|
|
If a feature has all three of these, it deserves its own module:
|
|
|
|
- custom data model
|
|
- config or definitions
|
|
- one or more listeners, commands, or scheduled tasks
|