Engine development: working sequence
When engine source is needed, how to verify a change and what to deliver.
Engine development
Start with a reproducible problem: which actions produce the wrong result, what was expected and which binary exhibits it. Change engine source when project code, configuration or an extension cannot solve the problem.
Choose the change level
| Task | Where to work |
|---|---|
| Game logic, interface and resources | Project C# and settings. No engine rebuild needed. |
| Tool or integration using an available API | Choosing an extension API. |
| New native functionality in a separate library | Native extensions. |
| Core, renderer or built-in editor change | Separate source working copy and custom build. |
Following documentation does not itself require editing the core. Keep project changes, documentation corrections and engine changes distinguishable rather than combining them into an unexplained file set.
Working sequence
- Preserve reproduction on the original binary. Record version 1.0.0 and the specific build identity: the version alone cannot distinguish local binaries.
- Prepare a separate working copy and inspect existing changes. Do not clean up other people's files or replace the installed Runtime with an experimental build.
- Choose target, architecture, precision and modules using the build guide. See the separate Windows guide and managed build stages for C#.
- Make the smallest change that addresses the cause. Separate API renaming from behavior changes.
- Add a regression check: engine C++ tests exercise internal logic; a sample project exercises the public API.
- Repeat the original reproduction using the new binary. For a format change, save and reload data; for public APIs, check the consumed SDK and extensions; for export, run the exported game.
- Update RU/EN instructions when an action, name, limit or result changes.
What the result proves
Compilation proves the selected configuration builds. It does not prove freedom from regressions, frame quality or export functionality. A clean headless test also does not prove real GPU behavior.
Report changed files, the reason, build configuration, checks actually executed, known limits and the location of the separate test binary. If launch was refused or a filter selected no tests, retain that outcome as refusal or incomplete coverage. Do not call it successful testing.
When only documentation text needs changing, source review and a reproducible example are sufficient without installing a new build over the working engine.