Features: From Ideas To Implementation

Step 1: Write It Down

The very first thing Tim does when he has a feature idea — no matter how small or half-formed — is write it down. He stresses this because he's lost countless ideas by trusting his memory. A few days or weeks later, the idea is gone. Writing it down is non-negotiable.

Step 2: Informal Sounding Boards

Before any formal process, Tim bounces the idea off trusted people — teammates, colleagues at the company, even industry contacts. This is not a meeting. There's no design document yet. It's casual conversation.

Not everyone is good at this stage. Some people reflexively say no, or need mock-ups and specs before they can engage. Tim specifically names Leonard Boyarsky as an excellent sounding board — not just for art and story, but even for system mechanics, because he's played extensively and can quickly spot problems or overlap with existing features. Charlie Staples (lead designer on The Outer Worlds) was another go-to — Tim would walk around the corner with his "new idea face" and get sharp, useful feedback.

Step 3: Research Other Games

Tim looks at games that have the feature (or similar ones), and games that are missing it. He uses review aggregators like Metacritic to check:

• Did reviewers praise or criticize this feature?
• Did anyone wish this feature existed in a game that lacked it?
• Did anyone explain why a similar feature wasn't added?

This gives real-world signal about whether the feature is worth pursuing and what pitfalls to expect.

Step 4: Write a Formal Specification

Now Tim writes a proper spec covering:

• Every UI element needed
• New art requirements
• Connected systems
• Similar features in other games
• Goals — listed at the top, so future discussions stay focused on either "does this feature meet the goals?" or "are these the right goals?" (two separate conversations)
• Pillar alignment — connecting the feature to the game's design pillars. Tim says this is exactly why pillars exist, and he's gotten features approved specifically by showing they support an under-served pillar.

Step 5: Formal Review

At Obsidian, specs lived on Confluence. Reviewers were named explicitly with checkboxes. When they finished commenting, they checked their box — so you knew when all feedback was in.

This is where leads — programmers, artists, designers — raise concerns: time constraints, contradictions with other features, unclear mechanics, art scope. Tim connects this directly to the challenges he's discussed in other videos about what programmers, artists, and designers face. New features are a primary source of those tensions.

Step 6: Revise the Spec

Address every concern. On Confluence, Tim would reply to inline comments, resolve them when agreed upon, and produce a revised spec that has passed through all leads and stakeholders.

Step 7: Producer Scheduling

In modern development (as opposed to Tim's earlier days where he'd just code it himself), the revised spec goes to a producer who:

• Gets time estimates from the relevant developers
• Gets lead sign-off
• Puts it into the project schedule
• Assigns people to work on it

At this point, you can see who's working on your feature and roughly when it'll be done.

Step 8: Implementation

The feature gets built. Tim's executive producer would review what went in during daily or weekly production meetings, then notify QA to begin testing.

Step 9: QA and Personal Testing

Tim often tested new features himself, coming in early to grab the build. He looks for things QA typically doesn't:

• Does the implementation match the spec? QA catches bugs and balance issues, but Tim compares the result to what was actually asked for.
• How does it interact with other systems?
• Is it what was envisioned?

He'd then meet with his QA lead (he names Taylor Swope from The Outer Worlds) weekly, especially in the final months, to compare notes and prioritize revisions.

Step 10: The Test-Revise Loop

Revisions get scheduled through the producer with new time estimates. The loop — test, review, revise — repeats until either you're happy with the feature or the game ships, whichever comes first.

Arcanum vs. The Outer Worlds

Tim contrasts two extremes from his career:

• Arcanum: The test-revise loop barely happened once. Many features shipped in their first implementation, unbalanced and uncompared against other systems.
• The Outer Worlds: The loops were maintained throughout development. Features got balanced, debugged, and polished. Tim was "really proud" of how bug-free the final product was.

The Credits Problem

After walking through all 10 steps, Tim raises a philosophical question: who gets credit for a feature?

• The person who had the original idea?
• The people who heavily modified it during review?
• The programmer who spent months implementing it?
• The artist who redesigned the UI to support it?
• The QA team that got it working correctly?

Tim's answer: these are all wildly different questions with different answers. The originator might have spent three days on the idea before moving on, while others spent months bringing it to life. This is why he finds it hard to write credits that connect people to specific features, and why he struggles to answer "who did this?" questions — because the honest answer involves many people across many roles.

References

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