ゲーム起動時、タイトル画面のシナリオの読み込み時間の削減方法につきまして

[h.tsuch...@gmail.com]

宴     3.3.9

Unity 2018.1.3f1 64bit win 使用歴１年

ゲーム起動時のタイトル画面のシナリオ解析処理により

暫く固まるため、その硬直時間を削減したいのですが

何か回避策はございますでしょうか。

現在、製作中のシナリオの量は合計で４万行近くあり

商業フルパッケージ並みのボリュームになっております。

硬直時間はUnityエディター上は数秒なので気にならないのですが

リリース予定の Android端末では数分の硬直発生となっています。

(P-02E RAM:2GB CPU:1.5GHz クアッド)

また AdvEngine の bootAsync を true で試しましたが

読み込み完了前に本編をスタートさせると以下のエラーとなりました。

"XXX: はジャンプ先が存在しないシナリオラベルです"

プロファイラで拝見すると

AdvImportScenarioSheet クラスの CreateCommandList メソッド内で

時間が掛かっているように見えました。

とはいえ、そもそもシナリオの量が大きすぎるため

宴の現状の機能で回避が難しいようでしたら

こちらでコード書き換えするなど解決策を模索したいと思います。

何卒よろしくお願い致します。

[マッドネスラボ]

詳細なご連絡ありがとうございます。

先日、宴をバージョン3.4.0にアップデートして、その時に少しだけ高速化しました。

ですが、無駄に呼ばれている重い処理をコメントアウトしただけなので、おそらくそこまでは解決にはならないと思います。

現在のところ、以下の手法でチャプターに分けて使うシナリオを制御するやり方があります。

http://madnesslabo.net/utage/?page_id=375#i-4

ただ、これもゲームの設計にも関わるので、根本的な解決にはならないかもしれません。

エディタ上で数秒なのに、Android上で数分というのは、ちょっと想定外でした。

おそらくですが、シナリオの初期化時にオブジェクトをたくさんnewしすぎて、GCが極端に頻繁に走ってしまっているのだと思います。

この問題は、こちらでも改善したいと思っています。

おそらくこちらの問題と同じかと思います。

https://groups.google.com/d/msg/utageuser/w62Hj7kKx_Q/dG8n5u7yAAAJ

根本的には設計レベルで改善しないといけないので、そこまではちょっと難しいのですが、高速化できる部分は高速化しようと思っています。

よろしければ、こちらに問題を再現可能なプロジェクトを送信していただけるでしょうか。

シナリオの初期化部分の検証ができればよいので、送信プロジェクトが大きすぎるようであればリソースなどは省いてもらっても構いません。

http://madnesslabo.net/utage/?page_id=9349

[h.tsuch...@gmail.com]

大変返事が遅くなり申し訳ありません。

ご返信頂き有難うございます。

Ver3.4.0 で検証したところ読み込み時間が 3,4分 から 約40秒 まで減りました。

確かにタグクラスの new 辺りがネックになってそうですね。

チャプター分けの回避策も有難うございます。

頂いた別のQ&Aリンクも正に同じ状況でした。

再現可能なプロジェクトに関しましては

版権物を預かっているためそのままお送りは出来ないのですが

もしこれを元に再現データがご用意出来ればお送り致します。

また、これは私の都合で恐縮ですが

現在PCで既にリリースされている大量のADVゲームを

宴で移植させて頂く計画がございますので

もしこの辺りが解決されれば

商用で採用しやすくなり大変嬉しく存じます。

また、以下は現状のプロジェクトの規模感や

現状判明している問題等になります。

特に質問ではなくあくまでご参考までに。

手軽に報告する場が無かったのでこの場で恐縮です。

〇現状の規模は以下になっています。

・Resources容量

　約 550MB（ダイシングや背景のjpg化 など諸々対策済み）

　元のPC版のデータは 約3GB

・シナリオスクリプト行数

　約3万5千（最初は4万行でしたが最後にコメント等を削減）

・各要素ファイル数（数ファイルのグループは除外）

　Character 680

　BG    110

　Event 625

　Voice 2万

　SE     460

〇今回の開発で判明した問題等

・上記構成でエディタ上で Resources フォルダをリネームすると

　Unityがフリーズすることが判明しています。（PCは Win10 RAM:16G  CPU:i7 3.4GHz）

　そこで外部でリネームや移動しても再インポートが行われ２時間以上の待ち時間が発生。

　（Unity側の仕様の問題と思いますが AssetPostprocessor は未調査です）

　そのため Resources を含めずに Android の apk 作成は手軽に行えず

　現状非常に困難となっておりますが

　ビルド用プロジェクトをコピー作成し問題は回避出来ました。

　（IPreprocessBuild, IPostprocessBuild での移動も時間がかかり断念）

・上記構成で Resource Converter を使用すると

　コンバート中消費メモリが膨れ上がり10GB以上占有されます。

　

　また Rename Type を Rename にしてコンバートするとフリーズします。

　（再起動後、リネーム自体は行われていました）

[マッドネスラボ]

詳しい返信ありがとうございます。

＞Ver3.4.0 で検証したところ読み込み時間が 3,4分 から 約40秒 まで減りました。

そんなに減りましたか。

多くて30%くらいの高速化だと思っていたので、意外に効果があったようでよかったです。

＞再現可能なプロジェクト

もし、プロジェクトを送っていただくのが難しいようでしたら

Utage\Scripts\ADV\Command\AdvCommandParser.cs　の　CreateCommand内を以下のように書き換えてみてください。

Profiler.BeginSample("CreateCommandDefault" + id);　とすることで、コマンドの種類別にオブジェクト生成のプロファイルができるようになります。

（ただこれをしてしまうと、文字列の連結を毎回行うことになるので、これ自体が負荷になる可能性があり、正規版のコードには入れていません。手動で書き換えたのちに戻してください。）

そうすると、プロファイラーの結果はこのように、コマンドの種類別に計測結果が得られると思います。

何か特定のコマンドの作成がボトルネックになっているのであれば、そこを対策すれば解決するかもしれません。

たとえば、スクショのサンプルですと「CreateCommandDefault Parameter」が一番重いですが、これはフラグ操作などで使うParamコマンドです。

Paramコマンドは文字列で書かれた数式を、プログラムで解析しているため重い処理になっています。

ただ、これは必ずしもこのタイミングで行う必要がなく、少し工夫すれば処理を分散させることができます。

ボトルネックになっている部分がわかれば対策がしやすくなるので、上記のようなプロファイラーのスクリーンショットなどをいただければと思います。

＞〇今回の開発で判明した問題等

ありがとうございます。

AssetBundleの問題やインポート時間の問題は、Unity開発で昔から問題になっている部分で、Unity公式でないと解決が難しそうです。

おっしゃる通り、ビルド用のプロジェクトを作るのが一番効果がありそうです。

もしくは・・・

・本来のプロジェクトAを作る。ここにはリソースを含めない。

・AssetBundleを作成するプロジェクトBを別途用意して、出力先にプロジェクトAのStreamingAssets以下を指定する

という、AssetBundle作成用のプロジェクトBを別途用意するパターンが考えられます。

StreamingAssets以下に置いたファイルは、インポートの対象とならないため、ビルド時の再インポートの問題も回避できます。

または、AssetBundleを使う目的がファイルサイズの削減なのであれば、

AssetBundleは作成せずに、Resourcesのみを使うのも良いかもしれません。

Resourcesを使った場合にファイルサイズが増えるのは、圧縮がかからないためなのですが、

apkファイルの場合（iPhoneの場合はストアにアップロード後）全体に圧縮がかかるため、そこまで違いはないという話も聞いています。

また、最近のUnityであれば、PC向の出力であっても、全体に圧縮をかけるエディタ拡張方法があります。

ただ、実際にどのくらい違いがでるかは私もわからないです。

＞　（IPreprocessBuild, IPostprocessBuild での移動も時間がかかり断念）

情報ありがとうございます。私のほうで対策できるとしたら、この部分のエディタ拡張をするくらいしかないと思っていたのですが、

あまり効果が見込めそうにないのと、ビルド環境はやはりプロジェクト個別に環境を合わせるべきだと思い手を出していませんでした。

＞Resource Converter 

おそらく全てのリソースをロードせざるをえないせいだと思います。

Renameも同様にメモリが足りないなどで、なんらかの原因がありそうです。

Unity自体の仕様の可能性があり、ちょっと対策の目途が立ちません。

この辺は宴ではなく、Unityそのものの問題である可能性があり、

大手の開発環境では、ビルド専任のエンジニアが対策を行っているケースもあると聞いています。

根本的にResourcesもAssetBundleも問題が多いもので、昔からUnity公式でも問題視されていました。

Unityは現在それに代わる新しい仕組みを開発中です。

https://www.youtube.com/watch?v=Rls8e7tZUNE

https://www.slideshare.net/UnityTechnologiesJapan/unite-2018-tokyo-96499382/UnityTechnologiesJapan/unite-2018-tokyo-96499382

ただ、もうすぐ正式リリースではあるのですが、宴がこの仕組みに対応する予定はまだないです。

というのも、上記のビルド時間の問題が解決するわけではなさそうなのと、

新しい仕組みはUnity公式の不具合が必ず多発するので、私個人ではサポートできないためです。

もしそちらに移行するのであれば、一応こちらにファイルマネージャー自体をカスタムする手法をまとめてありますので、参考にしてください。

http://madnesslabo.net/utage/?page_id=464#i

[マッドネスラボ]

追記：AdvEngine.IsWaitBootLoadingが非同期のときに正常動作していなかったのを、Utage3.4.2で修正いたしました。

非同期ロード時に不具合が出ていた場合、アップデートを試してみてください。

[h.tsuch...@gmail.com]

返信が遅くなり大変申し訳ございません。

その後プロジェクトが無事完了し確認を怠っておりました。

アップデートのご連絡を頂き誠に有難うございます。

また近いうちに新タイトルに着手するかと存じますので

その際に是非利用させて頂きます。