Unity用ビジュアルノベルツール「宴3」開発帰還報告書

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

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

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

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

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

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

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

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

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

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

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

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

正直、「いまさらなにを話そうか」
とネタに困るくらい
13

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

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

「テキスト」と「画像」の表示
「サウンド」の再生をするだけです。
16

なんだか
かんたんそうですね
17

もう少し詳しくみると
18

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

20
・シナリオの再生
・必要となるファイルのロード
・画像表示、サウンド再生

21
こたえ
ファイルロード

22
・シナリオデータの再生
・ファイルのロード

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

念のために
24

かんたんに作れるわけじゃないからな！
25

26
・シナリオデータの再生
・ファイルのロード

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

28
それでも書いた通りには動く

29
ファイルロード

30
書いたとおりに動かない！

31
そもそも
ノベルゲームのロードと
Unityのロードの概念が相性悪い

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

33
シーンに含まれない
リソースをロードするには
Resourcesからロードするのが常道

34
がっ…
ここで地雷

35
ノベルゲームは
リソースを大量に用意する必要がある
商業だと画像やボイスが
数千とかいうレベル

36

37
さらに、スマホ時代になったことで
サーバーからのDLも必要

38

39
こういう仕組みが必要になる

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

41
UnityにはAssetBundleがあるじゃないか

42
だが…

43
宴のリリース当時の
ドキュメントを
よく読むと・・・

44

45
宴を作った当初（2013年）
はAssetBundleの使用には
Proライセンスが必要だった…

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

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

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

49
だが…

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

51
殆どは過去の問題
ただし、最近起きているバグもある

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

53
宴3の現在は
アセットバンドルに統一している

54
だが、それでも
多くの問題がまだある

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

StreamingAssetsにAssetBundleを置く
これで解決？
そうでもない →
そもそもAssetBundle作るのがやっぱり面倒
56

57
・Resources
・AssetBundle
・StreamingAssetsに置いたAssetBundle
これらをプロジェクトの規模や対象プラット
フォームによって使い分けないといけない。

58
詳しくは
宴のドキュメントに実例が

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

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

61
まぁ、当然ですよね。
こんなややこしいのは
自分たちで制御したいですよね。
拡張できる仕組みも用意しましたよ

62
いつになったらこの沼は終わるんだ・・・

63
ただファイルをロードしたい
だけなのに・・・

64

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

66
期待

さて、地雷の話は
あまり役に立たないので
役に立つTIPSを・・・
67

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

よく使うので、宴3では拡張メソッドにしてる。
69

70

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

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

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

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

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

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

77
色々作って、オレオレライブラリを増やしている。

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

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

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

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

Unity用ビジュアルノベルツール「宴3」開発帰還報告書

Unity用ビジュアルノベルツール「宴3」開発帰還報告書

Recommended

More Related Content

What's hot

What's hot(20)

Similar to Unity用ビジュアルノベルツール「宴3」開発帰還報告書

Similar to Unity用ビジュアルノベルツール「宴3」開発帰還報告書(20)

More from Ryohei Tokimura

More from Ryohei Tokimura(6)

Recently uploaded

Recently uploaded(11)

Unity用ビジュアルノベルツール「宴3」開発帰還報告書