前回の記事で、WebGLによる３D描画と、enchant.jsによる2D描画を組み合わせることを検討しているという話をしましたが、一つ問題があります。
ゲームループの問題です。
現在、私のWebGLゲームプログラムはrequestAnimationFrameによる自前のループを持っています。まぁゲームなんだから当然ですよね。
で、2D描画をenchant.jsにやらせようと、enchant.jsを軌道（game.start()）すると、そう、enchant.jsのゲームループ（requestAnimationFrame）も回るのです。
つまり、ゲームループが２重に発生してしまう。
以下の清水氏による記事では、
http://d.hatena.ne.jp/shi3z/20130521/1369101883
< 引用ここから>
enchant.jsはフレームワークとライブラリの間にあるギリギリの線を狙っている。
enchant.jsはしかし厳密にはライブラリである。
なぜかというと、
enchant();
window.onload=function(){
core = new Core(320,320); //ここでコアを初期化する
}
このように、ライブラリの導入からコアの起動までをユーザが記述する必要があるからだ。
純粋なフレームワークなら、window.onloadの処理は隠蔽する。
< /引用ここまで>
厳密にはライブラリ、とのことで、その思想含め、「なるほどなぁ」と思いましたが、
やはりenchant.js自身でゲームループを管理している以上、「やはりフレームワークなんじゃないか」という気もするわけです（笑）
で、解決方法ですが、考えられるのは以下の二つですね。
A) enchant.jsを改造して、自前のゲームループを使わせるようにする。
B) 思い切って、ゲームループはenchant.jsに任せてしまう。
いろいろ考えたんですが、A)の改造をした場合、enchant.jsのバージョンアップのたびに改造しなきゃなりません。（いっそゲームループ関連をカスタマイズできるようにしたものをPull Requestしてしまうという手もありますが……多分絶対はねられると思う）
B)の場合、それならもう全部enchant.jsベースでゲームを作り直した方がいいんじゃね？ という話にもなります。
実際、enchant.jsはプラグイン含め、日を追うごとにどんどん高機能化・多機能化しており、乗っかってしまった方が、ゲームに求められるもろもろの諸機能を自作するより開発効率は間違いなく上がるでしょう。（パフォーマンス面はちょっと気になるんですけどね）
なので、今のところ、ゲーム全体をenchant.jsベースに作り直してしまおうという方向に傾きつつあります。
ただ、これはこれでまた別の気になる問題があります。それについてはまた後ほど……。
