Abstract
Problem: How should game developers approach building internal tools for their teams, and what makes the difference between tools that help and tools that hinder?
Approach: Tim Cain draws on his experience shipping Fallout and Arcanum, contrasting the pain points of Fallout's tooling (which he didn't build) with the purpose-built tools he created for Arcanum.
Findings: Great tools come from two principles: understanding the discipline you're building for, and actually using your own tools. The best tools make common tasks fast and make mistakes hard. Arcanum — a much larger game than Fallout — was built in the same timeframe with a third of the people, largely thanks to better tooling.
Key insight: A little effort invested in tools saves exponentially more effort later. Make common things fast, make bad things hard.
Two Foundational Principles
Before getting into specific tools, Tim lays down two rules he considers more important than anything else:
Know Other Disciplines
Programmers who understand how assets are actually created make vastly better tools. Graphics programmers who know how models are textured, rigged, and animated build better pipelines. Tim extends this to all roles — designers who can code make more implementable designs, artists who understand rendering make faster-performing art. You don't need to be good at the other discipline, just understand it.
Eat Your Own Dog Food
If you've used any major commercial game engine, you've probably hit a moment where you think: "Did anyone at this company actually ship a real game with this?" Tim believes many engine features were built for simple demos but never stress-tested at production scale — thousands of objects, hundreds of interfaces, real search and bulk-edit needs. If you don't use your own tool at scale, you'll never find the pain points.
Fallout's Tool Pain Points
Tim didn't build Fallout's level editor, scripting system, or dialogue tools. But he heard constant complaints and fixed countless bugs that originated from them:
Map Editor
Fallout's isometric maps were assembled from sliced tiles and wall strips. Artists had to manually grab tiles, check a tiny preview strip at the bottom, place them, discover the pixels didn't match, and try again. Finding the right wall strip to connect to an existing wall was trial and error. Maps that should have taken minutes took hours or days.
Scripting
Fallout's scripting system allowed syntactically incorrect scripts, bad object references, and infinite loops — all of which produced bugs Tim had to fix on the programming side.
Dialogue
Dialogues were written independently by different writers with no reuse. The same concept (like bribing an NPC) was written dozens of different ways, meaning duplicate strings that wasted memory, load time, and localization budget.
Arcanum's Purpose-Built Solutions
When Tim co-founded Troika Games after leaving Interplay, they had to rebuild every tool from scratch. This time, Tim built them himself, informed by every complaint and bug he'd seen on Fallout.
The World Editor
The Arcanum map editor let designers "spray" terrain tiles (water, sand, grass, rock) that would automatically transition and connect to surrounding tiles, with random variations applied automatically. Buildings could be drawn as rectangles in a top-down view — the editor inserted all walls, corners, and roofs from matched asset sets. Windows and doors were placed with a single keypress on a wall segment, and could be widened by clicking adjacent segments. What took hours in Fallout took seconds in Arcanum.
Sock Monkey Script Maker
Tim's scripting tool for Arcanum was intentionally constrained. You couldn't write a syntactically incorrect script because you didn't type code — you selected actions and conditionals from dropdown menus. Infinite loops were nearly impossible (though some determined scripters found ways using multiple scripts, which Tim countered with a script call counter). The result: scripting was as fast or faster than Fallout, but bugs were almost exclusively semantic — wrong logic, not bad syntax or crashes.
Generated Dialogue
Instead of hand-writing every dialogue variation, Arcanum used a generated dialogue system with reusable subtrees — bribe, vendor, insult, ask-for-help, story-state queries. Writers could add variations in one place, controlling localization costs while keeping NPCs from sounding repetitive.
The Results
These tool investments paid off dramatically. Arcanum is a much larger game than Fallout, yet it was built in the same amount of time with roughly a third as many people. Tim attributes this directly to the tooling.
Tim's Tool-Building Summary
Three guidelines for building great internal tools:
- Know your users. Understand who will use the tool and how. Use it yourself if possible.
- Make common things fast. The operations performed most often should be the quickest and easiest.
- Make mistakes hard. Reduce memory waste, prevent syntax errors, block infinite loops — steer users away from bad patterns. They'll still find ways to break things, but friction helps.
The closing thought: a little effort on tools saves a lot more effort later.
References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=_P4-2Nv_Or8