# KITAQFC・KUROSAKI・SARAKURAによるゲーム開発プロンプト 以下の「依頼内容」を記入し、このファイル全体を生成AIに渡してください。 コマンドは、`kitaqfc`、`kurosaki`、`sarakura`、`kitaq-docs`、`game-fc` が同じ親フォルダーにある配置を前提にしています。既存環境では実際のパスを使ってください。 ## 依頼内容 - ゲーム名：〈記入〉 - ジャンル・遊びの中心となる仕組み：〈記入〉 - プレイヤーが行う操作と、成功・失敗条件：〈記入〉 - 必須の画面・ステージ・敵・アイテム：〈記入〉 - 見た目、BGM、効果音：〈記入。資料がある場合はファイルも指定〉 - 対象：〈NES/ファミコンのカートリッジ／FDS〉 - マッパー・ROM規模・ミラーリング：〈指定。未定なら要件から選定する〉 - 映像方式・性能目標：〈例：NTSC、通常時に毎秒60回のゲーム更新〉 - 保存・周辺機器・その他の要件：〈記入。不要なら「なし」〉 - プロジェクトの保存先：〈例：game-fc〉 - 再配布条件：〈例：自作コードと素材をMITで公開できる状態にする〉 ## あなたに実行してほしいこと KITAQFCと付属ライブラリで、上記のゲームを実装してください。 デバッグと実行検証にはKUROSAKI、診断の整理と修正前後の比較にはSARAKURAを使います。 「仕様を具体化 → 小さく実装 → ビルド → 操作して観測 → 原因を調べる → 修正 → 同条件で再検証」を、受け入れ条件を満たすまで繰り返してください。計画、コードの提示、コンパイル成功だけで完了にしないでください。 ### 1. 環境と受け入れ条件を確定する 1. 作業先の指示、各ツールのREADME、対象言語のHTMLマニュアル、使用するライブラリのヘッダーと実装を読んでください。実行ファイルの場所・バージョンまたはSHA-256を記録し、コマンドとAPIは実際の `--help` とソースで確認してください。 2. 操作、画面、音、進行、更新頻度について、合格・不合格を判断できる受け入れ条件を書いてください。「STARTを押して離すと開始する」「被弾で残機が1減る」「ゲームオーバー後に通常の操作で再開できる」など、確認可能な形にしてください。 3. 重要な仕様の曖昧さだけを確認し、通常の可逆な実装判断は自律的に進めてください。仕様や合格基準を勝手に弱めないでください。 4. まず付属の小さなサンプルでコンパイラ・KUROSAKI・SARAKURAの接続を確認してください。これを依頼されたゲームの完成と扱わないでください。 ### 2. マッパーと資源の構成を決める - 小さな構成ではNROMを検討し、規模やバンク切り替えの要件がある場合はMMC3などを選んでください。マッパー名だけで対応を判断せず、KUROSAKIの `inspect-rom`、`mapper-info`、`audit-board` と実装で必要な機能を確認してください。 - PRG/CHR容量、CHR-ROMまたはCHR-RAM、ミラーリング、固定バンク、割り込みベクター、保存RAMを計画してください。最適化やバンク変更の後も、ヘッダーと実際の配置を照合してください。 - `--nes-local-ram` を使う場合、対象はCPU内蔵RAM `$0000–$07FF` の範囲です。ゼロページ、スタック、OAMの作業領域、ライブラリ用領域との重複を確認してください。 - VRAM転送キューの空き容量と、PPUのVRAM自体の容量を混同しないでください。1回のNMIで処理できる更新量も確認してください。 - FDSではディスクアクセス、保存、BIOSなどの条件を別に検証し、通常のカートリッジと同じ起動条件だと仮定しないでください。 ### 3. 小さく遊べる単位で実装する - 最初に「起動・タイトル・操作可能なプレイヤー・成功または失敗・再開」をつなぎ、その後に内容を増やしてください。 - KITAQFCのC方言とFC用ライブラリを使ってください。GB版のライブラリやAPIがそのまま使えると仮定しないでください。エントリーポイントは `void main(void)` を使ってください。 - 関数は宣言だけでなく対応する実装を確認し、必要な `.c` をビルド対象に含めてください。付属ヘッダーに宣言のみの項目があることにも注意してください。 - PPUレジスター、NMI、OAM DMA、スプライトの走査線制限、スクロールとミラーリング、属性テーブル、APU/DMCの条件を踏まえて実装してください。 - 英数字・記号には、提供された自作 `ascii.c` から変換したFC用フォントを使ってください。CHR、パレット、ネームテーブル、属性データと編集可能な元データを保存し、ビルドが実際にそれらを読み込むことを確認してください。 - ソースのコメントは英語、作業報告は日本語で記述してください。SARAKURAの標準レポートは英語のまま利用してください。 ### 4. 各反復でビルドと実行を結び付ける `game-fc/out/iter-001` のように出力先を分け、実行コマンド、終了コード、ROM・メタデータ・素材・ソース・ツールのハッシュを記録してください。 ビルド失敗後に残っている別のROMを実行しないでください。ビルド情報とデバッグ情報は同じROMに対応するものを使ってください。KITAQFCのビルドメタデータを、形式を確かめずにKUROSAKIの `--kitaqfc-debug` へ流用しないでください。 以下は親フォルダーから実行する、NROM・入力なしの動作確認例です。`main.c`、追加のライブラリ、CHRファイル、マッパーは実装に合わせて用意してください。 ```powershell $iteration = '.\game-fc\out\iter-001' New-Item -ItemType Directory -Force $iteration | Out-Null # Include all additional implementation units required by the game. & '.\kitaqfc\kitaqfc.exe' '.\game-fc\src\main.c' ` -I '.\kitaqfc\lib' -o "$iteration\game.nes" ` --mapper=nrom '--nes-chr=.\game-fc\assets\game.chr' --no-disasm ` "--kurosaki-metadata=$iteration\build.json" if ($LASTEXITCODE -ne 0) { throw 'Build failed; inspect the build log.' } & '.\kurosaki\kurosaki.exe' run "$iteration\game.nes" ` --frames 300 --pad1 0 --png "$iteration\frame.png" ` --json "$iteration\run.json" --emit-diagnostics "$iteration\events.jsonl" if ($LASTEXITCODE -ne 0) { throw 'Emulator run failed; inspect the run log.' } & '.\sarakura\sarakura.exe' fc analyze ` --metadata "$iteration\build.json" --events "$iteration\events.jsonl" ` --frames 300 --out "$iteration\analysis" --fail-on error if ($LASTEXITCODE -ne 0) { throw 'Inspect the analysis report and fix the cause.' } ``` 300フレームの無入力実行はゲーム全体の検証ではありません。次の操作シナリオを必ず追加してください。 ### 5. 操作シナリオを再現して検証する - KUROSAKIの `--pad1` / `--pad2` は生のNESビットマスクです。A=1、B=2、SELECT=4、START=8、UP=16、DOWN=32、LEFT=64、RIGHT=128です。ライブラリの `BTN_*` の値と混同しないでください。 - `run --pad1` は固定入力です。開始、移動、アクション、ポーズ、再開などの順序付き入力にはリプレイを用意し、押下・保持・解放を区別してください。 - `replay-record` は公開CLIでは無入力の記録を作るコマンドです。人が操作した入力の録画だと扱わないでください。`Replay` / `ReplayFrame` の形式を読み、必要な入力列を作成してください。 - 実行前にROMのSHA-256、リプレイの対象、フレーム範囲を自分で照合してください。`replay-run --verify` は期待ハッシュが存在する場合の比較であり、操作結果やROMの対応を包括的に検査するものではありません。テストを通すために期待値を実測値で無条件に上書きしないでください。 ```powershell & '.\kurosaki\kurosaki.exe' replay-run ` '.\game-fc\out\iter-001\game.nes' '.\game-fc\tests\start-and-play.replay.json' ` --frames 900 --json '.\game-fc\out\iter-001\play.json' ` --png '.\game-fc\out\iter-001\play.png' ` --wav '.\game-fc\out\iter-001\play.wav' ``` リプレイファイルはそのビルドのROMに対応させて準備してください。修正前後で入力の意味と条件を揃え、ROMごとに適切な識別情報を記録してください。 **順序付き入力とSARAKURAの接続：** 公開CLIの `replay-run` には `--emit-diagnostics` がありません。存在しないオプションを追加して呼び出したり、CPUトレースを診断イベントとして渡したりしないでください。入力シナリオをSARAKURAで解析する際は、公開 `kurosaki-core` の `RunOptions.replay_frames` と `diagnostic_events_from_trace_and_report` を利用する検証ハーネスをプロジェクト配下に用意してください。同じROM・リプレイ・フレーム条件で実行し、その実行のトレースと診断レポートからJSONLを生成します。トレース設定・保存範囲を確認し、ハーネスとCLIリプレイの画面・観測結果も照合してください。無入力実行の診断を、操作シナリオの検証結果として流用しないでください。必要な環境がなく実施できない場合は未完了項目として報告してください。 ### 6. 画面・音・状態・性能を確認する - 起動、開始、通常プレイ、衝突、スクロール、ステージ遷移、失敗、再開、ポーズ、保存など、仕様にある経路を通してください。1枚のPNGだけで動作を確認したことにしないでください。 - 代表フレームと境界条件のPNG、入力、実行レポート、診断JSONL、WAV、必要に応じた状態・メモリ観測を保存してください。要求したフレームに到達したか、停止理由は何かも確認してください。 - 画像は実際に開き、タイルや属性の境界、画面端、スクロール境界、スプライトが密集する場面を確認してください。残機、スコア、座標、状態遷移は期待値とも照合してください。 - BGM、効果音、同時発音、途切れ、ポーズ・再開を確認してください。WAVの生成だけで音を正しいと判断しないでください。試聴できない場合は、実施した波形・数値検査と未確認事項を分けて報告してください。 - 重い場面のNMI内処理、CPU負荷、転送量、ゲーム更新回数を測定してください。ホスト上のエミュレータ速度を実機やゲーム内の更新頻度と同一視しないでください。 - `--allow-unimplemented` によって処理を続行できても、その機能を対応済みと判断しないでください。 ### 7. SARAKURAで原因を絞り、同条件で再検証する - `--metadata` は対象ROMのビルド情報、`--events` は対象実行の診断JSONLです。`--frames` は解析条件の指定であり、SARAKURAがROMを実行する命令ではありません。 - `report.html`、`ai_diagnostics.json`、`repair_prompt.md`、`retest_plan.json` を読み、診断を再現手順・画面・音・ソースと照合してください。ソース対応や原因の推定を確認済みの事実として扱わないでください。 - 正常な待機と停止不具合を区別してください。警告をフィルターで隠したり、試験を短くしたりして合格にしないでください。未対応のイベントや解析範囲も記録してください。 - 原因を最小再現例で絞り、必要な箇所を修正し、ビルドから再実行してください。ツール側が原因の場合はゲーム側の問題と切り分け、ツールの修正に回帰試験を付けてください。 - 修正前後の入力、乱数種、マッパー、映像方式、観測フレーム、診断条件を揃えて比較してください。コードやRAM配置が変わったROMに、保存状態を無条件で流用しないでください。 ```powershell & '.\sarakura\sarakura.exe' baseline-delta ` --baseline '.\game-fc\out\iter-001\analysis' ` --current '.\game-fc\out\iter-002\analysis' ` --out '.\game-fc\out\delta.json' --markdown '.\game-fc\out\delta.md' ` --fail-on-new error --fail-on-regression error --enforce ``` 差分診断は、操作・表示・音の合格判定と併用してください。同じ失敗を繰り返す場合はログと仮説を見直してください。 ### 8. 完了条件と納品 完成版のROMと同じソース・設定で、すべての必須シナリオを再実行してください。検証用の無敵状態や別のマッパーだけで完成版を検証済みにしないでください。 必須要件と試験の対応表、残る警告の理由、未対応・未確認事項を明記してください。実機で試していない場合は「実機未確認」と記載してください。 納品物は、ソース、使用ライブラリとツールの識別情報、編集可能な素材、ビルド・検証スクリプト、ROM、リプレイ・検証ハーネス、最終検証の証拠、起動方法・操作・既知の制限を記したREADMEです。 公開・外部送信は明示された範囲で行ってください。不要な中間ビルドや一時トレースは確認後に削除し、ソース、素材、最終成果物、必要な回帰証拠を保存してください。 環境や権限などの障害で必須検証を実施できない場合は、完了とせず、再現手順と必要な対応を具体的に報告してください。