種のシーディング
サーバーは、バトルを自分で解決します。ダメージの計算式を適用し、ダメージのランダムな振れ幅を決め、 急所を判定し、捕獲されたすべてのモンスターの個体値、性格、性別、色違いかどうかを決めます。 そのすべてを行うには、各種の基礎ステータス、タイプ、捕獲率、性別比が必要です。
それらはクライアントから得ません。 自分の種のステータスを送れるクライアントは 、 好きな値を送れてしまうため、サーバーはバトルのペイロードからそれらを読むことを拒否します。 サーバーは自分のストレージから読みますが、そのストレージは空から始まります。
これを省略するとどうなるか
目に見えることは何も起こりません。それが、何よりも先に理解しておく価値のある問題です。
シードされていないサーバーは、エラーを出さず、警告せず、バトルの開始を拒否することもありません。 フォールバックの連鎖をたどります。
species_dataストレージ：シードされた値、あなたの本物のデータ。SPECIES_FALLBACK_TABLE：サーバーモジュール内にテスト用にハードコードされた、組み込みの 6 種。DEFAULT_SPECIES：それ以外のすべてに適用される、汎用の 1 行のステータス。
つまり、シードされていないサーバーは、あなたのすべてのクリーチャーが同一の仮のステータスを持つバトルを
平然と実行します。捕獲は、種に関係なく、性別を単純な 50/50 で判定します。タイプ相性は NORMAL に対して
解決されます。誰もエラーメッセージを受け取りません。サーバーの視点では、何も間違っていないからです。
ストレージに尋ね、ストレージには何もなく、デフォルトを使っただけです。
シーディングは、権威を持つサーバーを、仮のもので はなくあなたのゲームに対して権威あるものにするものです。
2 つの半分と、それらが別になっている理由
シーディングは、Unity 内のエクスポートのステップと、その外のシードのステップに、意図的に分かれています。
シード RPC（mce_species_seed）はサーバー間通信専用です。ユーザーセッションを伴う呼び出しを拒否し、
Nakama ランタイムの HTTP キーを必要とします。そのキーは管理者の資格情報であり、持っている人は誰でも
任意のプレイヤーのストレージに書き込めます。コミットしてはならず、ビルドに埋め込んではならず、
ScriptableObject に入力してもいけません。
そのため、そのキーを安全に保持できない Unity は、ファイルを書き出すだけです。環境変数からキーを読み取る、 ターミナルから実行するスクリプトが、それを送信します。
Hub の Seeding タブは、以下のすべてについて購入者向けの経路です。ファイルをエクスポートし、 サーバーが現在保持しているものを報告します。
ステップ 1 — Unity からエクスポートする
Hub：Online タブ → Species Data → Export Species Seed JSON（または Seeding タブの Export seed files。種を含むすべてのエクスポーターを実行します）。
これはアクティブなモンスターデータベースを読み取り、プロジェクトのルートの SeedData/ に 2 つのファイルを
書き込みます。意図的に Assets/ の外にあるため、Unity はそれらをインポートせず、
.gitignore の対象にもなっています。
| ファイル | 内容 |
|---|---|
species-seed.json | 送信するペイロード |
species-seed.report.txt | スキップされたすべてのエントリと、サーバーが置き換えるすべての値 |
レポートを読んでください。 サーバーは、すべてのステータスを 1〜255 の範囲に収め、その範囲外のものには 自前のデフォルトを黙って代入します。ある種の基礎ステータスが 0 なら、その値はサーバーで置き換えられ、 そのことが言及されるのは、パイプライン全体でレポートだけです。
図鑑番号がない、ほかのエントリと図鑑番号が重複している、フォームがない、第 1 タイプがない、 といったエントリは、エクスポートされずにスキップされます。これらはすべて、レポートに名前付きで 一覧表示されます。
エク スポートされるのは、各種のベースフォームだけです。サーバーは種のデータを図鑑番号のみをキーに 保存するため、別フォームの 2 行目があると 1 行目を上書きしてしまいます。
ステップ 2 — サーバーをシードする
Assets/OpenMon/Online/Server~/nakama/ から：
# bash
export NAKAMA_HTTP_KEY=your-runtime-http-key
npm run seed:species
# PowerShell
$env:NAKAMA_HTTP_KEY="your-runtime-http-key"
npm run seed:species
スクリプトは、何かを送る前にファイルを検証し、サーバーが黙って置き換えるような値を見つけたときは シードを拒否します。その後、種をチャンクに分けて送信します。RPC は各リクエストを 1 回のストレージ書き込みに 変換するため、図鑑全体を 1 回の書き込みにすると、Nakama が拒否し始めるからです。
| 変数 | デフォルト | 意味 |
|---|---|---|
NAKAMA_HTTP_KEY | — | 必須。サーバーのランタイム http_key。 |
NAKAMA_URL | http://127.0.0.1:7360 | サーバーのベース URL。 |
SEED_FILE | SeedData/species-seed.json | 代替の入力パス。 |
SEED_CHUNK_SIZE | 100 | リクエストあたりの種の数。 |
何も送らずにエクスポートを検証するには：
npm run seed:species:check
シーディングは冪等です。各種は独自のキーで書き込まれるため、クリーチャーを追加した後に再実行すると、 変更された行が更新され、残りには手が付けられません。データベースが変わるたびに再実行してください。 これは通常のワークフローであり、復旧の手順ではありません。
ステップ 3 — 確認する
OpenMon Hub を開きます。コンテンツタブは 2 つのことを報告し、それらは異なる問いに答えます。
1 つ目はローカルで即座に得られます。ディスク上のエクスポートを、アクティブなデータベースと比較し、 ネットワークをまったく必要としません。これが、実際によく起こる失敗を捕まえます。誤ったシードではなく、 数週間前に書き出されたエクスポートの後に 40 体の新しいクリーチャーが追加された、というものです。 稼働中のサーバーのチェックではこれは見えません。サーバーは、あなたのプロジェクトに何が入っているかを 知らないからです。
2 つ目は Verify server ボタンで、ネットワークに触れるのはこれだけです。3 つの結果を区別し、 その区別が重要です。
| 結果 | 意味 |
|---|---|
| Seeded | コレクションに種の行があり、その数も表示される。 |
| Empty | サーバーが応答した。そのコレ クションは空。 |
| Could not ask | オフライン、ホストの誤り、サーバーキーの誤り。これはデータについて何も言っていない。 |
「シードされていない」と「応答がない」は別の事実です。それらを統合するステータスランプは、 ステータスランプがないよりも悪質です。実際の問題がネットワークなのに、データの問題を報告するからです。
データベースに対して直接確認することもできます。
select count(*) from storage where collection = 'species_data';
シードされた行は、Nakama のシステムユーザーの下に、公開読み取りとサーバーのみ書き込みの権限で 書き込まれるため、クライアントは種のデータを 読めますが、どのクライアントもそれを書き込むことは 決してできません。
再シードのタイミング
- 種を追加、削除、名前変更した後
- 基礎ステータス、タイプ、捕獲率、性別比を変更した後
- Essentials インポーターでプロジェクトをインポートした後
- 新しいサーバーをデプロイするたび -- 新しいデータベースは空から始まります