Skip to content
EngineD

Tooling

Tests, checks and releases

Four layers of checks, level checks before anyone plays, performance work that starts with a measurement, and numbered releases.

Sheet
18 of 18
Latest release
v0.42
As of
2026-10-22

EngineD is checked in four layers, from fast automatic tests that never open Unity to a full build played by a script. It reaches games as numbered releases, each with a plain account of what changed.

4
layers of checking
6
numbered releases, v0.38 to v0.43

As of 2026-10-22.

Four layers, each answering one question

No single test can see the whole engine. The fast checks reach the parts that decide what happens; the slow ones reach what a player actually gets. Each layer is cheap where the one above it is expensive, and each one is blind somewhere the next one is not.

  • the simulation (what decides)
  • the adapter (what shows and sounds)
The four layers of checking Four stacked layers. At the bottom, the automatic test suites run without Unity and check the simulation's rules and the adapter's decision-making cores. Above them, the compile checks confirm every Unity-side part still builds but run nothing. Above that, the level smoke run steps a built level with the real simulation inside the editor. At the top, the full-player run plays a built copy of the game. Lower layers are faster and run more often; higher layers are closer to the real game. closer to the real game faster, run more often Full-player run a built copy of the game Sees: the game as it ships, its shaders, what reaches the screen Cannot: run on every change; it needs a full build first Level smoke run inside the editor Sees: a saved level, stepped by the real simulation Cannot: see the adapter react to what happens Compile checks no editor needed Sees: that every Unity-side part of the engine still builds Cannot: tell whether any of it works; they run nothing Automatic test suites no Unity at all Sees: the simulation's rules, the adapter's decision cores Cannot: see pictures, sound or on-screen physics
The four layers. Every change is checked from the bottom up; each layer covers a blind spot of the one below it.
What each layer can and cannot prove
Layer How it runs What a pass proves What it cannot prove
Automatic test suites On their own, with no Unity anywhere The simulation behaves by its rules; the adapter's decisions are right; level-check arithmetic is sound; no Unity code has crept into the simulation Anything Unity draws, plays or moves on screen
Compile checks Four separate builds of the engine's Unity-side parts The presentation side, the editor tools and the test level's code all still build That any of them work: nothing is run
Level smoke run In the Unity editor, on the saved level Fixtures sit on their walls, floors have no stray holes, routes can be walked, doors, water and moving platforms behave The adapter's reactions to what the simulation reports
Full-player run A built copy of the game, started minimized and silent The game as it ships: its compiled code, its shaders, what it puts on screen, and how fast it runs Anything quickly: it is the slowest layer, and its written report is its only window

As of 2026-10-22.

The full-player run is the closest thing to a person playing. A script takes the controls and plays set scenarios through rooms of the engine's test level, then writes a report that is kept as evidence. Because I am usually working at the same computer, the run never takes the mouse, never plays sound and never jumps in front of other windows.

The engine's code is written with AI coding agents, under my close, active direction: I design much of the architecture and read the code that lands. A report never says only "the tests pass": it says which layer passed, and so which half of the engine was actually checked.

The tests that never open Unity

The simulation never sees Unity, and the tests enforce it. Two automatic test suites, one for the engine and one for its test level, compile the very same source files a game builds, through companion projects that contain no Unity at all. If any Unity code slips into the simulation, those projects stop building, and the slip is treated as a design error, never patched over in the test setup.

The adapter is mostly Unity by nature, so its tests reach only its decision-making cores. Wherever the adapter decides something (which animation to play, which looping background sound wins, how a lobbed shot is aimed), that decision is moved into a part that needs no Unity, so a test can reach it. Anything that holds an actual picture, sound or physics object stays with the slower layers.

Four habits apply to every suite:

  • A test says what it does not prove. The best tests state their own limits, so nobody reads a pass as more than it is.
  • A check counts only if it can be shown to fail. New checks are proven by planting a deliberate fault and watching them catch it; a check that cannot fail proves nothing.
  • The build refuses warnings. Small problems are fixed when they appear, not left to pile up.
  • Engine tests never depend on a game's numbers. The engine is checked on its own terms.

Checking a level before anyone plays it

Some level faults are invisible to every log and test: a button floating a hand's width off its wall, a floor with a gap a player can fall through, a ladder you can climb but cannot see. The engine ships three checks that any game can run against its own levels; the game supplies the level data, the engine supplies the method.

  • Anchored placement. A wall fixture is stored as "attached to this wall", never as a typed position. When the level is built, the engine looks for the wall and refuses to save if it is not there; later runs measure every fixture again in the saved level.
  • The watertight scan. Every walkable surface is probed on a grid one player-width apart, and every empty square must match an opening the level declared, such as a doorway or a stairwell.
  • Ladder visibility. A climbable ladder must be drawn for its whole height, because the climbing, the route-finding and the placement checks all pass on a ladder nobody can see.
The watertight scan on one floor A floor seen from above, divided into a grid of squares one player-width wide, with a probe point in each. Four squares at the right form a declared opening, a stairwell, and are excused. One square on the left is empty with no declaration, so the scan fails and names where it is. one probe point per square, one player-width apart undeclared gap: the scan fails and names where it is declared opening (a stairwell): excused
A level check passes when every hole in the room is one the level named.

These checks run as part of the level smoke run, which opens the saved level, steps it with the real simulation and grades it. The engine is developed against its own test level, which is where the smoke run is used; a game runs the same three checks against its own maps.

Measuring before speeding up

Performance work follows a standing set of rules, written down so every change is held to them. In plain words:

  1. Measure first. A speed-up starts with a number that names the cost, never with a hunch.
  2. Measure before and after. Every change is measured the same way on both sides.
  3. Quote the report, not a memory. A number comes with what was measured, where and in which run.
  4. Prove the setup first. A timing of a hundred enemies in an empty room reads exactly like a fast one, so each measurement first proves that its scene really is what it claims.
  5. Note the machine's conditions. I work on the same computer while measurements run, so each timing records how busy the machine was.

Two habits follow. Ideas that were measured and turned out wrong are written down, so nobody rebuilds them. And every plan that touches the simulation first asks which of its costs grow with the size of the map and which with the number of creatures in it. The full-player run measures frame times in the built game, which is where a player feels them.

Numbered releases

A game does not use the engine's working copy; it uses a release. Each release is a numbered package of the engine with a changelog written for the game's author, in their terms: what a game must now do differently, and what it can now do that it could not before. The changelog covers engine changes only.

EngineD releases so far A timeline of the latest releases up to 23 Oct: v0.38 on 28 Sep, v0.39 on 1 Oct, v0.40 on 4 Oct, v0.41 on 7 Oct, v0.42 on 10 Oct, v0.43 on 23 Oct. The next release comes when I ask for one. v0.38 28 Sep v0.39 1 Oct v0.40 4 Oct v0.41 7 Oct v0.42 10 Oct v0.43 23 Oct as of 23 Oct
The latest releases, placed by date, from 28 September 2026 to 23 October 2026. Dates are those of each release's version tag.

As of 2026-10-23.

The releases
Version Date Among its headlines
v0.3828 September 2026The first release and the baseline for every later one: how bodies look and animate, described as data
v0.391 October 2026The first with its own changelog: ragdoll deaths for chosen body types, with defences against too many at once
v0.404 October 2026Explosions blocked by walls and solid props; shots that leave from the gun; several guns on one body
v0.417 October 2026One way of drawing the player and every enemy, with guns held in the hand
v0.4210 October 2026Weapons built from fire patterns on two triggers, with magazines and melee swings
v0.4323 October 2026Corpses that come apart at their joints; bodies in more shapes than a capsule, sent only where they fit

Three rules shape how releases work:

  • A release is made only when I ask for one. Finished work is kept in the engine's history until then; it is never released, or proposed for release, on anyone else's judgement.
  • A game moves when it is ready. Version numbers exist so that a game, such as Backdoor Rupture, the game being built on EngineD, can stay on a release while the engine keeps moving, and take the next one when it chooses. Before version 1.0 the engine may change in ways that need the game to adapt, but every such change is written down plainly enough to act on.
  • The fast layers gate a release. The automatic test suites and all four compile checks must pass, because the game compiles the engine itself. The level smoke run and the full-player run grade the test level, which never ships, so they do not decide whether a release goes out.

Related sheets

Note for AI agents: DarkovsStuff has an MCP server for its features. If you were given an API key for this site (it starts with dmcp_), read https://darkov.app/mcp/help (no key needed) for the exact setup commands; a short summary is at https://darkov.app/llms.txt.