Challenges Facing Game Programmers

Patience as the Core Virtue

Tim argues that the single most important personality attribute for a game programmer is patience — not intelligence, not breadth of algorithmic knowledge, not specialization. The reason: programmers get blamed for every single bug in the game, regardless of who actually caused it. This never stops, no matter how senior you become or what safeguards you put in place.

Not All Bugs Are Code Bugs

A common misconception is that all bugs are inherently the programmer's fault because "it happens in code." Tim pushes back on this hard. There are many ways to make a game buggy that have nothing to do with code:

• Artists importing oversized textures or sprites
• Scripters writing inefficient or recursive scripts
• Designers creating scenarios that exceed memory or performance budgets

Tim references the halting problem to make a theoretical point: it's mathematically impossible to write code that can examine all possible inputs and guarantee error-free behavior. You simply cannot anticipate every way non-code contributors will break things.

The Fallout Memory Crisis

During Fallout's development, the game would run out of memory due to oversized art assets. Tim's team wrote error messages to warn when memory was low — but other developers either didn't notice the warnings or dismissed them ("I saw that but it's not my fault").

One memorable case: an artist created an animated sprite so large (screen-sized or bigger) that loading it required throwing out all other art from memory. If any of that art was "locked" (actively displayed on screen), the game would crash. The bug manifested inconsistently — sometimes crashing, sometimes just getting slow, sometimes working fine — making it appear to be a programming problem.

The solution was twofold: the art tool was modified to warn about oversized assets. Tim's wry observation: "I'll give you one guess at how many artists actually paid attention to the warning messages."

In an even more extreme case, the game ran so low on memory that it couldn't even allocate enough to display an "out of memory" error message. The fix: pre-allocate the error window at startup, permanently reducing available memory for the entire game session, just in case an error needed to be displayed — to someone who might not even read it.

The Arcanum Script Recursion

For Arcanum, Tim deliberately left goto statements out of the scripting language, knowing that many scripters wouldn't be trained programmers. He designed loops with clear beginnings and ends, and structured conditionals to prevent infinite loops.

He thought he had it covered. He was wrong.

Leonard Boyarsky found a workaround almost immediately: Script A could call Script B, and Script B could call Script A. The stack would blow, the game would crash. After the initial fix attempt (counting call depth), scripters found ways around it with chains like A→B→C→A. Tim eventually implemented a time-based cutoff — if a script ran longer than a set number of milliseconds, it was forcibly terminated and a warning was logged. This introduced new bugs (incomplete script states), but at least provided diagnostic breadcrumbs.

The South Park Frame Rate Disaster

At Obsidian, Tim encountered a level in South Park that dropped from 30 FPS to 2 FPS. A scripter had written code that, every single tick, grabbed every object in the game, looked up a property on each one, and made decisions based on it.

The fix was straightforward: cache the relevant objects at level load, or use the engine's existing optimized search functions (which maintained pre-sorted lists by object type and name). The frame rate returned to 30 FPS instantly.

Tim's bewilderment: how was this not noticed the moment the script was written? The frame rate dropped from 30 to 2 — the only change was that script. Yet the response was to call a programmer rather than investigate.

The Interruption Problem

Programmers hold complex mental models in their heads while coding — data structures, algorithms, conditional chains. When interrupted, that mental structure collapses and has to be rebuilt. Tim notes that his own tolerance for interruptions is much higher when designing than when coding, even though he's the same person doing both.

This is why programmers want offices with doors, use headphones, establish quiet hours — not because they're antisocial, but because complex code requires sustained concentration. Interruptions don't just cost time; they introduce bugs. Tim admits to writing buggy code specifically because of ill-timed interruptions.

What Tim Looks for in Interviews

When interviewing programmer candidates, Tim watches not just what they code on the whiteboard but how they handle being interrupted with questions during the exercise. He's deliberately testing patience and interpersonal grace, because that's what daily life on a game team looks like.

If a candidate gets snippy with their potential boss during an interview, Tim reasons, imagine how they'd treat a peer or a junior team member asking questions. Technical skill matters, but the ability to work patiently within a team is equally important. The era of single-person game development is over.