収集用JSONテンプレート · 現在の取り込み状況 · 既存の採用済み登録例 · 固定された計算方法・検算例 · 小さいモデル向けの作業手順 · 地域・間接影響・発生確率の定義
# 歴史要素を収集してゲームへ取り込む 正本は `catalog.json`。新しい調査結果をJSONの調査パックにし、インポート→検証→ビルド→既存のSites公開手順で反映する。年や地域ごとにJavaScriptを書き足す必要はない。ネット上の文章を自動的に真実と認定する機能、未確認の史料から数値や適用域を補う機能ではない。 ## 収集する項目 | 項目 | 必須情報 | 不明な場合 | | --- | --- | --- | | 識別 | 固有ID、改訂番号、題名、説明 | draftとして保持 | | 時間 | 西暦への正規化、開始・終了年、日／年／期間の精度。日付があれば月日 | 不明な日を1月1日などの史実日付に置き換えない | | 地理 | 地域ID、含める範囲・除外する範囲、出生地／居住地、粗さ、適用範囲の根拠 | unknownのまま保留。全国に拡張しない | | 人物条件 | 年齢、身分、生業。条件はすべてAND、各配列内はOR | 人物側の値が不明なら不一致 | | 史料 | URL、作成主体、参照日、何を裏付けるか、確度、限界 | 出典のないreadyはビルドで失敗 | | 効果 | 背景表示か、対応済みの処理へ接続するか | 史実の存在だけでお金・健康・権利を変えない | | 統計 | 値、単位、母集団、年代、地域、出典、推定の限界 | 母集団の平均を個人の確率や所得に置換しない | | 改訂・対立 | revision、競合する意味を表すconflictGroup | 重複範囲の競合は停止。後勝ちにしない | `ready` は上記が埋まり、登録者が採用可能と判断したレコード。`draft` と `rejected` は保管するがゲームに配信しない。必要条件が欠けたreadyはエラーとなる。出典の真偽・論争の評価自体をプログラムが保証するものではない。 ## 現在動く取り込み先 - `context-v1`：制度・風習・生業・統計・土地・移動・通貨の背景説明。対象年／地域／人物条件で「この時代・この土地の背景」に自動表示。数値・権利を変更しない。 - `disaster-v1`：地震・飢饉の発生とドット調イベント。現在の明示モデル効果・対応選択肢・台帳に接続。居住地域を用い、一回限りの地震を移住後に遡及発生させない。飢饉は対象年の継続状況として扱う。 - 購買・税・相続・移動禁止等を実際に計算する新しい法則は、`context-v1`で背景登録できるが、それだけで効力を付与しない。対象、例外、権利主体、費目、単位、決済時期を持つ専用adapterとテストを実装してから有効にする。未知のadapterは公開前にエラー。 現在の災害の効果量はprofileに紐づく仮値。同じprofileの新しい史実はデータだけで接続できるが、固有の被害率を再現する場合はprofileの拡張と検証が必要。 ## 範囲の意味 時間の年区間は両端を含む。地震の発生は西暦日付を年内比率へ変換。ゲームの実時間単位で最初に到達した刻みに発生する。史料に日付のない飢饉の `modelTriggerFraction` はゲーム上の配置であって史実の日時ではない。 地域IDは現在の旧国名ベースのゲーム地理索引13件。政治勢力や都道府県名を同一視しない。「尾張藩が関わる」資料だけで尾張国全域の全住民へ適用しない。現在は旧国単位まで対応するため、村・沿岸帯・飛び地・藩領・多重権利など精密な範囲の情報はdraftに保存し、旧国全体へ拡大してreadyにしない。 `all-modeled-regions` は登録地域への全国制度背景の説明だけに用いる。全日本の地理実装完了・実効的普及・全住民への適用を意味しない。`coverage: partial` は未収録地域を被害なし／制度なしと解釈しない。除外地域は包含地域より優先する。 今後、地域索引を拡張するときは、旧名・別名の解決表と有効期間、親子関係、形状IDとgeometry版、包含・除外領域、重層権利、原資料の範囲とゲーム適用範囲を別に持つ。未対応の沿岸判定・距離・勢力を条件へ入れたreadyは現在はエラーになる。 ## 取り込み手順 1. `gamestation/history-pack.template.json` をコピーして収集。出典があるだけではreadyにしない。該当する既存のreadyレコードを構造例にする。 2. `node scripts/import-history-content.mjs /absolute/path/research-pack.json --check`：正本を変更せず検証。 3. `node scripts/import-history-content.mjs /absolute/path/research-pack.json`：全件検証後にマージし、配信用データを生成。 4. `node --test tests/history-content.test.mjs tests/gamestation-disasters.test.mjs tests/gamestation-model.test.mjs`。 5. `npm run build`：必ず共通台帳を再検証してから配信ファイルを生成。既存Sitesワークフローで公開。ゲームの読込み時に登録データが接続される。 同じパックの再投入は同一内容なら何もしない。既存IDの変更はrevision増加が必要。史料レコードの差し替えは新しい出典IDで記録する。古い出来事IDを改訂しても同じ人生内で発生済みのイベントは再発生させない。レコードの削除は採用状態をrejectedに変更しrevisionを上げる。 ## 品質管理と運用 検証するのは形・参照・適用条件・競合・対応処理の存在。URLの到達性、原文の真正性、校訂、史学上の論争、引用・画像ライセンスは別に記録・確認する。原文や画像を取り込む場合はライセンス情報も必須にする。現状は独自要約と出典リンクを利用し、史料画像は収集しない。 候補収集→正規化→不明点と異説の保存→条件の確定→ready→自動検証→配信変換→ゲームで適用→台帳・出典表示、という順に進める。ウェブの新発見を常時収集・公開する定期実行はまだ設定していない。研究を追加する作業と、既知の形式をゲームへ取り込む作業を分けている。