Persistent NPC names

Generated names become persistent story data

An NPC’s name can appear in dialogue, journals, family records and a saved game. Recomputing it from a new word list after every update breaks continuity. This generator uses finite, versioned fictional component pools and a reproducible seed. Keep the accepted output in your project. A seed alone is not enough if the underlying corpus or rule ordering changes.

The grammars actually differ

River uses one set of given forms and family stems ending in -en. Ridge uses different given forms and -ak family construction. Coast uses another inventory and an -a family ending. Switching the grammar changes the eligible components and derivation, not just the title above the same random list. All three are invented project conventions. Their labels do not describe real communities or establish etymologies.

Locks and exclusions come before quantity

A locked family component replaces the generated family field while other components remain eligible for regeneration. String exclusions and exact-name exclusions have different effects. The generator applies them before selecting results, deduplicates within the batch and optionally against local favorites, and reports the remaining eligible pool. If twenty-four combinations exist, a request for thirty cannot honestly produce thirty unique results under the same constraints.

Fictional example: the renamed ferryman

A game update rebuilds a riverside settlement from a modified list. A ferryman receives a different surname, but the player’s journal still uses the old one. The repair is not to add another random seed. The game needs a stable person ID and a saved accepted name, or a truly pinned generation bundle including data and rule versions. The old journal may also need an explicit historical display policy.

What to save after choosing

Export the visible result with its seed and dataset version, and store the accepted identity in your own narrative system. This website is a naming workbench, not an automatic integration with a game engine or save file. Test migrations separately. If a character’s name changes because of a quest, update the display layer through a deliberate story event without changing the person’s resource key.

Read exhaustion as useful information

An empty result can reveal an exclusion that removes an entire suffix family, a locked component that violates every filter, or a uniqueness scope larger than the corpus supports. The report recommends a bounded change rather than silently loosening the rule. Increasing counts is not a substitute for designing a larger original grammar. After generation, compare the NPCs players will meet together; reproducibility does not guarantee that the cast is easy to remember.

Keep accepted identities when using reference components

Select the US reference-components option for a modern source-backed pool. This is separate from the authored fictional grammars: combining two source components does not identify a real person in the datasets. Prefixes, minimum published counts, locks and exclusions apply to new candidates. Accepted IDs and names are retained, not recomputed. The fictional family suffix is inactive in this mode, and the source archives have their own pinned hash. Keep the retained and newly generated counts separate. Source frequency is not a naturalness score, and the resulting bundle still makes only a bounded local uniqueness claim.

Decide what a generated identity must preserve

An NPC name is a piece of story state once the player has met the person. The same identity may own a shop, sign a letter, appear in a quest log and belong to a family. A reproducible generator helps create that state, but a generator is not the identity itself. Store an accepted name under a stable ID rather than treat every display as a new draw.

The workbench creates IDs with a chosen prefix and a sequence that avoids accepted IDs supplied in the persistence table. It keeps saved identities as accepted records and does not regenerate their components. New candidates are deduplicated against those names and the selected local comparison scope. This is a bounded project policy, not a worldwide uniqueness claim.

Choose a scope label that means something in your project: the port settlement, the northern region or the whole current cast. The label documents your intended boundary; the tool only compares the records you actually supply. Writing world in that field does not load every person who exists in the fictional world, much less every real name ever used.

Reproduce a versioned generation session

Select a fictional grammar, keep the seed fixed and generate a small set. The result includes given and family components, stable IDs, data and rule versions, and a derivation note. Repeating the same parameters and accepted-identity state should produce the same output. If you change the scope’s saved names, you have changed an input even if the seed is unchanged.

Save one accepted record in the persistence table, then change the authored family suffix for new results. The accepted name remains exactly as entered. Newly generated eligible family forms use the new suffix. A locked family component is stronger than the suffix override: it remains fixed while given components vary. This makes the precedence inspectable instead of letting the last random choice win.

An unsupported corpus version returns a conflict rather than quietly substituting the current data. Keep the existing accepted records and review a migration before creating new ones. The workbench does not contain every historical version of a future game dataset, and it does not claim to update engine save files automatically. Its bundle is a production artifact you can inspect and integrate.

Original fictional scene: the ferryman after the update

The player returned to the ferry after a game update. The familiar boat was there. So was the ferryman’s voice. The quest marker used a different surname.

In the journal, an earlier entry still told the player to ask for the old name. The interface appeared to describe two people who occupied one body and ran one route. Nothing in the story announced a rename.

At the production review, the writer suggested adding a line about marriage. The programmer asked whether that event existed anywhere else. It did not. The new surname had come from a reordered word list.

“Then it is not a story event,” the writer said. “We should not invent one to explain the bug.”

They restored the accepted identity record from the previous release. New inhabitants could use the revised grammar, but people the player had already met kept their saved names. The journal resolved its reference through the stable character key rather than searching for a display string.

Later, the writer did plan a deliberate name change for another character. That change received a quest event, updated dialogue and a decision about how historical journal entries would read. The same infrastructure could support it because accidental regeneration and narrative renaming had finally become different operations.

This is a fictional development story. It illustrates a continuity failure and an explicit repair; it does not describe a tested integration between this website and any particular game engine.

Why a new seed would solve the wrong problem

A different seed might happen to produce the earlier surname, but it would not restore the contract. Another data update could break it again, and other NPCs might change as collateral damage. The missing element is an accepted identity or a fully pinned generation bundle, not a more fortunate random draw.

Saving only the display string also has limits. If two characters share a name intentionally, using that string as a database key can merge their references. Keep the person ID separate. A title or surname may change while the underlying entity continues to own the same boat, relationships and quest history. The name is display state linked to identity, not a substitute for identity.

Conversely, if the author truly wants a newly generated replacement person after an NPC’s departure, preserve that distinction with a new ID and a story event. Reusing the old key would imply continuity the narrative does not support. The tool cannot decide whether a replacement is a new person or a renamed returning character from a string alone.

Treat finite pools honestly

The built-in fictional grammars are deliberately small enough to inspect. They are original construction examples, not demographic datasets. Switching grammar changes both component inventories and family construction. An override suffix changes the eligible family forms before exclusions and batch selection are applied. It must not be appended after selection in a way that creates unreported duplicates.

If twenty-four eligible combinations remain and you ask for thirty, the correct result is partial with a shortfall. A substring exclusion can remove an entire suffix family. An accepted-name list can exhaust the remaining scope. A fixed surname can narrow the pool to the number of available given forms. Each is useful information about your constraints.

Relax one condition at a time if you want to understand the cause. Reducing the requested count preserves the world grammar. Unlocking a surname changes the family decision. Expanding the original component inventory is design work that needs its own examples and consistency checks. None should happen silently merely to make the result panel look full.

Keep the reproduction bundle with the decision

The bundle records the seed, data version, rule version, scope label, parameters and identities. Retain the accepted output even when you can regenerate it. A future runtime, normalization policy or corpus revision can require an explicit compatibility decision. An unsupported version should remain a known limitation rather than a reason to falsify a historical result.

Before handoff, distinguish new candidates from accepted people. The presence of a generated ID does not mean the name has been approved in the story. Read it in a quest line, compare it with nearby NPCs and decide whether its reference forms are clear. The cast-comparison tool addresses those relationships; this generator addresses constrained, persistent creation.

If you import private project files, inspect the schema and retain a backup before adopting a new rule version. A corrupt import should not overwrite the current controls. A successful import proves only that the file fits the local contract, not that its cultural claims or external rights have been checked. Those boundaries remain the same whether your project contains six NPCs or six thousand.

Counterfactual: a ferryman with another name

If the updated corpus renamed the established ferryman, the new form could be perfectly consistent with the new grammar and still damage the quest. A returning player might infer a replacement worker or another landing place. Keeping the accepted identity preserves that continuity while allowing newly generated residents to follow the revised suffix. If the writer intends a replacement ferryman, create another stable identity and explain the change in the story; do not disguise that event as a randomizer refresh. The same method applies whenever an apparently cosmetic update would alter a reader's understanding of who has returned.

Does the same seed guarantee the same name forever?

Only with the same relevant inputs, data and rule versions, normalization policy and accepted-name scope. A seed is one part of the reproduction contract. Preserve the accepted identity and the full bundle rather than trusting a bare number after updates. Unsupported versions should produce a migration question, not silent substitution. The website does not claim compatibility with every future runtime or game save format.

Why are saved identities not regenerated with the new suffix?

They are accepted story state. A suffix change applies to new eligible names while preserved records retain their identity. If you intend a historical reform or personal rename, model that as a deliberate event and update dependent references. Rebuilding every saved person to make the current list look stylistically uniform would erase continuity the player may already know.

Does project scope mean all names in my project were checked?

Only supplied accepted records and the selected local saved-name list are compared. The scope label documents your intention but does not scan unseen files or load another device’s browser data. Export and consolidate the actual records when broader comparison is needed. No scope setting guarantees global uniqueness or establishes that a name has no external rights conflict.

What should I do when every combination is excluded?

Read which hard conditions restrict the pool. Reduce the count, revise an exclusion or unlock a component consciously. Expanding a fictional grammar is another option but needs its own design and regression examples. The generator should never fill the requested count with duplicates, silently relaxed names or invented evidence of a larger cultural dataset. An empty but explained result can prevent more rework than a plausible-looking list.