Abstract
Problem: What happens to game design ideas that get rejected not because someone had a better idea, but because they were deemed "impossible" to implement?
Approach: Tim Cain walks through several of his most ambitious design ideas that were shot down over his career — from a boss with its own save game to fully procedural worlds — and examines what "impossible" actually means when designers and programmers say it.
Findings: Most "impossible" ideas are really just impractical, unfamiliar, or unexplored. Programmers often say "impossible" when they mean "I don't know how" or "I didn't bother to look." Some ideas are genuinely ahead of their time, and a few remain forever in tension between technical feasibility and design wisdom.
Key insight: "Impossible" almost always means "impractical" or "I don't know how to do it" — rarely does it mean something truly cannot be done. The danger is that good features get cut not because they're infeasible but because no one investigated deeply enough.
The Boss With Its Own Save Game
In the game that would become Fallout (the "time travel magic dinosaur game"), Tim designed a mid-game boss — a wizard — who had his own save game. If you killed him, everything would rewind. He'd stand back up, hold up a little disc, and say "I'm on to you — I have save games too."
To truly defeat him, the player needed to invalidate his saves — either through a special ability, a device like a magnet to wipe the disc, or by destroying equipment in the room before landing the killing blow. The mechanic was technically feasible, but was rejected because there was no way to make it feel fair and fun to most players. Tim frames this as one definition of impossible: if most people are going to hate it, maybe you shouldn't do it, unless you're deliberately making a niche game.
Fully Realized Generated Dialogue
Tim wanted to expand Arcanum's generated dialogue system to a much larger scale. Dialogue would react specifically to: the exact armor you're wearing (not just "that's scary armor"), being nude, your identity, your past actions, and who the NPC is — a shopkeeper would react differently than a noblewoman.
Crucially, this generated dialogue would be interleaved with handcrafted dialogue, just as Arcanum mixed generated and handcrafted terrain. Tim emphasizes this as a key design principle: procedural and handcrafted content work best together.
The system would require AI — and Tim had this idea in 1998, long before LLMs. He envisioned neural networks handling both text generation and voice synthesis. The irony: what was once impossible due to technology is now possible but potentially unethical. Tim doubts this idea will ever be realized in the way he intended.
Procedurally Generated World Sections
Tim wanted worlds where level designers handcraft key locations (cities, dungeons, castles) while the rest is procedurally generated — forests, deserts, villages, wizard towers, cemeteries, ruins, caves, and monster lairs.
The vision extended to dynamic content: monsters based on location context (road vs. deep forest vs. cemetery), and repopulation over time (kill a wizard in his tower, bandits move in later because there's a road nearby).
What made it impossible in practice: roads, rivers, oceans, and railroad tracks. Tim never figured out how to procedurally generate long, multi-sector geographic features that looked good within the time constraints of 1990s hardware. All of these were hand-placed in Arcanum.
Tim credits Judges Guild modules from the 1970s–80s as major inspiration — books like Village Book, Castle Book, and Island Book that gave DMs rules for generating content on the fly alongside specific pre-made locations.
Major Permanent Map Changes
Tim wanted player actions to permanently alter the game world — destroyed buildings, leveled forests, not just a busted door or smashed chest. Every time he described this, programmers and artists said: "You're essentially asking for a new map."
Games like Red Faction have done this, but destruction becomes the entire game's identity. Tim identifies the core design problem: if everything is destructible, there's really only one way to play. Locked chests, sealed doors, and magical barriers all become meaningless when the player can just break through walls.
He draws a parallel to parkour mechanics: once you give players the ability to climb anything, they'll use it to bypass everything. If you then put invisible walls to stop them, players feel cheated. The mechanic reshapes the entire game around itself.
The Dual-Reality Children's Game
Tim designed a game where the player is a child in a post-apocalyptic world who perceives everything as a Candyland cartoon world (inspired by Adventure Time). When the character dies, the screen drains away and reveals the horrific reality underneath.
Implementation: every creature, wall, and prop would have two art versions — the child's perception and reality. Later in the game, the player could glimpse reality through drugs or special perks, woven into the storyline.
It was rejected as too expensive (double the art assets), too difficult, and too controversial — "you can't have a child as the main character who gets killed." Tim's response: "Did you play Limbo?"
Player-Constructed Classes, Perks, and Backgrounds
Tim's most ambitious character creation idea: let the player construct their own classes, perks, traits, and backgrounds during character creation. Not just picking from a list — designing the list itself.
Similar to Tyranny's spell constructor or Morrowind's class constructor, but taken further. A point-buy system would enforce balance: making a character who runs fast means they can't wear heavy armor. Perks would be player-designed bundles of good and bad effects, like Fallout's traits or Arcanum's backgrounds.
Tim's response to "it's impossible to balance": "Single-player game. I don't really care about balance that much." Despite this, he was told it was impossible because it had never been done.
What "Impossible" Really Means
Tim breaks down what people actually mean when they say "impossible":
- Designers and artists: "I can't do that" or "this tool doesn't allow it"
- Programmers: Usually "I don't know how to do it" — and sometimes "I didn't even bother to look"
He tells two pointed stories. In one, a programmer declared a feature impossible in their game engine — that afternoon, Tim found the feature highlighted in the engine's own demo code, complete with a named code chunk for exactly that purpose.
In another, a programmer said a feature was impossible, and Tim (not doing programming on that project) accepted it. After the game shipped, the programmer said "oh, I figured out how to do that." By then, the game had been redesigned around the feature's absence — a missed opportunity that couldn't be recovered.
Tim's conclusion: "Impossible" almost always means impractical. Rarely does it mean something truly can't be done. But there are also genuinely good reasons not to implement some features — the key is knowing the difference between "we can't" and "we shouldn't."