They Are Billions simulates every zombie and every unit on the map each tick, on the CPU. A developer has said outright that game speed depends on your CPU and on how many elements are on the map, and that the game slows itself down when the hardware can't keep up. In the final waves that means the recording freezes for whole stretches. In our tests of 800% footage, 56–85% of recorded frames were exact repeats of the frame before. Those can be removed after the fact.
Why the final waves lag
The game's selling point is the number of units on screen at once, and the final wave on higher difficulties arrives from every direction. Each zombie needs pathfinding, collision and target checks every simulation tick; each tower needs target selection among thousands of candidates. That work scales with the number of elements, not with your GPU, and it runs on a single thread.
When the CPU can't finish a tick in time, the game doesn't drop updates: it slows the simulation down. On the official forums a developer explained that game speed depends on the CPU's processing speed and the number of elements on the map, and that the game is balanced to stay playable on slower PCs. Players notice the same thing: a wave that takes 40 seconds of game time can take minutes of real time.
What that does to a recording
Your recorder keeps writing frames at a fixed rate. If the game hasn't drawn a new frame when the next slot comes up, the recorder writes the previous one again (why). OBS won't count this as a dropped frame.
We measured this on 30-second windows from two channels' 800% no-pause runs. Because the runs never pause, every frozen stretch is the game stalling:
| Source | Real game updates in 30 s | Frozen frames |
|---|---|---|
| KenseiTV, 800% Survival, Map 4 | 56 of 900 | 84% |
| indysc2, Campaign, Apocalypse 800% | 96 of 900 | 79% |
| KenseiTV, Final mission | 135 of 900 | 85% |
In the worst case the game drew under two distinct frames per second. Speeding that up in an editor just makes the freezes shorter; it doesn't make the motion continuous.
What helps in-game
- Fast Timers Optimization. There's an option by that name in the game's settings. Players report it makes the game run faster when the CPU can handle it, and that turning it off gives a slower, steadier pace. Try both for recording; a steady slower pace produces fewer freezes than a fast pace that stalls.
- Close everything else. Any background CPU load slows the simulation directly. That includes a CPU-based encoder in OBS; use a hardware encoder (the same OBS setup as for BTD6 applies).
- Record at 30 fps. If the game can only draw a few frames a second in the final wave, recording at 60 just doubles the padding.
- Fewer, bigger defenses. Thousands of individual walls, traps and low-tier towers each cost simulation time. Executors and shocking towers cover more with fewer elements.
A faster GPU doesn't help. The hard limit is single-core simulation speed, and even a top-end CPU stalls in the last waves on 800%.
Fixing the recording
Since every frozen frame is a copy of the one before, they can be detected and dropped, leaving only the frames where the map actually changed. For They Are Billions this needs some care: the HUD at the bottom shows tooltips, hover highlights and the day/hour clock, and many creators have a webcam in the corner. Those can change while the game is frozen.
LagCut for They Are Billions compares only the map viewport, split into blocks, and counts a frame as a real update only when most of the map changed. Multi-second stalls are listed on a review timeline. On the three clips above it produced 1.9, 3.2 and 4.5 seconds of continuous gameplay from 30 seconds of recording each. The before/after clips are on the tool page.