gameplay-systemslisted

# Gameplay Systems ## Purpose Mechanics start simple and accumulate exceptions: a damage calculation that grows a special case per weapon, a character controller with fifteen booleans, a buff system where each new buff needs a new branch. The result is a system nobody can change safely, in the part of the codebase that changes most often. This skill covers the structures that absorb new content without new branches. ## When to use - Building combat, abilities, status effects, progression, crafting, or any rule-driven mechanic. - Adding the third variant of something that already has two hard-coded cases. - When a character or entity's behaviour is controlled by a growing set of boolean flags. - When designers need to add content without a programmer. ## When NOT to use - The mechanic is genuinely one-off and will not vary. A direct implementation is correct; do not build a framework for one case. - Structuring the codebase as a whole. Use `game-architecture`. - Specific subsystems with their own skills: `inventory-systems`, `quest-systems`, `dialogue-systems`, `save-systems`, `game-ai`. ## Required context | Fact | Why it matters | |---|---| | The rules, as the designer states them | Ambiguity here becomes bugs later | | What varies between instances | Decides what becomes data | | Whether it is networked | Authority and determinism constraints (`client-server-trust`) | | Who authors the content | Decides the data format and tooling | | Expected content volum