SLINGLONGPlan for the smallest useful label
A player accepts a quest from Captain Elvaren Stonewake, sees Stonewake in a conversation log, and opens a marker labeled Captain Elv. They have three clues that could identify the same person. If the game has not established that relationship, the labels feel like three separate entities. A name that works in a spoken introduction also has to fit the places a player uses to act. Those places may include subtitles, inventory labels, quest objectives, maps, and roster rows. The design task is to connect them without asking the player to memorize every formal title.
List the surfaces that matter to your project before you choose a final spelling. For a conversation-heavy game, begin with the speaker label and the quest log. For a map-driven campaign, begin with the map pin and the instruction that sends the player there. A tabletop handout can have the same constraints as a game interface. A card printed in a narrow column may lose the end of a name even if a character’s introduction sounded clear. Decide which surface has the shortest useful space and test the names there early.
Separate an internal identity from player-facing forms
Keep one stable identifier for each person or place in your notes or project data. An identifier can be plain, such as east-ferry-keeper. It does not need to appear in dialogue. Give that entity a full name, a display name, and any spoken calls that matter. These forms have different uses. A formal introduction can use the complete name. A dialogue header can use a short form the player has already learned. A particular character may speak a nickname. When the project refers to the same entity through its identifier, revising a display name is less likely to create a second copy of the person or disconnect a quest from its destination.
Do the same for locations. A site may be formally called the Crown Landing at Lorport while the map says East Landing. In a quest log, “Meet Ivara at East Landing” connects a known person to the label on the map. A charter shown during the conversation can preserve the longer name. Give the two forms a shared first appearance if the story will later ask the player to verify an official document. A caption that says “Crown Landing at Lorport, now marked East Landing” can be sufficient. After the relationship is established, the game can use each label where it belongs.
Record who is allowed to introduce a nickname. A party member who knows the captain may call them Elv. A clerk might use Stonewake. If the interface displays Elv before any speaker uses it, players may assume it belongs to someone else. The display can adopt a familiar call after it is established in a scene. You can also keep a full name in an inspectable profile. This leaves room for character voice while giving the player a reliable place to check what the nickname refers to.
Test labels in their actual neighbors
Look at the shortest version of each name next to the names around it. Two inventory entries can both start with “Shield of” and differ only in the last few letters. Two quest destinations might have the same road prefix. If the distinguishing material is truncated, changing the type size may reduce readability without solving the basic naming choice. Try putting the important difference first. “Reed Bridge seal” and “East Landing seal” identify the items before the common word. The long description can explain that both belong to the same authority. This ordering also makes it easier to read aloud when a player asks which item to use.
Check the form on the map, in a list, and in the action line. A location labeled only Gannet may work as a pin when its icon clearly shows a tavern. In a quest line spoken without the icon, “leave the parcel at Gannet” may sound like a person. Use Gannet Inn in the instruction or establish the shorthand in dialogue first. A role tag can solve similar problems in a roster. A short note such as ferry pilot can distinguish an entry even if another character shares a close name. The player should be able to act from the interface where the choice occurs, with extra details available when they want them.
Use a real narrow display for the test. Browser resizing, a smaller phone, or a mockup at the actual card width will show where line breaks happen. Record whether the important words survive the first line, especially when a quest log folds long entries. If the form wraps, check that the next line still clearly belongs to the same entry. If there is clipping, check whether two labels become identical. Give someone the task of finding one destination or character without opening profiles. Their wrong turns tell you which differences the interface hides.
Match voice dialogue to readable text
A voiced scene can use a call that differs from a formal name. In a rescue, a companion shouts “Vath, hold the bow,” while the subtitles identify the speaker by a full commission name. If Vath is the listener rather than the speaker, the caption still has to let players understand who is expected to act. A prior scene can establish the shortened call through a handoff. Alternatively, the quest log can name the person directly after the exchange. Keep the spoken call and visible label connected before the game asks someone to choose between two possible responders.
Test a scene without sound and a scene without looking at the map. A player using only subtitles needs a way to tell that two spoken variants refer to the same character. A player listening while exploring needs a name that can be heard and repeated. Read the instruction at a natural speed. If the call sounds like a command or the first stressed sound of another name, revise the line or the shorter call. If a visual label is clear but difficult to say, you can keep it for an inscription while providing a more practical spoken form. Document that difference in the script so it remains consistent across recordings.
For text in more than one language, test the complete translated line as well as the name. A line break that worked in one version may hide a feature word in another. A title may need a different word order when spoken naturally. Keep your stable entity identity and choose labels that communicate the same destination or role in each version. If an invented name remains unchanged, provide a pronunciation cue for the person recording it where that is useful. If the displayed form changes, check that the quest objective and map still use the same visible label for the same place.
Work through a quest with a moved landing
The original quest says, “Deliver the seal of the Crown Landing to Captain Elvaren Stonewake at Lorport.” On the map, Lorport is the village and the old Crown Landing has been removed. A new ferry pin reads East Landing. In dialogue, an apprentice calls the captain Elv. A test player walks to the village marker and opens the roster to look for Elvaren. The story requires a trip to the ferry. The instructions need to carry a reachable place and a recognizable person, while the official form can remain in the seal’s description.
Revise the objective to “Give the crown seal to Stonewake at East Landing.” The map pin and objective now use the same place label. Put the complete commission in an inspectable entry and give the apprentice a line such as “Stonewake is at East Landing. We call her Elv at the ferry.” The player can now connect the informal call when they reach the site. If the official seal refers to the previous landing, explain that on its item description or let a clerk show the dated change in conversation. The historical detail remains available without deciding the next turn for the player.
Test two paths through the quest. In one, the player reads the objective immediately and goes to East Landing. In the other, they first hear the apprentice’s dialogue and approach from the old road. Both should identify the captain and a usable route without receiving an extra explanation from you. If the player takes the seal to a second office, check where that alternative office was labeled and whether the quest text accidentally reused its title. A map audit and a roster audit solve different problems. Record which surface needed the change so a later revision does not undo it.
Decide what changes after a title is awarded
A new title can mark progress. When a dragon becomes the Crossing Keeper, your game might show the new form in the council record and keep its short call in the speaker label. Decide when the new form becomes visible. If the player has not seen the scene that confers it, displaying it early may reveal a story event or make them think a different creature has appeared. Record the condition that triggers the change. Check older entries and saved references to see which form they should retain. A historical log can preserve the previous title while the current roster uses the new one.
If you are writing a project without runtime state, you can still test the change through successive handouts. Make an earlier roster and a later one. In the second, mark the title’s effective date and keep one clear short call that appears in both. Ask someone to find the same entity in both versions. If they recognize the name only through a hidden author note, add a visible connection in the story. A successful title change should be legible to someone who returns to the project after several days, not just to the person who wrote the data.
Prepare a small acceptance test
Pick one recurring person, one location, and one object that shares a root with either of them. Write the full form and the shortest display form for each. Place them in a subtitle line, an objective, and a map or inventory list. Then give a reader one task: follow the objective, choose the right entry, and tell you whom or what they expect to find. Repeat with voice only if your project uses voice. Record whether each wrong choice came from a missing cue, a collision, or a history the reader had not yet learned. Each cause calls for a different repair.
Finish by updating the same names wherever they need to match. Verify the visible labels on a narrow display and in the other language versions your project actually supports. Keep alternate forms where a speaker or record has a reason to use them. A name system that passes this check can support stories with titles, aliases, and changing maps while keeping the next action clear. The point of the short label is to give the player confidence that the door, person, or item they choose is the one the story asked for.
Make the next search work too
If your game lets players search for people or locations, try the name they are most likely to remember after leaving the scene. A player may search for Elv even if the roster displays Stonewake. An established alias can return the same character record and show the current display name. A historical term can return a relevant entry with a note identifying the modern place. Consider which aliases a player has actually learned. A search result that reveals the dragon’s future title or a secret identity can expose a connection before its intended scene. Decide whether those terms should be searchable from the beginning or only after the corresponding discovery.
Repeat the test after deliberately changing the displayed name of one character. An old objective may still name the former office, while a current directory should show the new one. Open a saved reference or use an earlier handout as a test fixture. Check that the old label still identifies the correct entity and that the player can find its present location. This is a practical reason to retain both forms in project data and choose the visible version by context.
Include one unfinished objective in that test. A player returning to an interrupted quest needs the old instruction to remain actionable, even if its display text is refreshed to match the current map.