完成を最優先にするゲーム開発：Pacman-likeから始める理由
こんにちは、yukiです。
今回は、バイブコーディング＋AI伴走の練習でもあります。
手を動かしながら違和感を拾い、それを言葉にしてAIに投げ返す。そのやり取りを通じて、設計の解像度を上げていく、という使い方を試しています。
なぜ Pacmanライクな小さなゲーム から始めることにしたのか、その判断と設計の考え方を開発記録としてまとめます。
結論から言うと、完成させやすさと拡張性を最優先にした結果です。
この記事で書くこと（先に結論）
- 「2Dタイルゲーム」を最初のゴールにした設計思想
- 無料・軽量・後拡張を前提にした技術選定
- GitHubとAIを使った、実務寄りの開発フロー
- まず触ってもらう用に、ブラウザで遊べるデモを置いています（インストール不要）。
- Play（GitHub Pages）: https://yukimomo.github.io/pacman-like/
- Repo（ソース）: https://github.com/yukimomo/pacman-like
おすすめ結論
👉 Minecraft的な学びは、2Dタイルゲームでも十分に得られる。むしろ最短ルート。
背景と目的
最この開発の主な目的は、バイブコーディングのやり方を身につけることです。
最初から仕様や設計を固め切るのではなく、
「今の理解と感覚（バイブ）」で一度作り、動かし、
違和感が出たところを言語化して直していく。
その往復そのものを、学習対象として捉えています。
今回は完成度の高いゲームを作ることがゴールではありません。
むしろ、
- 小さく作る
- すぐ動かす
- 壊しながら学ぶ
- 判断理由を言葉に残す
という、バイブコーディング特有の進め方を、安全に試せる題材としてゲーム開発を選んでいます。
そのため、最初のステップとしては
3Dやボクセルではなく、2Dタイルゲームという「軽くて構造が見えるもの」から始める判断をしました。
この記録は、
「どう作ったか」よりも
**「なぜそう判断したか」「どこで迷ったか」**を後から振り返れるように残すことを意図しています。
初期の制約条件
今回は、次の条件を前提にしています。
- できるだけお金をかけない
- 学習目的だが、遊べる完成物を残す
- 将来3D・ボクセル構造に発展できる設計
- GitHub 管理前提（差分・履歴・レビュー重視）
- AIと伴走する開発フローを試す
制約を明示すると、選択肢がかなり整理されます。
ファーストステップに選んだゲーム
Pacmanライクな2Dタイルゲーム（Pacman-lite）
理由は以下です。
- タイル（グリッド）は、後のブロック／ボクセルの原型
- シンプルなルールで、次を一通り実装できる
- ゲームループ
- 当たり判定
- 敵AI
- レベルデータ管理
- 状態遷移・リスタート
技術選定の考え方
候補に挙がったのは次の3つでした。
- Unity
- Godot
- Web（HTML5 Canvas + JavaScript）
判断軸は明確です。
- 無料であること
- 環境構築が軽い
- 配布・検証が簡単
- 2Dタイルゲームとの相性
- 将来3Dに拡張できる余地
結論として、Web（Canvas + JavaScript） を第一候補にしました。
必要になれば、Three.jsなどで3Dへ広げられる余白を残します。
AIと一緒に開発するための工夫
会話ベースのAIだけだと、
- コード全体の把握が難しい
- 差分レビューがやりづらい
という課題がありました。
そこで採用したのが、Codex × GitHub連携です。
- リポジトリ前提でコードを管理
- PR単位でレビュー・修正
- 差分ベースで指示できる
実務に近い開発体験を、そのまま学習に持ち込めるのが大きなメリットでした。
想定している開発フロー
- GitHubにリポジトリ作成
- 機能ごとにブランチ作成
- 実装 → PR作成
- AIでレビュー・改善
- マージ
- 小さく完成 → 次へ
「常に完成物がある状態」を保つのがポイントです。
この時点での学び
- 小さく作って完成させることが最短ルート
- 2Dタイルでも、設計の本質は十分学べる
- AIは
- 設計整理
- 選択肢の比較
- 試行錯誤の言語化に使うと効果が高い
次のステップ
- Pacman-liteの最小実装
- タイルマップ
- プレイヤー移動
- 簡易敵AI
- マップ定義の外部ファイル化
- GitHub + Codex運用を実際に回す
にほんブログ村
