2016-06-30

UniRxのコルーチンについて

こんにちは、Nobollelエンジニアの古屋です。今回はUniRx関連の話です。

UniRxは、.NETのReactive Extensions (Rx) を、neueccさんがUnity向けに移植されたものです。今回はこの中から、Rxに馴染みのない人でも比較的取っ付きやすいであろうコルーチン機能の紹介をしようと思います。

コルーチンの開始

UniRxでコルーチンを開始するには、FromCoroutineでIEnumeratorをIObservable<T>に変換した後、Subscribeします。

void Start() {
    Observable.FromCoroutine(() => Hoge()).Subscribe();
}

IEnumerator Hoge() {
    yield return new WaitForSeconds(1);
    Debug.Log("hoge");
}

コルーチン本体 (Hoge) の書き方はUnity標準のコルーチンとまったく同じで、代わりにStartCoroutine(Hoge())のように書いても動きます。

コルーチンの停止

UniRxでコルーチンを止めるには、StopCoroutineの代わりに、Subscribeの戻り値をDisposeします。

IDisposable coroutineDisposable;

void Start() {
    coroutineDisposable = Observable.FromCoroutine(Hoge).Subscribe();
}

void AbortCoroutine() {
    coroutineDisposable.Dispose();
}

IDisposable形式だと、たとえば複数のコルーチンを走らせて一括で止めるような処理が書きやすくなります。

IDisposable coroutinesDisposable;

void Start() {
    IDisposable hogeDisposable = Observable.FromCoroutine(Hoge).Subscribe();
    IDisposable fugaDisposable = Observable.FromCoroutine(Fuga).Subscribe();
    
    // 2つのIDisposableをくっつける
    coroutinesDisposable = StableCompositeDisposable.Create(hogeDisposable, fugaDisposable);
}

void AbortCoroutines() {
    // まとめてDispose
    coroutinesDisposable.Dispose();
}

コルーチンの寿命について

Unity標準のコルーチンは、MonoBehaviourを継承したコンポーネントの中で回ります。コルーチンを回すにはコンポーネント (とゲームオブジェクト) が必須で、Destroy(this)するとコルーチンは止まります。

一方、UniRxのコルーチンは、シーン上に自動生成されるMainThreadDispatcherというシングルトンオブジェクトの中で回ります。なので、MonoBehaviourを継承していないクラスからも利用できるという利点があります。しかし、先ほどのUniRxのコードでは、コンポーネントを破棄してもコルーチンが回り続けてしまうという問題も起こります。もしコルーチンの寿命をStartCoroutineと同じようにしたいなら、OnDestroyでIDisposableを破棄してやれば良いです:

void OnDestroy() {
    coroutineDisposable.Dispose();
}

コルーチンの操作

UniRxでは、コルーチンをIObservable<T>として扱えるため、Rxのオペレータを使ってコルーチンを操作することができ便利です。いくつか例を紹介します。

まずはコルーチンの連結です。Hogeが完了したらFugaを開始するコードを、UnityコルーチンとUniRxコルーチンの二通りで書いてみます。

コルーチンの連結 (Unity):

void Start() {
    StartCoroutine(Piyo());
}

IEnumerator Piyo() {
    yield return Hoge();
    yield return Fuga();
    Debug.Log("done");
}

コルーチンの連結 (UniRx):

void Start() {
    Observable.FromCoroutine(Hoge).SelectMany(Fuga).Subscribe(_ => {
        Debug.Log("done");
    });
}

この例だと、Unity標準が割とシンプルに書けるので、むしろUniRxの方が読みづらい気がします。Piyoのような新規メソッドを定義しなくて良い点は便利です。

しかし、もっと複雑な操作になると、UniRxの方が簡単に書くことができます。次はコルーチンの並列実行を書いてみます。

コルーチンの並列実行 (Unity):

bool hogeCompleted = false;
bool fugaCompleted = false;

void Start() {
    StartCoroutine(Hoge_());
    StartCoroutine(Fuga_());
}

void TryComplete() {
    if (hogeCompleted && fugaCompleted) {
        Debug.Log("done");
    }
}

IEnumerator Hoge_() {
    yield return Hoge();
    hogeCompleted = true;
    TryComplete();
}

IEnumerator Fuga_() {
    yield return Fuga();
    fugaCompleted = true;
    TryComplete();
}

コルーチンの並列実行 (UniRx):

void Start() {
    var hoge = Observable.FromCoroutine(Hoge);
    var fuga = Observable.FromCoroutine(Fuga);
    Observable.WhenAll(hoge, fuga).Subscribe(_ => {
        Debug.Log("done");
    });
}

Unityのコルーチンでは呼び出し側から完了を検知できないため、Hoge_やFuga_のようなコルーチンでラップする必要があります (コールバックを使う方法もありますが、同じくコードが煩雑になります)。完了したかどうかを保存しておくbool変数もコルーチンの数だけ用意し、コールバックが来るたびに、すべてのコールバックが呼ばれたかチェックする必要があります。

UniRxの場合、IObservable<T>に変換した時点でコルーチンの完了を検知できる状態になっています。そのため、WhenAllで複数のIObservable<T>の完了をまとめることができます。

2016-06-06

Unityの偽装nullの話

Unity

こんにちは、Nobollelエンジニアの古屋です。主にUnityでiOS/Androidのクライアントサイドの開発をしています。

今回は、UnityでオブジェクトをDestroyしたときの挙動に関する小ネタを書こうと思います。

Destroyされたオブジェクトは本当はnullではない？

UnityでオブジェクトをDestroyするとnullになります。

void Start() {
	var obj = new UnityEngine.Object();
	Destroy(obj);
	if (obj == null) {
		Debug.Log("obj is destroyed");
	}
}

Unityを使ってるとこれは普通なのですが、C#的に考えると、オブジェクトが勝手にnullになるのはおかしいです。実際のところ、Destroyされたオブジェクトは「nullっぽく振る舞うオブジェクト」であって、参照自体は生きています。

参照が生きていることを確認するために、System.WeakReferenceを使ってオブジェクトを追跡してみると、Destroyしても永久に「alive=True」であることがわかります。

UnityEngine.Object obj;
WeakReference weakRef;

void Awake() {
	obj = new UnityEngine.Object();
	weakRef = new WeakReference(obj);
	Destroy(obj);
}

void Update() {
	Debug.Log("alive=" + weakRef.IsAlive);
}

objが死なないのは、objの参照が「偽装null」として残っているせいでGCが回収できないからです。試しにobjをメンバ変数ではなくローカル変数として定義すると、Awakeを抜けた時点で参照がなくなり、次のGCのタイミングで「alive=False」になります。

また、System.Object.ReferenceEqualsを使っても、objがnullでないことが確認できます。

void Start() {
	var obj = new UnityEngine.Object();
	Destroy(obj);
	if (!object.ReferenceEquals(obj, null)) {
		Debug.Log("obj is not null");
	}
}

何が起きているのか

CUSTOM == OPERATOR, SHOULD WE KEEP IT?blogs.unity3d.com

この記事にもあるように、Unityのオブジェクトは==演算子をオーバーロードしてnullを偽装しているようです。たぶん、中にDestroyされたかどうかのフラグを持っていて、「本物のnull」でなければそのフラグを見ているのだと思います。

// たぶんこんな感じ
public static bool operator ==(UnityEngine.Object lhs, bool rhs) {
	bool objNull = ((lhs == null) || lhs.isDestroyed);
	return (!objNull == rhs);
}

実際に問題になるケース

この偽装nullはほとんどの場合うまく動いていて問題を起こさないのですが、かなり稀なケースにおいて問題になることがある (あった) ので、それらを紹介したいと思います。

ケース① ??演算子を使ったとき

??演算子は左辺がnullなら右辺を返す演算子です。次のコードなら、普段はaを返し、aがnullのときだけbを返します。

var c = a ?? b;

??を使うとコードが簡潔になって便利なのですが、このときもしaが「偽装null」だと、bではなくaが返されてしまいます。??の内部では「obj == null」ではなく「object.ReferenceEquals(obj, null)」としてnull判定しているのだと思われます。

ケース② ジェネリック内でnull判定をしたとき

次のようなコードに「偽装null」を渡すとfalseが返ってきます。

static bool IsNull<T>(T obj) where T : class {
	return obj == null;
}

T固有の==が実行され問題なく動きそうな気がしますが、すべてのTで共通の (たぶんSystem.Objectの) ==が実行されてしまうようです。

Tに制約をつければ、UnityEngine.Objectに定義された==が呼ばれ、問題なく動きます。

static bool IsNull<T>(T obj) where UnityEngine.Object {
	return obj == null;
}

ただし、これだとTにUnityEngine.Object以外を渡せず不便です。どちらも渡せて、かつ見かけ上のnullを判定したい場合は、次のように条件分岐する必要があります。

static bool IsNull<T>(T obj) where T : class {
	var unityObj = obj as UnityEngine.Object;
	if (!object.ReferenceEquals(unityObj, null)) {
		return unityObj == null;
	} else {
		return obj == null;
	}
}

2016-05-27

Cocos2d-x用新エディタ「Cocos Creator」

Cocos2d-x CocosCreator

こんにちは。清水です。現在、Nobollelさんにお世話になっているので、こちらのブログでも情報展開させていただきたいと思います。そこで今日はCocos2d-xの新しいツールである「Cocos Creator」について紹介します。

従来、Cocos2d-xを利用するときUIエディタ・アニメーションエディタとして、「Cocos Studio」が利用されていました。しかしこの「Cocos Studio」も2016年1月で開発がストップしています。これにとって代わって急速に開発が進められているのが「Cocos Creator」です。

この「Cocos Creator」では、「Cocos Studio」と同様に

　・UIエディタ

　・アニメーションエディタ

　・Windows, Mac, iOS, Android向けのビルドおよびパッケージ作成

　・ブラウザアプリの生成

ができるほか、

　・JavaScriptコードエディタ

も備わっています。つまりこれ1本で全てが完結することになります。

この「Cocos Creator」はCocos2d-x公式サイトのダウンロードページから入手することができMac・Windowsに対応しています。

http://cocos2d-x.org/download

「Cocos Studio」に扱い慣れていると、「Cocos Creator」を起動しても使い方がさっぱりとわからないのですが、そんな時は公式が用意したチュートリアルに沿って一通りの機能に触れてみると良いでしょう。

http://cocos2d-x.org/docs/editors_and_tools/creator-chapters/getting-started/quick-start/

2016/4にこのチュートリアルを利用したハンズオンを開催しましたので、そのとき使用したスライドも共有しておきます。

Cocos2d-x(JS) ハンズオン #07「新エディタ Cocos Creator v1.0」 from Tomoaki Shimizu

最もポピュラーなゲームエンジンである「Unity」に触れたことがある方なら、このチュートリアルを進めているとその「Unity」によく似ていると感じることでしょう。それもそのはずこの「Cocos Creator」は「Unity」を意識して作られているからです。公式のドキュメントには「Unity User Guide」まで用意されています。こんなドキュメントまで用意されていれば「Unity」ユーザにとっても「ちょっと触ってみようか」という気になるのではないでしょうか。

http://cocos2d-x.org/docs/editors_and_tools/creator-chapters/getting-started/unity-guide/

一方、これまで「Cocos Studio」を利用していたユーザにとって「Cocos Creator」はどの程度役立つツールなのか気になるところだと思います。ハッキリと言うと今(v1.0.3)の「Cocos Creator」はまだまだ発展途上であり、SDKBOXを始めとする重要な機能が備わっていないため、またところどころバグがあるため実用には向いていません。しかし「Cocos Creator」を少し触ってみると、UIエディタで設定できる項目が多く、コード量がかなり少なくなった印象を受けます。そのため今後安定した「Cocos Creator」がリリースされることに期待しています。

2016/5/26に「Cocos Creator v1.1.0 beta7」がリリースされました。「Cocos Creator v1.0.3」がリリースされたのが2016/5/11でしたので、この短い間に7回ものベータリリースを行ったことになります。このように急ピッチで改善が進められているためCocos2d-xのメインツールになることは間違いないでしょう。今後の「Cocos Creator」の動向に注目したいと思います。

http://forum.cocos.com/t/cocos-creator-1-1-0-beta-5-26-beta-7/36633

2016-04-16

知っていると特をするUnity AssetStoreアイテム6選