---
name: engine-programming
description: Use when modifying a game engine or its core systems, including maintaining an engine fork: rendering, memory, threading, scripting, editor integration and upstream merges. Prioritises stability, measurement and maintainability.
---

# Engine programming

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

## Goal

Improve the engine without destabilising the games built on it, and keep the fork maintainable.

## Before you start

- Understand the subsystem you are changing, its callers and its tests.
- For a fork, know where it diverges from upstream and why. Check whether upstream already solves the problem.

## Process

1. Write down the problem with evidence: a profile, a crash, a workflow cost or a missing capability.
2. Choose the least invasive change. Prefer extension points, modules or plugins over editing core files.
3. Keep fork changes isolated and labelled, so upstream merges stay manageable.
4. Measure before and after on target hardware: frame time, memory, load time and build time.
5. Add tests or reproducible benchmark scenes for the change.
6. Document the change for engine users: what changed, how to use it, and migration steps.
7. Merge upstream regularly. Small, frequent merges cost less than rare, large ones.

## Quality bar

- No regressions in existing projects or test scenes.
- Every divergence from upstream has a recorded reason.
- Performance claims are backed by measurements.

## Output

The engine change, tests or benchmark scenes, measurements, documentation and a divergence log entry.

## Avoid

- Large rewrites without a measured problem.
- Letting the fork drift so far that upstream fixes cannot be merged.