再現できるNPC命名

生成名も物語の永続データになる

NPCの名前は、会話、日誌、家族の記録、セーブデータに現れます。更新のたびに新しい語彙表から計算し直すと、同じ人物の名前が変わるおそれがあります。この生成器は有限で版管理した架空の要素とシードを使います。採用した結果はプロジェクトに保存してください。語彙や規則の順序が変われば、シードだけでは再現できません。

規則の変更が結果を変える

River は専用の名と姓の語幹に -en を使います。Ridge は別の要素と -ak、Coast は別の要素と -a を使います。分類を切り替えると、同じ一覧を引き直すだけでなく、候補になる要素と姓の作り方が変わります。いずれも架空の規則で、実在の共同体や語源を示す名前ではありません。

件数より固定と除外を優先する

姓の固定は、姓だけを保護してほかの要素を生成し直すためのものです。文字列を含む候補の除外と、姓名の完全一致の除外は区別します。同じバッチと、選択した場合のローカルの保存候補を重複範囲にします。24通りしか残っていない条件で30件を要求しても、独立した30件があるようには表示しません。

創作例：姓が変わった渡し守

ゲーム更新後、川辺の集落を新しい表から生成し直すと、渡し守の姓が変わりました。日誌だけには古い姓が残っています。必要なのは別の乱数ではなく、固定の人物IDと採用名、またはデータと規則の版まで含めた再現情報です。過去の日誌にどの名前を残すかも方針を決める必要があります。

採用後に保存するもの

出力のシードとデータ版を残し、採用した人物名を自分の制作システムに保存します。このサイトがゲームエンジンやセーブファイルと自動連携するわけではありません。物語上の改名は、同じ人物IDの表示層を出来事に応じて変えるものとして設計してください。

候補不足を設計に生かす

空結果は、特定の接尾辞をすべて除外している、固定した姓が除外条件に触れている、範囲に対して語彙が小さい、といった問題を示します。条件を黙って緩めず、変更する範囲を選んでください。再現できる名前でも、同じ場面で覚えやすいとは限らないため、生成後は群像としても比較します。

現実資料を使う場合も採用済み人物を守る

規則の選択で米国資料の要素へ切り替えると、大型のSSA・Census資料から新しい組合せを作れます。架空文化の規則とは別の選択で、作成した完全名が資料にある実在人物とは主張しません。先頭条件、公開件数の下限、固定、除外を適用し、採用済みのIDと名前は再生成しません。架空の姓の接尾辞はこのモードでは適用せず、原資料版を別のハッシュで固定します。既存名と新しい生成分の数を分け、公開資料の件数を名前の自然さの点数に読み替えないでください。

生成した人物に何を保持させるか

プレイヤーが出会ったNPCの名前は、物語の状態になります。店を持ち、手紙に署名し、日誌に登場し、家族に属するかもしれません。再現できる生成器は作成を助けますが、生成器そのものが人物ではありません。採用した名前を固定IDの下に保存し、表示のたびに新しく引き直さないようにします。

IDは指定した接頭辞と連番から作り、保存欄の既存IDを避けます。採用済みの記録は、そのまま保持し、要素を再生成しません。新しい候補は、それらの名前と指定したローカル範囲で重複回避します。プロジェクト内の方針であり、世界中で未使用という主張ではありません。

港の集落、北部地域、今回の全キャストなど、意味のある範囲名を使います。ただし、実際に比べるのは入力した記録だけです。world と書けば架空世界の全住民や現実の全人名を読み込むわけではありません。

版を固定した生成を再現する

規則を選び、シードを固定して少数を作ります。名と姓、ID、データ版、規則版、導出を確認します。同じ入力と採用済みの状態なら、同じ結果を再現できます。比較する保存名を変えた場合、シードが同じでも入力は変わっています。

一人を採用済み欄へ入れ、新規候補の接尾辞を変えてください。保存した人物は変わらず、新しく作る姓だけが変わります。姓の固定は接尾辞変更より優先し、固定した部分を保って名を変えます。最後の乱数に任せず、優先関係を確かめられます。

対応しないデータ版は、現在の版へ黙って置き換えず矛盾を返します。採用記録を保ち、新しい人物を作る前に移行を確認してください。このサイトが将来のゲームの全データ版を持ち、セーブファイルを自動更新するわけではありません。バンドルは確認して制作へ取り込むための資料です。

創作例：更新後の渡し守

ゲーム更新後、プレイヤーは渡し場へ戻った。同じ舟があり、渡し守の声も同じだった。しかしクエストの表示だけ、姓が変わっていた。

日誌には古い名前の人を訪ねるよう残っている。画面は、同じ身体で同じ航路を担当する二人がいるかのようだった。物語には改名の説明がない。

制作確認で、作者は結婚について一行加える案を出した。プログラマーは、その出来事がほかの場所にもあるか尋ねた。どこにもなかった。並べ替えた語彙表から、別の姓が出ただけだった。

「それなら物語の出来事ではありません」と作者は言った。「不具合のために経歴を発明するべきではない」

前のリリースの採用記録へ戻した。新住民は新しい文法を使っても、出会った人は保存名を維持する。日誌は表示文字列を探すのでなく、人物の固定キーで参照するようにした。

後で作者は、別の人物の意図した改名を設計した。その変更にはクエストの出来事、会話、過去の日誌をどう見せるかの判断を付けた。偶発的な再生成と物語上の改名を分けたため、同じ基盤で両方を扱えた。

これは開発を描く創作例です。連続性の失敗と修正を説明しますが、このサイトと特定エンジンの連携試験を報告するものではありません。

新しいシードでは直らない理由

別のシードで偶然前の姓が出ても、契約は戻りません。次の更新でまた壊れ、ほかのNPCも巻き添えで変わる可能性があります。必要なのは採用した身元か、要素と規則まで固定した再現情報です。幸運な乱数ではありません。

表示名だけの保存にも限界があります。同名の人物を意図して登場させる場合、名前をデータのキーにすると別人の参照を統合するかもしれません。IDは分けます。称号や姓が変わっても、同じ舟、関係、クエスト履歴を持つ人物を継続できます。

逆に、退場後の後任を新しい人物にしたいなら、新IDと出来事を与えます。前のキーを使うと、物語が意図しない継続を示します。文字列だけから、後任か改名した本人かを判断することはできません。

有限の候補数を正しく扱う

内蔵の架空文法は、確認できる規模の構成例で、人口統計ではありません。規則を変えると名の要素と姓の作り方が変わります。接尾辞の変更は候補の組立て段階で行い、その後に除外と選択を適用します。選んだ後で付け足し、未報告の重複を作らないようにします。

24通りに30件を要求したら、一部結果と不足が正しい表示です。部分一致の除外で接尾辞の一族全体が消えたり、採用済み一覧で残りが尽きたり、姓の固定で名の要素数まで狭まったりします。どれも入力条件についての有用な情報です。

原因を知りたいなら一つずつ変えます。件数を減らせば世界の規則は保てます。姓を外せば家族の決定が変わります。要素を増やすのは、例と一貫性確認を伴う新しい設計です。結果欄を埋めるために黙って行うことではありません。

再現情報を採用判断と残す

バンドルにはシード、データと規則の版、範囲、入力、人物を記録します。再生成できても採用出力を残してください。将来の実行環境、正規化方針、語彙改訂では、明示した互換性判断が必要かもしれません。対応しない版を、過去の結果を書き換える理由にしないようにします。

渡す前に新規候補と採用人物を区別します。IDが付いたことは物語上の承認ではありません。クエストの台詞で読み、近くに登場するNPCと比較して参照の明瞭さを決めます。群像比較はその関係を、この生成器は制約と永続性を扱います。

私用プロジェクトを読み込むときは形式を確認し、規則版を変える前に控えを残します。壊れたファイルは現行の入力を上書きしてはいけません。読み込み成功も、文化的な主張や外部の権利確認が済んだことではありません。六人でも六千人でも、この境界は変わりません。

同じシードなら永久に同じ名前になりますか

関連する入力、データ版、規則版、正規化、採用済みの比較範囲も同じ場合です。シードは契約の一部なので、更新後も裸の数値だけへ頼らず、採用した人物とバンドルを保存します。非対応の版は移行の問いにし、黙って置換しません。すべての将来の実行環境やゲームの保存形式との互換性を保証するものでもありません。過去の出力を残しておけば、意図した改名と再現できなくなった不具合を区別できます。

新しい接尾辞で採用済みの人を作り直さない理由は何ですか

採用した人物は物語の状態だからです。新しい候補へ規則を適用しても、保存した名前は保持します。歴史的改革や個人の改名を望むなら、出来事として設計し参照を更新します。今の一覧を統一したくて全員を作り直すと、プレイヤーが知る連続性を消すかもしれません。新しく生成した名前と保存済みの名前が混在していても、それ自体が誤りではありません。なぜ違うのかを制作上の履歴として説明できることが重要です。

プロジェクト範囲なら全ファイルの名前を確認しますか

比較するのは入力した採用記録と、選択したローカル保存一覧です。範囲名は意図を記すもので、未入力の原稿や別端末のブラウザーデータを読み込みません。広い比較が必要なら、実際の記録を統合して渡してください。どの範囲でも、世界での未使用や外部の権利上の安全は保証しません。記録が欠けている状態で大きな範囲名を付けても、検査した資料が増えるわけではないことを、共同制作者にも伝えます。

すべて除外されたらどうしますか

どの条件で候補が絞られたかを読み、件数を減らす、除外を直す、固定を外すなどを意図して選びます。架空の要素を増やす案にも、設計と検証例が必要です。重複や条件違反で件数を埋め、存在しない文化データを使ったことにしてはいけません。理由のある空結果は、一見もっともらしい一覧より手戻りを防ぐ場合があります。一つずつ条件を変えて原因を確かめ、採用済みの人物へ影響が及んでいないことも確認してください。

保存状態を移行する前の確認

版を変える前に、採用済みの人物IDと名前を控えます。旧記録の姓を新しい規則へそろえる必要があるのか、それとも新規の住民だけへ適用するのかを先に決めます。見た目の統一を理由に既知の人を改名すると、プレイヤーの記憶と記録が食い違います。

同じシードで違う結果が出たら、データ版だけでなく除外、固定、保存候補、要求件数を見ます。復元した比較範囲を現行の收藏一覧へ置き換えれば、入力はもう同じではありません。再現に必要な状態と、新しく参照したい状態を区別して保存します。

人物名を物語のイベントで変える場合は、保存した旧名を破損として処理せず、変更時点と参照方針を記録します。過去の日誌は当時の名を残すのか、現在表示へ変えるのかを選びます。この生成器がその全ファイルを自動編集するわけではありませんが、IDと版のある名前資料は、担当者が一貫した移行を行う基礎になります。