CreateJS 互換ライブラリ wahid の開発

このブログは「mobage developers blog」2016.10.3の記事を転載させていただきました。

こんにちは、システム本部の坊野です。

多くの方々のご協力をもちまして 9 月末にCreateJS 互換ライブラリ wahidをオープンソースで公開することができました。

本日はこの wahid の開発の話をしようと思います。

名前の由来

開発の話に入る前にこの wahid という名前の由来についてお話します。

この wahid という単語は、アラビア語で「(数字の) 1」を意味する単語 واحد をアルファベット表記にしたもので、 CreateJS 互換ライブラリ CreateJS-Lite (仮) の開発コード名でした。

しかし、この CreateJS-Lite (仮) をオープンソースで公開することになったときに CreateJS-Lite (仮) のままだとCreateJS と混同される恐れが出てきたため、区別しやすくするためこの wahid という名前を用いて公開することになりました。

開発の背景

そもそも CreateJS とは gskinner という会社が開発した JavaScript ライブラリです。

CreateJS を用いることによって、 Adobe Flash Professional (現 Adobe Animate CC) で作成された Flash アニメーションを JavaScript (HTML5) 形式で出力できます。

このため、 CreateJS は Flash アニメーションを用いたゲームでもよく用いられています。
しかし、当時 CreateJS はあまりゲームに特化した設計でなかったため、 CreateJS を用いたゲームをスマートフォンで実行した場合十分なパフォーマンスが発揮できないという問題がありました。

このため、目的を「ゲームのパフォーマンス向上」に特化して CreateJS を再実装することになりました。

開発の方針

このような経緯で CreateJS を再実装することになったのですが、開発に関していくつかの懸念点がありました。その中でも一番大きいものが「CreateJS との互換性をどうするのか」というものでした。

結論からいいますと、私たちは「CreateJS との互換性に注力しない」ことにしました。なぜなら、私たちは「CreateJS との互換性を重視してパフォーマンスを低下させるよりも互換性を犠牲にしてでもゲームのパフォーマンスを向上させるべきだ」と思ったからです。

実際のところ、互換性テストを見てみると、現在においても wahid の CreateJS との互換性はあまり良くありません...というかかなり悪いです。とはいえ、実際の CreateJS を用いたゲームを見てみますと (ゲーム開発者のみなさんのご協力のおかげで) 互換性テストで見るほどの違いはないと思います。

また、パフォーマンスに関しても残念ながら「すべてのブラウザで向上した」とまでは言えませんが、多くのスマートフォンのブラウザにおいては向上していると思います。

補足ですが、この「CreateJS との互換性に注力しない」は、決して「wahid は CreateJS との互換性を軽視している」ということではありませんし、私たちは常に互換性向上のための努力を行っています。しかし、残念ながら私たちの勉強不足のため、互換性問題を修正する方法としてパフォーマンスを犠牲にする方法しか思いつかない場合があり、パフォーマンスを犠牲にしなくても解決できる方法を思いつくまでその互換性問題を修正しないという選択をしました。

実装の過程

この wahid の実装にあたり、私たちはゲーム開発者のみなさんのご協力のもと実際のゲームにおいて CreateJS がどのように利用されているのか詳しく解析しました。その結果としてたくさんの有益な情報が得られたのですが、その中でも「ゲームは CreateJS のすべての機能を利用している訳ではない」ということは大変貴重でした。
なぜなら CreateJS は非常に大きなライブラリなのでその全てを再実装することは現実的ではなかったからです。

また、この解析結果をうけて、私たちは WebGL を用いて「ゲームで利用されている CreateJS の機能をエミュレートする」という方針で実装することにしました。もっと率直に言えば「WebGL を用いて高速実行可能な CreateJS の機能のみを実装する」ということです。

WebGL はスマートフォンのネイティブゲームなどで用いられている OpenGL ES 2.0 という API をブラウザ上で実装したもので、非常に高速に動作します。他方 WebGL は CreateJS が用いている Canvas 2D という API とは非常に異なる API のため、WebGL を用いて実装すると CreateJS との互換性を保障するのがより困難になります。このように WebGL を利用することには利点と欠点が両方存在していたため、私たちは実際にゲームの解析を行うまでWebGL を利用するべきかどうか決めかねていました。

しかし、実際のゲームを解析した結果、ゲームにおいて利用されている CreateJS の機能に限れば、それらを WebGLでエミュレートすることは十分可能と思われましたし、何よりも「ゲームのパフォーマンス向上のためなら少々の互換性問題は私たちの方でカバーする」というゲーム開発者のみなさんのサポートのおかげで、私たちはあえて WebGL を用いて wahid を実装することにしました。

ゲームへの組み込み

実装後も CreateJS の代わりに、 wahid をゲームに組み込んでリリースされるまでには、さまざまな問題が発生しました。もちろん、これらの問題の大半は wahid で対処すべき問題だったのですが、中にはゲーム側で対応したほうが良いと思われる問題もありました。

たとえば CreateJS で色変換を行うと非常に遅いため、色違いの複数の画像を用意しているゲームがあり、それらの画像が大量のメモリを消費しているという問題がありました。 (補足ですが、一般的に wahid は CreateJS よりも多くのメモリを消費します。) 他方 wahid では、色変換は非常に高速なのでそれらの色違いの画像を使わないほうが画像の読み込みが高速になりますし、メモリも節約できます。

ですから、この問題に対してはゲーム側で対処したほうが良いと思われたので、ゲーム開発者のみなさんに事情を説明してゲーム側で対処していただくことにしました。

また、問題の中にはあえて CreateJS との互換性を犠牲にしたほうがよいと思われるものもありました。たとえばCreateJS は画面をタップしたとき、画像のピクセルデータの読み込みをおこなってタップした位置にあるオブジェクト (画像) を取得します。
この方法は非常に高い精度で判定できるのですが、画像のピクセルデータの読み込みはブラウザでは非常に遅いため、ゲームのようなアプリケーションで行うとパフォーマンスが低下します。

このため、ゲーム開発者に目的を尋ねたところそこまで高い精度を必要としていなかったため、wahid では画像のピクセルデータの読み込む代わりに画像の表示位置と大きさを用いることによって、精度は犠牲にするかわりに高速に判定できる方法を提供することにしました。 (もちろん CreateJS と同様に画像のピクセルデータの読み込みをおこなって判定することもできます。)

他にも、ゲームに wahid を組み込む際には、本来の CreateJS の機能ではないのですが、追加したほうがよいと思われる機能も見つかりました。

たとえば、多くのスマートフォンのブラウザはタップをしないと音を鳴らないようになっているためスマートフォン用ゲームでは最初のタップ時に音を鳴らすという処理をするのが一般的です。

とはいえ、この処理の実装方法はスマートフォンの OS によって微妙に異なるためすべてのスマートフォンに対応するのは大変な労力が必要です。このようなゲームにおいて一般的な (共通の) 処理はライブラリ側で行ったほうがゲーム開発者が楽になると思われたため、私たちは最初のタップ時に音を鳴らす機能を wahid に追加しました。

このように CreateJS の代わりに wahid を利用すると、さまざまな問題が発生しましたし、これからも発生すると思われます。しかし、先に書いたとおりそれらの中はゲーム開発者のみなさんで対処していただいたり CreateJS との互換性を犠牲にしたほうが結果としてゲームのために良いと思われるものもあります。

ですから、問題を発見した場合は私たちがみなさんのゲームにとって最適な方法を見つけられるようにご協力いただければと思います。