Video Summary - Jonathan Blow on Why Gameplay Code Gets Slow

Technological concepts & performance problems discussed

Porting to lower-tier hardware (graphics + CPU constraints): As launch approaches, the team targets weaker systems (e.g., Steam Deck, Nintendo Switch, and a ThinkPad X1 Carbon with low-end GPUs/CPUs). Gameplay code that originally ran acceptably on more capable hardware becomes too slow.
Shader rework: The speaker describes reworking shaders to address performance and rendering needs—having previously “swept things under the rug.”
Gameplay logic is responsible for CPU slowdowns: Profiling shows large performance spikes during gameplay evaluation after object movement.

Frequent recalculation: Whenever objects move, the game calls a function like “post move re-evaluate”, which triggers substantial work.
Profiling shows spiky cost: The profiler reports giant spikes in a specific sub-section referred to as “section 5B.” This cost appears via a call chain such as 5A → 5 → post-move re-evaluate.
Debug vs release behavior:
- In debug builds, the costly path is about 13 ms per frame for one major function call (e.g., section 5B).
- In release builds, it drops to < 1 ms, but that’s still meaningful for a game’s performance budget.
- The speaker uses debug performance as a proxy to estimate what slower machines might feel like (not perfectly apples-to-apples, but useful for identifying bottlenecks).

Expensive brute-force search over many entities: The game checks whether entities have support beneath them by iterating over all entities and asking whether something supports each entity.
Worst-case scaling with many interactive objects:
- A scene can contain roughly 7,000–8,000 interactive objects (e.g., stacked rock barriers and many small level entries).
- Even if falling almost never happens, the support-checking logic is still expensive enough to show up in profiling.
- The earlier prototype mindset used broad/nested loops because performance was assumed not to matter yet.

Cost multiplies with monsters: Another expensive part decides whether objects should be crushed and involves weight calculations tied to monsters.
Data structure choice drives the cost:
- Current approach: for each monster, the code scans many/all game entities to determine support relationships (e.g., whether an entity is standing on a monster).
- Example scale:
  - ~140 monsters in a level
  - ~8,000 entities
  - Repeated across ~100+ relevant monsters → roughly ~800k–1.1M iterations per relevant game-turn evaluation.
Alternative approach proposed: Maintain/query relationships in the “support direction” (e.g., who is above me / who do I support) using a better structure:
- Potentially closer to one-to-many, or tree-like in rare grid/stack cases.
- The speaker believes the right structure would make queries fast instead of scanning everything.

Turn-based puzzle with time-limited turns: After each turn ends, the engine runs the re-evaluation work.
Choppy frame times on constrained devices: Desktop may hide issues, but Steam Deck (and likely Switch) shows stutter because frame-time spikes occur at turn boundaries.

Short-term goal (“this week”): Rewrite the slow gameplay code to speed up evaluation on low-end platforms.
Two main performance improvements proposed:
1. Reverse-direction data structure: Use a structure that answers support queries quickly rather than scanning all entities.
2. Limit work to affected movers/events: Instead of checking every monster in the world, check only monsters that moved or had something above them change.