Bugs In RPGs

Why RPGs Are Inherently Buggy

RPGs are extraordinarily complex software with many interlocking pieces. Unlike a fighting game with a dozen characters and a few moves each, RPGs have inventories, quest histories, leveling systems, multiple character builds, and nonlinear quest structures.

Three properties of RPGs specifically breed bugs:

• Nonlinearity — When players can do things in different orders, every permutation creates potential blocking conditions. Multiple solutions to quests mean multiple items, skills, and builds that all need to work.
• Emergent gameplay — Players combine skills, items, and environmental objects in ways designers never intended. These "emergent bugs" arise naturally from the rules and are extremely hard to anticipate.
• System interactions — Status effects stacking, items interacting with environments, key presses during specific states — the combinatorial explosion makes exhaustive testing impossible.

Tim emphasizes this has always been true. Even cartridge-era console games (which couldn't be patched) shipped with bugs despite heavy QA and deliberately simplified scope.

How Tim Cain Rates Bugs

Tim describes a clear priority hierarchy he used across his projects:

Tier 1: Ship-Blocking (Highest Priority)

• Crash bugs — The #1 priority. Crashes destroy player trust. If players notice crashes correlate with their build or certain actions, they stop playing entirely. Crash bugs are "probably the number one reason people rage quit."
• Build-blocking bugs — When a character build literally cannot complete the game because required skills, items, or quests are inaccessible. Players discover this 5, 10, or 50 hours in. Devastating because the player did nothing wrong.
• Certification failures — Platform requirements (Xbox, PlayStation, Windows) around achievements, content ratings, quit functionality. Fail certification and you don't ship.

Tier 2: Incorrect Implementation

• Features not matching design docs — A skill or item doesn't work as specified. Straightforward to fix once identified.
• Correct implementation with unintended consequences — Two items work fine individually but break when combined. Fixing these is harder because removing a system (like crafting) can cascade through the entire item economy.

Tier 3: Polish and Friction

• "Not fun" bugs — A class, dungeon, or skill that technically works but nobody enjoys using.
• Clarity issues — Telemetry shows players stopping at specific points because they don't know where to go or what to do next. Fixes range from new dialogue to quest marker changes.
• "Sanding off friction" — Drop rates too low, NPCs too annoying to interact with, minor irritants that accumulate. Low priority individually but shipped friction damages reception.

The Patching Problem

The ability to patch games post-release has made things worse — not by creating the bug problem, but by removing the incentive to fix bugs before shipping. Tim identifies several dynamics:

• Publishers push to ship early and "patch it later" to stop spending money
• Kickstarted or self-funded games may simply run out of funds with no money left to fix known bugs
• Some games are canceled entirely rather than shipped in a broken state — "there's a lot of games out there that you've never heard of"

In the cartridge era, you shipped what you burned. That constraint forced more rigorous pre-release QA despite more limited tools.

Three Practices That Actually Reduce Bugs

Start Playtesting Early

Begin as soon as the game is playable — first playable or vertical slice. But playtesters must understand the stage of development. Tim describes the soul-draining experience of giving testers a graybox level for mechanics feedback and receiving "it's ugly, I hate it" instead.

In-House QA

Tim strongly prefers in-house QA over remote/offshore teams:

• They can access living design documents (e.g., on Confluence) and verify whether behavior matches current specs
• They can write bugs with confidence about intended behavior
• No timezone problems — Tim describes having to come in at 6 AM or stay until 11 PM to talk to offshore QA

A key practice Tim started during Fallout: weekly meetings with the QA lead. The QA lead reports the worst bugs, explains why they matter, and shares how the game feels after sinking hundreds of hours into it. "No one will play your game more than QA." On The Outer Worlds, this feedback loop produced a notably stable launch.

Tim also shares cautionary tales: on his D&D game, QA barely tested Bards because they didn't like the class. On Vampire, they barely tested Nosferatu because the characters were ugly. Obvious bugs shipped as a result.

Test Plans

Designers should write explicit test plans describing how each feature should be tested. For a lockpicking skill: test it on doors, chests, unusual lockable objects, computers. Then verify QA actually follows the plans — the weekly QA meeting helps enforce this.

It All Comes Down to Money

Tim's summary is blunt: every solution costs money. Early playtesting, in-house QA, test plan creation and enforcement, designer time spent writing test plans instead of designing — it's all time, and time is money.

"I could have gotten rid of this entire video and just said: why do games have bugs? Money. Will we always see games with bugs? Yes, because of money. As long as money is not infinite, you will probably see bugs."

Source

Bugs In RPGs — Tim Cain (YouTube)