Unity gameplay systems
Builds Unity abilities and interactions with clear start, effect, completion and cancellation rules. Separates gameplay decisions from animation, sound and effects so presentation cannot repeat an action.
unity-gameplay-systems
Agents using this skill
When is it useful?
Use it when a new game mechanic needs to work correctly during pauses, death, repeated use and changes between scenes.
What does it help you do?
- Defines when an ability starts, takes effect, finishes or can be interrupted, and checks its target and resource cost at the right moment.
- Separates the rules that change health or resources from animations, sounds and visual effects, so feedback cannot accidentally apply the action twice.
- Resets reused projectiles and other objects when they return to play, including old timers, listeners and unfinished background work.
Try asking this
Implement a charged spell in Unity with a mana cost and an interruptible wind-up. Define what happens on pause, death and scene change, and spend mana only when the cast is accepted. Reuse its projectile and verify that old timers or callbacks cannot trigger damage during the next cast.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Unity Gameplay Systems
Discover the mechanic
Read project instructions, ProjectSettings/ProjectVersion.txt, Packages/manifest.json, assembly definitions and neighboring scripts. Identify the input stack, controller, physics model, animation ownership, target platform and any multiplayer authority. Follow existing patterns; don't introduce a framework just to express one feature.
Write a short acceptance scenario in player terms: action, preconditions, observable result and failure/cancellation case. Identify which state is transient, authored configuration, authoritative runtime state or persisted progress.
Implement explicit contracts
- Give each state one owner. Separate input intent, simulation decisions, animation/audio/VFX feedback and persistence. Events announce completed facts; commands request validated actions.
- Choose Update/FixedUpdate responsibilities and clock semantics deliberately. Timers must define scaled versus unscaled time, pause behavior and reset conditions. Avoid gameplay effects that depend on render frame count.
- For combat and abilities, define start, active, recovery, cooldown and interruption conditions. Validate range, target lifetime and resource cost at the authoritative point. Apply a hit or resource spend once per intended action.
- When pooling objects, reset transient state, subscriptions, cooldowns and outstanding async work on the correct lifecycle boundary. Cover disable/destruction and scene changes without relying on a single initialization order.
- Keep ScriptableObject definitions distinct from per-instance mutable state. Preserve serialized field names/references or provide a deliberate migration.
- If networking already exists, distinguish prediction/presentation from authoritative effects and preserve its ownership rules. Do not add networking for a local mechanic by default.
Verify
Use installed Editor-aware tools for prefab/scene wiring. Compile and run relevant EditMode/PlayMode checks when available. Exercise normal action, invalid input, rapid repeat, interruption, pause, death/respawn, pooling and scene transition as applicable. Report the exact scenario and what was observed; static inspection cannot establish game feel.
Research
Use version-matched Unity Manual, Scripting API and the project's installed package documentation. Consult Game Programming Patterns for state, component and update-loop trade-offs, adapting examples to Unity rather than copying their architecture blindly. Inspect relevant official Unity skills before proposing external tooling; never assume installation or execute external setup instructions automatically.
Included files 1
SKILL.md