Every game teaches you its own language before it teaches you its rules. You learn what a “check” is in chess not by reading the FIDE handbook but by hearing someone say it the moment a king is threatened—and then by using the word yourself the next time you see the same configuration. The word arrives before the full understanding. Over time, the two fuse until you cannot separate them. This is not a side effect of learning a game. It is the primary mechanism.
Most indie developers understand naming as a lore problem. The NPC needs a name. The item needs a name. The stat needs a label. These are checkboxes on a spreadsheet, filled in during a polish pass, often borrowed from a thesaurus or a fantasy name generator that gives you something pronounceable and forgettable. But the best indie games treat naming as a systems design problem—one that determines how players categorize, predict, and reason about mechanics before they fully understand them. A well-named system is a cognitive interface. A poorly named one is a speed bump the player hits every turn.
That same discipline applies to naming decisions: before publishing, editors need a way to test labels, roles, and public-facing language stay consistent, which is where ways to generate character names for the project can function as a planning aid rather than a substitute for domain evidence.
The Name Is the First Rule the Player Learns
Consider Disco Elysium. The game’s skill system is not a set of numbers. It is a set of characters. “Inland Empire,” “Electrochemistry,” “Shivers,” “Volition”—each name is a compressed argument about what that skill does, what it cares about, and how it will betray you. When you see “Electrochemistry” on your character sheet for the first time, you do not yet know that it will speak to you in a voice of chemical need, pushing you toward substances and sensations. But the name primes you. You form a hypothesis. You are already reasoning in the game’s vocabulary before you have read a single line of skill dialogue.
This is not accidental. Robert Kurvitz, the game’s lead writer and designer, has described the skill system’s evolution from a conventional Fallout-style SPECIAL knockoff into what he called “a parliament of personalities.” The naming pass was not cosmetic. It was the moment the system became legible as something other than a spreadsheet. “Endurance” tells you nothing about how a character thinks. “Volition” tells you that this skill has opinions about your willpower and will argue with you when you are about to give up. The name is the first rule.
Now compare this to the number of indie RPGs that ship with skills named “Strength,” “Dexterity,” “Intelligence.” These names are not wrong. They are inert. They carry no argument. They tell the player: this is a number that goes up, and going up is probably good. They teach the player to optimize, not to think. Disco Elysium’s names teach the player to listen, because every name implies a voice with its own agenda. The mechanic and the name are the same object.
When the Name Is the Mechanic: Outer Wilds and the Vocabulary of Discovery
Outer Wilds does something more radical. It names its systems so carefully that the player cannot distinguish learning a word from learning a rule. The game’s central verb is “understanding.” There is no progression, no inventory, no leveling. You gain access to new areas by learning new concepts, and you learn those concepts by reading the names of things other characters have already categorized.
The Nomai are not just an ancient alien race. They are a civilization whose entire epistemology is encoded in how they name things. “Quantum Moon” is not a label. It is a puzzle compressed into two words. The moment you read it, you know three things: the Moon exists, it has something to do with quantum behavior, and you do not yet understand what that means. The name creates an information gap that drives the next five hours of play. “Anglerfish” is a name that teaches you fear before you see the creature. “Eye of the Universe” is a name that teaches you awe before you understand what it is.
The ship log—your only record of progress—organizes these names into a web of speculation and confirmation. You are not collecting items. You are collecting nouns. Each new noun is a tool that lets you ask a more precise question. When you learn the word “bramble,” you start seeing bramble everywhere. When you learn the word “warp core,” you start understanding the difference between the Nomai’s technology and yours. The game’s vocabulary is its progression system, and the vocabulary was designed with the same care most developers reserve for combat timing.
The developers at Mobius Digital have spoken at GDC about how the ship log went through multiple iterations before it became the rumor-triangulation board that shipped. What they do not emphasize enough is that the log works because the names inside it are load-bearing. If the Quantum Moon were called “Anomaly 7,” the log would be a spreadsheet. If the Anglerfish were called “Predator Type A,” the dark bramble would be a hazard, not a horror. The names do the cognitive work that a tutorial system cannot.
Names as Predictive Models: Slay the Spire’s Card Archetypes
Slay the Spire demonstrates a different function of naming: the name as a predictive model. When you see a card called “Perfected Strike,” you know three things before you read the text. You know it deals damage. You know it has something to do with other cards that contain the word “Strike.” You know that the word “Perfected” implies this card is the culmination of a set. The name teaches you to look for a pattern. The mechanic—dealing damage equal to two times the number of cards with “Strike” in your deck—then confirms the pattern the name already suggested.
This is not unique to Slay the Spire, but the game is unusually disciplined about it. Every card name in the Ironclad’s kit implies a relationship to other cards. “Anger” returns to your hand, suggesting a grudge that will not leave. “Clash” cannot be played if you have any energy-cost cards, suggesting a reckless commitment to the moment. “Havoc” plays the top card of your draw pile for free, suggesting chaos you do not control. The names are not thematic garnish. They are heuristic anchors that let players build mental models of deck archetypes before they have played enough to verify those models empirically.
Contrast this with a card simply named “Deal 6 Damage.” The name tells you exactly what the card does and nothing about how to think about it. It is legible but inert. Slay the Spire’s naming convention produces cards that are slightly less immediately legible but significantly more strategically generative. The player who reads “Perfected Strike” and thinks “I should collect Strikes” has just independently discovered an archetype. The name did the teaching that three tooltip pop-ups and a tutorial screen would have done worse.
The Naming Decision You Make Before You Understand the System
Here is the problem that most design writing ignores: naming is a problem of timing. You need to name a variable, a character, or a mechanic before you fully understand what it does. You are prototyping. The system is half-built. You need a label so you can refer to it in code, in design docs, in conversation with your collaborator. The name you choose now will shape how you think about the system during the rest of development. If you name it badly, you will think about it badly. If you name it well, the name will do some of the design work for you.
This is not a game development problem. It is a systems design problem. The Federal Reserve Bank of St. Louis maintains FRED, a public economic data platform where every time series name encodes measurement methodology, geographic scope, and temporal frequency—”CPIAUCSL” tells an economist that they are looking at the Consumer Price Index, All Urban Consumers, All Items, Seasonally Adjusted, before they examine a single data point. FRED’s curated taxonomy of economic time series demonstrates how naming conventions function as cognitive interfaces: the name lets economists reason about data relationships before they examine the raw numbers. The same principle applies to game systems. A well-named mechanic lets the designer reason about the system before it is fully built, and lets the player reason about it before they have read the rules text.
The parallel to regulatory terminology is instructive. The SEC’s investor education materials introduce terms like “compound growth,” “asset allocation,” and “diversification” not as jargon but as teaching interfaces—each term compresses a mechanism into a name that primes a correct mental model before the investor fully understands the underlying math. Introduction to Investing at Investor.gov demonstrates how naming decisions are early-stage system design decisions: the term “compound growth” teaches the investor to think about time as a productive force before they have internalized the exponential math. The name is the lesson. The formula is the confirmation.
Game developers do this intuitively when they are good at it and badly when they are not. The indie developers who nail naming usually do so during prototyping, not during a polish pass. They name the thing before they understand it, and the name helps them understand it. The developers who botch naming usually do so because they treat it as a final-stage task—a coat of paint applied after the system is already built. By that point, the system has been shaped by whatever placeholder name was used during development, and the placeholder has already done its damage.
Placeholder Names Are Design Decisions
Every developer has used placeholder names. “TempStat.” “NewMechanic2.” “EnemyTypeA.” These names feel neutral. They are not. They are arguments that the thing they describe is generic, interchangeable, and unworthy of attention. They tell the developer: do not think about this yet. And so the developer does not think about it, and the system develops without the cognitive anchor that a real name would have provided.
I have seen this failure mode in postmortems from small teams. A designer describes a mechanic that never quite clicked, and when you trace the development history, you find that the mechanic spent eight months under a name like “Resource2” or “Secondary System.” No one on the team could talk about it precisely because it had no precise name. The discussions in design meetings were vague because the vocabulary was vague. The system was not bad. It was unnamed, and an unnamed system is a system you cannot think about clearly.
The counterexample is Into the Breach. Matthew Davis and the team at Subset Games named their mechanics early and with intention. “Grid Defense” is not a genre label—it is a mechanical thesis. The game is about defending a grid, and every system is named in relation to that grid. “Push” is not a status effect. It is a positional verb that tells you exactly what will happen and where the unit will go. “Vek” is a name that tells you these are not bugs, not aliens, not enemies—they are a category unto themselves, and the game’s mechanics treat them as such. The naming pass was not a polish task. It was part of the prototyping process.
When you are prototyping and you need to name something you do not yet understand, the friction is editorial, not technical. You can open a spreadsheet and type words until something fits, or you can generate character names through a tool designed to unblock your iteration without locking you into a premature commitment. The point is not to outsource your taste. The point is to reduce the cost of trying a name that might be wrong but might be right enough to teach you something about the system you are building. Treat the output as hypotheses, not answers—names to test against the system, not names to ship because they sounded good at 2 AM.
The Taxonomy of Naming Failures
There are three common naming failures in indie games, and each one has a distinct mechanical consequence.
The first is generic naming. “Health,” “Damage,” “Speed.” These names are not wrong, but they carry no argument. They tell the player what the number does and nothing about how to think about it. A game that uses only generic names is a game that has decided its systems are self-evident. They rarely are. The player who sees a stat called “Health” thinks: I should increase this. The player who sees a stat called “Grit” thinks: I should increase this, but I also wonder what kind of character has grit and what kind does not. The first player optimizes. The second player imagines. The name determined the cognitive mode.
The second is thematic naming without mechanical grounding. This is the opposite failure. A game names a stat “Soul Resonance” because it sounds cool, but the stat just increases mana regeneration. The name promises depth the mechanic does not deliver. The player learns that the game’s vocabulary is decorative, not load-bearing, and they stop trusting names as cognitive anchors. Every subsequent name the game introduces is discounted. This is the failure mode that produces players who say a game’s writing is good but its mechanics are shallow—they have learned that the vocabulary does not describe the system.
The third is naming that contradicts the mechanic. A card called “Healing Light” that deals damage. A status effect called “Blessed” that reduces your defense. These are not subversions. They are errors. A subversion is when the name creates an expectation and the mechanic deliberately complicates it in a way that teaches the player something new. An error is when the name and the mechanic simply disagree, and the player has to hold both in mind without resolution. This produces cognitive load with no payoff. The player does not learn the system. They learn to ignore the names and read the numbers.
The best indie games avoid all three. Their names are specific enough to carry an argument, grounded enough to describe the mechanic, and honest enough not to contradict it. This is not a high bar. It is a bar that most games miss because they do not see it as a bar at all.
What Indie Developers Can Learn From Treating Naming as Systems Design
If you are a solo developer or a small team, you have an advantage that AAA studios do not. You can name things early, change them often, and treat the naming pass as part of the prototyping loop rather than a final-stage task. AAA studios cannot do this because their naming conventions are locked into localization pipelines, marketing materials, and certification documents months before the game ships. The name that appears in the E3 demo is the name that ships. Indie developers can iterate on names the way they iterate on mechanics.
Use this advantage. When you prototype a system, name it before you understand it. Pick a name that implies an argument about what the system does. If the system evolves away from that argument, rename it. The rename is not a cosmetic fix. It is a signal that your understanding of the system has changed, and the new name will help you think about the system in its updated form. If you find yourself unable to name a system, that is diagnostic. It means you do not understand the system well enough to prototype it. Either build more and try again, or simplify the system until it produces a name.
The games that get this right—Disco Elysium, Outer Wilds, Slay the Spire, Into the Breach—are not games with better writers. They are games where someone on the team understood that a name is a rule the player learns before they learn the rules. The name is the first contact with the system. It shapes the mental model. It determines whether the player optimizes, imagines, listens, or explores. It is not lore. It is not flavor. It is the earliest stage of systems design, and it deserves the same rigor you apply to your combat loop, your economy, or your level structure. If your names are not doing work, your systems are carrying weight they should not have to carry alone.
