enchant.jsのスクロール処理検証とフレームワーク自作の話

ここでアップした不思議のすごろくのすごろくシーンのデモだけど、
http://d.hatena.ne.jp/tsugehara/20130108/1357628651
どうにもスクロールが滑らかに見えないなぁ、という事で少し検証してみる事にした。

以前のバージョン

どうもスクロールが不自然に見える、は、これ。
http://tsuge.sub.jp/sugoroku/blog/sugoroku/test.html

なんか背景が遅れて動いているように見える。
ただfpsを60くらいにすると、それほど不自然な動きでもなくなるので、気のせいなのかもしれないし、もしかしたら他の問題なのかもしれない。

cocos2d javascriptで作られたアプリケーションのデモが大変滑らかななので、もしかしたらenchant.jsが悪いんじゃないかという可能性を捨てられず、ちょっと検証してみる事にした。

このバージョンはenchant.jsの設定で24fps。
なお、これも含めてすべてのバージョンは、一歩ずつ動く事を想定しているため、移動の際はキャラが移動終わりに少し硬直するけど、それはこっちの仕様。

enchant.jsの60fps版

cocos2d javascriptは60fpsを目指してるので、enchant.jsも60fpsにしてみたのがこちら。
http://tsuge.sub.jp/sugoroku/blog/60/test.html

サイコロを振るとか、メニューを表示するとか、矢印を表示するとかの余計な処理はカットしている。

そこそこ程度のpcでも、chromeなら60近く出るけど、enchant.jsは設計がflashと同じくフレームベースでメインループを管理しているため、滑らかに動き続ける代わりに遅くなる。
てことで、一部環境では動きが遅くなってるはず。enchant.jsでfpsとる方法しらんから、どのくらいから遅く感じるかはっきり調べてないけど。

ただ、このレベルの細かさで動かすと、スクロール時にキャラ先、背景後のような遅延は出ていないように見える。

canvas + 独自版

cocos2d javascriptで検証しようかとも思ったけど、あのフレームワーク安定板の最終更新が一年半以上前だし、なんか元気がないので、まあ作ってみるかって事で60fps前提で昨日やっつけで作った"ぼくのつくったさいきょうのふれーむわーく"で動かしたのがこちら。
http://tsuge.sub.jp/sugoroku/blog/new/my-test.html

あ、最強とか嘘ですw
お勉強もかねてtypescriptで適当に書いただけで、現状相当バグフィックスしないとデモ以上のものは作れない。
シーンを追加してくとどんどんゴミイベントハンドラがたまって死ぬw

ただそんな未完成な状態でも、フレームベースじゃなくて時間ベースで、処理が間に合わない場合はコマ落ちするタイプなため、仕組み上enchant.jsよりも滑らかになるはず。

でもスクロールは、enchant.jsとかわんなかった。
つまり、スクロールの問題はenchant.jsは別に悪くなくて、多分フレームが遅すぎ + マップチップの色が違うため目の錯覚が出やすかった、という事だと思われる。

なおタッチでは動かずキーボード入力のみな点に注意。
昨日はもう眠かったんで。。

速度はそこそこレベルのpc + opera辺りで見ると大分違うけどね。
手元のmacだとoperaでもこれは60fps出てて（safariだとrequestAnimationFrameが機能しないのか100以上出てしまうw）、enchant.js版は大分遅くなる。

発見

今回検証してみて、いくつか発見があった。

まず、TypeScriptはまあ触る前から予想はついてたけど、本当に導入が簡単で気をつける点がほぼ０。
初めて触っても全然違和感ないし、開発環境構築も楽だし、コーディングもまあやりやすいレベル。constructorって予約語もうちょいなんとかならんかったのかなってのと、他のtsファイルとの依存関係指定がモジュール使ってない場合ださくなってしまうくらい。

これ依存関係指定。

/// <reference path="E.ts"/>

なんでマークアップな上にこんな長いねんと。モジュールにしとけばimportってのが使えるけど。
個人的には自動解決（AAAってクラス使ってたらAAA.ts自動読み）希望、それが駄目ならせめて#include辺りにしてほしい。

TypeScriptのメリットデメリットは、これも予想ついてたけどメリットは事前チェックが出来る事、デメリットはコンパイルが必要なのでコンパイルを忘れる + コンパイルが体感出来る程度の時間がかかるってこと。
一回のコンパイルにかかる時間は、現在のスクリプト量だと2〜5秒くらいで終わるけど、javascriptでブラウザリロードすればいいのに比べると地味にストレスはある。

全体的にピュアjavascriptとどっちがいいかってのは難しいところだけど、javascriptに慣れてない人程使った方が楽じゃないという印象。特にC#屋にお薦め。
俺個人で触る分には、javascriptのが若干開発速度が速いかもしれないけど、多分本当に若干程度。
今のmac + Sublime Text 2のなんちゃって環境じゃなくて、Visual Studioで入力補完が完璧に出てくれるようになったら、多分開発速度も上がりそう。

それと、スクロールは良いんだけど、思ったよりenchant.js遅いという発見。
まあflash系のフレームワークだから、せいぜい30fpsが限界だろとは思っていたので予想の範疇ではあるけど、60は出ないね。
60出すつもりなら使わん方がいいかなと。

最後に、ゲームフレームワークは自作してもさして問題ないわと。
作る前から別に難しい事はモバイル対応以外にないなぁとは思っていたけど、enchant.jsもcraftyもコンパクトなフレームワークだし、少なくともpcでの動作前提 + 多少モバイルを意識する程度なら、3日もあればそこそこのが出来ると予想ついた。
人に使ってもらうフレームワークってのは、また別問題だけど、自分が使う分にはね。

自作しようかなぁと

まあ、TypeScriptで書かれたhtml5のゲームフレームワークもまだないだろうし*1、自作してもいいかなという気はしてる。

最初はenchant.jsに手をいれた方が早いかと思ってたんだけど、基本的な設計思想からして60fps出ないタイプだし、enchant.jsのソースも多分諸々の機種サポートとかcanvas対応とかのせいだろけど思ったよりわかりにくいから、作っちまった方が将来的にはいいんじゃなかろかと。

車輪の再発明な気もするけど、偉い人の言葉借りるとほらmatzもプログラマーは書けって言ってるし。モチベーションある内にやっちゃってもいいんじゃないのと。

モバイル対応はどうせテスト出来ないだろとか、tl.enchant.js相当のが無いときついなぁとか、デメリット結構ある。
tl.enchant.jsは、MITだし勝手に移植しちゃおうと思うけど、どうしても工数がかかっちゃうわな。

スクロールに問題がないか調べられて、そこに問題が無い事がわかったのに、遅いとかいう別問題で因縁をつけられたenchant.jsさんには申し訳ないのだが。
多分不思議のすごろくは、今回のデモで作ったものに近い、typescriptで書かれた自作ゲームエンジンで動かす事になると思われますわ。

*1:知らんけど。あったりしてw