Adding New Features After Launch

The Generic Answers: Money and Team

Tim opens by acknowledging the universal answer to "why don't they just add X": money. Every new feature competes for priority against bug fixes, DLC content, sequels, and entirely new projects. Time is money, and post-launch time is especially expensive.

The second generic answer is team availability. The people who built the base game — designers, programmers, artists, audio engineers, testers — may have been reassigned or left the company. New features are always harder without institutional knowledge.

But Tim considers these answers unsatisfying because they apply to virtually any post-launch question. He instead focuses on two specific, technical reasons.

Example 1: Companion Line-of-Sight (Harder Than You Think)

A common player complaint in action RPGs: companions and friendly NPCs keep walking into your line of fire. Why can't the AI just move them out of the way?

Tim breaks down the cascading complexity:

• Target identification: Many games don't have explicit target-locking, so the AI has to guess who the player intends to shoot — before they shoot.
• Moving targets: Both the player and the target are moving, so the "line of fire" is constantly shifting.
• Multiple potential targets: Should NPCs avoid the line between you and every potential target? That's a huge exclusion zone.
• Cover calculations: AI already tries to find cover from enemies. Now it must also find cover that doesn't intersect the player's line of sight to all targets.
• Companion-to-companion conflicts: Each companion has their own targets and lines of fire, multiplying the line-of-sight calculations per tick.
• Priority conflicts: If staying out of the player's way isn't the #1 AI priority, the problem persists. If it is, other behaviors break.
• Melee companions: A melee companion literally needs to run toward the target — directly through your line of fire. Asking them to avoid a 100–120° arc in front of you makes melee attacks nearly impossible.

The Cascade Effect

Even a partial solution creates new visible problems: companions never taking cover, companions blocking each other, or melee characters behaving erratically. You solve one complaint and generate several new ones.

Example 2: Inventory Sort by "Recently Added" (Save Game Incompatibility)

A seemingly simple request: add a sort mode that orders items by when the player picked them up. The game already sorts by name, type, value, and weight — how hard can one more be?

The problem: this sort requires a timestamp on every inventory item, and the game probably wasn't recording timestamps before.

The Old Save Game Problem

You can add timestamps to the code going forward, but existing save games don't have them. When a player loads a pre-patch save, what happens?

Tim outlines three approaches, all flawed:

• Disable the feature for old saves: Players won't understand why the patch note feature is missing. Bad UX.
• Assign random timestamps to existing items: Items appear in nonsensical order. Players notice and file bugs you can't fix.
• Scan older save files to reconstruct order: Compare successive saves to deduce when items appeared. This is complex, depends on the player having kept old saves, and still produces incorrect ordering for items acquired between saves.

The Core Issue

Sometimes a feature requires data that simply doesn't exist in the save format. You can't retroactively generate accurate data, and any approximation will look like a bug to players.

Tim's Two Specific Post-Launch Blockers

Beyond the universal constraints of budget and team:

1. Hidden complexity — The feature is genuinely harder to implement than it appears from the outside, often involving cascading side effects.
2. Save game incompatibility — The feature requires data that old saves don't contain, making a clean retrofit impossible.

Both are invisible to players, which is why the reaction is always "why don't they just fix it?"

References

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