---
name: gameplay-programming
description: Use when implementing or changing gameplay features: player control, abilities, AI behaviour, items, rules and game state. Favours data-driven design, small testable systems and fast iteration.
---

# Gameplay programming

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Implement mechanics so designers can tune them, engineers can trust them and the game feels right.

## Before you start

- Read the design brief and agree the parts likely to change. Those belong in data, not code.
- Read the existing systems before adding new ones. Extend patterns already in use.

## Process

1. Get a rough version playable fast, then refine. Feel is found in the build, not in documents.
2. Move tunable values into data files or resources that designers can edit without a code change.
3. Keep systems small with clear inputs and outputs. Avoid hidden coupling through globals or singletons.
4. Make state explicit: what can happen in each state, and what causes transitions.
5. Handle timing deliberately: fixed versus variable update, input buffering and frame-rate independence.
6. Add debug views and cheats for the feature, so it can be tested quickly.
7. Write tests for rules and edge cases that can be tested outside the engine loop.

## Quality bar

- Designers can tune the feature without engineering help.
- The feature behaves the same at different frame rates.
- Edge cases (death mid-action, disconnects, pausing, saving) are handled.

## Output

Feature code, data definitions, debug tools, tests and a short note on how to tune it.

## Avoid

- Magic numbers in code.
- Building a general framework before the second use case exists.