AIでタワーディフェンスゲームをコーディングし、全プロセスを文書化しました
(github.com/maciej-trebacz)- ソフトウェア開発歴20年の開発者が、ゲーム開発は初挑戦ながら、AIコーディングエージェントを活用して Phaser.js ベースのタワーディフェンスゲーム "Tower of Time" を完成
- 目標は AIによる実際のゲーム開発の可能性を検証することであり、コードに加えて すべてのAIプロンプト と作業過程を GitHub に文書化
- コードの95%以上をAIが作成しており、Augment Code、Cursor、Claude Sonnet 4 など複数のAIツールを連携して使用
- ゲームは 時間巻き戻し（リワインド）機能 を活かした戦略性に加え、多彩なタワー、エネルギー管理システム、ウェーブごとの敵出現など独自の面白さを提供
- リアルタイム配信、アートおよびサウンドアセットの活用、開発過程で得た教訓や実践的なコツなど、ゲーム/AI初心者の双方にとって有用な学習資料
Tower of Time 概要
- 本プロジェクトは、AIコーディングツールで実用的なゲーム開発が可能かを実験することを目的に進行
- Phaser.js という JavaScriptゲームエンジンを初めて学び、Beginner's Jam Summer 2025 に参加して、25〜30時間で「Tower of Time」を完成
- 開発の全工程とすべてのプロンプト、コード、ドキュメント、プレイリンクを GitHub に記録
ゲーム紹介
- Tower of Time は 時間旅行テーマ のタワーディフェンスゲームで、プレイヤーはウェーブ形式で押し寄せる敵を防ぎつつ、危機的な状況では 時間を巻き戻して戦略を再設計 できる
- 複数種類のタワー（基本、スナイパー、スローダウン、スプラッシュなど）と エネルギーシステム（タワー建設・時間巻き戻しに使用）を組み合わせている
- 主な特徴
- 時間巻き戻し: 不利な場面で以前の状態に戻り、防衛戦略を立て直せる
- 多彩なタワー: それぞれ異なる特性のタワー配置により、多様な防衛戦略を組み立てられる
- エネルギー管理: エネルギーの使い道を慎重に考える必要があるリソース運用要素
- 操作方法
- キーボード/ゲームパッド対応（移動: 方向キー/スティック、アクション: スペース/ゲームパッドボタン、巻き戻し: バックスペース/トリガー）
AIコーディング実験と開発過程
- 全コードの 約95%をAI（Claude Sonnet 4、OpenAI、Augment Code、Cursor など）で作成
- 主要なプロンプト、試行錯誤、最終成果物をすべてリポジトリ内の PROMPTS.md に記録
- AIによるコード自動生成の利点: 高速なプロトタイピング、反復的なコーディング作業の自動化、文書化のしやすさ
- 限界と注意点: AIはコードを過剰生成しがちで、特定の実装課題が発生した際にはプロンプトの再設計やロールバックが必要。デバッグログの活用を推奨
開発で得た教訓
- AIコーディングだけでも 面白いゲームを十分に完成させられる
- プロンプトの品質、明確な文脈の提示、デバッグ戦略 が非常に重要
- コード量を不必要に増やさないよう 継続的な点検が必要
技術スタック
- エンジン: Phaser 3 (v3.90.0) + Phaser Editor v4
- 言語: TypeScript
- ビルドツール: Vite
- アートアセット: itch.io、一部は手動で補正
- サウンド: freesound.org
ブラウザでプレイする : Tower of Time
3件のコメント
良い参考になりそうですね
私もAIをフル活用してウェブゲームを作っています。
Hacker Newsのコメント
開発に使われたプロンプト を一つひとつ読んでいくのがなかなか楽しい
「vibe coding の成功事例」に関する記事は、多数のエージェントと複雑なコードオーケストレーション、LLMが生成したルールさえ揃えば、「時間を巻き戻すタワーディフェンスゲームを作って、欠陥もバグもないように」と一行プロンプトを書くだけでゲームがさっと出来上がる、という幻想を与えがちだ
しかし、実際のプロジェクトで使われたプロンプトは、AIコーディングで最も効果が出やすい方法と一致している
明確で丁寧なアイデアを何百もの小さな問題に分解し、本当に重要な部分には具体的なアーキテクチャ上のガイドを与えるやり方が有効だ
技術リードとプロダクトオーナーを兼ねる立場として、このやり方は人間と仕事をするときでも王道だ
自分の仕事の70%は、役員の「タイムトラベルタワーゲーム、バグなし」という抽象的な要求を、チームが高い抽象度を保ちながら互いに衝突せず作業できるよう、強いアーキテクチャビジョンを文脈に埋め込んだ一連のプロンプトへ変換することだ
シンプルな Just One ボードゲーム用のHTMLゲーム作りに挑戦したが、入力欄が動いてしまうバグを4つのLLMに何度もプロンプトしても直せなかった
みんなはゲームを一気に実装しているのに、自分はテキストボックスの動きすら直せないので不思議に感じる
「セキュリティ欠陥なし、バグなし」プロンプトに続いて、「幻覚(hallucination)なし」も必須だ
AI初心者向けの基本条件だ
AIコーディングでうまくいく自分のやり方は、基本機能やゲームプレイの骨格をAIで「ワンショット」で作り、その上に何度も反復的に積み上げていくことだ
ワンショットの結果がすぐに印象的でなければ、すぐ別のプロンプトで補強して、納得できる結果が出るまで再試行し、土台を作る
このやり方には全面的に同意する
実際、自分の最近の投稿 もこの考え方に基づいている
コーディング前にAIに仕様書を先に書かせると、人が最初から仕様を書く負担が減り、実際に書かれる確率がずっと上がる
20年以上ソフトウェア業界にいるが、同僚の多くはAIコーディングに懐疑的だと感じる
最近では34,000行ほどある大きなアプリを主にAIで開発してみたが、その効率は、自分が出す指示の質、対話の構造、出力結果への注意の払い方（軌道修正を含む）によって指数関数的に上がる
「結局ほかのあらゆるツールと同じだな」と思うくらいだ
ただ、このツールはこれまで出会ったどんな「10xツール」と比べても、本当に10倍のレバレッジがある
たいていの懐疑派が見落としているのは、こうしたツールを完全に外部の存在として扱ってはいけないという点だ
目標を曖昧に説明して丸投げしようとすると痛い目を見る
いつかAIがこちらの考えをそのまま読める日が来るかもしれないが、今はまだそうではない
現時点では、考えを明確に整理し、新しいことを学び、面倒な部分を素早く片づけるところに真価がある
最大のレバレッジを得るには、このツールを自分の思考プロセスの中にうまく溶け込ませる必要がある
プログラミング歴は長いが、ゲームは高校時代の Hunt the Wumpus くらいしか触ったことがなく、最近になってAIの助けを借りて新しいゲームを作り始めた
AIには大きく3つの役割がある
(1) 学習ツール - こちらが用語を知らなくても質問の意図をうまく汲み取って出発点を示し、「自分が知らなかったこと」まで教えてくれるので、いちばん重要な役割だ
(2) 反復的または退屈な作業の処理 - コードコメントや設定ファイル作成など、自分でもできるが速度を落とす作業を無難に片づけてくれる
(3) 検索 - (1)と同様に、実際に自分が求めているものをAIが理解し、フィルタリングや推薦などを任せられる
AIに「思考」を任せることもできるが、その必要はない
人間より賢いわけではなく、ただより速く、より多くを知っているFPUのような存在だ
HN基準ではかなり懐疑的な部類だが、実際には会社でAI導入をずっと推し進めており、今も Claude に何か作業させながらこのコメントを書いている
懐疑的になる理由は、現在のAIソリューションの「売られ方」と「実際にやっていること」の間にギャップがあるからだ
すべてのAIソリューション、特にエージェントは、熟練者のガイドなしでは役に立たない結果しか出さない
実際に「自律的」な要素はほとんどない
「vibe coding」という用語を作った本人でさえ、業界が手順を逆に踏んでいると言っている
こうしたツールが素晴らしいことは事実だが、強く制御する必要がある点を省くのは、ほとんど嘘に等しい
この数か月で自分の考えも似た結論に至った
以前はAIについて批判的なコメントを書いていたが、最新のツールは確かにかなり進歩している
以前なら数週間かかっていた仕事が、今では数時間で片づく
ただし、プロンプトをよく考えて細かく分解し、IDEとうまく連携させる必要がある
最も革新的なのは、まったく新しいライブラリやフレームワークを扱うときだ
以前は使い方を検索してサンプルコードをいじっていたが、AIははるかに直感的で多様な方法を示してくれるので、しばしば驚かされる
まだ懐疑的な人も、もう一度試してみる時期だと思う
10xレバレッジの例として、言語が挙げられる
以前は Lisp などがより多くのことをより速くできると言われていたが、今では実際に自分で書くコードを減らしつつ、結果は高速で高性能な言語で生成できる
ただし、生成されたコードのうち簡単には検証できない部分を十分にレビューしなければならないという「罠」がある
高い表現力を持つ言語のおかげで、事前計画のない人たちが混沌としたコードベースを量産したのと同じように、AIツールでも同じことが繰り返されるだろう
とはいえ、自分が本当に時間を節約できるのは、まったく新しいコードを書くときよりも、古いコードと新しいコードを統合したり改善したりするときだ
デバッグでは大きな飛躍が起きている
以前のように print を打つだけでなく、コードをコピーして貼り付けるだけで「出力がこうならずにああなるのはなぜか？」とAIに聞いて、すばやく原因と代案を得られる
特に SQL、IaC、ビルドスクリプトなど、デバッガを付けにくい作業では、このやり方の利点は非常に大きい
もう一つ、学習曲線と難易度の上限は思ったよりずっと高い
Claude Opus を複雑な自動化フレームワークとして使う場合と、ブラウザで GPT-4o にコピー＆ペーストするだけの場合とでは、結果に大きな差が出る
開発プロセスを透明に公開し、プロンプトまで共有してくれたのが素晴らしくて、GitHubで star を付けた
コードも成果物も美しく感じる
明らかにAIだけを使ったのではなく、直接手を入れた部分も多いはずだ
自分は長くコーディングから離れていたが、友人たちに勧められてAIを使った簡単なコードを作ってみた
完成したのは、Bubble Wrap を潰すものと、消音器（ボタンを押すと音が消える）くらいだ
Bubble Popper
Silencer
PRを受け付ける予定があるのか気になる
インディーゲームこそ、コーディングAIの優れたユースケースに見える
リスクが低く、楽しさ重視という性格がぴったり合う
最初のコミットには大量のコードが含まれているが、
PROMPTS.mdはまだないたとえば EnergySystem.ts は最初のコミットですでに存在しているのに、後から追加された
PROMPTS.mdではAIが最初から作ったように見えるリポジトリ履歴のこの点について、もう少し詳しく説明してもらえるとありがたい
最初のコミットへのリンク
プロンプトも逐一書き留めていたわけではなく、ゲーム完成後に使っていたチャットツールの履歴をさかのぼって
PROMPTS.mdファイルにコピーしたプロジェクト生成の過程を見たければ、プロンプトファイルを最初から最後まで読むのがいちばん良い方法だ
たとえば EnergySystem.ts ファイルは、敵の経路探索、スポーン、タワー射撃などの実装が終わった後で、「エネルギーサブシステムを実装したい」というプロンプトによってAIが完全に新規作成した部分だ
Augment Code というツールは初めて聞いた
何をするものなのか、なぜそれを選んだのか、競合ツールとの違いや実際の使用感など、おすすめできるかも気になる
両方とも有料で契約したのか気になる
プロンプトを記録している点が印象的で、やる気をもらえる
自分の経験では、「vibe coding」は素早く進むこともあれば、どこまでも遅くなることもある
簡潔で明確な指示、素早いコードレビュー、アーキテクチャを把握する力があれば、本当に開発速度を上げられる
自分も以前タワーディフェンスゲームを作ったことがあり、最近はAIを使って新しいウェーブ生成やバランス調整までやってみようと考えていた
ゲームをAIが「感じ取れる」ようにするには、画面に見えるゲーム状態をトークンに変換してエンコードするプロトコルが必要なのではないかと思う
地形やゲームエンティティの位置、そのほかプレイヤーに見える属性などだ
全体をオートエンコーダに入れるのはあまり良くなさそうだが、ゲーム要素ごとのリストをトークン化するなら可能性はある
ゲームエンジン側で画面画像を提供し、トークンをAIに直接展開して見せれば、AIは実際のゲーム進行をより深く理解できるはずだ
こうしたトークンをきちんと活用するのにどの程度の学習セットが必要かははっきりしないが、現在の埋め込み空間でも数個のトークン内に表現できるかもしれない
ゲームログとユーザーの楽しさ評価を集めた訓練セットさえあれば、面白いデータも多く得られそうだ
プレイヤー嗜好のクラスターを見つけて、さまざまなタイプ向けのゲームを作ることも可能になるだろう
こうしたワークフローを共有してくれてありがとう
自分もLLM活用ワークフローに追跡可能性と透明性を持ち込むことを考えている
プロンプトを共有し履歴として残せば、開発者が最初に解こうとしていた本質的な問題と、それがどう変化し、新たな問題がどう生まれたかまで一目で追える利点が大きい
クールなプロジェクトだ
責任あるLLM活用に関する投稿
20年以上テック業界にいて、最近は Gemini-cli でエンタープライズアプリの統合テストツールをゲーム化しながらさまざまな実験をしている
MCPサーバーと組み合わせてみると、問題を段階ごとに分解し、プロンプトをより明確にしたときに最も良い結果が出る
AIがミスしたりループにはまったりすることもあるが（特にアプリのルーティングのような部分で）、そういうときは積極的に「ペアプログラミング」する姿勢で向き合うのが有益だ
もう一つ注目したのは、コード重複禁止のような原則を以前よりはるかに簡単に守れることだ
そうしないと、AIが一部分だけを変えて関連ファイルを見落とす状況が起きやすい
これはプログラミングロジックだけでなく、UXやアプリの挙動にも同様に当てはまる真理だ
AIと一緒なら、以前は数週間かかっていた作業も今では数時間で楽しく終えられる
Gemini に個性を与え、GEMINI.md ファイルを複数のデバイスでそのまま持ち運んで調整できる点は、とても大きな利点だ