プレイヤー名の処理経路チェック

入力欄で通った名前は、どこへ戻るのか

プレイヤーが入力画面で選べた名前が、次の場面にも同じ形で戻るとは限りません。画面の表示、保存に使うキー、再登場時の台詞が、それぞれ別の文字列を参照する設計もあります。この作業台では、その境界を作者が明示した処理でたどります。元の表示と入力例のIDを保持し、どの段階で値が変わり、拒否され、区別を失ったかを確認します。

目的は名前の良し悪しを順位付けすることではありません。二つの表示が一つの保存キーへ変わるなら、まず点検するのはその変換の選択です。片方のプレイヤーに改名を求める前に、表示とは別の識別方法で両者を保持できるかを考えます。文字列の一致を人物の同一性と取り違えないことが、このページの中心になります。

命名仕様の相談、保存処理の変更案、シナリオ担当から実装担当への具体例の引き渡しに使えます。ただし実際のゲームへ接続せず、セーブファイルも読みません。ここでの戻り値は宣言したモデルの出力であり、実機で保存と読み込みを観察した結果ではありません。出力を使い、実際の環境で何を試すかを狭く決めます。

先に三つの約束を分ける

最初に、プレイヤーへ見せる名前、記録を識別する値、後で戻す表示を別々に書きます。三つが同じである必要はありません。画面にはMiraを保持し、内部の例のIDをp1にできます。別の人物のmiraはp2として保持できます。このp1とp2は作者が指定した入力例の識別子で、本番アカウントのIDを発行しているのではありません。

入力例はidと正確なdisplayの組です。前後の空白、大文字と小文字、結合文字もそのまま入れます。空文字は境界を試す例として許可します。禁止したいなら、空文字を拒否する長さ検査を段階として指定してください。作業台の上限は五十例、各表示はUTF-16で二千単位です。この上限はローカル処理の範囲で、作品に許される名前の長さを勧めるものではありません。

初期例にはMira、mira、前後に空白のあるKiri、結合文字を含む短い表記があります。どれも技術上の創作例で、プレイヤーから集めたデータや言語圏の需要を表していません。同じ表示と別々のIDも試してください。同名という理由だけで二人の記録を一つへ統合する処理はありません。

創作例：橋に戻った二つの灯り

ここからは架空の協力ゲームの場面です。実装済みのゲームや利用者テストの報告ではありません。祭りを準備する二人の旅人が橋の受付に到着します。一人は大文字で始まるNeri、もう一人は小文字のneriと名乗ります。受付の小さな板には、その二つの署名が別々に残ります。自分で選んだ綴りが画面に現れる場面です。

Neriは青い提灯を直して市場へ向かい、neriは琥珀色の提灯を直して夕方の舟を待ちます。しばらくして二人は橋へ戻ります。ところがこの設定で考えた保存案は、表示を小文字に変えた値を記録のキーにしていました。二つの修理履歴に同じキーが割り当てられ、戻った旅人と提灯を確実に対応させられません。

受付係の「あなたの琥珀の灯りは、まだ点いています」という台詞は、優しく聞こえます。しかし青い提灯を直したNeriに向けると、別の人の行動を本人の思い出として渡します。名前を呼ばない文章へ変えても、履歴の混線は残ります。neriだけに別の名前を選ばせれば、物語が必要としなかった保存上の都合を、プレイヤーの選択へ押し付けることになります。

変更案では、二人の表示を保ったまま内部の記録IDを分けます。受付の署名も二つのままです。青と琥珀の灯りが、それぞれの旅人の行動を覚えている構造へ戻ります。この場面で名前が重要なのは、美しい綴りだからではありません。プレイヤーが作った身元と、ゲームが覚える行動をつなぐ約束だからです。

もし二人ともNeriを選んだとしても、履歴を区別する必要は消えません。見た目の重複を保存記録の統合許可とは扱えません。逆に物語が一つの共同の儀礼名を必要とするなら、共通表示を使いつつ記録は分けられます。応用するときは、プレイヤーの何を保持し、何を技術的に導き、帰還の場面で何を区別するかを先に決めます。

順番のある一覧に、小さな分岐を作る

各段階にはid、参照元のfrom、操作のopがあります。fromはrawか、一覧ですでに現れた段階です。先の参照、循環、段階IDの重複は入力の矛盾になります。表示用の分岐とキー用の分岐を同じ原文から作れるため、全操作で一つの文字列を順に壊していく必要はありません。

対応する操作はidentity、trim、lowercase、normalize、length、truncate、fixtureIdです。identityは入力を保持します。trimとlowercaseは実行環境のECMAScript文字列メソッドを使います。normalizeではNFC、NFD、NFKC、NFKDの形を明示します。ECMAScript仕様を参考資料にしていますが、lowercaseを特定言語の小文字化や完全なUnicode case foldingへ勝手に置き換えません。

lengthは値を変えず、最小と最大を検査します。truncateは指定した最大まで実際に切り詰めます。どちらにもcodepointかgraphemeを明示します。後者は実行環境のIntl.Segmenterが返す分割で、印刷上の一字幅や音節数の保証ではありません。Unicodeの分割指針はその区別の参考です。実行環境と移行先の版や処理が同じかは別に確認します。

fixtureIdは、指定した参照元が取得できた場合に、その例のIDを出力します。表示と識別を分けるモデルを示す操作です。IDの発行やアカウント照合はせず、本番のID生成の一意性も保証しません。指定していない音写、置換、空白除去、正規化はありません。未対応の操作や余分な段階項目は拒否し、入力したコードを実行することはありません。

初期例を使って、キーだけを変更する

初期状態を実行し、最初の二例を開きます。どちらもinputCheckを通過します。keyTrimはMiraとmiraを保ち、Kiriの前後の空白を取り除きます。keyは最初の二つを同じmiraへ変えます。指定キーの衝突グループにはp1とp2が残り、それぞれ元の表示、経路、結果カードを持ちます。loadedDisplayはrawを見るため、最初の二例の期待値は一致したままです。

次にidがstableKey、fromがraw、opがfixtureIdという段階を追加し、keyStageをstableKeyへ変えます。キーはp1とp2へ分かれ、表示や戻り分岐を変える必要はありません。変更前後を比べると、片方の大文字を好むという編集判断でなく、識別方法の変更で区別を回復したことが分かります。共同作業では両方の記録を残すと、変更理由を説明できます。

この比較はモデル内の検査です。successは入力した例に拒否、キー衝突、判明している戻り値の不一致がない意味です。未入力の期待値は、全体がsuccessでもunknownです。製品全体の出荷可否ではありません。非公開の引き渡しには段階、選択したキーと戻り先、予約値、正確な経路、制限が入り、同じ有限の検査を再現できます。

拒否の前と後では、同じ上限でも意味が変わる

正確な入力が「 A 」で、上限が一コードポイントの場合を考えます。rawへの長さ検査は三として拒否します。先にtrimを置き、その出力を検査すればAとして通ります。同じ乱数から別の候補を出したのではありません。検査する対象が変わっています。入力画面で約束する処理を決め、その境界で同じ順番を再現します。

拒否した段階には候補値、計測、理由が残ります。それを参照する段階はblockedになり、利用可能な出力を作りません。別の独立した分岐は動けます。予約キーで拒否しても、rawからの表示まで消す必要はありません。ただし一段階でも拒否があれば全体はpartialです。使える分岐があることと、仕様全体が通ることを分けます。

予約値はstage、正確なvalue、作者のreasonで指定します。完全一致なので、Miraの予約からmiraも自動で予約しません。小文字化した後を予約したいなら、その段階を明示します。理由はプロジェクトが定めたものです。世界共通の禁止、文化的な不適切さ、法律上の利用不可を認定するデータではありません。

衝突と戻り値を読む順序

衝突グループは選択したキー段階の利用可能な値を比べます。別分岐が失敗していても、取得できたキーは対象です。取得できない値は除きますが、取得できた空文字は一つの値なので衝突できます。グループ内のIDを統合しません。各組について原文がすでに同じか、最初に利用可能な出力が等しくなった段階も記録します。分岐があるので、最初の一致が必ず指定キーの原因とは限りません。参照経路を追うための手掛かりです。

期待する戻り値はfixtureとvalueで明示し、returnStageで比べます。matchはモデル内の完全一致、mismatchは期待と実際のモデル出力の違いです。unknownは期待値の未入力、unavailableは期待値はあるものの戻り段階から取得できない状態です。どれも実機の保存と読み込みの観測を捏造しません。

カードの展開欄では、文字列をJSONの引用付きで表示します。前後の空白を見つけ、空文字と取得不可を区別できます。コピーは元の表示を保ちます。同名の例も別の文脈で保存と比較ができます。非公開の書き出しには制作中の文字列や処理仕様が入り得ます。匿名の公開名簿と思わず、共有前に内容を確認してください。

次に確かめるのは、失敗した約束

衝突なら、表示名を識別キーにする必要があるかを先に考えます。長さの拒否なら、上限を増やす前に単位と参照元を見ます。戻り値の不一致なら、入力画面の約束と戻り分岐を並べます。blockedなら、下流を推測で埋めず最初の拒否を直します。この順序なら、名前を変えるべき問題と実装の契約を直す問題を分けやすくなります。

その後、同じ入力例を実際のゲームへ持ち込みます。入力方法、直列化、保存、取得、会話、画面での表示を確認します。この作業台はそれらの環境を試していません。不正利用対策、なりすまし分析、商標、文化的な確認も別の作業です。正確な経路を残すことで相談を具体的にし、プレイヤーの表示の選択と、別々の行動を覚える物語を両立させます。

次の問題が台詞への差し込みなら、会話スロットのツールを使います。制作素材に文字がないなら字形台帳、架空の個体と番号の対応なら技術的な身元台帳が適しています。接続する作業でも判断規則は違います。この処理経路を通ったことだけで、文法、字形、物語の身元まで解決したとは扱いません。

successならゲームの保存は正しいですか

入力した例と宣言した操作をたどった結果です。実際の入力、直列化、保存、読み戻しは移行先で試します。モデルに判明した失敗がなくても、期待する戻り値の未入力はunknownです。

キーが同じなら二人とも改名が必要ですか

識別の契約を先に見ます。fixtureIdの分岐なら、元の表示を変えずに別のキーを示せます。本番のID発行や、実際の識別子生成の一意性は検証していません。

lowercaseは全言語の照合方法ですか

ECMAScriptのtoLowerCaseです。完全なUnicode case foldingや特定言語の照合方法ではありません。ほかの変換も暗黙に足しません。実際の移行先の規則は別に定めて試します。

不適切な名や文化上の問題を判定しますか

予約値は作者の理由付きの完全一致指定です。モデレーション資料や普遍的な禁止一覧ではありません。文化、不正利用、なりすまし、権利の確認は別の作業です。