Abstract
Problem: How did source control practices evolve in the game industry from the 1980s through the 2000s?
Approach: Tim Cain walks through his personal experience with version control across multiple shipped titles — from no source control at all, through Microsoft SourceSafe, to custom locking systems, to Perforce.
Findings: Each generation of source control solved real production problems but introduced new workflow considerations. The shift from exclusive checkout to non-exclusive checkout with merging fundamentally changed how teams structured their code. Features like shelving and branching became essential for demos, patches, DLC, and multi-platform development.
Key insight: Source control wasn't just a technical tool — it actively shaped how programmers broke up their code into modules, because exclusive checkout meant smaller modules reduced team bottlenecks.
The 1980s: No Source Control At All
In the 1980s and early 1990s, source control software simply wasn't used — at least not where Tim worked. For single-programmer games like Bard's Tale and Rags to Riches, whatever was on your machine was the latest version. Your machine was the build machine. Artists, sound designers, and scripters would hand you their files, and you'd assemble the build yourself.
On multi-programmer projects like Grahn's Star Bridge, each programmer still owned specific code modules exclusively. The lead programmer would receive code from others and build on his machine. By Rags to Riches, they may have had a dedicated build machine — a shared computer where everyone deposited their assets for building.
Fallout and Microsoft SourceSafe (1994)
Fallout in 1994 marked Tim's first experience with actual source control software: Microsoft SourceSafe. It lived on the network and introduced key concepts:
- Check-in/check-out — Files were read-only by default. You checked out a file to make it writable, then checked it back in.
- Get latest — Anyone could pull all the latest versions of every asset to do a local build.
- Exclusive checkout — When you checked out a file, nobody else could check it out. SourceSafe would tell them who had it.
- Linear history — Every file had a history of changes with names and timestamps. You could roll back and diff versions.
How Exclusive Checkout Shaped Code Architecture
This is where Tim makes a particularly interesting observation: exclusive checkout forced programmers to think about module size differently. If you had one big interface module, multiple programmers would fight over it. So you'd break the interface into inventory, options screen, main HUD, journal — each as separate code modules so different people could work simultaneously. The source control system directly influenced code architecture.
History and diffing also helped with debugging. When something broke, you could see who checked in what, diff the files, and spot the bug in the changed lines.
Arcanum: A Custom Locking System for the World Map
Arcanum presented a unique problem: the entire game world was one continuous map. You couldn't let someone check out the world map file — that would lock everyone else out of all outdoor areas.
Tim's team built a custom sector-locking system using the Windows filesystem:
- When the editor started editing a sector, it would attempt to create a file on a shared network folder named with the sector number and a
.loextension. - File creation is atomic in Windows — if the file already existed, someone else had the lock. You could see who created it and when.
- When done editing, the lock file was deleted.
This gave them SourceSafe-like exclusive checkout at the sector level, though without file history — data just went into their database when unlocked.
Perforce: Non-Exclusive Checkout and Merging
By Temple of Elemental Evil and Vampire: The Masquerade – Bloodlines, the team had moved to Perforce, which Tim describes as "everything you wanted in SourceSafe but didn't get."
The big change was non-exclusive checkout: multiple programmers could check out the same file simultaneously. The first person to check in had no issues. The second person would be prompted to merge:
- Good day: Changes were in different parts of the file. Merge automatically, check in, done.
- Bad day: Both people edited the same area. Manual conflict resolution — figure out whose fix to keep, or combine the changes.
In practice, conflicts were rare because lead programmers assigned different tasks to different people, so overlapping edits were uncommon.
Tim notes that for non-text files (art, audio), they usually kept exclusive checkout enabled because merging binary assets was impractical.
Shelving
Perforce introduced shelving — a way to save work-in-progress to a private area on the server without affecting the main codebase. This meant:
- You could work on something over multiple days without risk of losing work to a machine crash.
- Shelved files weren't included when others did a "get latest."
- When ready, you'd unshelve into the main branch, merging if necessary.
Branching
Branching created completely separate copies of all assets. You'd specify which branch you were working in when checking in or out. Tim lists key use cases:
- Demos — Branch the game, add tutorial content or a special demo level, keep it isolated.
- Patches — Branch from the shipped version so you can always return to the original.
- DLC — Develop new content on its own branch.
- Multi-platform ports — A PC-to-PlayStation port might branch from the base (unpatched) version, since rendering optimizations won't apply, while gameplay bug fixes can be cherry-picked.
Still Perforce Today
Tim confirms Perforce was still in use at Obsidian on The Outer Worlds. He reflects that source control has come an enormous distance from "whatever's on my machine is the real version" — a journey of over 40 years, and a clear example of where tooling has dramatically improved the game development process.