Unity用ビジュアルノベルツール「宴3」開発を通しての地雷とか役立つTIPSとかのまとめ

1. Unity用ビジュアルノベルツール
開発帰還報告書 2017/5/12 時村良平
Twitter @rodostw
公式サイトhttp://madnesslabo.net/utage/
1

2. ゲームプログラマ10年ちょい
過去の主な開発実績
アークシステムワーク（株）
「バトルファンタジア」
（株）チュンソフト
「Trick×Logic」（メインプログラマ）
「もののけ大戦”陣”」（クライアント側メインプログラマ）
2
自己紹介

3. 4年ほど前から独立して
個人開発者として活動してます
3
自己紹介
ビジュアルノベル作成ツール「宴」
第一回アセットストアコンテスト
グランプリ受賞
書籍
「Unity ゲームUI実践ガイド」
スマートフォンアプリ
「ダイスふる」
「宴」でCEDEC AWARDS2016の
エンジリアリング部門にノミネート

4. ちなみに、宴は今（2017/5/12）
Unite記念セールで30%オフです！（宣伝）
4
自己紹介

5. ゲームジャムのお手伝いも何度か
今回の会場でもあるデジハリでは
「ノベじゃむ」がありまして、去年技術サポートしてたりしました
ちなみに、今年も7月にやるそうなので興味ある人はどうぞ。
5
自己紹介

6. ・Unityの情報の集め方について
・宴を作っていて、地雷が多かった場所
・バグが出にくくなるちょっとしたTIPS
・エディタ拡張TIPS
6
今日の予定

7. 公式からの情報提供がたくさんあるので
基本的にはUnityからの情報を追いかけるのが
ベストです。
7
Unityの情報の集め方について

8. Unite2017の講演は、
すでにほとんどスライドが公開されています。
英語の講演は、同時通訳つきの講演動画が後日に公開されるので
それをチェック
http://events.unity3d.jp/unite2017tokyo/session-lineup.html
8
Unityの情報の集め方について

9. さらに言うと
Unite2017の情報ですら、既に過去のUnity道場で発表済みのもの
が結構あります。
https://speakerdeck.com/unitydojo
9
Unityの情報の集め方について

10. たとえば、「uGUIの最適化」については
最適化する前にまずこれを
【Unite 2017 Tokyo】最適化をする前に覚えておきたい技術
具体的な最適化についてはこの辺を
【Unity道場】パフォーマンス最適化のポイント
【Unite 2017 Tokyo】Unity UI最適化ガイド 〜ベストプラクティスと新機能
【Unite 2017 Tokyo】パフォーマンス向上のためのスクリプトのベストプラクティス
*英語系のスライドは後日の同時通訳付きの動画をチェック
10
Unityの情報の集め方について

11. 読むのが面倒な人向けにまとめると
「まず最適化すべき場所を絞る」
「プロファイラー使って重いところを調べて、必要な部分だけする」
＊注 Uniteだと「LINQはランタイムで使うものではない」と言っていた講演もあったけど、それ
も極論かと。最適化は場所を絞るほうが重要。
「プロファイラ―は実機じゃないと正確な値が出ない点に注意（エディタ上でも大ざっぱにはわかる
のでまずはそれで）」
「UIは描画構造の再構築（バッチング処理）が重いのでなるべくそれを起こさないようにする」
「非表示にするならGameObjectのActiveのオン・オフではなく、CanvasコンポーネントのEnableのオ
ン・オフ」
「バッチングは一部のUIが変化するだけでそのCanvasの全UIに対して再計算になる点が重い」
「結果動くUIが混じっていると、Canvasの全UIが毎フレーム再計算になる」
「対策はCanvasを入れ子にしてCanvasを細かく分ける」 11
Unityの情報の集め方について

12. 公式のドキュメントやリファレンス
FaceBookのUnity助け合い所
各種書籍に、コミケで発売されるUniBook
「テラシュールブログ」はじめ、Unity系のブログやUnityまとめ
UnityJapanスタッフのSNS
その他、色々情報はあふれています。
実際、Google先生にお願いすると大抵解決したりする
12
Unityの情報の集め方について

13. 正直、「いまさらなにを話そうか」
とネタに困るくらい
13
Unityの情報の集め方について

14. なので、自分からは「こうしたらいいよ！」という
「スマートな情報」ではなく
「宴」を作った過程における
「地雷源の歩き方」について帰還報告でもしようかと
14
Unityの情報の集め方について

15. 「宴」はノベルゲームのツールです。
15
宴を作っていて、地雷が多かった場所

16. 「テキスト」と「画像」の表示
「サウンド」の再生をするだけです。
16
宴を作っていて、地雷が多かった場所

17. なんだか
かんたんそうですね
17
宴を作っていて、地雷が多かった場所

18. もう少し詳しくみると
18
宴を作っていて、地雷が多かった場所

19. 19
宴を作っていて、地雷が多かった場所
地雷原（致命的なバグが起きやすい場所）
はどこでしょう？
・エクセルのシナリオデータの構文解析
・シナリオの再生
・必要となるファイルのロード
・画像表示
・サウンド再生
・シナリオのセーブ、ロード

20. 20
宴を作っていて、地雷が多かった場所
・エクセルのシナリオデータの構文解析
・シナリオの再生
・必要となるファイルのロード
・画像表示、サウンド再生
・シナリオのセーブ、ロード

21. 21
宴を作っていて、地雷が多かった場所
こたえ
ファイルロード

22. 22
宴を作っていて、地雷が多かった場所
・エクセルのシナリオデータの構文解析
・シナリオデータの再生
・ファイルのロード
・画像表示、サウンド再生
・シナリオのセーブ、ロード

23. この辺は
作るのに時間はかかっても、
書いた通りに動く
地雷になることは
そんなにない
23
宴を作っていて、地雷が多かった場所

24. 念のために
24
宴を作っていて、地雷が多かった場所

25. かんたんに作れるわけじゃないからな！
25
宴を作っていて、地雷が多かった場所

26. 26
宴を作っていて、地雷が多かった場所
・エクセルのシナリオデータの構文解析
・シナリオデータの再生
・ファイルのロード
・画像表示、サウンド再生
・シナリオのセーブ、ロード

27. セーブ機能だけは
「どのページでもセーブロード可能」
というノベルゲーム特有の事情で大変
全ての機能ごとにセーブロードが影響するので、
拡張するごとにセーブ機能も更新しないといけない
正直この仕様がもう時代遅れ
27
宴を作っていて、地雷が多かった場所

28. 28
宴を作っていて、地雷が多かった場所
それでも書いた通りには動く

29. 29
宴を作っていて、地雷が多かった場所
ファイルロード

30. 30
宴を作っていて、地雷が多かった場所
書いたとおりに動かない！

31. 31
宴を作っていて、地雷が多かった場所
そもそも
ノベルゲームのロードと
Unityのロードの概念が相性悪い

32. 32
宴を作っていて、地雷が多かった場所
シーン切り替え
シーン丸ごとで
リソースのロード処理
Unityの
標準
ゲームの実行中
そろそろ必要そうな
リソースをバック
グラウンドロード
必要になったとき
にはロード済み
不要なリソースを
アンロード
ロード済みファイルはすぐに解放せず、
次のロードに備える。
しばらく参照のないものは解放
数ページ先のリソースを
事前にロードしておく
ノベル
ゲーム

33. 33
宴を作っていて、地雷が多かった場所
シーンに含まれない
リソースをロードするには
Resourcesからロードするのが常道

34. 34
宴を作っていて、地雷が多かった場所
がっ…
ここで地雷

35. 35
宴を作っていて、地雷が多かった場所
ノベルゲームは
リソースを大量に用意する必要がある
商業だと画像やボイスが
数千とかいうレベル

36. 36
宴を作っていて、地雷が多かった場所

37. 37
宴を作っていて、地雷が多かった場所
さらに、スマホ時代になったことで
サーバーからのDLも必要

38. 38
宴を作っていて、地雷が多かった場所

39. 39
宴を作っていて、地雷が多かった場所
こういう仕組みが必要になる

40. 40
宴を作っていて、地雷が多かった場所
サーバー
必要になったら素材をDL
普通の
ロードは
遅い
サーバー
デバイスストレージに
キャッシュ
システムメモリに
プール
シナリオを解析
あらかじめロード
ロード済みファイルはすぐに解放せず、
次のロードに備える。
メモリ使用量に応じて自動で解放
次ページ以降の素材をあらかじめロー
ドし、ロード待ちを減らす
バックグラウンドでDL
一度DLしたら、ローカルに保存
二回目以降の余計なDLを避ける
ロード
を
最適化

41. 41
宴を作っていて、地雷が多かった場所
UnityにはAssetBundleがあるじゃないか

42. 42
宴を作っていて、地雷が多かった場所
だが…

43. 43
宴を作っていて、地雷が多かった場所
宴のリリース当時の
ドキュメントを
よく読むと・・・

44. 44
宴を作っていて、地雷が多かった場所

45. 45
宴を作っていて、地雷が多かった場所
宴を作った当初（2013年）
はAssetBundleの使用には
Proライセンスが必要だった…

46. 46
宴を作っていて、地雷が多かった場所
当時個人ながらProライセンスを持っていた。
でも、アセットストアで「宴」を買う人はもっているか？
「Pro限定」の機能が売れるとは
思えなかった

47. 47
宴を作っていて、地雷が多かった場所
そもそもAssetBundle自体
当時は問題が多すぎた
ファイルサイズが大きかったり
サウンドが丸ごとオンメモリになったり
Unityのバージョンで作り直す必要があったり・・・etc

48. 48
宴を作っていて、地雷が多かった場所
なので、pngとか、wavとかmp3とか
.txtとか.binを
DLしてキャッシュしてロードする
仕組みを自作していた…

49. 49
宴を作っていて、地雷が多かった場所
だが…

50. 50
宴を作っていて、地雷が多かった場所
アセットバンドル固有の問題はなくなったが
「プラットフォームで微妙に動作が違う」
「違うどころか動かない」
というUnityのバグが大量に・・・

51. 51
宴を作っていて、地雷が多かった場所
殆どは過去の問題
ただし、最近起きているバグもある

52. 52
宴を作っていて、地雷が多かった場所
たとえばこれとか
昔のUnityでは起きなかったのに最近発生した致命的なバグ
古いグラフィックチップだと
テクスチャがロードできないどころかGPUが壊れる
機種依存バグでUnity側で再現しないらしく修正されない…
追記） 本セミナーの帰宅後、UnityのQ&Aチームから何度目かの返信があって、結果やはり再現できない模様

53. 53
宴を作っていて、地雷が多かった場所
宴3の現在は
アセットバンドルに統一している

54. 54
宴を作っていて、地雷が多かった場所
だが、それでも
多くの問題がまだある

55. ・AssetBundleだとサーバー用意しないといけない？
ノベルゲームでデータサーバーとか使いたくない人が殆ど
・Resourcesだと
PCでアプリサイズ激増→32bit機で動かない
WebGLでも起動が激重
・StreamingAssetsにAssetBundleを置いてロードすれば？
サーバーはいらない
WebGLでも起動時ではなく逐次ロードになる
55
宴を作っていて、地雷が多かった場所

56. StreamingAssetsにAssetBundleを置く
これで解決？
そうでもない →
そもそもAssetBundle作るのがやっぱり面倒
56
宴を作っていて、地雷が多かった場所

57. 57
宴を作っていて、地雷が多かった場所
・Resources
・AssetBundle
・StreamingAssetsに置いたAssetBundle
これらをプロジェクトの規模や対象プラット
フォームによって使い分けないといけない。

58. 58
宴を作っていて、地雷が多かった場所
詳しくは
宴のドキュメントに実例が

59. Unity5.6で
ゲームのビルド直前に “ファイルの退避” や “シーンの最適化”
等の処理を挟む とか ゲームに最初から含めるアセット群を圧
縮するオプション とか新機能ができたので、
この辺使えば解決しそうだけど・・・
宴3はUnity5.5だし・・・またバージョン互換気にしてエディ
タ拡張コード書いて？ そもそもこういうのってプロジェクト全
体に影響するので、宴みたいなプラグインで上書きするのも
なぁ・・・
59
宴を作っていて、地雷が多かった場所

60. 60
宴を作っていて、地雷が多かった場所
しかもこんなに苦労したあげく
「宴のファイルマネージャーいらないから
自分たちのプロジェクトで使ってる
ファイルマネージャー使いたい」
とか言われる。

61. 61
宴を作っていて、地雷が多かった場所
まぁ、当然ですよね。
こんなややこしいのは
自分たちで制御したいですよね。
拡張できる仕組みも用意しましたよ

62. 62
宴を作っていて、地雷が多かった場所
いつになったらこの沼は終わるんだ・・・

63. 63
宴を作っていて、地雷が多かった場所
ただファイルをロードしたい
だけなのに・・・

64. 64
宴を作っていて、地雷が多かった場所

65. 65
宴を作っていて、地雷が多かった場所
Unity公式で
新規に実装しなおしてるらしいです
【Unite 2017 Tokyo】もっと気軽に、動的なコンテンツ配信を
〜アセットバンドルの未来と開発ロードマップ

66. 66
宴を作っていて、地雷が多かった場所
期待

67. さて、地雷の話は
あまり役に立たないので
役に立つTIPSを・・・
67
宴を作っていて、地雷が多かった場所

68. これ「超」役に立ちます
【Unity】Awake や Start の実行順を意識することなく他
のコンポーネントを参照する
68
バグが出にくくなるちょっとしたTIPS

69. よく使うので、宴3では拡張メソッドにしてる。
69
バグが出にくくなるちょっとしたTIPS

70. 70
バグが出にくくなるちょっとしたTIPS

71. ここ重要
Unityのコンポーネントではコンストラクタが使えない。
だからといって「AwakeやStartで初期化」としてしまうと
「AwakeやStart」がまだ呼ばれていないケースが起きうる
こうなると「未初期でバグる」ということが良く起きる
71
バグが出にくくなるちょっとしたTIPS

72. AwakeやStartと言えば、
通常のイベント関数の実行順は基本として
プログラムからAddComponentしたときにいつ呼ばれる
か知っていますか？
72
バグが出にくくなるちょっとしたTIPS

73. AddComponentしたコンポーネントのイベント関数の実行タイミングまとめ
（そのGameObjectはActiveである前提）
・ AwakeとOnEnable
AddComponentしたタイミングで同時に呼ばれる
・Start
Start中にAddComponentしたら、通常通りそのフレームのUpdate前に呼ばれる
Update中にAddComponentした場合、そのフレーム内の全オブジェクトのUpdate後〜全オブジェク
トのLateUpdateの前のタイミングで呼ばれる
LateUpdate中にAddComponentしても、そのフレーム内の全オブジェクトのLateUpdate後に呼ばれる
73
バグが出にくくなるちょっとしたTIPS

74. ・Updateは
Start中にAddComponentしたら、通常通りそのフレーム
Update中やLateUpdate中にAddComponent しても、そのフレーム内には呼ばれない
・LateUpdate
Update中までにAddComponentすれば、通常通りそのフレーム内には呼ばれる
LateUpdate中にAddComponentしても、そのフレーム内には呼ばれない
・コルーチン
最初の1フレームは、 AddComponentしたタイミング（このフレームで再度アップデートはかからな
い）次のフレームからは、通常通りUpdate 関数の後に実行。
74
バグが出にくくなるちょっとしたTIPS

75. AwakeやStartに実行順に依存する処理を書くと
この辺でいつか地雷を踏みます。
実行順以外にもGameObjectのActiveがオフだと、
そもそもAwakeやStartが起動しない。
なので、プロパティ内でGetComponentするアプローチのよう
に、「必要になったら初期化」のような構造にすると安定する。
75
バグが出にくくなるちょっとしたTIPS

76. 76
エディタ拡張TIPS
カスタムプロパティドロワーもオススメ
Attributeを自作してしまえば、ちょっとしたエディタ
拡張ならコード書かなくて済むようになる。

77. 77
エディタ拡張TIPS
色々作って、オレオレライブラリを増やしている。

78. 78
エディタ拡張TIPS
実のところUnityのエディタ拡張はかなりコーディングが面倒
名前指定になりがちでメンテナンス性も悪い。
（あまりアップデートされないので、皮肉にもそっちの意味ではメンテナンス性が良い）
しかも、似たような機能でも汎用的に使いまわせるような仕組みを作りづらい。
エディタ拡張は沼な上に、Unity側から提供されるドキュメントや新たな改善機能も少ないので
正直いつまでも使いづらいままというのが現状。
なるべく、回避できるなら回避する方向性で頑張ったほうが良い。
第一に、OnValidateで解決できるならそれで。
第二に、カスタムプロパティドロワーでできるならそれで。
カスタムプロパティドロワーは、一度作ればどのコンポーネントでも使えるので汎用性が高い。

79. ずっとツールとか作ったり、本書いたりしてましたが、
今年からは個人ゲーム開発をはじめてます。
79
おまけ

80. マルチシーン編集たのしー
どのシーンを開いても、自動的に関連するシーンが開くような
エディタ拡張とかしてる。
80
おまけ

81. マルチシーン編集たのしー
どのシーンを開いても、自動的に関連するシーンが開くような
エディタ拡張とかしてる。
→エディタ拡張は沼だと言ったろ！
もういいからゲーム作ろうな？
81
おまけ