11月までの進捗状況

どうもです。毎月月末になって焦りだすうｐ主です。11月までのきょだいむすめしみゅれーたの進捗状況について報告したいと思います。さて気になるゲームの開発状況ですが…今月も先月より進めているゲームオブジェクトの作成作業がメインとなってしまっているので目に見える成果というべきものがあまりないのが現状になります。申し訳ございません…。

ただ今月末にあったAssetStoreなどのBlackFridayセールを利用して前回の課題だった音素材を買いあさることができました。まだSE関連のシステム構築は済んでいませんが、テストとして簡易的に音を付けてみました。それが下記の動画になります。

（シーン内の素敵な看板は”すぺいす”さんの『制作途中のワールドに置く看板』です。boothでダウンロードできます。）

動画を見ればわかる通りスパークの効果音が入っていません。現状破壊モーションが始まったと同時に時間差でスパークが発生するようにしているのですが、このスパークのインスタンス化と同時に音を再生すると音の重なりが出てしまう問題があるので今は削除しています。まぁ一つのスパークごとに一つのSEを連続で鳴らすのではなく、スパーク全体を一纏めとしたSEを付ける方が良いと言う事でしょうね。ここはもう少し工夫が必要そうです。

また効率的なSE関連のシステム構築も重要でした。最初は建物ごとにオーディオソースを入れようかと思っていましたがこれをやるとメモリを消費しすぎるのでプールした方がやはり効率的な様です。こちらもテストしながら進めていこうと思います。

さておき、来月も素材作成がメインとなるのであまり大きな変化が期待できないと思われますが気長にお待ちください。なお余談ですが、EasyRoads3Dで使える道路系素材をCGTraderやその他素材サイトで探しまくっていたのですが…全然見つからないのでもう諦めてとうとう何度も挫折しているBlenderに手を出しました（今度は挫折できないな…）。と言っても必要なのは交差点であったりインターチェンジやジャンクションなのでそれほど難儀はしないと信じたいです…。それでは今回はこの辺で。

なお余談ですが、Unity内に建物破壊で使用するメッシュオブジェクトが大量に出来たせいでUnityが開くまでに10分近くかかるようになりました…。むろんプロジェクトデータは内臓SSDに保存してあるので読み込みは速い方なのですが流石にメッシュオブジェクトが30000以上もあると非常に遅くなる様です（しかもまだ半分しか終わっていない）。まぁ一度読み込ませれば動作自体は普通です。とはいえUnityだけでメモリ30GB消費はキツイですね。オープンワールドゲームの開発ってとてもシビアな世界の様です。

10月までの進捗状況

どうもです。10月までのゲームの進捗状況について報告します。

前回の課題

先月末にリリースしたVer2.0.8の課題はゲームを快適に遊べるためにもオブジェクトの最適化が必要というものでした。そこで現在は主にゲームで使用する素材の作成と最適化作業を行なっています。この一ヶ月はステージ作成のノウハウを蓄えたり、ビルの破壊可能オブジェクトを延々と作成したりと正直苦行のようなことをしていました。ということで簡単にこの一ヶ月に行ったことを（忘備録も兼ねて）振り返ってみたいと思います。

Rayfire for Unityでビル破壊

これは二年前くらいに買って放置していたアセットです。AssetStoreで買ったものって本格的に使い始めるまで自分の場合１年くらいかかるっぽいです（その前の作業が終わらないのが一番の理由）。

さておき破壊系Assetの中でもRayfireは高価な部類に入るだけあって機能はとても充実しています。このアセットの中で今回特に使っているのがアニメーション作成機能です。今までの破壊表現ではvoronoi形状に破壊したオブジェクト一つ一つに物理演算と衝突判定を入れて建物を崩壊させていました。そのため複数のオブジェクトを破壊するとリソース喰いする素材が溢れてフリーズするという現象が起きていました。これを回避するにはやはり衝突判定と物理演算を無くすというのが一番の方法でしょう。コンシューマー向けゲームの破壊表現を観察していると（一部例外を除き）当然ながらアニメーションで行なっていると思われるので、最適化の方法としては間違ってはいないと思われます。そこで登場するのがRayfireのアニメーション作成機能になります。Rayfireにはエディタ上（テストプレイ）で物理演算で破壊したオブジェクトのモーションを保存する機能がついており、それを仕様することで以降はアニメーションとして利用することができます。つまり粉砕したオブジェクト一つ一つの落下軌道の座標をアニメーションとして保存できるので、完成したオブジェクトからは物理演算と衝突判定というリソース喰いの要素が排除できるという事になります。まぁこれを手作業でやってたら一生終わらないことでしょうね。最終的に出来上がるオブジェクトは破壊前の建物（アクティブ状態）と破壊後のオブジェクト（非アクティブ）とエフェクト（非アクティブ）で構成され、プレイヤーが接触するとアクティブ状態がリバースになるといった感じです。これによってかなり軽量化することが可能になりました。

ちなみに100個のビルを同時に破壊するテストを行ったところ、物理演算を使う場合とアニメーションのみの場合を比較したら10倍くらいの差がありました。

差が出たのはやはり物理演算だと思われます。プロファイラーを見るとオレンジ色の物理演算はオブジェクト同士が連鎖的にぶつかるごとに増えるので処理が重くなることがわかります。一方アニメーションによる負荷は常に少ないことがわかりますね。

欠点としては建物の崩壊をアニメーションにすると破壊表現が単調になるというものがありますがそこは建物の種類で十分カバーが可能でしょう（同じ様な動きをしていたのはこのせい）。また上記のアニメーションと合わせて破壊オブジェクトの一部をパーティクルシステムに置き換えているので軽量化の一助にはなっていると思われます。ただ問題はこの素材作成がかなり苦行に近い作業ということで…Youtubeや音楽を聴きながら作業していますが未だに1/10くらいしか終わっていません。

作業内容としては以下の通りです。

①建物のメッシュからvoronoi形状のオブジェクトを作成する。この素材をエクスポートしてプロジェクト上に保存する。
②作成したvoronoi形状郡の親オブジェクトにRayfireRigidを入れたのち、エディタ上でRayfireRecorderの設定する。
③エディタ上でシーンを再生してアニメーションキーフレームを保存する（自動保存で大体1分くらいかかる）。
④作成したvoronoi形状郡の親オブジェクトから物理演算と衝突判定を排除する。
⑤破壊前の建物と破壊後の建物を一つのオブジェクトにまとめる。
⑥制御用のスクリプトにオブジェクトやエフェクトや紐付けしていく。
⑦テストプレイで確認

と、こんな感じの作業を行なっています。大体ひとつの素材を作るまでに10〜15分かかるのでかなり気が遠くなりますね。エディタ作業で完結できるのは楽で良いのですが、自動化することが難しくなるところがネックですね。以前はpyautoguiを使用して自動化していましたが、最終的に自分が確認しなければならない以上、これ以上の簡略化はそれほど時間短縮にはならなそうです。なお残りの建物は200くらいあります。作業が完了するのは年末あたりではないでしょうか。まだまだ遠いですねw。

またその他のアイデアとしては今回プレイヤーのサイズごとに破壊演出を簡略化させる試みを入れてみました。早い話LOD（Level of Detail）ですね。一般的なゲームなどではプレイヤーのサイズが極端に変わることはないので軽量化にはカメラで写っていないオブジェクトを描写させなかったり、背景として同化させるべく立体オブジェクトではなく二次元スプライトにしてしまうなどの試みが行われていますが、プレイヤーのサイズが大きく変わるこのゲームではこれらの手法が全く使えなくなってしまいます。そこで今回はプレイヤーの現在スケールを取得して、それに応じて破壊演出を簡素化する方法を取り入れてみました。先述した通り崩壊用のオブジェクトには100～500くらいのオブジェクトが入っているのですが、これらを一斉にアクティブ化させると重くなります。この破壊演出LODはこのアクティブ化させる頻度を制御することで可能な限り処理を緩和させようというのが狙いです。プレイヤーが1～10スケールだと破壊は詳細に描いた方が良いですが、プレイヤーのサイズが100倍になれば足元にはそれほど目を向けなくても良いだろう、という訳ですね。この手法を使う事でPCのスペックにもよりますが一応はフリーズすることはなくなりました（上のテストではこのLODを使っている）。

LODなしだとそのままアクティブ化されますが、LODありだと一瞬遅れてオブジェクトがアクティブ化されます（細かい所だと炎や煙などのエフェクトも減らしている）。オブジェクトが非アクティブでもアニメーション自体は進行しているのでアクティブ化されると同じキーフレームの位置に動いています。まぁ若干ラグがあるので違和感は感じますが巨大化していればそれほど問題はないでしょう。ただFreeLookCameraでプレイヤーのサイズとは違ったところから観察するときにどうすればよいのかという問題が残っていますね。こちらはオクルージョンカリングの様なものを優先させるような機能をいれれば解決できそうですが…現状どうするのかは未定です。

ということで、この様な作業を前回のアプデ以降延々としていました。長い道のりですが、これによってゲームプレイは快適になると思われます。

EasyRoads3D

こちらは昨年買った道路系のアセットになります。このアセットは知っての通りterrain上に道路やフェンスなどを作成するアセットで、これによって下道から高速道路、橋、トンネルなど様々な道路設計ができます。3時間くらいの動画を全部見たので使い方は大体掴めました。

今まではFantasticCityGeneratorを使用して一個で完結していましたが、これを使用することでより広大なマップの作成を目指しています。まぁ街制作はセンスが問われますが…そこはまた別の問題なので今回はスルーします。さておき、このアセットは当然ながら道路を作成するために買ったのですが、使い方を学んでいくうちに別の使い方が可能であることがわかりました。それが道路を引いた場所に応じて建物が配置できるというものです。このEasyRoads3Dは道を引いた後に街灯やガードレールなどプロップを自動配置するSideObjectという機能があるのですが、使い方によってはこれを利用することで道を引きその周囲に建物が配置できるというわけです。ちなみにTerrain上に道を引いてその周囲に建物を自動生成するアセットには「CiDy」というものがありますが、EasyRoads3Dでもやり方次第ではこれが可能でした。実際にやるとこんな感じです。

こんな具合に作成することが可能です。時々エディタがバグるので完璧に制御することは難しいですが方法としては確立しつつありますね。これで街製作が捗りそうです。またサードパーティ製の素材と合わせることで自分好みの道路を作れました。こちらはboothで購入したchgmworksさんの道路素材と合わせたものです。日本の高速道路っぽい感じのものが簡単にできました。

今後は道路系の素材を集めてどんどん連結していけたらと思います。

来月予定

最後に来月の予定ですが今月と同じく素材づくりがメインになってしまうのでその進捗状況の報告がメインになると思います。目標は街に使用する道路のプロトタイプぐらいは完成させたいところですね。それではまた次回もよろしくお願いします。

ちなみに今回のキャラはVRoidでツインテールを作成する練習として作ったキャラになります。ツインテールは難しいですね。