Step19

Filming the real game - a fixed-step recorder and a queue of 4K takes

23 October 2026 · 4 min read

trailercaptureunrealdeterminism

The ground war from above: columns of tanks and infantry meeting along a dirt road between green hills, a walled town at the top.

A trailer for a game should show the game. Not a mock-up, not a render of something similar: the real simulation, running the real units, filmed by something that is not a person holding a phone. This step is about how we film Brick & Mortar.

A recorder that does not care how fast your PC is

If you record a game while it runs, you film its frame rate: whatever the machine managed that second. A busy explosion drops the rate, and the film stutters.

Our recorder (Core/IDCapture.cpp) does the opposite. It steps the game a fixed 1/60 second per frame and waits for the frame to be written before it takes the next. The film is exactly 60 frames a second, in exact simulation time, whether the machine renders that frame in 8 ms or in 800. The back buffer goes straight to ffmpeg through a pipe, as 4K HEVC.

Fixed stepping has a consequence we had to deal with: sound cannot be recorded live. The game's own audio is rendered offline instead, from the game's own clock, in lock-step with the frames, to a WAV file, and muxed in afterwards.

Cameras are data

A camera path is a list of keyframes: time, position (in map cells and metres above ground), yaw, pitch, field of view, focus distance and f-stop. They are flown along a smooth curve with eased timing. In play you press K to drop a keyframe where you are; a file holds the paths, and a script writes new ones. Later we added follow cameras that track a unit, a roll, and a capped shake. The time of day is a flag, so the same battle can be shot at dawn, noon or sunset.

The queue

On 23 October the tools came together. One CSV lists the takes: a name, the map or scenario, the launch flags, the camera, how much interface to show (none, full or banner only), and a time limit as a fail-safe. A script runs the whole list unattended. Each take comes out as one 4K, 60 fps HEVC file with the game's sound effects and no music, voice or announcer, plus a text log and a list of sounds.

A queue like that wants a machine nobody is using, so another script waits for the owner's game to close and for free memory before it starts.

Massive battles from the real simulation

The owner's brief was clear: full rosters on the ground with a big air force, a fleet battle with lines of battleships, and buildings going up while a battle rages behind them. We call them set pieces.

How they work matters for honesty. A scenario file places the armies at the start, the way a scenario editor would. After that the mission director's own attack script sends each group at the enemy and then switches it to hunt, so idle units pick the nearest foe or building. There are no changes to health or damage, and nothing is teleported. What you see is what the simulation did.

From a ground set piece. 4K 60 in the original, a 720p loop here.

The set pieces are deterministic at normal speed: re-shooting the first ground take logged exactly the same census of units alive, in view and fighting. Run at five times speed they are not, and the battle goes differently late on. That is why every take is shot at 1x. A census line is written twice a second into each take's log: units alive on each side, how many are in view, what percentage of those are doing something. A take with a third of its units idle is not a battle, and we can see that from the log without watching it.

From the build set piece: structures going up while the battle goes on behind them. 720p loop of a 4K take.

The rejects

We threw some away. Takes that missed (a camera that faced the empty side, a fleet that never closed) and takes superseded by a better angle go to a rejected folder, not the bin. The queue overwrote four of our own bad first attempts. A set piece has a version two and a version three, and the best one is chosen by a person watching, not by a script. A take is 120 to 200 MB for twelve seconds, so we have plenty to choose from and a disk to watch.

What we would do differently

Build the recorder before the maps. Every earlier screenshot was taken at whatever frame the machine got to.
Log what is in frame, every half second. It found weak takes faster than watching did.
Do not trust fast-forward. If a result depends on speed, it was never deterministic.

Try it yourself

Treat your game as a film set that you can run again: a fixed time step, camera paths in a file, a log of what is in view, and a queue that works while you sleep.

Next: The brand kit and this website - built from code, no trackers (23 October 2026)

Start at Step 1 All 27 steps