1.
「宴」実装時に得られた
Unityプログラムのノウハウ
Unity用ADV制作ツール「宴」
http://madnesslabo.net/utage/
2014/05/19
マッドネスラボ代表 時村良平
https://twitter.com/rodostw

2.
概要
• Unityにおけるプログラム一般（ C# ）
• これが重要！どうやって探して、どこに渡す？
• シリアライズ
• コルーチン
• エディタ拡張
• より具体的なプログラムについて
• 2D
• 画面サイズに対応
• プロジェクト設定
• ADVエンジン（シナリオ解析）
• エクセルの読み込み
• リソースのDLとメモリ管理
• セーブロード

3.
「宴」
このスライドでは「宴」の実装を通して得られた
Unityプログラムのノウハウを紹介します
ADV（ビジュアルノベル）をUnity
で制作するためのツール。
AssetStoreで販売中。
https://www.assetstore.unity3d
.com/#!/content/15905
詳細は「宴」のサイトを！
無料体験版もあります。
http://madnesslabo.net/utage/

4.
「宴」のプログラムの構成の紹介
参考 以下のスライドでは、参考になりそうなリンクや「宴」のソースコードパスをここに記述
ADVに特化した部分
ゲームプログラム
全般に汎用的に使う
サンプルコード
主にUI処理を記
述

5.
Unityにおける
プログラム一般（ C# ）

6.
これが重要！
どうやって探して
どう呼び出す？
～ コンポーネントを使いこなそう ～

7.
どうやって探す？
～ 目当てのコンポーネントはどこにある？ ～

8.
• たとえば、GameManagerというコンポーネントから
Playerというコンポーネントを使うことを考える。

9.
• ただのC#なら
プロパティを使う
なりして、あらかじ
めメンバ変数に
セットしておく
もちろんこれでもいい
または、メソッドの
引数に持たせて
呼び出す

10.
コンポーネント
ならではの使い方

11.
• 一番素直なのはインスペクターを使う
GameManagerと
Playerのオブジェ
クトが別々の場合
ドラッグ＆ドロップでGameManagerの
インスペクターにPlayerを設定してやる

12.
• インスペクターで設定するのが基本だけど
プレハブ化すると
他のオブジェクトへの参照はMissingに
なってしまう。
他にもスクリプトから動的にオブジェクトを作った場合にも、
インスペクター経由での設定はできない

13.
他の手段は
なにがある？

14.
• GetComponentを使うパターン
GameManagerと
Playerのオブジェ
クトが同じ場合
インスペクターで設定する必要はない
→プレハブ化などすると、インスペクターを使ったオブジェクト
の参照は不安定なので、可能ならこのほうが安全で手軽

15.
• GetComponentInChildrenを使うパターン
Playerが子
親子構造が保障されているときや、
子オブジェクトを動的に生成した場合にも

16.
• 親オブジェクトのパターン
Playerが親
親子構造が保障されているときや、
親子オブジェクトを動的に生成した場合にも
Unity4.5で
GetComponentInParentが
追加されたのでそっちのほ
うがいい

17.
• GameObject.Findを使うパターン
名前だけは分かっ
ている
シーン編集時には存在しないオブジェクト（動的に生成した
GameObjectや、他のシーンで生成したGameObject）を参照
するときなど。
速度は遅いので注意
子にあることが分かってる
なら、transfom.Findというの
もある。

18.
• GameObject.FindWithTagを使うパターン
GameObject.Findと似ているが、タグを指定するのでちょっと
早い模様。
ただし、タグはプロジェクト間で共有が非常にしづらいので、
汎用性に欠ける
速度はちょっと遅い
タグを指定

19.
• FindObjectOfType<T>を使うパターン
Activeであるのが
必須
GameObject.Findと似ているが、型を指定できるので便利
コンポーネント以外に、TextureなどのAssetの型も指定できる
速度は遅い？

20.
今までは対象が一つの場合を想定
とはいえ複数の場合も応用すればOK
複数用の処理
・GetComponents
・GetComponentsInChildren
・GameObject.FindGameObjectsWithTag
・FindObjectsOfType

21.
• ゲーム中に必ず一つという保障があるなら、シング
ルトンを使うパターンもあり
手軽で速度低下もないが、シングルトンで作れなくなったとき
に構造を大幅に変える必要がでてくるので、多用は禁物
シングルトンな処理
を作る
Unityのシングルトン
の書き方はいろいろ
あるが、一番単純な
パターンがこれ

22.
ここまでが基本

23.
もうちょい頑張る

24.
遅い処理はキャッシュしよう
• FindやGetComponentは遅い
参考 http://docs.unity3d.com/410/Documentation/ScriptReference/index.Performance_Optimization.html
プロパティと null 合体演算子を使うと
コードがスッキリする！
オススメ！
一度みつけたら、変数として保存（キャッシュ）しておくと
二回目以降はすぐ呼び出せる

25.
遅い処理はキャッシュしよう
• Transformは注意
Transformの==はカスタムされているのが原因
参考 http://blogs.unity3d.com/2014/05/16/custom-operator-should-we-keep-it/
this.transformは内部でGetComponentしてるようなので、
処キャッシュしたほうがいい。
ただし、 null 合体演算子だとバグる！
こうする

26.
RequireComponent
• そのコンポーネントを使う場合、
必ず同時に使うコンポーネント
を指定できる
参考ソース Utage¥Scripts¥ADV¥AdvEngine.cs
AddComponentすると、自動的に
RequireComponentで指定されてるコン
ポーネントもAddされる

27.
RequireComponent
• これを使うと、安全なコードが書ける。
参考ソース Utage¥Scripts¥ADV¥AdvEngine.cs
コンポーネントがあることが保障されているので
GetComponetでnullにならない！

28.
RequireComponent
・RequireComponent
・プロパティ内のnull合体演算子からのGetComponet
組み合わせて使うと便利！凄くオススメ

29.
どう呼び出す？
～ 命令を呼ぶ ～

30.
• 普通は、メソッドを呼べばいい

31.
• コンポーネントの種類を指定したくないとき
型はPlayerとEnemyの二種類が
ある。
C#的には継承を使うのが普通

32.
• SendMessage
Classの型を気にせず
柔軟に使える
メソッド名を指定し
てSendMessage

33.
• SendMessageの真の力
TargetとFunctionをインスペクター上で変えれば、
ソースコードを変えることなく
好きな相手に好きな処理をさせられる

34.
• SendMessageのさらなる力
SendMessageには引数を一つだけもたせられる
ただし、返り値はもてない。
それでも、こんな感じで処理を繋げられる。

35.
• SendMessage、SendMessage ・・・
引数をGgamaObjectにすると、「誰から呼ばれたか」
も制約せずに柔軟に使える。
引数をGgamaObject にしても、GetComponentを使
えば、コンポーネントを取得することもできる。
SendMessageからSendMessageを呼ぶことも可能。

36.
• SendMessage、SendMessage ・・・
SendMessageはやりすぎる
と、わけがわからなくなるの
で注意。
参照関係をエディタ上で追
えなくなりがち。
どこからも呼ばれてないよう
に見えてしまう

37.
• プログラム内で完結させるならデリゲートを使う手もある
型安全に使える。ただし、プログラムを書かないと処理を切り替え
られない。
ゲーム内で「プレイヤーと敵」のように頻繁に処理が切り替わる場
合は向かないかも。
ロードの終了とかのフレームをまたぐ処理に使うのがよさげ。
（宴では、ユーザの独自拡張のための入り口とかによく使ってる）

38.
SendMessage
GameObjectに対して名前指定で処理を呼ぶ。引数を一つだけ持たせ
られる。
• メリット
• 名前指定なので、ソースコードを変えずに呼び出し先を変えるのに使える。
• たとえば、「ボタンを押されたら呼び出す処理名」などをインスペクターに登録しやすい。
• 複数のコンポーネントに対しても個別に処理をさせらる。
• BroadCastを使えば子階層のオブジェクトにも処理をさせられる。
• デメリット
• 返り値がもてない。
• 複数処理がされる場合は、処理順が制御できない？
• 非アクティブなオブジェクトには使えない。（ので、初期化処理などには使いづらい）

39.
Func,Actionなどのデリゲード(コールバック)
C#の標準的な仕組み。
メリット
• 型指定なので、ある程度複雑な処理も安全に使いやすい。
• ロード終了時など、「タイミングが来たらこの処理を呼んで」という形で使える。
• 「追加の独自拡張」を想定する場合にも使える。
• 返り値がもてる
• デメリット
• プログラムとして記述しなければ使えない。
（SendMessageのように「インスペクター上に記述された文字列の処理を呼ぶ」ということはで
きない。）

40.
シリアライズ
～ Unityのシリアライズは奥が深い･･････ ～

41.
シリアライズって？
• Wikiより引用
• コンピュータプログラミングにおいて、シリアライズ、もしくはシリアル
化 (serialize) という用語は、次のような異なる2つの意味を有する。
• ある一つの資源を、複数の主体が利用しようとするときに、それを調
整（同期）して、一つの時点では一つの主体だけがそれを利用する
ようにすること。この意味では逐次化という訳語が用いられる。対義
語は並列化である。
• ある環境に存在しているオブジェクトをバイト列やXMLフォーマットに
変換すること。この意味では直列化という訳語が用いられる。同義
語にMarshallingがある。対義語は直列化復元ないしデシリアライズ
である。

42.
Unityのシリアライズ
• シーンやプレハブの情報はYAMLという書式で保存している
AssetServer使っているなら、
対象のAssetを選択→右クリック→Compare Binary で
中身がみれる。
どこを変えると、どう変わるか見てみるのも一興
参考 http://docs-jp.unity3d.com/Documentation/Manual/FormatDescription.html

43.
Unityのシリアライズ
基本

44.
シリアライズって？
• イメージ的には「インスペクターで扱える」でOk

45.
何がいいことあるの？
• シーンやプレハブ、Assetとしてデータを編集・保存できるようになる
• インスペクター上のGUIで編集できるようになるので楽
• シリアライズできない＝Unityエディタ上では扱いづらいと考えてOK
参考 http://docs-jp.unity3d.com/Documentation/ScriptReference/SerializeField.html

46.
どうすればいい？
• 基本的に対象になるクラスは
• MonoBehaviourを継承するクラス（コンポーネント）
• ScriptableObjectを継承するクラス
• 通常のC#クラスも[Serializable]を使えばOK
• 対象になるメンバ変数は
• Public
• [SerializeField]を適用すれば、privateな型でもOK
参考 http://docs-jp.unity3d.com/Documentation/ScriptReference/SerializeField.html

47.
似てるけど違う
コンポーネントとScriptableObject
コンポーネント
MonoBehaviourを継承するクラス
GameObjectにアタッチする
Sceneビューの
GameObjectにアタッチ
する。
各オブジェクトの
「機能」のイメージ

48.
似てるけど違う
コンポーネントとScriptableObject
ScriptableObject
ProjectビューにAsset
として作成される。
つまり、テクスチャな
どと同じく素材・デー
タのイメージに近い
ScriptableObjectを継承するクラス
コンポーネントと同じく、
インスペクターを持つ

49.
似てるけど違う
コンポーネントとScriptableObject
• コンポーネント（MonoBehavior）
• オブジェクトにアタッチする「機能」
• ScriptableObject
• データの塊（独自定義のAsset）
• 宴での使用例「ADVのシナリオデータ、フォント定義、描画順定義･･・など」
・・・という感じで使い分けるとよさげ。
（本来はScriptableObject はUnityの基本データクラスみたいなもの
MonoBehabiorやEditorWindowもScriptableObject を継承しているハズ）

50.
シリアライズのための記述方法まとめ
• [Serializable]
• 独自定義のクラスをシリアライズ
可能にする
• クラスに定義する
• C#の標準的な機能
• [SerializeFiled]
• 非publicなメンバ変数をシリアライズ
の対象にする
• 変数に定義する
• Unity独自の機能
似てるのでまとめ。
使っていればたぶんすぐ慣れる。
参考 http://docs-jp.unity3d.com/Documentation/ScriptReference/SerializeField.html

51.
Unityのシリアライズの基本
• Publicか[SerializeFiled]か
参考 http://docs-jp.unity3d.com/Documentation/ScriptReference/SerializeField.html
簡単に書くならpublicにするだけ
[SerializeField]にすると、privateな
変数もシリアライズできる
こうすれば、プロパティ（get,set）でアクセスを制御できる。
C#的はpublicを使わずに、プロパティを使うのが基本。
Unity的にはどっちがベターか？

52.
Unityのシリアライズ
一歩先

53.
Dictionaryのシリアライズ
• Unity（というかC#）では、
Dictionaryはシリアライズ不可
（ Dictionaryはジェネリックの入れ子
的な使い方をしているせい。詳細は
割愛）
• 使用頻度は高いので、シリアラ
イズ可能なDictionaryを作った。
• ただしキーは文字列のみとする
参考ソース Utage¥Scripts¥GameLib¥Dictionary

54.
ジェネリックのシリアライズ
• ジェネリックを使う場合の注意
クラス定義を型ごとにすること
MyGenecricClass<int>はダメ
class MyGenecricClassInt :
MyGenecricClass<int>{}
と定義すれば使えるようになる。
参考 http://answers.unity3d.com/questions/214300/serializable-class-using-generics.html

55.
ネームスペース＆デフォルト引数は禁止
• ネームスペースを使った場合、デフォルト引数を使ったメソッドを持つ
クラスはシリアライズができなくなる。
• デフォルト引数は使わないように修正。
• コルーチンにデフォルト引数を使っている場合はちょっと注意。
https://www.facebook.com/groups/unityuserj/permalink/620981311295146/?
comment_id=621128654613745&offset=0&total_comments=7
参考 https://www.facebook.com/permalink.php?story_fbid=541323405927604&id=167184853341463
Unity4.5では問題なく使える模様
http://terasur.blog.fc2.com/blog-entry-795.html

56.
子
親
親子参照でバグ？
• ScriptableObject内親子構
造にある[Serializable]なク
ラスに互いへの参照をも
たせた
• なぜかUnityエディタがこ
とあるごとに遅くなった。
（コンパイルで一分以上
かかる）
• アプリの起動時は特に影
響なし。エディタのみ？
参考ソース Utage¥Scripts¥GameLib¥StringGrid
こうすると
妙に重い
コールバックで参照する
というよくわからない処
理にしたら解消。
Unityのバグ？

57.
Mono DLL
～ たぶん殆どの人は使わなくてもOK ～

58.
DLL化
• C#のプログラムをDLL化して使うこと
ができる。
• 体験版などでコードを隠蔽する場合
や、複数プロジェクトにまたがる共
通ライブラリを作る場合に使える。
参考 http://docs-jp.unity3d.com/Documentation/Manual/UsingDLL.html
http://terasur.blog.fc2.com/blog-entry-312.html

59.
またしてもデフォルト引数が！
• シリアライズ関係ない、通常のC#のクラスでもデフォルト引数はダメ
な模様。
• DLLは.Net3.5以下しか対応してないけど、デフォルト引数は3.5だとコ
ンパイルできない模様
もうUnityでデフォルト引数は全面的に避けたほうがいいかも・・・
4.5以降ならDLL使わなければいいので、ほぼ問題ない？

60.
Missing・・・
• コンポーネントやScriptableObjectをDLL化する
と、作成済みのシーンやプレハブは全部
Missingになってしまう・・・
（GUIDを使ったUnity内部での参照関係がおかしく
なってしまうらしい）

61.
Missing・・・
• 回避するには継承を使う。
参考ソース Utage¥Scripts¥GameLib¥File¥FileIOManagerBase
DLL化したいソースはスーパーク
ラスに記述
スーパークラスだけDLL化する
スーパークラス作って、それを継
承する形にする

62.
シリアライズと
リファクタリング
～ もうMissingはうんざりだ！ ～

63.
Missingを避けるための、リネームの法則
リネームしていいか？
シリアライズが関係ないクラス名やメンバー名 ○
コンポーネントとScriptableObjectのクラス名 ○
コンポーネントとScriptableObjectの
[SerializeField]またはpublicなメンバー変数名
×
[Seriazible]なクラス名 ×
[Seriazible]なクラスの[SerializeField]またはpublicなメンバー変数名 ×
基本的にシリアライズが絡むなら、コンポーネントとScriptableObjectのクラス名以外は変えてはいけない。
それ以外は、リネームするとシーンやプレハブに設定された値は初期値にリセットされる。
シーンやプレハブに設定された値を残したまま、インスペクター上の表示名だけ変えたい場合は
エディタ拡張をするしかない。
シーンやプレハブに設定せずに、AddComponentなどで動的に生成する場合は、リネームしてもOK
（シーンやプレハブに設定されたメタデータの問題なので･･･）

64.
コンポーネントのクラス名の変えかた
まず、Unity上でファイル名を変える
（F2でリネームできる）
次にMonodevelopなど、エディタ上でクラス
名を変える
MonodevelopやVisualStudioならクラス名を
記述してる場所は全て書き換えてくれる機
能がある。
Monodevelopならクラス名でフォーカスして
右クリックでRefactorが出てくる。

65.
シリアライズおわり
Unityのシリアライズは奥が深かった･･････

66.
コルーチン
～ その裏技 ～

67.
コルーチンからコルーチンを呼ぶ
void Load()
{
StartCoroutine( CoLoad ());
}
IEnumerator CoLoad()
{
yield return StartCoroutine(CoLoadSub1());
yield return StartCoroutine(CoLoadSub2());
}
IEnumerator CoLoadSub1()
{
yield return new WWW(url1);
}
IEnumerator CoLoadSub2()
{
yield return new WWW(url2);
}
コルーチン内部で
yield return StartCoroutine()
とする。
この例では →
CoLoadSub1()が終わってから、
CoLoadSub2()が始まる

68.
コルーチンをMonovehavior以外で使う裏技
public class MainClass : MonoBehaviour
{
SubClass sub = new SubClass();
void Load1()
{
StartCoroutine(sub.CoLoad1());
}
void Load2()
{
StartCoroutine(sub.CoLoad2(this));
}
}
//コルーチンをもつ通常のクラス
public class SubClass
{
//コルーチン
public IEnumerator CoLoadSub1()
{
yield return new WWW(url1);
}
//コルーチン内部でStartCoroutineを使うには、MonoBehaviourを渡す
public IEnumerator CoLoadSub2(MonoBehaviour parent)
{
yield return parent.StartCoroutine(CoLoadSub1());
yield return new WWW(url2);
}
}
StartCoroutineはMonovehaviorからしか呼べ
ない。
IEnumerator で宣言するコルーチン自体
は通常のC#のクラスでもOK。
その内部でさらにStartCoroutineをした
いなら、Monobehaviorを渡してやるとい
う手もある。

69.
止め方に注意
• StopAllCoroutinesを呼んでも、
呼び出したコルーチンはそのフ
レームの最後までは動くので
注意。
IEnumerator CoLoadSub2()
{
while(true)
{
if(isEnd)
{
StopAllCoroutines(); //ここで止めても
}
Debug.Log("!");
//ここは呼ばれる
yield return 0;
}
}

70.
エディタ拡張
～ 手抜きのレシピ ～

71.
OnValidateが便利
/// <summary>
/// インスペクターから値が変更された場合
/// </summary>
void OnValidate()
{
dataTbl.RefreshDictionary();
}
リファレンス http://docs-jp.unity3d.com/Documentation/ScriptReference/MonoBehaviour.OnValidate.html
インスペクターのエディタ拡張をせずに、
インスペクターで値が変えられたときの
操作を記述できる。
簡単な処理ならこれでOK
参考ソース Utage¥Scripts¥GameLib¥CustomProjectSetting¥Node2DSortData.cs

72.
OnValidate ＋MarkAsChangedパターン
参考ソース Utage¥Scripts¥GameLib¥2D¥2D¥Node2D.cs
/// <summary>
/// インスペクターから値が変更された場合
/// </summary>
protected virtual void OnValidate()
{
MarkAsChanged();
}
/// <summary>
/// 毎フレームの最後の更新
/// </summary>
protected virtual void LateUpdate()
{
if ( CachedTransform.parent != lastParent || hasChanged )
{//構造に変化があった
Refresh();
}
}
インスペクターでの変更だけなく、
・スクリプト内部からのsetなどで変更されうる
・パラメーターが多く、かつ更新による負荷が大きい
など、ある程度複雑になる場合は
「変更があった」というフラグのみ設定して、
LateUpdateやUpdateでチェックして一度だけ変更す
るという手もある。

73.
EditorGUILayout.PropertyFieldを使うと楽
参考ソース Utage¥Editor¥Scripts¥Inspector
UtageEditorToolKit.PropertyField(serializedObject, "engine", "Engine");
UtageEditorToolKit.PropertyField(serializedObject, "isAutomaticPlay", "Is Automatic Play");
UtageEditorToolKit.PropertyField(serializedObject, "startScenario", "Start Scenario Label");
public static void PropertyField(SerializedObject serializedObject, string propertyPath,
string label, params GUILayoutOption[] options)
{
SerializedProperty property = serializedObject.FindProperty(propertyPath);
if (property == null)
{
Debug.LogError(propertyPath + " is Not Found");
}
else
{
EditorGUILayout.PropertyField(property, new GUIContent(label), options);
}
}
メンバ変数名 インスペクターに表示する名前
EditorGUILayout.PropertyFieldを使
うと、stringやMonobehavior、
Vector3、enumなどの型によらず
適切なGUIで表示してくれる。
細かい制限をかけない（エディタ
拡張しないでよい）パラメーターに
関してはこれで書いたほうが楽
エディタ拡張をする場合でも、なるべく簡単に書く。

74.
Property Drawerを使う
リファレンス http://docs-jp.unity3d.com/Documentation/Components/editor-PropertyDrawers.html
参考ソース Utage¥Editor¥Scripts¥Attribute¥EnumFlagsAttributeDrawer.cs
EnumFlagsという、フラグを表示する
Property Drawerを作成しておく
こう書くと
[System.Flags]
enum DebugOutPut
{
Log = 0x01,
Waiting = 0x02,
CommandEnd = 0x04,
};
[SerializeField]
[EnumFlags]
DebugOutPut debugOutPut = 0;
Property Drawerを使うと、コンポーネ
ントごとにエディタ拡張をしなくても、
特定の表示パターンを指定できる。
Enumとして表示さ
れてしまう
フラグ操作に適したUIで表示

75.
より具体的な
プログラム

76.
画面サイズに対応
～ アスペクト比を変えたり、レターボックスをつけたり ～

77.
デバイスごとにバラバラな解像度に対応
デバイスの解像度に応じて描画領域が広げる
ように設定もできる
レターボックス
（設定したアスペクト比を越える部分は黒で塗りつぶす ）
NGUIはなぜか縦長タイプに対応
できないが、そこもカバー

78.
アスペクト比の範囲を設定可能
参考ソース Utage¥Scripts¥GameLib¥Camera¥CameraManager.cs"
アスペクト比を固定のままなら、全部同じ値にする
（殆どはこのパターンだと思われる）

79.
実装のコツ
参考ソース Utage¥Scripts¥GameLib¥Camera¥CameraManager.cs"
その他のカメラの
ViewPortを調整して
描画範囲を操作する
カメラを二つ以上使う。
全画面を黒で塗りつぶすだけのClearCameraを描画
順が先に来るように設定

80.
2D
～ Spriteのアレな感じを使いやすく ～

81.
Unity4.5（Spriteの改良）
や
Unity4.6（uGUI）次第では
この辺全部無駄になる可能性
あります

82.
Unityの2DSpriteの問題点
• 描画順は、ヒエラルキーを無視してしまう
たとえば、こんな風に
一画面丸ごとの描画順を変えようとしても

83.
Unityの2DSpriteの問題点
描画順は、各スプライトの一つ一つのSortingLayer
かOrder In Layerを設定するしかない
親オブジェクトを一つ変えれば、
子の描画順も全部変わる！
・・・とかができない

84.
Unityの2DSpriteの問題点
• そのくせ、コリジョンの優先順はZ値なのでヒエラルキーに依存する。
Z値と描画順を合わせないと、
一番手前に描かれてるスプライト
にタッチ判定・・・とかができない
手前に描画するものはZ値も手前
にする必要が・・・

85.
描画順に親子関係を反映するようにした
参考ソース Utage¥Scripts¥GameLib¥2D¥2D¥Node2D.cs
親の描画順
1500 親の影響を受けて、
子のグローバルな
描画順は1500
子のローカルな
描画順 0

86.
カラーの値も親子関係に影響するように
親を半透明に
一つ変えるだけで、画
面全部が半透明に

87.
描画順制御のデータテーブルを作成
参考ソース Utage¥Scripts¥GameLib¥CustomProjectSetting¥Node2DSortData.cs
描画順は手作業
でも設定できるし、
あらかじめ用意し
たデータテーブル
からも設定できる
描画順とZ値を
プロジェクト内で共通の
値として管理できるよう
にした。

88.
カスタムプロジェクト設定
～ 共通設定！一元管理！ ～

89.
共通で使う値を、一元管理したい
• ゲーム内で共通で使うデータを一元管理したい
• 描画順のテーブル
• ローカライズ用のキーワード
• エディタ上からもいつでもロードして使いたい

90.
共通で使う値を、一元管理したい
参考ソース Utage¥Scripts¥GameLib¥CustomProjectSetting
カスタムプロジェクト
設定を作って
起動時に読み込むようにした

91.
しかし、どうにもバグというかスッキリしない
まだ検討の余地あり
• 課題
• カステムプロジェクト設定といってもプロジェクト内に必ず一つと決められない。
ツールとして提供するときは、サンプル設定データが必要になる
多言語対応も考えると、もっとややこしかったり
• エディタ中でも参照するためシーンを開いていないときですら、参照したい。
• 色々やり方はあるが、（初回起動時など）どうしても読み込めないときが出てきてしまう。
• この辺のノウハウが欲しい・・・

92.
ADVエンジン
～ 「宴」のADVエンジンの構造 ～

93.
ADVエンジンの構造と流れ
シナリオのエクセルデータを
解析
シナリオの
コマンドデータ作成
ゲーム実行中
コマンドデータを実行し
ていく
おおざっぱな処理の流れ

94.
エクセルの読み込み
～ とっても便利！一度使うとやめられない！ ～

95.
Npoi使えば楽
• 各Cellの文字列を読み
込むのは楽
• あとは文字列を解析す
るだけ
参考 http://terasur.blog.fc2.com/blog-entry-511.html
参考ソース Utage¥Assets¥Utage¥Editor¥Scripts¥ExcelParser.cs

96.
StringGrid
• 宴では、StringGridとい
う文字列のグリッド解析
クラスを用意して、エク
セルやCSVの文字列を
解析している。
参考 Utage¥Scripts¥GameLib¥StringGrid

97.
インポートの設定だけちょっと面倒
• 「拡張子がエクセルファイ
ルだったらインポート」と
かやってしまうと、他の環
境と衝突するかもしれな
い。
参考ソース Editor¥Scripts¥Menu¥ScenarioData¥AdvScenarioDataBuilderWindow.cs
プロジェクト設定的なものを
作って、そこで管理している
ファイルだけインポートする
ようにする。

98.
インポートしたらScriptableObjectに
参考ソース Assets¥Utage¥Editor¥Scripts¥Menu¥ScenarioData¥AdvExcelImporter.cs
出力したものは、
ScriptableObjectにするのが
良い。

99.
一度作ってしまえば、すごく便利！
• OnPostprocessAllAssetsを使えば、インポートは、ファイルが更新され
ると自動で行われる
• エクセルを編集→上書き保存→Unityエディタに戻る
自動で更新が行われる。凄く便利！

100.
ADV用の
コマンドを実行していく
～ キャラを表示したり、テキストを表示したり、音を鳴らしたり ～

101.
コマンドの処理の流れ
参考ソース Assets¥Utage¥Scripts¥ADV¥Scenario¥AdvScenarioPlayer.cs
初期化
リソースのロード
コマンド実行
待機処理
次のコマンドへ
改ページ待ちなど
毎フレームの処理
オートセーブ

102.
実際にはもう少し複雑
• ジャンプ命令や、既読スキップ、シーン回想への対応など
• 特にセーブがらみはわりと面倒。
• 「いつでもセーブできる」とした場合、演出の途中でセーブロードするのが凄
く大変
• シーンの冒頭など「セーブポイント」でしかセーブできない代わりに、「動的な
演出に凝れるモード」もあったほうがいいかも？
• 動的な演出についてはこのまとめがわかりやすい
http://www.slideshare.net/tunacook/ss-35094307

103.
オートセーブ
• 基本は改ページの直後の状態をセーブデータとして記録し
ておく
• スプライトやサウンドなど、「シーンのそのときの状態」をセーブ
データとして利用する。
• わりと簡単に作れる。
• コマンドを追加拡張するごとにセーブデータの拡張も必要になる可能性
がある。
• 宴ではこっちを採用
• これとは別に、シナリオのページラベルをキーにして、「そのページ
の状態」をシナリオデータから再現できるようにするという手もある。
• こっちは難しいが、柔軟に使えるという利点もある。
• コマンドを拡張しても、セーブデータ自体はいじらないですむ場合もある
IOの仕組みは後述

104.
コマンドの処理の流れ
初期化
リソースのロード
コマンド実行
待機処理
次のコマンドへ
改ページ待ちなど
毎フレームの処理
一番のポイントはこれ
オートセーブ

105.
リソースのロード
• ロード待ちを減らすため、あらかじめ素材をロードする
• 今のコマンドだけではなく、この先数ページぶんのコマンドのロードだけ先に
やっておく。（いわゆる裏読み・バックグラウンドロード）
• これがADVエンジン制作の一番難易度が高いポイント･･･と思ってる
• UnityではResouces.Loadが同期しかなかったり、ロード後のリソース
の初期化とかは同期だったりするので、実際はどうしてもロードによ
る処理落ちができる。

106.
リソースのDLとメモリ管理
～ 大量のリソースをどうさばくか ～

107.
「宴」のAssetファイルマネージャー
• 目標
• ダウンロード機能をつける
• AssetBundleを使わない（UnityBasicで動くようにする）
• なるべく早くロードする
• 必要以上のメモリを使わない
参考ソース Utage¥Scripts¥GameLib¥File¥AssetFileManager.cs

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

109.
ファイルロードの課題
• Resouces.Loadは？
• ダウンロードできない
• アプリサイズが増える
• リソースの修正にはアプリ自体のアップデートが必要になる
• AssetBundleは？
• UnityProじゃないとAssetBundleの作成ができない
• Unityのアップデートによっては、過去のAssetBundleと互換性が取れない
• サウンドのStream再生ができない。（メモリ消費が大きい）
• WWWは？
• 毎回ダウンロードすることになる
参考ソース Utage¥Scripts¥GameLib¥File¥AssetFileWork.cs

110.
「宴」のAssetファイルマネージャー
• 目標
• WWWとResoureces.Load両方でロードできるようにする
• ロード＆メモリ管理機能をつける
• WWWでロードする場合はキャッシュ機能をつける
• 一度DLしたファイルはキャッシュファイルとして保存・再利用する
• ロードした後のリソースはプール機能をつけて管理する
• 一度ロードしたAssetは、メモリ内に残しておいて再利用する
• メモリ不足になったら、使っていない古いAssetをアンロードする
参考ソース Utage¥Scripts¥GameLib¥File¥AssetFileWork.cs

111.
デバイスキャッシュ
参考ソース Utage¥Scripts¥GameLib¥File¥AssetFileManager.cs
Tool>Utage>Open Output Foloder>Cache
キャッシュファイルを保存しているフォルダ
が開く
キャッシュファイルは連番でファイル名がつく。
そのリソースがバージョンアップしたら、新し
いファイルを書き込んで、古いファイルは消
す。
WebPlayerではファイルIOができないので、
キャッシュ機能は実装できない

112.
デバイスキャッシュ
参考ソース Utage¥Scripts¥GameLib¥File¥AssetFileManager.cs
ローカルに書き込む際
に、圧縮・暗号化もか
けられる。
符号化したシナリオファイル
バイナリエディタなどで覗い
てもネタバレはしない

113.
• 目的は、LoadFromCacheOrDownload と殆ど同じ
• つまり、ファイルのバージョン管理つきのDLとローカルへの保存
• ただし、アセットバンドルではなく.pngや.wavなど汎用的なファイルを扱う
• メリット
• アセットバンドル化しないので、pngなどはサイズが小さいままDLできる
• Unityのバージョンアップに左右されない
• →アセットバンドルはUnityのバージョンアップでDLしなおしになる可能性がある
• デメリット
• 今のところアセットバンドルに未対応
• つまり、3DモデルなどはDLできない
• 将来的にはアセットバンドルも併用したいけど検討中。
デバイスキャッシュ
参考ソース Utage¥Scripts¥GameLib¥File¥AssetFileManager.cs

114.
アンロードする際には、
可能な限りこのサイズ以
下になるようにする
システムメモリにプール
参考ソース Utage¥Scripts¥GameLib¥File¥AssetFileManager.cs
ファイルマネージャー
こんな感じ
DLのタイムアウト時間
エラー時のリトライ回数
同時にロードするファイル
の最大数このサイズ（MB）を越えた
ら、プールしてるリソース
をアンロードする

115.
システムメモリにプール
参考ソース Utage¥Scripts¥GameLib¥File¥AssetFileManager.cs
ファイルマネージャー
をデバッグモードでみる
管理中のファイル情報
を見れる
使用中のファイル
ロード中のファイル
ロード待機してる
ファイル
使用済みのファイル
（アンロードせずに
プールしてある）

116.
システムメモリにプール
参考ソース Utage¥Scripts¥GameLib¥File¥AssetFileManager.cs
プールしてあるファイルが
必要になったらすぐ使える
（ロードが必要なくなる）
使用し終わっても、アンロー
ドせずに、いったん使用済
みとしてプールする

117.
メモリ管理→参照管理
• プールの仕組みを実現するには
「どのファイルが使用中なのか？」という
参照管理が必須になる。
参考ソース Utage¥Scripts¥ADV¥Scenario¥Command¥AdvCommand.cs
どのobjectから参照してる
か、参照がなくなったかを
常に設定する
（この場合はthis）

118.
この仕組みは
テクスチャを大量に使うゲーム
（カードゲームとか）
にも使えるハズ

119.
けっこう作るのは面倒

120.
ブラッシュアップしていって
そのうち「宴」から独立させて
AssetStoreでリリースするかも？

121.
セーブロード
～ たぶんUnityではこれが正解！WebPlayerでも使える ～

122.
PlayerPrefsは手軽だけど、柔軟には使いづ
らい・・・
• 大規模になると管理がつらい
• 数が少ないうちはいいが、セーブする要素が増えたりすると困る
• サイズ可変の配列だったり、セーブデータを複数もったり･･･
• 遅いとか、レジストリをいじるとか、困る面もある。

123.
C#のシリアライズは･･･iOSで使えない
• セーブデータはやはりバイナリで作りたいところだが・・・
• C#のクラスを自動でバイナリ化してくれるBinaryFormatter を使う？
参考ソース http://forum.unity3d.com/threads/140606-iOS-Basic-BinaryFormatter
public static void SaveToBinaryFile(object obj, string path)
{
FileStream fs = new FileStream(path,
FileMode.Create,
FileAccess.Write);
BinaryFormatter bf = new BinaryFormatter();
//シリアル化して書き込む
bf.Serialize(fs, obj);
fs.Close();
}
iOSでは使えない
（使える場合もあるようだが、
非常に限定的なので非対応
と思ったほうがいい）

124.
バイナリデータを作成
• BinaryReader＆ BinaryWriterで手作業でバイナリ化処理を
• コードを書くのは面倒だけど、バージョンアップ対応など細かい融通は利く
参考ソース Utage¥Scripts¥ADV¥Save¥AdvSystemSaveData.cs

125.
WebPlayer対応を考慮したセーブデータのIO
参考ソース Utage¥Scripts¥GameLib¥File¥FileIOManagerBase.cs
バイナリ化できてしまえば、
ファイルとしてIO（入出力）す
ればいい。
WebPlayerなど、ファイルIOに対
応してない場合は、PlayerPref
でセーブロードする
バイナリ配列をStringに変換し、
ファイルパスをキーにしてIO

126.
WebPlayer対応を考慮したファイルIO
バイナリ化を駆使すれば、
スクリーンショット（テクスチャ）
つきのセーブデータを
WebPlayerで保存できる！
WebPlayerのPlayerPrefにはサイズ
制限があるのでそこだけ注意

127.
その他のプラグラム紹介

128.
テキストの禁則処理
参考ソース Utage¥Scripts¥GameLib¥2D¥2D¥TextArea2D.cs
そういう場合に適度な改行
をして読みやすくするのを
「禁則処理」という
日本語を表示する場合に
句読点や括弧等が行頭や行末に
くると読みづらくなる
禁則処理
こういう日本独自の処理はおそらく
Unity公式ではサポートされないと思
われる
（日本人が書くしかない）
行頭に 。
かっこ悪い

129.
構文解析
• ADVを作るためには
「構文解析」が色々必要になる
• <Color>タグつきのテキスト
• “Point+=1”という「文字列」を数式として処理したり
• その他いろいろ
詳しくはソースを確認してほしい

130.
「宴」のプログラム構成
ADVに特化した部分
ゲームプログラム
全般に汎用的に使う
サンプルコード
主にUI処理を記
述

131.
ADV特化部分
主に、テクスチャや
サウンドなどの設定
ADVの多言語対応
ADV中の2D描画
ADVのシステム制御
ADVのセーブ処理
ADVのシナリオ制御
ほぼ中心となる処理 UI制御

132.
ゲームプログラム汎用部分
２D処理
カメラ・タッチ入力処理
シリアライズ可能な
Dictionary
文字列で書かれた数式の解析
ファイルマネージャー関係サウンド処理
（ボリューム調整や、
フェード処理つき）
iTween
カスタムプロジェクト設定
（一元管理用データ）
エクセルやCSVなど、
文字列のグリッドの解析
タグつきテキスト解析
フォント制御
その他の便利処理

133.
おしまい
Unity用ADV制作ツール「宴」
http://madnesslabo.net/utage/
2014/05/19
マッドネスラボ代表 時村良平
https://twitter.com/rodostw
「宴」実装時に得られた
Unityプログラムのノウハウ