Skip to content

The Name Problem

In a virtual world, you are represented by, represent, or are an individual. The world fiction may pretend otherwise, for example, by allowing hive minds (for example, ant nests) or shared-mind couples (for example, Tweedledum and Tweedledee), but these are mere conceits. You are associated with a single, sentient game object: your character 1. So that people can refer to your character in conversation and commands, that character must have a label; in other words, a name.

MUD1 allowed players to have the same names, as long as they weren’t logged on at the same time. This rapidly led to problems of mistaken identity (and, to a lesser extent, impersonation). Permitting only one person with a particular name to be in the virtual world at any one time was no help: Players could find themselves locked out that way. The solution adopted was to allow only one instance of any name in the entire virtual world. There were still occasional problems when a character was killed and someone stole its name before the original player had recovered enough to return, but these were only isolated incidents that could be handled by administrators on a case-by-case basis.

On the whole, this is how virtual worlds are still designed today. There are implementational reasons why two characters 2 with the same name should not be allowed into a virtual world at the same time (it makes parsing and communication so much easier), and disallowing name clashes 3 for offline characters, too, is essentially a customer relations requirement (although there are other benefits to do with helping engender a sense of identity).

Virtual worlds with large numbers of players rapidly run out of decent names. It’s not a problem that dogs only virtual worlds, of course—it’s far worse for URLs, AOL account names, and Hotmail email addresses—but that doesn’t mean it isn’t an issue. The designers of Ultima Online anticipated that names would be in short supply, so they took the decision to allow them to be non-unique. To stop lock-outs, people with the same name could both play at the same time. Impersonation and communication evils ensued. Both were fixable while retaining non-unique names, but only with immersion-breaking solutions. The graphical virtual worlds that immediately followed did not make the same mistake, and used unique names from the beginning.

This still meant that there was a shortage of supply, of course: If you have 400,000 players, they need to have 400,000 names (and more if they have multiple characters). An obvious compromise is to limit uniqueness to server cluster (that is, to an individual incarnation/shard). With 40 servers, players’ imaginations need only stump up 10,000 different names, which is far more tractable. Sure, some other guy might be using your name on a different server, but your friends are all on this one.

How to choose a name? Players identify more with their characters if they get to choose the names themselves; name selection is the first and arguably most important decision concerning their virtual identity that a player can make. Giving them a free hand, though, can be tiresomely fiction-breaking (Robinhood the elf is here). It’s a problem: Randomly select any virtual world with a policy of free naming and the chances are there will be someone called “Gandalf”—irrespective of the genre.

One solution, hinted at previously, is to use a restrictive naming policy. Administrators vet prospective names. This is practical and very effective in virtual worlds with strong role-playing elements, because in explaining why their character has the name it does, a player must necessarily flesh out that character. It’s a barrier to entry, though: If someone tries to play your virtual world and finds there’s a 10-minute delay while you okay the character name, they’ll go somewhere else that doesn’t have a 10-minute delay. It’s also way too expensive to implement for virtual worlds that have thousands of newbies arriving every day.

A way to preserve an element of choice, while limiting the freedom to choose something unfortunate as a name, is to use name lists. The idea is to present players with a list of, say, 10 or 20 available names, and let them pick which one they want. If none of them really suit, another list can perhaps be presented, until all the options are exhausted. Players could still be given the option to enter a freeform name and wait for it to be vetted, but they wouldn’t have to do so.

There are a number of ways that name lists can be generated. The most obvious one is to do it randomly. This has to be good to work: EverQuest tried it, but it wasn’t and it didn’t.

Another way is to use the context of the virtual world to present possibilities. This is used sometimes in pencil-and-paper role-playing games. The idea is that the character’s name is built up from syllables that have a meaning in some ancient language supposedly spoken by the character’s people. A typical arrangement is to have an opening syllable, one or more middle syllables, and a closing syllable. An elf might thus choose “Ard-la-shi-sa” meaning “tree-of-silent-spirit,” whereas a dwarf (using a different set of syllables and ostensible meanings) might pick “Khad-rak-uz” meaning “Stone-strongbeard.” These are fun for designers to design and for players to play with, but you have to be careful—I once managed to get Fu-qu-az-ole out of one of these.

Using such pseudo-cultural definitions for names, it’s possible to re-introduce a modicum of non-unique naming. If players are given a surname based on their character’s race/class/gender/ whatever, then they might be able to choose the same first name as someone else with a different surname. If Urk Wolfhead and Urk Sharpspear play at the same time, either can be referred to as Urk by other members of their tribe or by people in the same general location as they. Only when someone from a different tribe wants to reference one rather than the other does the surname also have to be used (adjectivally). This is a neat solution that allows for some degree of choice while preserving the decorum of the virtual world.

Names are referents, but they are not the only ones. Hey, you know that charismatic, short, French general who conquered half of Europe in the early 1800s? Well yes, of course you do—it was Napoleon Bonaparte. I didn’t have to give you his name before you knew who he was, though, did I 4? There is an argument that virtual worlds should allow this kind of relative description for characters, and that it should be preferred until you’ve actually been introduced to someone (or told who they are by someone who already “knows”). The rationale for this is that in the real world people don’t walk about with their names tattooed to their foreheads, and therefore neither should characters in virtual worlds. The counter argument is that having to refer to someone as “The Tall Stranger” the whole time gets in the way of interactions—even if it eventually encourages people to interact by asking each other their names. As with many real-versus-virtual arguments, both sides have a point, and it’s ultimately up to designers to decide how they want to handle the situation in their own virtual world. Most of them go with the see-the-names approach, because it’s easier on newbies. If people complain, they can always produce some fiction to explain it away (“All player characters are by definition heroic, therefore they’re also famous, therefore everyone knows who everyone else is already”).

Relative names illustrate a point that game designers often forget: Names are owned by an individual, but used by everyone else. If “The Tall Stranger” won’t tell me his name, I may just decide to call him Lanky: I can invent names for other people. In MUD1, killers would give themselves hard-to-type names like Mmnmnnmn so that people would have a hard time casting spells on them, stealing goodies from them, and so on. I got round this by using pronouns, although this was not itself without problems. In particular, you might type something like “sleep him” then just as you were hitting return a friend would appear and change the binding for “him.” MUD2 added the ability to create synonyms for players and objects, so that once you (or anyone else) had typed “syn Mmnmnnmn as “Mm,” you could thereafter refer to Mmnmnnmn as Mm.

Why stop there, though? Why not allow players to annotate one another? Most people see, “Jay says, ‘hello’”; you see, “Jay the boring creep says, ‘hello’.”

This raises the issue of how players annotate themselves.


  1. Or avatar or persona, but these generally lose out to character in discussions for which immersion is not an issue. ↩︎

  2. It’s actually stronger than this: No two objects should have the same name (identifier). ↩︎

  3. Names don’t have to be exact to “clash,” just similar enough that at a glance you could mistake one for another. ↩︎

  4. If I did, you should have paid more attention in history class. ↩︎