すごろくシーンのイメージアップと、現在までのenchant.jsについての感想
まだ結構すごろく生成部分にバグあるだろうけど、PCが返ってきてない*1のでまあそれはおいておくとして、とりあえずenchant.jsのテストがてら作っていたすごろくシーンのイメージをアップ。
http://tsuge.sub.jp/sugoroku/blog/sugoroku/test.html
最初の画面でタッチするか、Enterキーでメニューを出して、メニュー左上のボタンを押すとサイコロ転がして移動出来る。
移動時の通路判定とかは一切してないので、道がないところももりもり動けるし、ゴールしてもなんの特典もないし、画面外にも動ける点など諸々ご容赦を。
enchant.jsに慣れる目的だったので、その辺りでいくつか気づいた点があるので、メモ。
レイヤーが無い
えー、そうだっけなぁと思ったんだけど、enchant.jsにはレイヤーが無い。
正確にはレイヤーというクラスはあるけど、これは画面に重ね合わせて表示するという意味でのレイヤーではなく、描画単位を管理するためのものでTHREE.jsで言うrendererに近い。
enchant.jsは基本的に単一レイヤーで、例外的にDOMLayerとCanvasLayerを重ね合わせて描画する事は出来る。
別レイヤーを作る事も可能だけど、設計指針としてenchant名前空間に作る必要があるので、先にenchant.MenuLayerとかを作る事で、初めて「scene.addLayer("Menu")」が使える。
サードパーティがenchant名前空間いじることを想定しているとも思えないので、現状は基本単一レイヤーの最大２レイヤーなのだ。
ということで、レイヤー系は基本自力実装になる。
ネットを眺めると、皆Group使って頑張ってるみたい。でも表示順はSceneへのaddChild順になるので、注意して設計しないと駄目だろうねと。
俺もどうしようか検討中。
小数座標でマップが滲む
CanvasSceneを使っている場合、マップが妙に滲む場合がある。
色々調べてみたら、Scene自体の座標が小数座標の場合に滲むみたい。
小数座標になる条件ってのは結構色々あって、特に0.6系では必須のtl.enchant.jsを使うとほぼ確実に小数点で扱われる。
だから、シーンのスクロールにtlを使ってはいけない。
今回だと主人公キャラにシーンのフォーカスを自動で合わせるので、主人公キャラの移動にもtlを使ってはいけない。
画像が滲むせいでスクロールが妙に不自然に見えたり、DOMで書くと不要な境界線が出たりするので、最初何事かと思ったよ。
SceneにmoveToを使ってはいけない
SceneにmoveToを使うとレイヤーが追従しないので、Sceneの座標を移動する時はxやyで移動させないといけない。
//これはOK scene.x = x; scene.y = y; //これは駄目 scene.moveTo(x, y);
どうしてもSceneにmoveToとか使いたい場合、こういうよくわからんことしないといけない。
scene.moveTo(x, y); scene._layers.Canvas.moveTo(x, y);
※言うまでもなく、こういう事はフレームワークのアップデート一発で死ぬので、やっちゃいけない
Sceneのxとyはただのフィールドではなくプロパティになっているので、実態は自身のx、yを自身が管理するレイヤー全てに反映させるって事やってる。
だから実はSceneのxやyには意味が無くて、座標の本体はLayerなんだけど、moveToとかはラップしきれてないので使っちゃいけないメソッド化してるということ。
全部は見てないけど、この手のメソッドがSceneとLayerのつなぎ不足としてまだいくつかあると思われる。
なんかオブジェクトの位置関係がおかしい
アップしたものを見てもらえればわかるとと思うけど、マップスクロール中のキャラクターの座標がおかしい。
マップスクロールが終わって、ようやくキャラクターがちゃんとした座標に入るんだけど、この間キャラクター座標なんていじってないんだよね。
この現象はまだちょっと謎。
メインPCが戻ってきたらちゃんと調べようと思うけど。
全体的に
enchant.jsはCanvasLayerを後付けで入れたので、DOMからCanvasへの切り換えがまだ未成熟なんじゃないかなぁと。
そこまで追ってないけど、多分XXLayerクラス自体が後付けで、前はSceneだけだったんじゃないかな。だからLayer機構も少しおかしい。
enchant.jsのLayerは本来Rendererなんだけど、DOMで書くフロントレイヤとCanvasで書くメインレイヤを使いたいというケースを考慮して、RendererとLayerがごっちゃになった今の設計になったんじゃなかろうかと勝手に推測。
ここまで見てきて、enchant.jsはDOMゲーム作る場合は確実に筆頭フレームワークなんだけど、Canvas中心のゲームフレームワークとして筆頭かっていうと、そうでもない気がしてきた。
とはいえ、じゃあCanvas中心のゲームフレームワークで筆頭っていうとArctic.jsなのかっていうと全然そんな事もないと思うので、そんなに代替候補もないんだよね。
現在までで大分癖に慣れてきたので、後は戦闘時に30スプライト + 30エフェクトくらいをごちゃごちゃ動かす状況の中で、どのくらい動けるかを見た上で判断したい。
慣れれば１から作るよりは大分楽なので、昨日よりはポジティブな手応えがあるけど、以前よりも少し癖が強くなってきたなというのがenchant.jsに関する現在までの印象。
