プレイヤー名と台詞の置換欄

プレイヤーの名前は文法の指示ではない

作者のお気に入りの名前では自然に見えた台詞も、プレイヤーが別の表記を選ぶと成立しないことがあります。名前欄に入っていない称号、代詞、名前の順序、語形を文が前提にしているかもしれません。このツールは、台詞が必要とする文字列と、それを人物の例・言語ごとに明示したかを確認するためのものです。

ゲームや対話型の物語でプレイヤーが名前を選ぶ場合や、一人を指す複数の承認した形を脚本で扱う場合に使います。出力は置換した台詞と未解決の作業です。個人の身元の生成、性別の判定、代詞の推測、名前の語形変化、文の翻訳、ゲームエンジンとの直接連携は行いません。置換できたことを、言語上の承認に見せないための範囲です。

二言語の人物名マップは、別の版の名前が同じ人物を指すかを扱います。このページは、その参照を使う文章を確認します。人物の対応が正しくても、所有を表す形や置換欄が不足する場合があります。反対にすべての欄が埋まっても、語り口、関係、場面の点検は必要です。

置換欄を信頼する前に文を書く

テンプレートにはID、正確な言語ラベル、台詞の文字列を入力します。IDは改稿後も行を探すためのものです。言語ラベルは完全一致で扱います。台詞には通常の文章と{{name}}、{{subject}}、{{possessive}}、{{call}}などの置換欄を使えます。nameは入力した名前そのものを使い、ほかのキーには、その人物と言語について明示した形が必要です。

キーには先頭が英字、その後が英字、数字、ハイフン、アンダースコアという小さな構文を使います。欄内の前後空白は除きますが、プロパティ参照、関数、入れ子、任意の式は扱いません。{{name.toUpperCase()}}は実行する命令ではなく、未対応の置換欄です。特定の表示規約が必要なら、承認した別の形をキーとして用意します。

置換欄の外の文章は作者が書いたままです。そこにある冠詞、語尾、敬称が適するかは判定しません。文章が欄にない情報を前提にしていれば、置換だけでは直りません。名前に見えない文法情報を求める代わりに、中立的な文、明示した参照の形、別途確認する台詞の案を考えてください。

名前と入力した表記を分ける

人物の例には固定ID、正確な名前、任意の言語別表記を入れます。利用者が用意する確認例であり、新しく生成した人物や実際のプレイヤーの観察ではありません。courierやvisitorなど、管理しやすいIDを使います。同じ例に英語の主語形、日本語の呼称、別の署名を用意しても、ソフトウェアがそれらを翻訳したとは主張しません。

初期のcourierには英語のキーへTheyとtheir、日本語のキーへ作者が選んだ呼称を入力しています。Miraという綴りから得た値ではありません。visitorには山括弧とアンパサンドを含む名前を使い、文字列として表示するかを試します。日本語の呼称は意図的に未入力で、承認した値を入れるまでその台詞は未解決です。

nameは予約したキーで、言語別表記から上書きできません。ある言語で別の名前のような参照が必要なら、別のキーを付け、台詞でも明示します。これによりプレイヤーが選んだ名前そのものと、場面で使う形を分けられます。一つの呼称を直しても、人物の基礎となる名前まで変えたことにはなりません。

初期例を最後まで確認する

英語の二つの文は、人物を迎える台詞と、入力した主語・所有の形で荷物へ言及する台詞です。二人とも必要な英語の値を持ちます。日本語の文はcallを使いますが、courierには値がありvisitorにはありません。そのため六つの組合せのうち五つを作成し、残り一つで不足するcallを示します。

visitorへ日本語のcallを入れて再実行します。その台詞だけが解決し、英語の挨拶やcourierの表記は変わりません。次にcourierの英語の所有の形だけを変えます。その人物の英語の荷物の台詞だけが変わるはずです。広い文字列の一括置換ではなく、依存するキーが明示されることが、この作業の価値です。

言語ラベルをenからen-USへ変え、対応する表記を用意しない場合も試してください。nameだけなら人物の基礎データで作れますが、subjectやpossessiveが必要な台詞は未解決です。enから値を借りたり、別の言語を選んだりしません。その区別が必要かをプロジェクトで決め、対応する値を用意します。

創作例：名前から役職を作った掲示板

依頼の掲示板は、新しい配達人を、人物設定にない称号で迎えていた。どの挨拶でも、選んだ名前の前にその称号が付く。

草稿の試遊で、プレイヤーはNot Your Captainと名付けた。掲示板にはCaptain Not Your Captainと出た。そこで笑いが起きたが、次は笑いで済まなかった。門番がその称号を役職として扱い、制限した部屋への立ち入りを認めたのだ。

名前が露呈させた前提は二つあった。表示文字列へ称号を付ける文型と、その称号が確定した役職を表すつもりの物語の規則である。名前を変えれば挨拶は奇妙に見えなくなるが、どちらの規約も直らない。

作者は一般の挨拶から自動の称号を外した。地位が本当に必要な場面では、明示した参照キーと別の物語条件を使った。役職を持たない人物の名前にたまたまCaptainという文字があっても、文字列の似方だけで昇格しない構造にした。

次の例では別の不足が分かった。英語の荷物の文は所有を表す形を必要とするが、設定には名前しかない。綴りから推測する案も出た。作者は代わりに、その例に使う形を明示し、ゲームがその選択を得ていない場合には、キーを必要としない別の文を書いた。

日本語版では、その場面の関係に合わせた呼称を選び、言語ごとのキーに記録した。英語の形を翻訳の権威として扱わず、馴染んだ綴りに見えるという理由だけで敬称を足すこともしなかった。

次の試遊でNot Your Captainは、昇格せずに普通の配達を引き受けられた。表記が不足する例は、値か台詞を書くまで未解決として残った。プレイヤーは名前の冗談を維持し、物語は役職と呼び方を管理できるようになった。これはオリジナルの架空の場面です。実在するゲームの事例や、このサイトがゲームのアクセス制御を実装するという主張ではありません。

名前を変えるだけでは問題を隠す

普通に見えるテスト名なら、Captainと名前の組合せがもっともらしく見えるかもしれません。それで選んだ表示文字列と、物語が認める役職の差が隠れます。次のプレイヤーが同じ問題を露呈させる可能性は残ります。役立つ修正は、不便に見える名前を原因にすることではなく、文章の規約と称号を認める状態を変えることです。

代詞の不足も同じ構造です。名前から作者が何かを連想しても、入力された値にはなりません。ツールは不足するキーを示します。物語がその情報を尋ねていない、必要としないなら別の文を書けます。必要な表記なら、綴りからの近道ではなく、プロジェクトが実際に定めた人物やプレイヤーの情報から得ます。

単名、句読点を含む名前、長い形、置換欄に似た形を試し、置換後の台詞の意味を読んでください。確認例は脚本が持ちそうな前提を試すためのものです。現実の文化を順位付けしたり、ある種類の名前を本質的に不便だと決めたりするためには使いません。

挿入した値は文字列のまま

処理はテンプレートを一度だけ分解し、通常の文章と入力した値を連結します。プレイヤー名を別のテンプレートとして再解釈しません。正確な名前が{{subject}}なら、挨拶にはその文字が名前として出ます。代詞への追加の置換は行いません。入力した別の表記が括弧を含む場合も同じです。

ウェブサイトのプレビューでは、マークアップのような文字も文字列として表示します。ただし、それはローカルの表示の動作であって、書き出し先のエンジンの解釈を保証するものではありません。受け取る側の連携は別に確認してください。文字列のダウンロードだけでは、移した先も同じ処理をするとは証明できません。

この構文には、台詞の中で二重の波括弧そのものを直接書くためのエスケープ言語はありません。対応しない括弧や不正な欄は、元の位置を示して報告します。単独の括弧は置換欄ではありません。物語にその記号が必要なら、入力する文字列の形を用意するか、未定義の動作に頼らず規約を見直します。

未解決は、残っている執筆作業

不足する形を発明したり、別言語から借りたり、空の名前で完成した台詞に見せたりしません。人物の例、テンプレート、言語とともに不足するキーを示します。構文の問題は該当行に残ります。ほかの正常な行は作れるため、一つの執筆上の不足とファイル全体の形式の問題を分けられます。

不正なJSON、重複ID、未対応の欄は範囲全体の分析を止めます。参照を信じる前に元のデータを直してください。誤って付けた人物IDが本当は誰を指すかを、ソフトウェアは知りません。固定IDも、作者の実際の判断と一致して初めて役立ちます。

全部置換できた行は、文字列の規約を満たしたという意味です。自然な文法、関係に合う文体、筋の整合、外部連携まで認定しません。台詞を動機となる行動と並べ、誰が誰に話し、その文脈でその形が許されるかを読みます。

切り詰めずに作業範囲を区切る

人物の例は最大12件、テンプレートは40件、選んだ組合せは120件までです。大きい一覧は人物IDか正確な言語ラベルで絞ります。上限を超えた範囲は矛盾として示し、末尾の行を黙って落としたり、代表例だけを選んだりしません。

名前、表記、元の台詞にもUTF-16単位の上限があります。置換後の一行は12,000単位、選んだ出力全体は200,000単位です。同じキーの反復で短い原文から大きな出力ができるため、連結前にサイズを確認します。大きすぎる行を、切り詰めた文へ置き換えて成功にしません。

これは作業台の範囲であり、完成したゲームが扱える長さではありません。脚本を版付きの場面群に分け、その範囲も残してください。12件の例で成功しても、すべてのプレイヤー名を試したことにはなりません。意図的に前提を試す例を入れ、構文や表示先を変えた後で再確認します。

作れた台詞と不足した作業を渡す

書き出しには対象の人物と行のID、正確な言語の範囲、作成した文字列、使ったキー、別の未解決一覧が入ります。不足するキー、構文、出力サイズの診断を残し、未解決の行が実装済みだと見せません。非公開プロジェクトには元のJSONと絞り込みが残り、同じ判断へ戻れます。

受け取るプロジェクトに元の版を残します。一つの承認した形を変えたら、そのキーを使う行を探して意味を点検します。技術上正しい値でも、親密さ、地位、話者が知っているように見えることが変わり得ます。その関係に独自の規則が必要なら呼称や役職のツールを使い、一般的な名前の置換欄へ推測させないようにします。

最後に確かめるのは、プレイヤーの選択が名前として保たれ、作者の意図を文章が述べ、何を入力したかを正直に説明できることです。文字列の置換は小さな仕組みですが、名前のせいにする前に前提を見えるようにできます。

選んだ名前から代詞を推測しますか

台詞が必要とする正確な形を入力するか、その形を必要としない文章を書きます。馴染んだ名前は代詞、称号、文法の指示ではありません。各言語で独立して同じ方針を使います。

en-USでenの表記を使わないのはなぜですか

言語ラベルを完全一致で扱い、暗黙の補完をしないためです。等しく扱う版があるなら、プロジェクトで決めて値を入力します。nameだけの行は作れても、不足する別のキーがある行は未解決です。

プレイヤー名の括弧は別の置換を実行しますか

挿入した値は文字列として連結し、再び構文として読みません。名前に{{subject}}があればその文字が残ります。ただし、このプレビューの動作が、書き出し先のゲーム側の解釈を保証するものではありません。

解決した台詞はすべて文法も正しいですか

対応する置換欄に明示した値があったという意味です。作者の文章、関係に合う文体、筋の文脈は別に確認します。文字列の置換成功から語形、翻訳、文化上の適切さを推定しません。