Unity1週間ゲームジャムに参加してきました
この記事は LOCAL Students Advent Calendar 2021 の24日目の記事です。
はじめに
Unity1週間ゲームジャムという、Unityを使って1週間でゲームを作るイベントに参加してきました。
今回のお題は「正」ということで、正月な雰囲気のオンライン対戦カードゲームを制作しました。
制作したゲームは、unityroomというサイトでブラウザ上で遊ぶことができます。
(対戦ゲームなので、2人いないと遊べませんが...)
↓遊んでいる動画↓
ブログ用デモ動画 pic.twitter.com/Ob2yR3cw8Y
— さんたろ@日常 (@Santaro_daily) December 29, 2021
↓ソースコード↓
この記事では、今回のゲーム制作にあたって特に意識した、設計についての話と、簡単な反省を書いていこうと思います。
設計
「アウトゲーム」と呼ばれる、メニュー画面などゲーム本編以外の部分はゲームジャンルによらず比較的一般化しやすいです。
UIイベントに応じてデータを表示や画面の遷移をする、という点はWeb開発にも通ずるところもあります。
一方で「インゲーム」と呼ばれる、キャラクターを操作してゴールを目指す、などのゲーム本編の部分は一般化が難しいです。
パフォーマンスを突き詰める点からも、インゲーム部分の実装は冗長にできなかったり、方針がバラバラだったりしがち(あるいは無い)な印象です。
今回は「カードゲーム」という、比較的アウトゲーム部分に似た動きをする点もあり、「インゲーム・アウトゲーム全て同じ設計でいこう」となりました。
今回の設計
MVPパターンを意識し、View、UseCase、Modelに分け、VContainerを利用して依存性の注入をしています。
イベントの発行にはUniRxを利用しています。
下の図には記載していませんが、Photonによる送信処理と受信イベントの発行もViewが担っています。
反省
ゲーム性も相まって、今回の設計はアウトゲーム・インゲーム共に良い方向に働いたと感じています。
今回の開発で、実装に関する問題の原因特定に30分以上かかることがなかったのは、設計のおかげだと思います。
一方で、アクションゲームなど、衝突判定や時間経過が絡む処理や、パフォーマンスを求められる処理には不向きに感じました。
＜メリット＞
- プロジェクト全体で、役割分担や処理の流れの統一
⇒問題があったときに原因箇所の検討がしやすい。他人のコードなら尚更 - MonoBehaviour非依存、1クラスの責務の減少、DIの利用
⇒クラスの差し替え・テストが容易に
＜デメリット＞
- クラスやインターフェースの数が増える
⇒コンパイル時間が長くなる。Assembly Definitionなどを利用してアセンブリを切り分けるなどで対処？ - 余分な処理が増える
⇒「ボタンが押されたら特定のGameObjectを表示する」など、Modelを参照しない処理はViewだけで完結させるべき？
おわりに
今回の開発を通して、思ったよりも設計の恩恵を感じることができたのはとても嬉しいです。
一方で、「同時に2人以上プレイしないと遊べない」という対戦ゲームはUnity1Weekに非常に不向きだと感じました涙
一番の反省点はここです涙
次回のUnity1Weekでは、今回作ることを諦めたSlay the Spireのようなデッキ構築型ローグライクカードゲームに再挑戦したいです。
