この記事は夏のブログリレー29日目の記事です。

こんにちは。25Bのfken_57です。今回は、1か月でゲームを作る部内ハッカソン「1-Monthon」にソロで参加した体験を振り返ります。

制作したのは、量子の「分裂」をモチーフに、複数の状態を同時に管理しながら解くパズルゲームです。この記事では、特に設計とAIを活用した開発の進め方を紹介します。

ゲームのテーマをどうやって決めたのか

最初は、できるだけ複雑なパズルを作りたいという気持ちから始まりました。複数の状態を同時に管理する仕組みが面白そうだと考え、「分裂」という発想から、量子をモチーフにしたパズルへとテーマを広げていきました。

設計

今回の開発で最も力を入れたのは設計です。UnityでUIの責務を分離する方法の一つにMVPがあります。MVPでは、PresenterがModelとViewを仲介します。

一方、今回のパズルゲームには、オブジェクトが複数に分裂し、その状態によって挙動が変わるという特性があります。そのため、Model内部を単一の層として扱うと、複雑なルールや処理順序、さまざまなブロックの挙動が集中し、Modelが肥大化する問題がありました。

そこで、今回のModelは、複雑なルールと依存関係を扱うWebサイトのバックエンドに近い性質を持つと考えました。バックエンドの設計手法としては、依存関係を整理しやすいOnion ArchitectureやHexagonal Architectureが知られています。今回は、Modelに相当する部分にOnion Architectureの考え方を取り入れることにしました。

具体的には、次のような構成です。

• D Domain
• U Use Case
• I Infrastructure
• H Handler
• P Presenter
• V View

まさかのDUIHPVモデルです。依存関係は Infrastructure → Domain ← Use Case ← Handler ← Presenter → View となっています。一般的なMVPの Model ← Presenter → View と比べると、Modelに相当する部分を複数の層へ分割した構成だと捉えられます。画像で見ると、より分かりやすくなります。

このような方針でアーキテクチャを設計しました。DomainからHandlerに相当するバックエンド部分については、まず私がロジックや内部クラスを大まかに組み、AIが全体構造を把握できる土台を作りました。その後、考案したアーキテクチャをもとにAIが残りのクラス設計を生成し、私がレビューしながらすり合わせを進めました。

設計を守る仕組み

AIを活用した開発では、設計方針を宣言するだけで、生成されるコードにその方針を守らせるのは難しいと感じました。そこで、GitHub Actionsの多くの構文と互換性を持つGitea Actionsを活用し、プルリクエストやプッシュを契機に自動検証を実行するワークフローを設定しました。具体的には、次の検証を行いました。

• Validate assembly boundaries
• Validate source static rules
• Validate scene and prefab assets
• Validate generated puzzle catalog

これらは、アセンブリ間の依存関係、Unity内でのGameObject.Findの使用、シーンやPrefabの不正な設定、生成したパズルステージの妥当性を検証するためのものです。

これにより、AIが生成した変更に設計違反や事前に想定した問題が含まれていた場合、CIで機械的に検出できるようになりました。ただし、検出できるのは、あらかじめ検証項目として定義した範囲に限られます。

実装

期日が迫っていたこともあり、実装では設計を前提に生成AIを活用しました。アーキテクチャとCIを整え、実装方針を明確に示しながら進めたことが功を奏し、開発は順調に進みました！

実装/UI/作問

実装

期日が迫っていたこともあり、実装では設計を前提に生成AIを活用しました。アーキテクチャとCIを整え、実装方針を明確に示しながら進めたことが功を奏し、開発は順調に進みました！

UI

UIは締め切り直前に集中的に開発しました。Figmaを使ってさまざまなデザインを検討したものの、グラフィック制作の経験が少なかったこともあり、ゲームへ組み込むと視認性に問題が生じて苦戦しました。最終的に、展示会では発展途上のUIを使用することになりました。
写真は試遊会で出した未完成のUIになります。所々読みにくかったりする部分があったので、実際に作ってみて難しいなという感想になりました。

開発し終わった後に、余りに見た目が素朴だなと思って、延長戦をやりながらUIの改善に挑戦しました。

作問

残り1日で18問を作成しました（汗）。プレイしながらルールを少しずつ理解できる構成を目指しました。作問については、教育的な観点から見ても悪くない構成にできたと思います。
なお、作問するにあったってCodexにVibe Codingで作問エディタを作らせたりしました。今のLLM怖いですね、という感想に。

写真はLLMに作らせたjson出力可能な作問エディタになります。

まとめ

今回の1-Monthonは、「1人ですべてを作る」というよりも、人間1人とLLMが協働して開発する取り組みになりました。チーム開発に近い分業を進めるうえで、設計やCIによるガードレールの設け方を練習できたのは大きな収穫です。一方、UIやグラフィックにはまだ未熟な点が多かったため、今後はその技術を伸ばし、ゲームとしての表現力を高めていきたいと思います。

余談

今回のゲームのGithubはこちらになります
ゲーム自体はこちらで遊べます

明日のブログの担当は@Cd_48です。