UE5ぷちコンでCursorを使用してゲームを作った話

# はじめに

まず、UE5ぷちコンとは株式会社ヒストリア様が主催しているUnreal Engineの学習を目的としたコンテストです。
こちら [UE5ぷちコン](https://historia.co.jp/ue-petitcon/)
テーマに沿った内容であることが条件ですが、自分は勉強のために毎回そのテーマとは別に開発テーマを設定して作っています。

今回はAIプログラミングをテーマにゲームを作りました。
これです。
https://youtu.be/LQ_u38frxTM
<iframe width="960" height="540" src="https://www.youtube.com/embed/LQ_u38frxTM" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" loading="lazy" allowfullscreen></iframe>

そろそろいけるだろうとよく分からないことを思い、ギルティギア2を作ろうと思って作りました。
オリジナル性皆無のものを作ろうとしたことについては後述。

ということで、どう作ったのか？どうだったのか？というのをつらつらと書いていこうと思います。
が、先に言ってしまうと、AIを使えば誰でもゲームを作れる！なんてことにはならないし、プログラミングの知識、ゲーム開発自体の知識がないと難しいというのが現状です。

# AIプログラミングについて

AIプログラミングというのはChatGPTを利用して、質問して実装を作るというものではなく、いわゆるエージェント型やDevinのように自立型のものを利用した開発手法だと考えています。
はっきり言ってしまうと、自分はAIプログラミング自体は初ではないです。
ただ、まだまだ勉強中で、完全に開発手法を確立しているとも言えないのが開発前の自分の状態でした。

色々とAIプログラミングの話は出てきている状況ですが、その多くはWeb開発についてで、C++やC#等といったアプリケーション開発についてはほぼ話題になっていないというか、どこまでできるかも触れられていないというのが現状です。
実際、Web開発で使用するような言語、それとPythonについてはかなりAIは強いです。
なので、ツールを提供する側もそこの話をメインにするし、いわゆる驚き屋やAI関連の紹介をする方々もそこばかりを触れます。

で、実際自分の主戦場はC++やC#(仕事は割とこっち)が多いので、そこでどこまでできるかを見ていきたい、見なければならないと考えていました。

## なぜCursorか

ツール選択の指標として
1. C++を利用できる
1. 現実的に利用しやすい

というのがありました。
まずトライアルできるので、それで試してできそうだったのでそのままというのもあります。
あと、仕事でも使ってる。

Devinがいいと聞きますが、如何せん料金が高いし、C++はサポートしているけれどおそらく作れないだろうというのがありやめました。
作れないだろうというのは、実装したところでそれを試すのが難しすぎて、エージェント型との差別化がされないだろうというところです。
作った話も聞かないし、トライアルできるでもないし、それで出来なかったら本当に痛い。
本当は試したいけれど。

2025/4月現在、VS CodeもかなりCursorに近づいてきたので選択肢は広がったと思いますが、まだCursorには追いついていないかなと。
主に使いやすさとパフォーマンスの点で。

# 開発の流れ

ネットの記事でも本でも、とにかくプロンプトで指示して作らせるスタイルの話が多いように思います。
ここはエージェント型の使い方がまだまだ発展途中で情報が少ないというのと、作るものが小さいというのもありそうですが。
ですが、ちょっと試すような規模ではないのは明白なので、違うアプローチを取りました。
大まかな流れとしては、
1. 仕様書を作成する
1. 設計書を作成する
1. 実装する

という、流れだけ見たら完全なウォーターフォール型の開発手法です。
今回に関して言えばこのメリットは大きく、特に仕様書の部分を実際に存在しているゲームの情報からAIに作らせることができるというのが魅力です。
最初の段階では仕様書の大まかな部分はChatGPTを使用しました。
[その会話](https://chatgpt.com/share/6807cfae-4eac-800b-a2f8-0a3b4d5152b6)

# 基本戦略
## 一般的な開発関連
- とにかくAIに任せる。
仕様書も設計書も実装も、とにかくAI任せで細かい修正やどうにもならない部分だけ手を入れるようにする。
- 実装は機能を細かく分ける
- 仕様書、設計書を食わせながら実装する


## UE関連
- C++でクラスを実装した後、BPに継承して使用するようにする。
これは最悪どうにもならない場合、BPでしかできないことをやるため。
- 面倒がないようにBPに関数を公開しすぎない。
継承してから使用する部分ははっきりさせるといった、UEでの開発の一般的なことをしっかりと意識したくらいです。

# 実際開発を進めて
正直、かなり快適でしたが、問題が起きると対応が難しい大きな問題ばかりという感じでした。

## 一般的な開発の問題
- AIの苦手分野
- 一生エラーを解決できない
- 単純にソースから辿れないシーケンシャルな処理

### AIの苦手分野
Strawberry問題というものがあります。
これがクラス名などでも発生します。
ちゃんと指示すればできることが多いですが、何故か普通に実装の指示をした時に盛大にクラス名を間違えたりしました。
プロジェクト固有のクラスを区別しやすいようにAS(ActionStrategyの略)をプレフィックスとして付与していたんですが、これがアクタークラスになるとAAS～になるので、ASとしか書かれなかったりして、とに各エラーが頻発しました。
ちゃんとnamespaceとかで区別しろという話ですよね。

あとはいきなり実装を行うと妙な実装になりやすいです。
最初に設計を考えさせて、それを実装させるほうがいいです。

### 一生エラーを解決できない
コンテキストウィンドウのサイズの問題なのか、はたまた他の問題なのか、自動でビルド→ビルドエラー→修正→ビルドエラーというのを何度かやっていると、堂々巡りを起こし始めます。
解決方法が分からないのか、総当たり的に修正を始めますがだいたい3、4回修正するような場合は正解にたどり着けません。
こうなると自分の手で修正していくしかないですが、単純なエラーならいいですが、ソースを理解して正しい形が何かを考えないといけない。

### 単純にソースから辿れないシーケンシャルな処理
例えばイベント呼び出しによってシーケンシャルに処理が行われるような場合です。
UE5の作り的な部分はありますが、そうでなくても発生する問題だと思います。
今回ではイベントの処理からイベントを呼び出し、無限ループが発生する状態に陥っていました。
設計がしっかりしていれば発生しないとも考えられますが。

## UE5独自の問題
- C++の実装とエディタ側操作の棲み分け
- AIの学習不足
- 見えるソース外へのアクセスの困難さ

### C++の実装とエディタ側操作の棲み分け
マテリアル、Niagara、レベル、ビヘイビアツリー、UIが絡む部分は自分でエディタ側で作りました。
ビヘイビアツリーに関しては必要なタスクやサービスはC++で実装するようにしました。
UIに関してもC++で機能は実装して、極力それを呼び出すだけにしました。

## AIの学習不足
最新のUE 5.5で開発していましたが、当然のことながらAIが学習していることもなく…
ただ、最新の機能を使ったりしなければそんなに問題はなかったです。
既存コード(この場合はエンジンコード)を参照することで、破壊的な変更にも対応できていたと思います。
そもそもそんな問題が起きるような変更入ってなかった気もしますが。

一生エラーを解決できないというのも、結局は学習不足に起因するところもあるのかなと。

## 見えるソース外へのアクセスの困難さ
BPは言わずもがな、データドリブンなGAS(Gameplay Ability System)とも相性が悪かったです。
また、マクロが展開される部分にも弱く、マクロで書かせた内容が、修正の段階でまるっと展開したようなコードになったり、使えないものを追加されたりと散々でした。

特にGASに関しては最初は使用しようと思って進めていましたが、GameplayTagとAIの相性の悪さも相まって断念し、レガシーな実装をする方向に舵を切りました。
仕様や設計側でしっかり固めれば作れたかもしれませんが、そこまでいったら自分で実装した方が早いという状況になりそうな気がしました。

# 総括
## 失敗したこと
色々ありますが、一番の失敗はGASを使ったことです。
GameplayActionsは問題ないんですが、GameplayEffectとGameplayAttributeは相性が絶望的でした。
しっかり設計書に書き起こせばまた違う気もしますが、それを書くくらいならエディタで作ったほうが早いという問題も出てきます。
C++とエディタの棲み分けがしっかり決まっていなかったのもあるかなと思います。
もちろん、頑張ればできるとは思いますが、手が入りすぎるので完全に放棄して、新たにGameplayEffectとGameplayAttributeを使わない形に作り直しました。
これは明らかに内容が変わり、設計まで変わるのでまるっと作り直しました。

作り直すにしても設計書はほとんど使えたので、ほぼ一日くらいで作り直して同じくらいのなんとなく動くような状態に出来ました。
UE5でVibeCodingは無理だとは思いますが、こういう作り直しの判断をして変更していけるｎ、しっかり内容を把握しているからなのかなと思います。

## 成功したこと



# 実際に作ったドキュメント類
https://github.com/aki-senri/ActionStrategyDoc

# 他
まだまだ書いてる途中
見切り発車がすぎる