これはKMCアドベントカレンダー22日目(？)の記事です。気付けば今年のアドベントカレンダーももう終盤ですね。

はじめに

はじめまして。kmc-id:kataです。京大マイコンクラブとあくあたん工房というサークルに所属しています。

最近はアドベントカレンダーに嬉々として登録し、直前になって書く内容が無いと周りに漏らし、結果記事を落とすという超絶厄介な活動をしています。ごめんなさい。

また、現在Clocklockというゲームを開発しています。デジゲー博2018に参加したりもしました。

kmc.hatenablog.jp

Clocklockとは？

Clocklockとは、一言で言うと時を止めて障害を突破しながら進む2D横スクロールアクションゲームです。

プレイヤーは主人公を操作し、様々なギミックや敵が配置されたステージを駆け抜けていきます。

開発にはUnityを使用し、サークル内の10人程のメンバーと共に開発しています。

今回は、そんなClocklockというゲームを開発する上で困った点とその改善方法を一つ書けたらなと思います。

開発上の問題

今回、Clocklockというゲームを作る上で一つ重要な仕様として掲げたのが、「ステージは全て繋がっている」という点です。つまる所、某のカービィや某ーパーマリオブラザーズで用いられているような、扉や土管といった暗転等を要する移動手段をなるべく用いず、なるべくステージ内でのプレイヤーの操作不能時間を減らそう、という事ですね。某ックマンを想像して下さると良いかもしれません。

この仕様の善し悪しについてはひとまずこのお話の対象外として、Unityでこの仕様を実装する為に最も簡単な方法といえば、ステージに存在するオブジェクトを全て1つのシーン上に置く、という事が考えられます。

……まあ、そんなテキトーな感じで管理できる訳がありませんよね。

1ステージが非常に小さい場合はともかく、今回の様に数画面必要とするようなステージを開発する場合は、ゆうに百を超えるオブジェクトが一つのシーン上に配置される事となります。さらに、それぞれのオブジェクトは異なる挙動を持ち、それぞれのオブジェクトに対して当たっているかどうかの判定や物理演算を行います。到底人間が全てを管理できるはずもありません。

他にも、処理速度の問題があります。処理速度とステージの規模はトレードオフの関係にある、と決め付けてしまえば楽ではありますが、この状態ではあまりにもすぐステージの規模に限界がきてしまい、十分にレベルデザインを行う事ができません。

解決

この問題を解決するために、我々はUnityのマルチシーンエディティングという機能を利用する事にしました。マルチシーンエディティングとは、複数のシーンを同時に読み込む事が可能となるUnityの機能の事です。

参考にしたのはこちらの記事です。(Unity5.3時点での記事なので注意)

tsubakit1.hateblo.jp

今回の開発において、一つのステージは、唯一のシーンによって構成される訳ではなく、ある程度のオブジェクト数毎に分割したシーンを複数読み込む事によって実現される、というように定義しました。また、そのシーン毎に分割する単位の事を、セクション、と呼びます。

で、このセクションを複数読み込む事でステージを表現するのですが、何も考えずに全て読み込むと結局元のままですよね。そこで、進行状況に合わせてセクションを逐次読み込む事によって、同時に存在するUnity上のオブジェクトの数を減らし、処理を軽くしようとしました。

と、こんな感じに逐次読み込みしています。

この機能が実装された事によって、我々はステージを開発する際に、一つのステージ単位で開発を行うのではなく、一つのセクション単位で開発が可能になりました。例えば、一つのステージが八つのセクションによって構成される場合、一度に管理しなければならないオブジェクト数は単純に計算して8分の1となるのです。文明の進歩です。

また、処理速度の面に関してもこの試みはある程度は成功していて、多くのオブジェクトを含む、規模の大きいステージにおいても、適切にセクションが区切られてさえいればフレームレート等が落ちる事なく動作するようになりました。

今後の課題

先程の章で「ある程度は成功」と書いたのですが、まだまだ改善しなければならない点はあります。

上記の他セクションの読み込みや破棄はセクション切り替えの際に行われるのですが、その際に少しだけカクついてしまうのです。

なんとなく察されている方も多いとは思いますが、つまり、次セクションの読み込みや必要無くなったセクションの破棄にかかるオーバーヘッドが誤魔化しきれていない、という課題が残されているんですね。

雑に調べた感じではリソースのキャッシュ周りを良い感じにしてやればもうちょっとマシになるのかなーと思います。まあ、他の作業もまだまだ残っているのでいつ取り掛かれるのかはちょっと分かりませんが、体験が向上する事は間違いないので頑張りたいですね。

余談

この機構を採用する事によって得られた利点がもう一つあります。それは、それぞれのセクションが独立して開発可能になった、という事です。

たとえば、セクションA -> セクションB -> セクションCという状態の中セクションBの長さを変更した場合、一つのシーン上に全てのオブジェクトを配置するこれまでの設計では、セクションBに引っついているセクションAとセクションCについても調整が必要となっていました。

しかし、この機構を実装した事により、セクションBでの変更が、接続されている他のセクションに影響を与える事が少なくなりました。

この事により、既に完成しているセクションを編集する際のコストが大きく減り、また、一つのセクションの開発者が他のセクションの事をあまり気にしなくとも良くなった為、チーム開発による並列開発の利点をより享受しやすくなりました。開発をしている身としてはいっその事管理のしやすさや処理速度うんぬんというよりこちらの方が嬉しかった事かもしれません。

まあ、今思えばそんな地獄みたいな環境で開発を続けていた事自体がウソのようですが……。