5.1さらうどん

@giginetの技術ブログ。ゲーム開発、iOS開発、その他いろいろ

CocosStudioが使いにくかったからcocos2d-xにPull Request送った話

cocos2d-xにPR送った

f:id:gigi-net:20140829182816j:plain

Add the feature that CCSSceneReader can load name properties as node names. by giginet · Pull Request #7883 · cocos2d/cocos2d-x

無事に通った、めでたい

何が良くなったか

PRを送ったのは、『CocosStudio』で作成したシーンをcocostudio::SceneReaderで読み込んだときの挙動。

今までは、CocosStudioで作成したシーンプロジェクトを読み込んだとき、その子ノードにアクセスするためには、タグを使ってアクセスする以外の方法がなかった。

auto scene = cocos2d::cocostudio::SceneReader::getInstance()->createNodeWithSceneFile("Scene.json");
// 子ノードを取るにはタグからアクセスする必要があった
auto object = dynamic_cast<cocos2d::Sprite *>(scene->getChildByTag(42));

これは、いちいちタグを定数として定義しておいたりしないといけなくて見通しが悪く、使いづらい。

しかし、CocosStudioには各ノードに対してnameを付ける機能が存在する。

f:id:gigi-net:20140829184534j:plain

現状の実装では、nameが出力されるシーンファイルには書き出されているが、ノードとして読み込む際に、特にどこにも設定されずに捨てられていた。

一方、cocos2d-x 3.2からは、Nodeに名前を付けることができるようになっていて、名前から子ノードが取り出せるAPIが提供された。

cocos2d-x: Node Class Reference

というわけで、このname属性をそのままNode::nameとして利用できるようにしたという話。

auto scene = cocos2d::cocostudio::SceneReader::getInstance()->createNodeWithSceneFile("Scene.json");
// CocosStudio上で設定したname属性からアクセスできるようになった!(ついでにテンプレートも使えるようになった!)
auto object = scene->getChildByName<cocos2d::Sprite *>("objectName");

一方でGUIReaderの場合は

Node::nameプロパティはcocos2d-x 3.2から追加された新しいプロパティなので、対応が追いついていなかったのではないか、という好意的解釈もできるが、以下の点について説明が付かない。

SceneReaderと似た機能に、cocostudio::GUIReaderというクラスもある。

これは、CocosStudioのシーンプロジェクトではなく、UIプロジェクトをノードとして読み込むクラス。

しかし、似たような機能を持つGUIReaderでは、Widgetを読み込むときにちゃんとname属性を読んで名前からアクセスできるようになっていた。なぜなのか。(バージョン3.2で確認)

cocos2d-x/CCSGUIReader.cpp at 2210d1fe87c3dd7d2ce79d01945b85a0de24862d · cocos2d/cocos2d-x

// Widgetを読み込む
auto widget = cocostudio::GUIReader::getInstance()->widgetFromJsonFile("Widget.json");
// ラベルのノードを取り出す
auto atlas = widget->getChildByName<ui::TextAtlas *>("AtlasLabel");

cocos2d-xヤバい

前回と同じ結論だけど、使えば使うほど闇っぽい。

今回は似たような機能なのに、両者間で微妙に仕様が違うと言ったことが起きていた。

name属性を引き継ぐかどうか、という話もそうだし、getChildByNameはテンプレートが利用できるのに、getChildByTagはなぜかテンプレートが利用できない点とか。

何か、GitHub覗いてる感じ、来たお便利機能のPRを片っ端からマージしてるみたいな感じで、ロードマップとかあるのかなあと疑問に思ってしまう。

とはいえ、日々送りつけられ続ける大量のPull Requestをしっかりレビューして、保守管理しているデベロッパーさんには頭が上がらない。

次回予告

あと何個かネタがあるので気が向いたらPRを送りたい。バグ修正だけじゃなくて、「ぼくのかんがえた最強のAPI」みたいな感じで欲しいモノ作って送ってもちゃんと見てくれてる感じがあるので、どんどん貢献していきたいところですね。

cocos2d-xでPhysicsWorldを使ったときのScene Graphの挙動にハマった話

f:id:gigi-net:20140710105133p:plain

ちょっと物理エンジンを使う必要があって、cocos2d-x 3.0から本体に取り込まれた物理エンジンを使ってみることにしました。

ところが、以前一度使ったことがあったのですが、バグっぽい挙動で数時間ハマって困った。

あれこれ調べてみて無事に解決したのでブログに記しておきます。

以下、3.1環境を想定して読んでください。

問題

今回起こった問題は、「剛体を付けた子ノードが親ノードに追従しない」という問題。

3.x系になってから一度物理エンジンは使ったことがあるけど、スクロール無しで完結するゲームだったので特に困らなかった。

Scene Graphが維持されないという問題は、画面スクロールがあるようなゲームを作るときに大変困る問題だと思う。

問題を検証するために、3.1環境で新規プロジェクトを作成し、HelloWorldSceneを書き換えてみた。

物理エンジンの初期化

Scene* HelloWorld::createScene()
{
    // 物理エンジンを有効にしたシーンを作成する
    auto scene = Scene::createWithPhysics();
    
    // 物理空間を取り出す
    auto world = scene->getPhysicsWorld();
    
    // 重力を設定する
    world->setGravity(Vec2(0, -1));
    
    // デバッグモードを有効化する
    world->setDebugDrawMask(PhysicsWorld::DEBUGDRAW_ALL);
    
    auto layer = HelloWorld::create();
    
    scene->addChild(layer);
    
    return scene;
}

まず、createScene()メソッドを書き換えて、物理エンジンを有効化します。

2.xと違い、3.xからはPhysicsWorldがSceneに取り込まれたので、Sceneにくっつけてあげます。

ちなみに、公式のドキュメントがあるんですが、3.0α版の時点で書かれたモノのようで、公式ドキュメントなのに、最新版の環境でドキュメントを写すとビルドすら通らないという割と酷い代物なのでご注意を!おそらく最新環境では上記コードが正しいです。

Physics | Cocos2d-x

問題:子ノードが親ノードに追従しない

   
    // add "HelloWorld" splash screen"
    auto sprite = Sprite::create("HelloWorld.png");
   
    // Spriteを剛体にする
    auto body = PhysicsBody::createBox(sprite->getContentSize());

    // ここをコメントアウトすると物理エンジン無しの挙動を簡単にシミュレートできる
    sprite->setPhysicsBody(body);
    
    // 重力を無効化する
    body->setGravityEnable(false);
    
    // 適当なラッパー用のレイヤーを用意する(わかりやすいように色を付けている)
    auto node = LayerColor::create(Color4B::BLUE);
    this->addChild(node);
    
    // 検証のためにラッパーがゆっくり上に上がるようにする
    node->runAction(RepeatForever::create(MoveBy::create(30, Vec2(0, 5000))));
    
    // position the sprite on the center of the screen
    sprite->setPosition(Vec2(visibleSize.width/2 + origin.x, visibleSize.height/2 + origin.y));
    
    // Spriteをシーンに直接追加せず、ラッパーに追加する
    node->addChild(sprite, 0);
    

こういうコードを書くと、nodeが上に上がる際に、それの子ノードであるspriteが追従して一緒に上がる挙動になるかと思います。

物理エンジン無し(3.1)

f:id:gigi-net:20140710103828p:plain

青いレイヤーがActionで上に移動していき、その子ノードのSpriteが一緒に追従して上っていく。想定された挙動。

sprite->setPhysicsBodyの行をコメントアウトするだけ。

物理エンジンあり(3.1)

f:id:gigi-net:20140710103708p:plain

同じ挙動をして欲しいのに、なぜか親ノードだけが上がっていき、Spriteは動かない。バグっぽい。

ちなみに、ラッパーを作らずに、thisを直接上に動かしても再現するけど、見やすさのためこのような実装にした。

明らかにバグっぽい

どうやら、PhysicsBodyをセットしたノードは親ノードの動きに追従してくれないみたい。

酷い挙動だ。

親ノードに剛体を付けたりしてみたけれど、それでもダメ。

マニアックな問題ではなく、物理エンジンとスクロールを併用しようとすると結構ハマる問題では。

例えば、『AngryBird』や、『LIMBO』のような物理エンジンを載せたプラットフォームアクション的なよくあるゲームを作るだけでも困る。

解決するには

当初は、自分で中のコードを弄って解決していたのですが、3日前(2014/7/7)に出たばかりの3.2rc0のCHANGELOGを見ていたらこんな記述が

   [FIX]           Physics integration: child node can move with its father

cocos2d-x/CHANGELOG at e1b29a8ef61248ec047b17be921e031d0d637904 · cocos2d/cocos2d-x

どうやら3日前に出たバージョンでは直っていたようだ。

3.2rc0

f:id:gigi-net:20140710104753p:plain

3.2rc0に上げたところ無事に動く。よかった!

がんばってdiffを追ってみたところ、2週間前のこのPull Requestで修正されていたようだ。

closed #5614: add transform support for physics by boyu0 · Pull Request #7234 · cocos2d/cocos2d-x

このPR出している人、物理エンジンガチ勢みたいな人で、履歴を見てみると物理エンジン周りに大量のPRを送っている。ありがたい限りである。

テストアプリ

3.2rc0から、付属しているcpp-testアプリに「Physics Transform Test」というテストが追加されていて、そこで挙動を確認できる。

このように、移動だけでなく、親ノードに対して回転や拡縮を行っても子ノードが追従して動くようになった。嬉しい。

f:id:gigi-net:20140710105133p:plain

まとめ

cocos2d-xヤバい。数週間に1回バージョンアップする上に、1回のバージョンアップで大量の変更が取り込まれ、数日前に動かなかった物が今日は動く、みたいなことがよく起きる。

今回発見できた問題はたまたま氷山の一角で、この手のバグは大量にありそうなのでご注意を!

よく使うディレクトリに瞬時にautojumpするAlfred Workflow作った

autojumpが便利

autojumpというCUIユーティリティがめっちゃ便利で良く愛用しています。

zsh使いなら効率改善のため知っておきたいAUTOJUMP - Glide Note - グライドノート

autojumpはある文字列から、それを含む一番よく使うディレクトリに自動的に移動してくれる優れもの

例えば

$ j D

などと入力すると、~/Desktopなどに一発で移動できます。

GUIで使いたい

他にjoというコマンドがあって、それを使うとGUIでディレクトリを開くこともできるけど、いちいち黒い画面を立ち上げなければならないので、上手い具合にGUIでも使いたかった。

Alfred Workflow作った

Alfred App - Productivity App for Mac OS X

Alfred2の有償版には"Workflow"という仕組みがあり、自分で検索用のスクリプトを作ることができます。 というわけで、Alfredからautojumpを叩く奴を作ってみた。

giginet/alfred-autojump-workflow

基本の使い方はAlfredを立ち上げて「J <キーワード>」と入力するだけでOK!

また、候補がみつからなかったときは、データベースの上位にあるディレクトリの一覧を表示してくれる。ディレクトリ名がうろ覚えでも簡単にアクセスできてベンリベンリ。

Workflow内にautojumpを含めているので、shellでautojumpを導入していなくても使えるはず・・・・・・。(未確認)

CUI版を使っている人は、同じデータベースを共有しているので、今まで学習させた頻度データがそのまま使えます。逆にWorkflowからautojumpしても、CUIで使うのと同様に利用頻度の更新も行われるため、CUI版を使わなくても利用できるはず。

導入方法

  1. Afred2をインストールする
  2. Alfred PowerPackを買う
  3. autojump.alfredworkflowをダウンロードする
  4. ダブルクリックでインストールする

どうぞご利用ください。

Alfred Workflowの作り方

初めて作ったので見よう見まねでやってみました。

基本はスクリプトを書いて、標準出力を順次受け渡していくだけ。 普通にShellスクリプトを書いて自由に実行できる。Python, Perl, Ruby, PHPなどのスクリプトを実行することもできるので好きな言語で書けます。 一覧表示をしたり、特殊な表示方法は、決まったフォーマットのXMLで出力することで整形してくれます。

公式ではPHPスクリプトが多くて、Alfred向けのフォーマットに出力してくれるライブラリが充実している感じ。要はXMLを吐けばいいので何でも書けます。僕はPythonで書いた。

autojump.alfredworkflowは、ScriptFilterで候補を表示し、Run Scriptでopenしてるだけの簡単な実装

f:id:gigi-net:20140626113240j:plain

資料はあんまり多くないですが、公式のフォーラムや、他の人が作ったWorkflowを参考にすれば、割と自由にいろいろ作れると思います。

Workflows - Alfred v2 Support

zenorocha/alfred-workflows

Thanks to WPZOOM about nice icon sets.