生成AI時代の今、10年前に作ったミニゲームを復刻させた
10年前に作ったスマホミニゲームをWebゲームとして復刻させました。
※ 音が出るので注意！！
10年前の生成AIがなかった時代に作ったものとほぼ同じものを、生成AIの力を借りつつ再度作ったので、生成AIの有無による開発の違いを比べることができました。なお、過去に作ったコードを全てを生成AIに読み込ませて作り直させたという話ではなく、あくまで人間が０から作った時に生成AIがどのように貢献したかという考察になります。
なぜ復刻させたのか
10年前に個人開発でスマホアプリのミニゲームをつくりました。社会人になってから独学でプログラミングを始めたのですが、当時はゲームAIに興味があり、オライリーから出ている「実例で学ぶゲームAIプログラミング」を読みながら一通り勉強してなんとか完成させました。それ以降、運よく自分のソフトウェアエンジニアのキャリアがスマホゲーム開発を皮切りに始まったのですが、程なくしてゲーム開発とは離れてそのまま月日が流れていきました。
仕事でゲーム開発をすることはなくなって久しいのですが、このゲームこそが自分のキャリアの原点であり、ソフトウェアエンジニアになってから10周年を迎えるにあたって、初心に帰るつもりで再度作ってみようと考えました。
開発概要
技術スタックは以下のようになっています。
| 新（2025年） | 旧（2015年） | |
|---|---|---|
| プラットフォーム | Web | スマホアプリ |
| プログラミング言語 | TypeScript | C++ |
| フレームワーク | Phaser | Cocos2d-x |
| 生成AI | あり | なし |
今回TypeScriptを選んだのは特に深い理由はなく、単純に開発開始当時に仕事で使っていて、もっと慣れ親しみたいと思ったからです。Webゲームだとパフォーマンスの懸念はあったのですが、今どきのブラウザはJSの処理も早いですし、PhaserはWebGLにも対応しているのでこれでやってみることにしました。
前回との大きな違いは生成AIの有無です。もちろん10年前に生成AIはありませんでした。自分は仕事でも日常でも生成AIは普通に使っているのですが、Claude Codeに課金してゴリゴリ使うようなガチ勢ではないです。なので開発開始当初は無課金のChatGPTを主に使っていました。開発途中で愛用しているJetBrains製品でAI Assistantが追加料金なしで使えるようになったのでこちらでClaude 3.7 Sonnetなども使うようになりました。
画像素材に関しては10年前に自分で作成したものをそのまま使い回しました。音声素材についても10年前にお借りした素材を公式のサイトから再度ダウンロードして再びお借りいたしました。[1]
前回作った時とプログラミング言語や環境が違うものの、根本的なロジックの中身は前回と変わっていません。ただ、当時のソースコードを今読んで理解するのは難しかったため、設計や実装は全て０からやり直すことにしました。
普段はフルタイムで仕事をしているので開発は平日の業務終了後か休日となり、時間の制約があります。しかもやる気が出ない時は素直にやらないタイプ（ただし個人開発の時のみ）なので、なんだかんだでダラダラ時間がかかって最終的には１年３ヶ月もかかってしまいました。最終的に書いたコード量は7600行程度になりました。
生成AIの役割
ゲームのフレームワーク（Phaser）はあくまでシーンのライフサイクルとレンダリングとサウンドとゲームループの管理を担当するぐらいで、衝突判定や経路探索などのゲームロジックは自前で実装しています。ゲームロジックのコンポーネントがそこそこあり、コンポーネント間での複雑なデータのやり取りを考えると生成AIだけで全てを完結させるのは難しいと思い、生成AIはあくまで補助的な役割にとどめています。
今だとClaude Codeを使えばもっと生成AIに大きな役割を任せてもいいのかも知れませんが、開発を始めた当時はClaude Codeはなかったことと、ゲームプログラミングはステートフルで複雑で、自分が何を実装したかがわかってないとバグを潰すのが難しくなってしまうので、開発失敗のリスクを抑えるために生成AIに設計や実装を積極的にさせることはしませんでした。
生成AIの大きな恩恵を受けた箇所
生成AIがなかった10年前と比べて以下の２点で大きな恩恵がありました。
フレームワークの使い方をソリューションレベルで提案してくれる
Phaserを使うのは初めてなので色々調べながらやったのですが、検索においてやはり生成AIはかなり便利でした。
例えばレンダリング負荷の削減のためにGPUへのドローコールを減らそうと生成AIにPhaserでバッチレンダリング[2]を使う方法を聞いたのですが、バッチレンダリングが適応される条件だけでなく、さらに効率がいいBlitterという仕組みもサンプルコード付きで提案してくれてました。
10年前にCocos2d-xを使ってた時は公式ドキュメントを舐めるように見ないと適切な機能を見つけられなかったのですが、ふわっとした文章を生成AIに投げるだけで適切にソリューションまで提案してくれてサンプルコードまで提示してくれるのはかなりの時間短縮に繋がりました。
数学の知識が必要な実装を作図なしで行える
衝突判定のためのベクトル演算や経路探索のアルゴリズムなどはちょっとした数学の知識が必要になるのですが、10年前に一通りやっていたものの完全に忘れていました。当時は紙に作図をしながら全ての場合分けを書き出して時間をかけて検証してたのですが、これが生成AIだとすぐに解とコードまで出力されます。自力で紙に描いてやってた時だと簡単なものでも検証に数十分はかかるし、難しいものだと数日はかかっていたのですが、それが十数秒で終わってしまい解も間違ってなかったのでかなりの衝撃でした。
ただし、あくまで一般的なものに対しては正確なのですが、計算量を抑えるためのゲーム固有の特殊な方法を指示してみたところ、要件を満たさない不正確な回答になることが多かったです。回答が正しいかどうかを検証する人間の判断は必要そうです。
とはいえ相当な時間短縮に繋がったし、ゲームロジックという本質的なところに意識と時間を集中することができたので相当な恩恵を受けられました。これが一番恩恵がデカかったです。
生成AIでは難しかった箇所
一方生成AIでは難しいところもありました。
ゲーム固有ロジックのバグ修正
ゲームロジックでバグがあったのでコンテキストを含めて生成AIに聞いてみたのですが、あくまで一般論を述べているだけで具体的な解決策の提示は難しそうでした。コンテキストを絞って情報を渡せるバグなら大丈夫かなと思って試してみましたが、結果は変わらずでした。
Phaserの使い方の間違いなどはちゃんと返してくれましたが、やはり固有のロジックの実装を細かいレベルで読み取るのはできてない印象でした。ただ、今回は実装の全コンテキストを与えた訳ではないので、Claude Codeなどを使うともっと違った結果になるのかもしれません。
感想
生成AIを使えたことによる時間短縮効果は思ってたよりかなり大きかったです。ただ今回のケースだと生成AIにコードを書いてもらうというよりかは、コードを書く前の調査・検証で大幅な時短につながりました。この調査・検証が一般的な内容であったため生成AIがより活きたのだと思います。
あと、期待する回答が得られなかった時に生成AIにより具体的な指示を出そうと思ってプロンプトを書いたのですが、細かい仕様を自然言語で書くぐらいだったらコード書いた方が早いと判断する場面はたくさんありました。今回はあくまで個人開発なので詳しいドキュメントを残す必要はなかったのですが、ビジネスユースだと自然言語でドキュメントを残してそれを元にコード生成させるような使い方がいいのかも知れません。
今回は開発失敗のリスクを抑えるために生成AIの役割はかなり絞ったのですが、今後は生成AIに大きな役割を持たせてみようと思いました。
Discussion