Because We Love Happy Coding

フリーライターからエンジニア × 講師。発信力だけあり余ってる感じ

【AIでゲームソロ制作】始めました。初日

今日もまたコーディング。だって僕らはHappy Codingが大好きだから。

 小学校4年生の時にファミリーコンピュータを買ってもらって以来、(時には狂ったように)さまざまなゲームをたしなみ、20代の頃はゲーム攻略ライターを生業にしていたくらいなので、自分でゲームを作りたい欲というのはずっとあった。小学生の頃はそれこそ「僕の考えた最強のスターラスター」とか考えてましたよ。ハードウェアスペックのことも考えずにリッチな夢想をしていたもので。

 実際、ゲーム制作ツール(RPGツクールとか)見ると欲しくなっちゃう人なんだけど、ゲーム制作というのは膨大なデータを地道に作り上げる作業であり、やる気と根気が重要で、私のような怠け者には到底無理なのであった。俺の嫌いな言葉は一番が「努力」で二番が「頑張る」なんだぜェーーー!

 40代になってプログラミングを学んだのも、あわよくばゲームを作れるようになるかも……という下心があったのは間違いない。プログラミングを学んだところでやる気と根気がないので無理なのだが……。

 しかし今や私にはAIがある。IT企業に勤めているおかげで少しはAIコーディングの知識もある。今こそ! 今こそゲームを作れるのではないか! そういう勘違いから始まる【AIでゲームソロ制作】記事を書いてみようと思う。やる気と根気はないが……。

初日

 初日にやったのはだいたいこんなこと。以下説明していく。

  • VSCodeはインストール済み
  • Codexインストール
  • プロジェクトフォルダを作る
  • ドキュメントフォルダを作る
  • ルールファイル(AGENT.mdなど)を作る
  • 変更履歴を記録するルールをルールファイルに記載する
  • 開発フローをルールファイルに記載する

 いろいろ作ってみたいゲームのアイデアはあるけれど、まず最初は、ローグライクなRPGっぽいもののプロトタイプ(動くだけのやつ)を作ってみようかと思う。ChatGPTにお伺いを立てて、自分のスキルセットに合わせて技術スタックを提案してもらう。

Steam配信を念頭に、VSCodeを中心にしたゲーム開発をしたい。とりあえずまずはWindowsで動く、ってことを目標にする。アイデアはいろいろあるんだが、仮にローグライクRPG風ゲーム2Dドット絵ってことにしてみよう。技術スタックを選定してみてくれないか。ご存知の通り、俺はJavaScript系が一番得意で、次いでPHP、Javaという感じだ。

 あ、烏滸がましくも「Steam配信」って書いてますけど、「最終的には」ってことだよ。すぐに売り物が作れるとは思ってないよ。将来ね、将来……あわよくば。

 ChatGPT(以下KITT)は推奨スタックとして「TypeScript + Phaser 4 + Vite + Electron」を挙げてくれた。TypeScriptは仕事で使ったからだいたいわかる。Viteもちょっと使った。Electronは噂に聞いたことがある。あとはわからんが、まあAIがやってくれるだろう。

PhaserはJavaScript/TypeScript向けの2Dゲームフレームワークで、CanvasとWebGLを使って描画します。ビジュアルエディター主体ではなく、コードを中心に開発するため、VSCodeとの相性がよい構成です。

 成ル程。  この他にも詳しいライブラリの説明や、ディレクトリ構成案なんかも教えてくれたが、それはまたいずれ。

Codex導入

 今回、Codexを使ってみようと思い立った。社内でちょくちょく「Codexがいい」という話を聞くので。もっとも会社のアカウントとは利用プランが違うので、使用感も違うのかもしれないが……。個人でそんなにお金かけらんないからね。

 今、私がどういうAIを常用しているかというと、ChatGPT Plusプラン(20ドル)とVSCode用にはCopilot Proプラン(10ドル)を使っている。CodexはChatGPT Plusのプランに含まれているので、インストールすればすぐ使える。

 今回はSteamを意識してWindowsが主戦場になるので、WindowsのゲームPCにCodexをインストールした。画面自体は、ほぼChatGPTみたいな感じ。

 コードを置くためのプロジェクトフォルダを用意して、それをCodexの「プロジェクト」に設定した。さて、どこから手を付けたものか。

ドキュメントフォルダを作る

 まずは、ドキュメントフォルダを作ることにした。というのも、仕事では「指示ファイル」を作って「この通りに作業せよ」という形でAIエージェントに指示を出している。そうすることで、事前に念入りに詳細な指示を練り込むことができるし、それを誰かにレビューしてもらったり、後から参考にしたり、再利用したり、ということが可能になる。それに、AIに指示を出すにも仕様書があった方がいい。いろいろ考えると、まずはドキュメントフォルダかな、と。

 公開用のドキュメント(マニュアルとか)を入れるdocsフォルダと、開発用のドキュメント(仕様書とか)を入れるdocs_devフォルダを作ることにした。

 これまでに考えたコンセプト案なんかを/docs_dev/20260618コンセプト案/フォルダに入れておく。yyyymmddでフォルダ名を始めるルールは、自分ルールとしてだいたいそうしている。

変更履歴ルールをルールファイルに記載する

 さて、次は変更履歴だ。後になって「どういう順番で何をやったんだっけ」となるのが嫌なので、docs_dev/history/フォルダを作成する。そしてAIがファイルを変更するたびにここに変更履歴を書き込む、グランドルールを作るのだ。

 ところでCodexのグランドルールはどう書くのがいいんだっけ。ChatGPTに聞いてみた。「最上位のディレクトリに AGENT.mdを配置」とのこと。では「ファイルを変更するたびにdocs_dev/history/yyyymmdd.mdファイルを作って変更内容を書き込む」というルールをAGENTS.mdに作成してもらった。

変更履歴ルール

  • ファイルを作成・編集・移動・削除した場合は、必ず docs_dev/history/yyyyMMdd.md に変更内容を記録する。
  • 当日分の履歴ファイルが存在しない場合は作成する。
  • 日付は Asia/Tokyo のローカル日付を使い、ファイル名は yyyyMMdd.md 形式にする。
  • 変更履歴には、変更したファイル、変更内容、変更の意図が分かる説明を記載する。
  • 履歴更新はファイル変更と同じ作業内で行う。
  • 履歴ファイルは次の形式で記載する。
# yyyy-MM-dd

## 変更記録

### 1. 変更の概要

- 対象ファイル:
  - `path/to/file`
- 変更内容:
  - 何を変更したかを簡潔に記載する。
- 意図:
  - なぜ変更したか、どのような状態を目指したかを記載する。

 Codexについてはこれでいいんだけど、VSCode側でCopilotがファイルを変更することもあるので、こちらは.github/copilot-instructions.mdファイルに同様のルールを作ってもらった。

 なぜかAGENTS.mdが英語だったので、日本語に修正させました。自分でさっと読める方が安心だからね。

開発フローをルールファイルに記載する

 次は開発フローをルールファイルに記載する。  自分が仕事でAIエージェントを使う時の開発フローをベースに、個人開発なのでちょいとアレンジした。

開発フロー

バックログ

バックログ定義

  • バックログは実現すべき機能を書き表したもの。
  • 原則としてバックログは「ユーザー側の目線から表現される機能」を記載する。
  • 原則としてバックログは動作確認可能な状態で終わる(常にエラーで止まるような状態で終わるバックログは作らない)。これはバックログ完了時に動作確認、レビューをする必要があるため。

手順

  • /docs_dev/backlogs/フォルダ内のbacklog_oneline.mdから、着手するバックログを決める。この段階ではバックログのIDはなく、優先順位順にmdファイル内に書かれている。
  • /docs_dev/backlogs/フォルダ内にyyyymmdd_backlog_{{000}}_{{概要}}.mdファイルを作成する。{{000}}はバックログのIDでファイル作成時に採番する。{{概要}}はバックログの内容を簡単に表す短文。ファイルの中には詳細なバックログが記載されている。
  • /docs_dev/workfiles/フォルダ内にyyyymmdd_work_{{000}}_{{概要}}.mdファイルを作成する。{{000}}はバックログのID。{{概要}}はバックログの内容を簡単に表す短文。ファイルの中には詳細な作業内容が記載されている。
  • /docs_dev/tests/フォルダ内にyyyymmdd_test_{{000}}_{{概要}}.mdファイルを作成する。{{000}}はバックログのID。{{概要}}はバックログの内容を簡単に表す短文。ファイルの中には詳細なテスト仕様が記載されている。
  • テストコードを作成する。
  • yyyymmdd_work_{{概要}}.mdファイルを実行し、機能を実装する。テストも行う。
  • 実装完了後、AIがコードレビューを行う。
  • コードレビュー完了後、マネージャーレビューを行う。マネージャーレビューでは動作を確認し、backlog_oneline.mdに追加すべき項目があれば追加する。
  • マネージャーとAIでrecap(振り返り)を行う。改善可能な点がないか検討し、もしあれば改善活動を行う。
  • もしあれば改善活動を行う。

 この下書きを元に、Codexに「このフローに改善すべき内容があれば提案してくれ」と訊いてみた。  提案をもらい、いくつかは採用し、開発フローに反映してもらった。これはだいぶ長いドキュメントになったので割愛します。

まとめ

 まだ「ゲームを作る」どころの話じゃない。開発の最初の一歩くらい。ここまでやるだけでも半日かかってしまった。

 しかも、うっかりしてVSCodeのモデルを高額なモデルにしてしまっていたようで、月額の10ドルを使い切ってしまった。今月末まであと10日ほどあるので、臨時に上限を5ドル追加した。まあこれでなんとかなるだろう。
 ありがたいことに、5ドル買い切りじゃなくて「上限を+5ドル解放」ってことなので、少なめで止まれば5ドル未満で済むらしい。良心的だね。