The Cost Of Moddability

tim-cain game-development modding programming architecture arcanum game-engines

Abstract

Problem: Players often ask "why didn't they just make it moddable?" as if it's trivial — what does moddability actually cost in time and money?

Approach: Tim Cain draws on decades of experience (including Arcanum) to break down the three stages required to make a game moddable, and the hidden costs at each stage.

Findings: Moddability requires architectural commitment from day one, involves three distinct engineering stages, imposes performance costs, demands separate tooling and documentation for end users, and directly competes with other features for budget and schedule.

Key insight: Whenever anyone says "just make it moddable," they almost certainly don't understand what's involved — moddability is a major architectural decision, not a bolt-on feature.

1. The "Just Do This" Fallacy

Tim opens by addressing the common player sentiment: "Why didn't they just make it moddable? All they had to do is..." His gut reaction whenever anyone says "just do this" is that they have absolutely no idea what they're talking about. The answer to "how much does it cost?" is always the same: time and money.

This applies equally to managers who say "hey Tim, why don't you just do this?" — Tim's response is to break down exactly how long it would take and how much it would cost, then ask if they still want it done. The answer is usually no.

2. The Three Stages of Moddability

At the highest level, making a game moddable requires three stages:

2.1. Stage 1: Making Systems Exposable

You can make systems exposable in two ways:

Data exposure — A method uses parameters read from data files. Modders can change those values. Example: item weights stored in a data file. A player who wants weightless ammo just sets ammo weight to zero.

Method exposure — The entire calculation/function is exposed and can be overridden by modders. This is far more powerful. Instead of just changing ammo weight to zero, a modder could make the encumbrance calculation skip ammo entirely, or make ammo weight only count on hard mode, or double the weight of certain ammo types.

2.2. Stage 2: Exposing the Systems

For parameter data, this is relatively straightforward — the values live in files that get read in. For method overrides, it's harder and highly engine-dependent.

Tim describes how Arcanum handled this: every system had two script override points — a "can I do this?" check and a "do this thing" action. For items: can I pick it up / pick it up, can I wield it / wield it, can I drop it / drop it. For creatures: can the player be seen / they see them, can they enter combat / start combat.

The "can" overrides let modders prevent actions entirely (e.g., "Orcs can't pick up this sword"). The "do" overrides let modders add custom behavior (e.g., "if an Orc picks it up, they take damage"). This same pattern enabled things like artifact-level invisibility rings that override the "can see" function entirely.

The critical architectural requirement: Every way of performing an action had to go through a single choke point in the code, so the script override would always be checked. Every way of picking up an item went through one function. This is straightforward if planned from the start, but potentially very difficult to retrofit into existing code.

2.3. Stage 3: Making Exposed Parts Changeable

For data files, modders need to be able to edit them, and edited files must take priority over the originals. Ideally, you also let modders bundle their changes into a mod package that users can drop into a mod folder.

For method overrides, modders may need tools — potentially even a compiler if overriding with C scripts. Internal dev tools often assume they're on the company network (checking files into Perforce, filing bugs in Jira), so they may need to be made standalone or rebuilt entirely for home users.

3. Hidden Costs

3.1. Performance

Validating mod data on load slows the game down. Many of Tim's games turned off validation checks when going from debug to release builds for speed. This creates a dilemma: do you leave mod checks enabled in the shipping game (slower), or add a special "mod test mode" that re-enables them?

3.2. Error Handling

Internal error messages like "illegal script code — see Dave" work fine for a dev team but are useless to modders. You may need an entirely separate error reporting system for mods. Bad models or textures from modders can crash the game, and bulletproofing against all of that takes significant effort.

3.3. Documentation

Internal documentation may reference company-specific tools and workflows that aren't appropriate to externalize. Some docs can be reused, some must be rewritten from scratch for modders. Modders need to know things like required animation states for creature models, texture size constraints, and data format requirements.

3.4. Opportunity Cost

For a game with a fixed timeline and budget, every hour spent on moddability is an hour not spent on other features. Tim references his "design fallbacks" video — if you want to add one thing, you may have to cut something else.

4. Plan From the Start

Tim emphasizes that moddability should be decided before writing a single line of code. Retroactively converting a game to be moddable means rewriting code that already works flawlessly, just to route everything through choke points where modifications can be checked. This is enormously expensive.

5. Conclusion

Adding moddability is not a no-brainer. Anyone who claims otherwise is either inexperienced or trying to talk you into something. It requires three stages (make systems exposable, expose them, make exposed parts changeable), each with significant engineering, tooling, documentation, and testing costs. Whether moddability is worth it depends on your game's goals — it should be a deliberate architectural decision, not an afterthought.

Source: Tim Cain — "The Cost Of Moddability"

6. References