Content That Multiplies

Additive and multiplicative content#

There are two ways content can relate to a game.

Additive content sits alongside everything else. It's single-use: it can't combine freely with the rest of the game's content. The player experiences it once, and its novelty is gone soon after. A handmade level, a scripted boss fight, a story cutscene, a unique quest. Each one adds its own few minutes of play, and that's all it will ever add.

Multiplicative content is flexible, modular, swappable and combinable. It interacts with everything already in the game. Each new piece adds its own value and gives every old piece something new to combine with. One new weapon in a game where any character can carry any weapon, on any level, in any configuration, isn't one new experience. It's a new variation of every situation the game can already produce.

That's where the name comes from. Additive content adds up: ten levels give ten levels' worth of play. Multiplicative content multiplies: ten weapons, ten enemy types and ten level layouts give a thousand combinations, and adding one more weapon adds another hundred.

Please note that multiplicative content isn't a special category of thing, like "mechanics" as opposed to "levels". People sometimes describe it that way, as if levels, characters and items were always additive and only new mechanics could multiply. That's not it. In a game organized in a modular, interchangeable way, levels, characters, props, weapons, vehicles and items can all be multiplicative. It's about how the content is organized, not what kind of content it is.

Five weeks for five minutes#

Here's the difference in practice:

• With additive content, you spend five weeks making something that lasts five minutes.
• With multiplicative content, you spend five hours making something that lasts five weeks.

Additive content also has a cost that grows over time. Each piece often needs special rules written just for it, which means extra programming for anything complex, and it's still restricted in how it can work. Players consume it far faster than anyone can produce it, so a game that lives on additive content is a treadmill: the developer has to run faster and faster just to keep the game from emptying out. Because each piece expires so quickly, the author feels pressure about whether it was worth the weeks it took, unless it reaches a huge audience.

Multiplicative content gets the benefits of standardization and modularity. The content system is set up so each new piece naturally bends into almost any situation. That's why it's usually cheaper and quicker to produce, once the framework exists.

Additive content still has its place. It's the right tool when a project's purpose is to tell a very specific story or present a highly curated experience, as in the handmade campaigns from Chapter 13. But for any game whose purpose lives in its mechanics, I think multiplicative content is the future, and additive content will fade into that smaller role.

Levels that multiply: spawn zones#

Here's a concrete example, from a hypothetical game where you assault an enemy base with a soldier.

Instead of building a level with everything placed by hand, place zones on the level, in which items, characters and structures can appear when the level loads. Zones can be nested: sub-zones within a zone further randomize what ends up there. A rectangle zone is just an origin point plus a width and height; a circle zone is a center point plus a radius. The code picks a spot inside at random.

A static level offers no surprise after the first time. A zone-based level can have the player start anywhere, put the enemy base somewhere else each time, and shuffle the defenders into different places and numbers. Suddenly every playthrough is unexpected.

Then push it further:

• Do zones spawn one type of thing or several? How many of each?
• Do groups spawn in formation (a line, a circle, a curve, a square) or scattered? Facing the same way or different ways?
• Does everyone carry the same equipment, or is each individual different?
• Can a zone spawn nothing at all, or extra terrain instead of enemies?
• When the game picks a random range for something, make the range as wide as you can. Narrow ranges produce sameness.

Levels themselves can be modules too. In one of my designs, a game set inside the human body where you play as a medical nanomachine, the building block is a "room" (call it a scene, a level, a map, a location, whatever your engine calls it). Basic rooms are where things happen, and highway rooms are for traveling between them, with currents that push things around like a river. A generator connects rooms into a network containing only the parts relevant to the current mission, which keeps play focused and short. Combine the randomization inside each room with the randomization of the network, and one set of rooms gives an endless supply of campaigns that are never the same, but still have meaning, structure and context. Add one new room, and it shows up in all of them.

Characters and items that multiply#

Instead of a predefined character with fixed abilities, traits, clothing, armor and weapons, all of those can be handed out by a generator. You no longer fight the same named villain each time. You fight opponents who might have almost anything, in any configuration. Maybe they all have sniper rifles. Maybe only pistols. Maybe a mix.

For this to work, the character has to be built to accept anything. Design the character's hands to hold, use, stash, drop and throw any object, with context flags on the object deciding what it does (a held weapon, a consumable, an ability trigger, a stat changer). Then no item, ability or piece of equipment is bolted permanently onto anyone, and every new item works for every character, player and enemy alike.

Weapons, items, armor and equipment become multiplicative the moment they join the shared pool. Combined with randomization, the number of new combinations from even one added item grows enormously. Sometimes a single addition makes the game feel new all over again.

Structured randomness: the heuristics randomizer#

Randomness done lazily ruins all of this. Put "spawn anything anywhere" into a game and you get noise: every result technically different and all of them feeling the same. That's the famous "thousand bowls of differently colored porridge" problem. A thousand variations that nobody can tell apart in any way that matters.

The fix is what I call a heuristics-driven decision tree randomizer. It may well have another proper name (flowchart, decision tree, heuristics), but in code it's just a sequence of if/else statements arranged as a tree. The randomizer decides which way to lean first, and only then hands out the randomness. Things decided at a higher level influence things at the lower levels, like a butterfly effect that makes sense.

For the base assault, the questions might be:

1. How many defenders? Few, some, a lot?
2. How are they placed? As individuals, in groups, all in one place, a mix?
3. Close to what they guard, or far? By how much?
4. Are they healthy, damaged, or are some already dead when the battle starts? To what degree?
5. Are supplies near them or far away?
6. Primary weapons and sidearms, only sidearms, only grenades, only fists, a mix?
7. Is their mood aggressive or defensive? To what degree?

Some questions branch off into a subtopic that only makes sense for one answer, and then merge back. Others branch off entirely into a separate type of result. And at some steps, there's a small chance (say 0.01%, 1%, 5% or 10%) of introducing chaos, to spice things up.

The same structure works for whole environments. Let the generator first read the general environment, then decide what's common there, what's rare and what's an anomaly. In a desert, sand is common and abundant. An oasis is less likely. And very rarely, as a freak occurrence, there's a snowman, with a freezer next to it that explains how it got there and why it hasn't melted. Allow the freak occurrences. Just always support them with a reason the player can discover. That's the difference between chaos that delights and noise that annoys.

Done this way, randomness has logic, structure, origin and meaning. Every result feels like it came from somewhere, because it did.

Cheap, mass-producible content#

High-quality, complicated content is worthless if it's rare, inflexible, slow to make and one-dimensional. If making content becomes the bottleneck in your workflow, the game will never really thrive: long delivery times, nothing interchangeable, and inflated quality standards that make it hard for anyone else to help. Content is at the center of a game. If there isn't a steady flow of it, there isn't much to play.

So make content cheap to produce, for yourself and for anyone you might bring in later:

• Reduce animation frames. Fewer frames, cleverly used, often read just as well.
• Reuse graphics wherever possible. This is the good kind of reuse, the opposite of the padding kind in Chapter 18, because it makes more variety possible instead of disguising its absence.
• Draw in grayscale and tint in the engine. One sprite becomes any number of color variants, chosen by the game or the player at runtime. Shaders and other in-engine tricks can modify images on the fly.
• Keep the graphics needs of systems minimal. Design mechanics so they need as little art as possible to work.
• Make it easy to learn. Keep the barrier to making new content as low as possible, for others and for yourself. A pipeline only one expert can use is a pipeline that stops when that expert does.

The cheapest, most powerful customization there is: let the player pick a color tint for one to three parts of their character. Hair, armor, accessories, equipment, skin. That's all it takes. If the game has a gritty tone, restrict the palette to avoid harsh colors while still offering the whole rainbow.

Nothing hard-coded#

A multiplicative game has to be able to keep growing, so never build in a ceiling on how much content it can hold.

• In menus, prefer scrolling lists, drop-downs, content browsers and dynamically scaling bars over fixed buttons and slots. A screen with exactly twelve slots is a promise that the game will never have a thirteenth thing.
• In code, don't hard-code anything about content. Make it possible to swap even the main character, and how they control at a fundamental level. The player could be a human, a car, a helicopter, a dog, an alligator, a blob, a swarm of drones.
• In structure, don't tie content or difficulty to a fixed level order. Let levels shuffle. Make later levels different in style, not just harder.

Every hard-coded limit is a future overhaul waiting to happen, at exactly the moment the game is doing well enough to want more content. Avoiding it costs almost nothing at the start.

With content that multiplies, a game can keep growing for as long as anyone wants to keep adding to it. The next chapter is about giving it a structure that lets it.