設計書の読み方・構成

AIドパガキ GBC 版の技術設計ドキュメントの入り口。

ドキュメント体系

文書	役割	更新タイミング
ゲーム説明書	プレイヤー視点の仕様。仕様検討のベース文書	遊び方・ルールを変えたいとき最初に更新
ゲーム仕様書	画面レイアウト・判定・進行・定数一覧の正典	説明書で固めた仕様を数値に落とすとき
システム構成・エンジン設計	ROM 構成・フロー状態機械・OAM / VRAM キュー・実行予算・サウンドドライバ	実装構造を変えたとき
アセット・パレット規約	2bpp 配置・パレット規約・一枚絵パイプライン	アセット追加・規約変更のとき
E2E テスト設計	PyBoy ハーネスのシナリオ・不変条件・ラッチ方式	テストシナリオを追加・変更したとき
サウンドドライバ実装契約	tools/ref_sim_gb.py と 1:1 対応する asm ドライバの契約	音まわりの実装・参照シミュレータを変えたとき
issue 分割案	issue 粒度・順序・依存関係・受入条件の正典	開発計画を見直すとき
ビルド手順 ほか開発・ハード文書	開発環境から実機動作までの手順	手順が変わったとき

仕様を固める手順

1. 説明書 LP 本文 (docs/manual/parts/lp.md) を編集   ← 遊び方・ルールのたたき台
2. 仕様書 (docs/spec/aidopagaki-gb-design.md) で数値を確定 ← 判定フレーム数・スコア等の正典
3. 実装 (src/*.asm, src/constants.inc) を追従         ← 定数は src/constants.inc に集約
4. サイト再デプロイ:
     akc run -- npm run docs:deploy    # 開発ドキュメントサイト
     akc run -- npm run manual:deploy  # 説明書 LP サイト

⚠ 仕様書 §12 のコードブロックと src/constants.inc は 1:1 対応でなければならない。名前・値・順序のいずれかがずれると tools/test_build.py::test_spec_constants_have_one_to_one_source_of_truth が落ちる。

変更しない確定事項（ユーザー確定要件）

• キャラアニメは 4 コマ × ANIM_STEP_LEN(5) = 20 フレーム固定・接地固定（ジャンプのみ pose_dy で Y 浮上）
• ストーリー等の表記は「SNS」で統一する（実在サービス名は使わない。2026-07-28 確定）
• moves 配列（判定対象の譜面データ）は NES 版から 1 バイトも変えない。変わるのは speed88 のみ

プロジェクト概況

項目	内容
ハード	Game Boy Color 専用（$0143 = $C0）、MBC5 / ROM 128KB / セーブなし
移植元	NES 版 nes_AIDopaGaki（開発ドキュメント）
ツールチェーン	RGBDS 1.0.3 + Python 3.12 / PyBoy 2.7.0（ビルド手順）
開発フロー	issue 駆動（issue 化 → 調査 → 実装 → PR → レビュー → マージ → マージ後テスト）
実機経路	カートリッジ改造手順 → フラッシュ書込み手順

issue の最新状況は GitHub の issue 一覧（gh issue list --repo aieo-product/gb_AIDopagaki）を参照する。⚠ 状況表をこの文書に転記しない。 転記すると必ず古くなる。issue の粒度と受入条件そのものの正典は issue 分割案。