こんにちは、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運用を実際に回す