# ゲームデータ作成方針

チャットで作成・改善したゲームの経験を、今後の新規作成と既存JSON修正へ引き継ぐための正本です。今回の依頼、指定された基準JSON、ゲーム固有ルールを優先し、この方針は指定がない部分の制作判断に使います。既存ゲームへの一括適用や、JSON形式・初期値・実行器の変更を意味しません。

技術的な実現方法は[設計・実装パターン](authoring-patterns.md)、[データ仕様](game-data-spec.md)、[部品仕様](component-reference.md)、[処理仕様](action-reference.md)、[登録表](reference-contract.md)で確認します。制作上の希望と、現在利用できる機能を区別してください。

## 1. 作る前に確認すること

- 新規作成、既存データの修正、調査・整理のどれかを確認します。調査・整理だけの依頼ではデータを変更しません。明示された作成・修正依頼と確定条件を、不要に聞き直しません。
- 修正時はユーザーが最後に指定したJSONを基準にし、ユーザーが調整した画像・配置・寸法・説明・ID・オプションを依頼範囲外で作り直しません。ファイル名の版番号だけで基準を決めません。
- 素材、説明書、人数、オプション、勝敗条件、手動／自動の範囲、保存先を確認します。既存資料で分かる内容を調べてから、進行や秘密情報に影響する未確定点だけを質問します。
- ルールの根拠は素材・公式説明書・公式FAQを優先し、第三者の解説や推測を区別します。類似ゲームのルールで未確定点を埋めません。

## 2. 画面には今必要なことを出す

- 操作案内は原則として画面上部へ短く表示し、「誰が」「今何をするか」が分かる文章にします。例は「カードを選択して配置」です。
- 常時表示のタイトル、進行状況テロップ、内部変数、同じ説明の重複、不要なフレーバー文を増やしません。詳細な遊び方はルール、カード効果の補足は閲覧権限に従うカード説明へ分けます。
- 対面表示で回転する盤面には操作説明を焼き込まず、駒・札・配置先を中心にします。
- カード、チップ、駒の状態で分かることは、その表裏・配置・画像で表現します。持ち駒など実物を操作する対象は、数値だけで代用せず実体を見せる構成を検討します。
- 買い物は候補名と価格を一緒に示し、資金不足は非活性などで判別可能にします。例は「食堂（$3）」です。
- 待っている人にも、誰が選択中かなどの公開可能な状態を短く伝えます。選択途中の秘密の内容まで表示しません。
- 上部の進行案内と同じ文章や、盤面の変化で分かる獲得数を追加の通知で繰り返しません。使用カードの拡大で伝えた効果説明も重ねず、他者の判断に影響する重要な状態変化を優先します。表示だけの案内は原則として全員の読了待ちにせず、実際の選択・回答や指定された初回確認と区別します。

## 3. 操作する場所と案内を一致させる

- 実カードを選ぶ場面では、対応する場合は手札・ホルダー・盤面で直接選択し、確定する流れを優先します。別の選択一覧や専用タブを不要に増やしません。ピースや独自候補へ実カード専用機能を流用しません。
- 山札の先頭だけが対象のルールでは、裏向きの先頭1枚だけを候補にします。山札内部の一覧や2枚目以降を選べる状態にしません。通常の場札や、複数枚選ぶ別ルールにはこの制限を広げません。
- 配置先の選択は、その場所が分かる盤面上の操作を検討します。行動の開始・確認・手番確定はフェーズ別ボタンを基本にし、盤面の対象選択と役割を分けます。
- 単純な配札・集計・補充・次手番への移行は自動化します。判断、会話、結果を見せる間はゲームに合わせて残します。最後の効果が完了した後、意味のない「効果を確定」「手番終了」を追加しません。プロジェクトLの仮配置確定など、ルール上必要な確認は維持します。
- 読了確認だけなら選択肢や回答用変数を作りません。確認ダイアログを使う場合は既存の通知・確認処理を使います。個人タブ上での確認が指定された場合は、フェーズボタンと各人の確認状態で進めます。

## 4. 本人の情報と共有盤面を分ける

- 役職・勝利条件・手札内訳などは本人が見られる場所へまとめ、ゲーム中に変わる内訳は現在の状態に追従させます。ただし、ルールが再確認を禁じる情報は再表示しません。
- 情報確認や操作が必要なタイミングで、対象者だけを対象タブへ案内します。他人の画面を一緒に切り替えません。確認後に共有盤面へ戻るなど、次の操作場所まで設計します。
- 全員が確認するフェーズでは全員が操作できる条件を用意し、確認済み・未確認を個別に扱います。手番外の閲覧と状態を変更する操作は分けます。
- 入室順や各チーム内の順番を、交互進行の都合だけで並べ替えません。チームごとの手番位置とJSONの処理で表現できるかを先に確認します。
- `visible: false` や非表示タブで秘密化したつもりにしません。本人・チームの公開範囲、サーバーの操作検証、参加者別配信を維持します。警告を消すために秘密値を公開しません。

## 5. 素材・配置・サムネイル

- 支給素材と既存の調整を優先し、画像内の文字が潰れる場合は元画像の解像度、切り出し、表示寸法を確認します。長い説明をカード画像へ詰め込むだけで解決しません。
- 画像の種類や容量が負担になる場合は、分類ごとの軽い共通ベース画像と、名前・価格・効果文などの文字変数を組み合わせます。文字を画像へ焼き込まず、元の効果文と詳しい処理をカード説明にも保持します。分類数やサイズはゲームごとに判断し、既存ゲームへ一括適用しません。
- 共通ベースへ作り直す場合も、元カードの配色・絵柄・構図・枠・文字の配置を優先します。元の素材を参照し、別の美術様式へ置き換えるのは明示的に求められた場合に限ります。文字の変数表示と軽量化を維持するための調整は、元デザインを残す範囲で行います。
- サムネイルを作る依頼では、タイトルとゲームを象徴する絵を中心にします。人数・オプション表記・説明文・人物を必要なく足しません。元ゲームの特徴が伝わる要素を確認します。
- スマホで全盤面を小さく縮めて収めることを優先せず、カード・名前・操作対象が読める表示範囲とスクロールを設計します。安全領域と文字の見切れも確認します。
- 対面、個人、チーム、共有などのタブ用途を先に決め、同じ用途のホルダーや表示部品を必要以上に増やしません。
- 作者の画像にはSVGを使わず、PNG・JPEG・WebP・GIFを埋め込みます。使えないJSONは読込時のエラー一覧で場所と理由を確認し、修正してから再読込します。
- 別端末で使うJSONに端末専用画像参照を残しません。画像の保存・読込・再書出を確認し、指定された保存先へ成果物を置きます。

## 6. データ修正と基盤不具合を切り分ける

- まず既存の部品・処理・共通処理で実現します。ゲーム固有の都合で基盤の並び順や共通権限を変更せず、未登録のJSON項目を作りません。
- 進行停止時は対象JSON、実行環境、認証状態、回答待ち、演出待ちを照合します。JSONの誤りと確認モード・サーバー・画面の不具合を区別し、基盤の問題を不自然な追加ボタンで回避しません。
- ルール計算と演出の表示順は分けます。演出で一時値の計算や次手番への確定を遅らせる前提のJSONを作りません。
- やり直しは既存のセーブ・復元を使い、保存するゲーム全体の状態と、復元できる人を区別します。新しい秘密情報を見た後の復元禁止と古い回答の無効化を維持します。
- 必要な機能が未対応の場合は差分と影響を整理します。「JSONだけ」の指定があれば基盤を変更せず、実現可能な範囲と未達を示します。

## 7. 完了の判断と引き継ぎ

1. JSON構文・Schema・正式読込、ID参照、人数・オプション別の初期状態を確認します。
2. 各効果の最終操作から次手番・次ラウンド・終局へ進むかを確認します。入力が続く効果だけでなく、引く・得点するだけの効果、候補なし、資金不足、全員確認も含めます。
3. 本人・他人・観戦者の公開範囲、不正な選択、処理対象、再接続や復元後の進行を関係範囲で確認します。
4. PC・スマホ縦・スマホ横で、実際の選択・確定・タブ移動・メニュー・ドラッグなどを確認します。矩形や実行器の検査だけで実画面を確認済みとしません。
5. 画像を含めて保存・再読込し、可能な範囲で初期状態から終局まで遊びます。検証用コードが演出待ちを手動解除した結果を、画面での自動進行成功と扱いません。
6. 基準JSON、変更点、保存先、検証条件、未確認事項、ローカル／オンライン／本番の状態を分けて報告します。修正の依頼だけで既存ゲームの一括更新や本番公開まで行いません。

## 方針の根拠と更新方法

2026-10-28に、参照できた以下のチャットと、正式ソースにあるゲーム例・現行ガイドを照合して整理しました。全チャット・全版の監査や、各ゲームの全実操作確認を済ませたという意味ではありません。

| チャット | 引き継ぐ経験 |
| --- | --- |
| タイムボムの自動進行を作成 | 余計な文章を減らす、個人タブで確認、全員の確認ボタン、直接選択、チップとピースによる状態表示、簡潔なサムネイル |
| アルカトラズのゲームデータを作成 | 指定JSONを基準にする、購入価格と非活性、カードの説明と画質、山札の先頭選択、入室順を保ったチーム交互進行 |
| ナショナルエコノミーのゲームデータ作成 | 効果終了からの自動手番移行、全体状態と選択待ちの復元、確認モードの実画面と実行器検証の区別 |
| プロジェクトLのゲームデータ自動化を分析 | 配置・ホルダーへの返却の実操作、基盤の選択仕様変更による他ゲームへの影響、認証状態との切り分け |
| ボドゲデータ作成を分析 | 今必要な短い上部案内、盤面上の配置先選択、対面表示、持ち駒の実体表示、選択中の公開状態 |

ゲーム固有の数値、カード枚数、配役、勝敗、特殊ルールは共通化しません。例えばタイムボムの役職再確認を、再確認禁止のあるタイムボムQへそのまま流用しません。今後の修正で共通の希望が確定したら、この正本を更新し、個別の例外は対象ゲームの制作記録へ残します。