The Credits Problem (e.g. Fallout Companions)

1. The Origin of Fallout Companions

In 1994, during early Fallout design meetings, the team debated whether the player would control a single character or a party. Many RPGs of the era — Ultima, Wizardry — used multi-character parties. However, one of Fallout's core design pillars was reactivity to the player: the game should respond to the kind of character you built and how you behaved. A single protagonist made this far more tractable — your actions, your skills, your consequences.

Tim believes it was Scott Campbell who originally raised the single-vs-party question in 1994, though he notes he doesn't have his original notes to confirm.

2. Jason Anderson Revives the Idea (Early 1997)

More than two years later, with the game approaching what they hoped was the bug-fixing phase, Jason Anderson wanted to revisit the companion concept. At this point, NPCs like Tandi existed as quest objects — you'd rescue her, she'd thank you and reappear back in Shady Sands. There was no system for followers joining you, fighting alongside you, or sharing inventory.

Jess Heinig, a scripter, figured out how to make a basic companion system work using just scripts. He wisely chose Dogmeat as the proof of concept — no dialogue, no inventory, just a dog that follows you, fights when you're attacked, and transitions between maps. The implementation may not have been entirely clean under the hood, but it worked. When QA got their hands on it, they loved it and immediately wanted more.

3. The Implementation Crunch

The team was already working six or seven days a week, 10–14 hours a day. Expanding companions beyond Dogmeat to human NPCs required substantial new work:

• Map transitions needed code support — the script-only approach could break save games and bloated every map's scripts. If you missed adding the script to one map, your companion would simply vanish. Jesse Reynolds, a programmer, took over this work.
• Dialogue and inventory access — Tim leveraged the existing pickpocketing interface so players could manage companion equipment ("basically you were pickpocketing your companions but they didn't care").
• Companion AI — Tim repurposed the enemy AI for companions. It mostly worked, but produced many bugs, including the infamous tendency for companions to shoot the player in the back. With the team already overwhelmed, and Tim spending two weeks hunting a random crash bug, companion AI polish simply couldn't be prioritized. A companion occasionally friendly-firing was less critical than save game corruption or random crashes.
• Narrative — Other team members wrote companion dialogue.
• QA — Testers reported a massive number of companion bugs, many of which shipped unfixed.

4. The Impossible Question

After Fallout shipped, journalists asked a simple question: "Who did the companions?"

Tim describes every possible answer as a trap:

• "Scott Campbell" — People object that Jason revived the idea and actually got it going.
• "Jason Anderson" — This dismisses Scott's original contribution, and Jess Heinig was the one who actually got it working in-engine.
• "Jason and Jess" — Jesse Reynolds and Tim were the ones who made it shippable.
• "Scott, Jason, Jess, Jesse, and me" — Narrative writers feel left out. QA feels excluded ("it wouldn't have worked if we hadn't reported all those bugs").
• "It was a team effort" — Individual contributors resent being dissolved into the collective. Journalists groan at the non-answer. A PR manager once told Tim to stop saying "we" because it was coming across wrong.

5. The Troika Experiment

At Troika Games, they tried a clever solution for Arcanum's credits: simply listing "Arcanum was made by" followed by all 14 Troika employees' names, with no individual titles. This backfired when databases like MobyGames required titles for each person — Tim ended up listed as "Lead Animator" of Arcanum. Even after corrections, unrecognized names appeared in the main section, implying they worked at Troika when they didn't.

6. The Problem Never Goes Away

Tim shares several additional anecdotes illustrating the persistence of credits friction:

• A colleague who refused interviews confronted Tim for not crediting him in an interview — despite never crediting Tim for anything himself, and having declined the same interview opportunity.
• Crediting by title instead of name — Tim once credited someone by their role rather than name in a video. The person took offense, even though the title was easily searchable.
• Industry-wide practices — Many companies remove names from credits if someone leaves before a game ships, regardless of their contributions. Tim's own code shipped in Pillars of Eternity II: Deadfire, but he received no credit because he was reassigned to The Outer Worlds partway through development. He advocates for "Additional Programming/Art/Design by" sections for departed contributors.
• WildStar — Tim designed character classes that shipped in WildStar but doesn't appear in the system design credits.

7. Tim's Conclusion

There is no solution. Giving credit is an inherent minefield in collaborative creative industries — games, film, and beyond. Every attribution method will anger someone. Tim's approach is to spread the answer across contributors: "the idea came from this person, the implementation was this person, and then this other person did these other things." But even that careful parsing produces a pause and "a kind of look of fear in my eyes" every time a journalist asks the question.

His advice to aspiring developers: the credits issue will come up. No company's policy resolves it perfectly, and even if the credits page is handled well, someone will inevitably be unhappy with how interview questions about the game are answered.

8. References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=JOVgSfjWeVI