【CEDEC 2018】大規模開発におけるUnityの“弱点”解消法が語られたポケラボの講演「SINoALICE -シノアリス-におけるUnity活用術」をレポート

一般社団法人コンピュータエンターテインメント協会（CESA）が、8月22日～8月24日までの3日間、パシフィコ横浜にて開催した国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2018」（CEDEC 2018）。

本稿においては、8月24日に実施されたポケラボによるショート講演「SINoALICE -シノアリス-におけるUnity活用術」の内容をお伝えしていく。こちらの講演にはポケラボのUnityエンジニアである加茂雄吾氏が登壇し、Unityでのゲーム開発におけるアドバイスが披露された。


▲Unityエンジニアの加茂雄吾氏。『SINoALICE -シノアリス-』の開発に立ち上げから参画し、Unityを用いたクライアント設計と実装を担当している。

自らを“Unity大好きおじさん”と形容する加茂氏は、ポケラボ内では社内のUnityエンジニア育成チームのコーチを務めた、自他ともに認めるUnityのスペシャリストだ。そんな加茂氏が本公演でテーマとしたのは「大規模開発におけるUnityの弱み」そして「弱みの克服法」である。

まず、加茂氏は「Unityの弱み」について、仕様上「同時に複数人で同じシーンを編集できないこと」を取り上げた。大規模なチームによる開発において、コアとなるシーンに触れられるのが1人だけとなると、開発スピードのボトルネックとなってしまう。

その克服方法として提示されたのが「マルチシーンエンディング」「メッセージシステム ExecuteEvents」「FSM（ステートマシン）」の3つ。ここでは、それらの詳細を個々に紹介していこう。



 

■マルチシーンエンディング

「マルチシーン」は、Unity 5.3で追加された複数のシーンを同時の編集する機能だ。これを活用すれば、ひとつの画面を個別のシーンに分割して編集することが可能となる。

ここで例に挙げられたのが『SINoALICE -シノアリス-』のマイページ画面だ。こちらでは、各画面で共通のヘッダーやフッダーなどをCommon Sceneとして分離し、MyPage SceneおよびDont Destory OnLoad Sceneと足し合わせる形で構成されているという。



また、別の例としてクエストシーンについても解説された。クエストシーンは、キャラクターのアクションなどを現すField Scene、ダメージなどの情報表示を担うUI Scene、それらの各画面に司令を送るLogic Sceneの3つに分割管理されているとのこと。






これら3つのシーンを別々のエンジニアが開発することで、これまで1人で開発せざるを得なかったボリュームあるシーンの製作を、複数人で分担可能となる。Logic Sceneを除く各シーンの開発ボリュームの差（コード量、およびオブジェクト数）にも大きな差はなく、均等なタスク調整も実現できているようだ。




こうした開発スピード向上にとどまらず、マルチシーンエンディングを用いた開発には、バグを低減する効果もあるという。

まず加茂氏は、バグが発生しやすい環境を「シーン内のモジュールが非常に密結合な状態にある状態」と定義。マルチシーンエンディングを用いて各シーンを明確に分割すれば、階層構造が強制的に保たれた疎結合なコードを実現できると語った。




 

■メッセージシステム ExecuteEvents

ExecuteEventsは、特定のインターフェースを持つコンポーネントを一括で操作する機能を持ったメッセージシステムだ。これを用いることで、一部のタスクを軽減することができる。

『SINoALICE -シノアリス-』においては、クライアントエンジニアとUIエンジニアがペアを組む形で画面を作るケースが多いようだ。こちらの開発は、その分担構造を前提とした内容となる。

加茂氏は実装例として、画面上に“報酬A”が表示され、アイコンタップで詳細画面に移行する構造を取り上げた。これを、報酬Aのアイコンにイベントリスナ（onClickなど）を登録したとしても、単に一度実装して完成するだけであれば問題ない。しかし、実装後の仕様追加が発生した場合、クライアントエンジニアとUIエンジニアの双方に追加タスクが生じてしまう。






こうした仕様変更は「ゲームの仕様を洗練していく過程で発生する事を前提」として、UI変更はView側のみで完結させるのが最善だ。ExecuteEventsを用いる事で、それが実現可能になるとのこと。

ExecuteEventsでは、ControllerとViewの間でインターフェイス（Event Handler）を定義し、Viewがイベントを送信し、Controllerが受信する形式を取っている。



以上の構造上、それぞれのコードは疎結合な形が保たれるため、先の例のような仕様追加が発生した場合でも、View側にのみ追加実装が発生する形を実現できるというわけだ。




▲実際に用いられているコードも公開された。
 

■FSM（ステートマシン）の活用

ここまでで解説された内容は、いずれも「疎結合なコード作成」を企図したものだ。最後となるFSMもまた、それを実現するための手法として紹介された。

ここで例に挙げられたのは『SINoALICE -シノアリス-』において、15対15のオンラインバトルが展開される「コロシアム」の画面だ。コロシアムは内には「フィールドモード」「蘇生モード」「ギルドシップモード」といった複数の状態が存在し、それぞれを管理する必要がある。





開発の当初は、各モードが密結合でバグ発生率の高い状態になっていたが、FSMを導入することでモード別に疎結合な実装を実現したという。会場では、実際に使用されている『SINoALICE -シノアリス-』のFSMが公開された。

各モードが明確に分割されており、モードの移り変わりが視覚的に理解できるのがFSMの大きな特徴だ。例えばFSM上で「蘇生モード」から「ギルドシップモード」へはラインが接続されておらず、直接的な遷移が発生しないことを示している。また、それらが互いを参照する事はなく、疎結合な構造を保つ助けとなっている。



このように、複数の状態を持つシーンの管理・製作でFSMを活用することで、コード内の複雑な状態変数・条件分岐を排除しする事が容易となる。

大規模開発に向かないとされるUnityだが、こうした機能の活用によって分解・分担が可能となる部分も存在する。加茂氏はそうしたUnityの有用性を紹介し、本セッションを締めくくった。




   

公式サイト

公式twitter

App Store

Google Play

© 2017, 2018 Pokelabo Inc./SQUARE ENIX CO., LTD. All Rights Reserved.