Player name pipeline review

Follow the name beyond the entry screen

A player can choose a name successfully and still lose it later. The interface may display one string, the save system may derive another, and a returning scene may use a third. Reviewing only the entry screen misses the boundary where those values separate. This workbench follows exact creator-supplied examples through a declared sequence, retaining the original display and each fixture ID throughout.

Its question is practical: which operation changed, rejected or collapsed these examples? It does not rank names or decide whether a person deserves a spelling. A storage design that maps two displays to one identifier has made a technical choice. The resulting collision is a reason to inspect that choice before proposing that either player must rename their character.

Use the tool while defining a game's naming contract, reviewing a save migration proposal or preparing a small handoff between narrative and engineering. It models only the operations you enter. It does not connect to an engine, inspect existing saves, measure a real read-back or prove that a production database preserves identity. Those checks require the actual destination. The fixture report makes that later integration test more precise.

Start with the destination you want to preserve

Write down three separate promises: what the player sees, how the system identifies the record and which text should return in a later scene. They can use different values. The display might remain exactly Mira while a stable internal identifier uses p1. Another character can retain mira with identifier p2. In this worksheet those fixture IDs are explicit examples, not freshly generated production account identifiers.

Each fixture contains an ID and an exact display string. Spaces, capitalization and combining characters are retained. An empty string is allowed as a deliberate boundary test; add an explicit length check if your proposed contract rejects it. The worksheet accepts at most fifty fixtures, with each display bounded to two thousand UTF-16 units. That input bound protects this local worksheet and does not establish your game's permitted name length.

The defaults include Mira, mira, a display with surrounding spaces and a short combining-mark example. These are original technical fixtures. They are not names collected from players, evidence of demand or observations about a language community. Add your own project cases, including repeated visible names with different IDs. Repeated displays do not authorize the software to merge two characters.

Original fictional scene: two lanterns at the checkpoint

The following is an invented game scene and interface problem, not a report of an implemented game or a player study. In a cooperative festival adventure, two travelers reach a bridge where an attendant records the lantern each has repaired. One signs Neri, with a capital N. The other signs neri. Their choices appear separately above their characters and on the bridge's small noticeboard.

Neri repairs the blue lantern and takes a route through the market. neri repairs the amber lantern and waits for the evening ferry. Later, both return to the checkpoint. A proposed save design has used a lowercased display as the record key. The two repair records have been assigned the same key. The return scene therefore cannot reliably tell which repaired lantern belongs beside which arrival.

The attendant's line, “Your amber light is still burning,” seems friendly. For Neri it attributes someone else's action to the character. Changing that line to avoid the name would conceal the symptom while leaving the two records entangled. Forcing neri to select another display would make the player's choice pay for a storage assumption that the story never required.

The revised design retains each chosen display and gives the travelers different internal record identifiers. The noticeboard keeps its two signatures. The blue and amber lights can now acknowledge different histories. The names matter because the game promises continuity between a player-authored identity and a remembered action; the repair belongs to the key contract, not to the legitimacy of either signature.

If both travelers had deliberately chosen Neri, the identity requirement would remain. A visual duplicate is not a license to merge save records. If the story instead required one shared ceremonial title, that shared display could be authored while the records remained separate. Apply the method by asking what must stay the same for the player, what may be technically derived and what the returning scene must distinguish.

Build a small explicit graph in an ordered list

Stages appear in execution order. Each has an ID, a source named from and a supported operation. The source is raw or an earlier stage. Later references, cycles and duplicate stage IDs are rejected. This lets a display branch and a key branch share the original input without pretending that every operation belongs in one destructive chain.

The supported operations are identity, trim, lowercase, normalize, length, truncate and fixtureId. identity passes its source through unchanged. trim and lowercase use the host's ECMAScript string methods. normalize requires an explicit NFC, NFD, NFKC or NFKD form. The ECMAScript specification documents those string operations; this model does not substitute a locale-specific lowercasing policy or full Unicode case folding for lowercase.

length validates a minimum and maximum without changing the string. truncate changes the string to the declared maximum. Both require either codepoint or grapheme as the unit. A grapheme here is a segment produced by the host's Intl.Segmenter, not a promised glyph width or syllable count. Unicode's segmentation guidance explains the distinction; runtime data and your destination may differ. Test the destination separately.

fixtureId explicitly outputs the fixture's stable ID after its declared source is available. It illustrates separating an identifier from a display. It does not allocate IDs, query account records or certify that your real ID generator is unique. No transliteration, replacement, trimming or normalization is appended silently. Unsupported operations and unexpected stage properties produce a conflict rather than executing arbitrary code.

A worked comparison: repair the key, retain the choice

Run the defaults and inspect the two Mira fixtures. Both pass inputCheck. keyTrim preserves the first pair while removing the surrounding spaces from the Kiri example. key converts Mira and mira to the same value, mira. The declared key collision group lists p1 and p2, and each retains its own raw display, trace and result card. The loadedDisplay branch reads raw, so the entered expectations for the first pair still match.

Now append a stage with ID stableKey, source raw and operation fixtureId. Set keyStage to stableKey. The proposed keys become p1 and p2; the display and return branch need no alteration. Comparing the before and after reports shows a changed identification policy rather than an editorial preference for one capitalization. Keep both reports if you need to explain the decision to a collaborator.

This is a model comparison. A success result means the supplied fixtures produced no modeled rejection, key collision or known return mismatch. An omitted expectation remains unknown even in a success result. It does not mean the full product is ready to ship. The private handoff includes the declared stages, selected destinations, reservations, exact traces and limitations so an engineer can reproduce the bounded exercise.

Ordering changes the promise

Consider the exact input “ A ” and a maximum of one code point. A length check directly on raw rejects three code points. A trim stage followed by the same length check passes A. Neither result is a random draw: the order changes what the validator examines. Decide which promise the entry screen should make and reproduce that same policy at the relevant boundary.

A rejected stage records its candidate, measurement and reason. Dependent stages are blocked and produce no available output. Independent branches can still succeed. For example, a reserved key need not erase the raw-display branch. The overall result stays partial when a stage rejects, even if a separate selected key exists. You should not mistake a usable branch for an entirely passing contract.

Reservation records specify an existing stage, an exact value and an authored reason. They use exact equality: a reservation for Mira does not silently reserve mira. Put a case-changing stage before the reservation if that is the policy you intend, then check the resulting trace. A project's reserved label is not a universal prohibition, a cultural judgment or a claim that a word is legally unavailable.

Read collisions and return states carefully

Collision groups compare available outputs at the selected key stage, even when an independent branch has failed elsewhere. Unavailable keys are excluded; an available empty key is still a value and can collide. The report preserves every fixture ID in a group. For each pair it also shows whether the raw displays already matched and the earliest declared stage with equal available outputs. With branching, that earliest equality is a clue to inspect, not automatic proof of a causal path into the selected key.

Expected returns are explicit fixture/value records compared at returnStage. match means exact modeled equality. mismatch shows both values. unknown means the fixture has no entered expectation. unavailable means an expectation exists but the selected return stage could not produce a value. None of these states is an observed engine save/load result. Avoid turning a carefully modeled comparison into a claim about an integration you have not run.

Inspect the expandable trace on each card. JSON-quoted strings expose surrounding spaces and distinguish an empty string from an unavailable value. Copy preserves the raw display. Saving and comparing retain separate fixture contexts, including identical visible names. A private export can contain project strings and the complete pipeline; review it before sharing rather than treating it as an anonymous public name list.

Choose the next test from the failure

If the worksheet reports a collision, first ask whether the selected key should be derived from a visible name at all. If it reports a length rejection, inspect the declared unit and source before increasing the limit. If a return expectation mismatches, compare the return branch with the promise shown on the entry screen. If a branch is blocked, repair its first rejecting ancestor instead of filling downstream gaps with guessed values.

Then carry the exact fixtures to the actual game. Verify the intended input method, serialization, storage, retrieval, dialogue and interface surfaces. This workbench has not tested those systems. It also does not perform abuse moderation, spoofing analysis, trademark checks or cultural review. A technical trace should help the team ask narrower questions, while the final naming decision still respects the player's visible choice and the story's need to remember distinct actions.

Use the dialogue-slot tool when the next question concerns how supplied forms enter an authored sentence. Use the glyph ledger when a production asset lacks a required character. Use the technical identity registry for fictional units and their serials. Those are connected tasks with different rules; a pipeline pass does not answer them automatically.

Does a success result prove my game saves names correctly?

No. It traces declared operations on the supplied fixtures. Actual input, serialization, storage and read-back require a destination integration test. Missing expected returns remain unknown even when the model has no known failure.

Must two players with equal keys choose different names?

Inspect the identification contract first. The explicit fixtureId branch demonstrates a separate key without altering either raw display. It does not allocate production IDs or prove your real identifier generator is unique.

Does lowercase implement every language’s matching policy?

This operation is ECMAScript toLowerCase. It is not full Unicode case folding or a locale-specific matching policy. No other transformation is added silently. Define and test the actual destination policy separately.

Can this reject offensive names or certify cultural fit?

No. Reserved values are exact project declarations with authored reasons, not a moderation dataset or a universal prohibition. Cultural review, abuse handling, spoofing analysis and rights checks are separate tasks.