はじめに
まず、UE5ぷちコンとは株式会社ヒストリア様が主催しているUnreal Engineの学習を目的としたコンテストです。
こちら UE5ぷちコン
テーマに沿った内容であることが条件ですが、自分は勉強のために毎回そのテーマとは別に開発テーマを設定して作っています。
今回はAIプログラミングをテーマにゲームを作りました。
これです。
https://youtu.be/LQ_u38frxTM
そろそろいけるだろうとよく分からないことを思い、ギルティギア2を作ろうと思って作りました。
オリジナル性皆無のものを作ろうとしたことについては後述。
ということで、どう作ったのか？どうだったのか？というのをつらつらと書いていこうと思います。
が、先に言ってしまうと、AIを使えば誰でもゲームを作れる！なんてことにはならないし、プログラミングの知識、ゲーム開発自体の知識がないと難しいというのが現状です。
AIプログラミングについて
AIプログラミングというのはChatGPTを利用して、質問して実装を作るというものではなく、いわゆるエージェント型やDevinのように自立型のものを利用した開発手法だと考えています。
はっきり言ってしまうと、自分はAIプログラミング自体は初ではないです。
ただ、まだまだ勉強中で、完全に開発手法を確立しているとも言えないのが開発前の自分の状態でした。
色々とAIプログラミングの話は出てきている状況ですが、その多くはWeb開発についてで、C++やC#等といったアプリケーション開発についてはほぼ話題になっていないというか、どこまでできるかも触れられていないというのが現状です。
実際、Web開発で使用するような言語、それとPythonについてはかなりAIは強いです。
なので、ツールを提供する側もそこの話をメインにするし、いわゆる驚き屋やAI関連の紹介をする方々もそこばかりを触れます。
で、実際自分の主戦場はC++やC#(仕事は割とこっち)が多いので、そこでどこまでできるかを見ていきたい、見なければならないと考えていました。
なぜCursorか
ツール選択の指標として
- C++を利用できる
- 現実的に利用しやすい
というのがありました。
まずトライアルできるので、それで試してできそうだったのでそのままというのもあります。
あと、仕事でも使ってる。
Devinがいいと聞きますが、如何せん料金が高いし、C++はサポートしているけれどおそらく作れないだろうというのがありやめました。
作れないだろうというのは、実装したところでそれを試すのが難しすぎて、エージェント型との差別化がされないだろうというところです。
作った話も聞かないし、トライアルできるでもないし、それで出来なかったら本当に痛い。
本当は試したいけれど。
2025/4月現在、VS CodeもかなりCursorに近づいてきたので選択肢は広がったと思いますが、まだCursorには追いついていないかなと。
主に使いやすさとパフォーマンスの点で。
開発の流れ
ネットの記事でも本でも、とにかくプロンプトで指示して作らせるスタイルの話が多いように思います。
ここはエージェント型の使い方がまだまだ発展途中で情報が少ないというのと、作るものが小さいというのもありそうですが。
ですが、ちょっと試すような規模ではないのは明白なので、違うアプローチを取りました。
大まかな流れとしては、
- 仕様書を作成する
- 設計書を作成する
- 実装する
という、流れだけ見たら完全なウォーターフォール型の開発手法です。
今回に関して言えばこのメリットは大きく、特に仕様書の部分を実際に存在しているゲームの情報からAIに作らせることができるというのが魅力です。
最初の段階では仕様書の大まかな部分はChatGPTを使用しました。
その会話
基本戦略
一般的な開発関連
- とにかくAIに任せる。
仕様書も設計書も実装も、とにかくAI任せで細かい修正やどうにもならない部分だけ手を入れるようにする。 - 実装は機能を細かく分ける
- 仕様書、設計書を食わせながら実装する
UE関連
- C++でクラスを実装した後、BPに継承して使用するようにする。
これは最悪どうにもならない場合、BPでしかできないことをやるため。 - 面倒がないようにBPに関数を公開しすぎない。
継承してから使用する部分ははっきりさせるといった、UEでの開発の一般的なことをしっかりと意識したくらいです。
実際開発を進めて
正直、かなり快適でしたが、問題が起きると対応が難しい大きな問題ばかりという感じでした。
一般的な開発の問題
- AIの苦手分野
- 一生エラーを解決できない
AIの苦手分野
一生エラーを解決できない
UE5独自の問題
- C++の実装とエディタ側操作の棲み分け
- AIの学習不足
- 見えるソース外へのアクセスの困難さ
C++の実装とエディタ側操作の棲み分け
マテリアル、Niagara、レベル、ビヘイビアツリー、UIが絡む部分は自分でエディタ側で作りました。
ビヘイビアツリーに関しては必要なタスクやサービスはC++で実装するようにしました。
UIに関してもC++で機能は実装して、極力それを呼び出すだけにしました。
AIの学習不足
最新のUE 5.5で開発していましたが、当然のことながらAIが学習していることもなく…
ただ、最新の機能を使ったりしなければそんなに問題はなかったです。
既存コード(この場合はエンジンコード)を参照することで、破壊的な変更にも対応できていたと思います。
そもそもそんな問題が起きるような変更入ってなかった気もしますが。
一生エラーを解決できないというのも、結局は学習不足に起因するところもあるのかなと。
見えるソース外へのアクセスの困難さ
BPは言わずもがな、データドリブンなGAS(Gameplay Ability System)とも相性が悪かったです。
また、マクロが展開される部分にも弱く、マクロで書かせた内容が、修正の段階でまるっと展開したようなコードになったり、使えないものを追加されたりと散々でした。
特にGASに関しては最初は使用しようと思って進めていましたが、GameplayTagとAIの相性の悪さも相まって断念し、レガシーな実装をする方向に舵を切りました。
仕様や設計側でしっかり固めれば作れたかもしれませんが、そこまでいったら自分で実装した方が早いという状況になりそうな気がしました。
総括
失敗したこと
成功したこと
実際に作ったドキュメント類
他
まだまだ書いてる途中
見切り発車がすぎる