Crafty の使用にあたって
Javascriptでゲームを作りたいと思い、
Crafty というフレームワークを使用しました。
今後、このフレームワークを使いたいという人の参考になればと思い、開発の経緯ほかをまとめました。
ちなみに、できあがってゲームはこちらです。
カピバラ・キッドの脱出（ブラウザ版）
Crafty選定の理由
極端に凝ったゲームを作る気はさらさらなかったので、軽量でシンプルな構造で、最低限の機能が揃っているフレームワークを探しました。
http://html5gameengine.com/
とか
http://buildnewgames.com/game-engine-comparison/
とか
http://matome.naver.jp/odai/2134682461157875201
とか
http://www.jsbreakouts.org/
とかを参考にしながら、Craftyを選定し、とりあえずやってみようということにしました。
まずはチュートリアル
普通なら、まずはドキュメントとを読んで言いたいところなのですが、Craftyのドキュメントはこのありさまです。
http://craftyjs.com/documentation/
2014年10月現在では「Here would be information about...」の連発になっていて、まったく役に立ちません。
そこで、Craftyの開発は、
を参考に進めることになります。
何はともあれチュートリアルをやってみて感触をつかみます。
チュートリアルは英語ですがそれほど難しいことは書いていませんし、Javascriptが読めればどうにかなります。
ざっくりとやってみるだけなら半日もかかりません。
そして、この段階では深いことは考えず、ざっくりとやってみるだけで十分です。
ここで挫折するなら、Craftyの使用は諦めたほうがいい、という話になります。
なお、このブログ記事の続きを読む前にチュートリアルに目を通しておくことをお勧めします。
シーンの設計
要件はすでに決まっているものとして話を進めます。
（Craftyの機能の把握ができんていないのに要件を決められるのかといった、卵が先か鶏が先かの話になるのですが、それはそれで別の機会に）
Crartyは、シーン（画面）という単位でアプリケーションを管理します。
スタート画面、ヘルプ画面、ハイスコア画面、プレイ画面、ゲームオーバー画面、といった画面の一つ一つがシーンとなり、これらのシーンが集まって、一つのゲームになります。
なので、コードを書く前に、いくつのシーンが必要になるのか、目算を立てておく必要があります。
ざっくり考えて
- 起動直後、リソースのロード中に表示する「ちょっと待っててね」の画面
- タイトル画面
- ヘルプ画面
- 設定画面
- ハイスコア画面
- スタート画面
- プレイ画面
- 1ステージクリア後の、次のステージへのつなぎ画面
- ゲームオーバー画面
といったあたりを準備することになります。
これらの構成をどうするか、しっかり構想を練ってから、チュートリアルでいうところの、scenes.jsを書くことになります。
コンポーネントの設計
Craftyはコンポーネント指向の設計になっています。
クラスを作ったりインスタンスを作ったりすることはないので注意してください。
ゲームのキャラクターや障害物はコンポーネントとして作成することになります。
これについては、チュートリアルをこなしていれば、それほど難しいものではないでしょう。
いわゆる普通のプログラミングです。
ここで分からないところがあれば、APIドキュメントやCraftyのソースにあたることになります。
最終的にアプリケーションを書き上げるには、めんどうですが、ざっくりとAPIドキュメント全体に目を通すことになってしまうでしょう。
APIドキュメントは上から読むと頭が痛くなるので、Eventsコンポーネントや2Dコンポーネントのあたりから眺めるのをお勧めします。
一番上のCoreは、ある程度Craftyに慣れてからでないと、何を書いているのかよく分かりません。
ゲームの構成
ここまで来たら、後はgame.jsを書いてゲーム全体をまとめるだけです。
これも普通のプログラミングですので、開発経験があればそれほど困ったことにはならないでしょう。
モバイル対応について（画面）
ソースコードを見れば分かるのですが、Craftyは、モバイル環境にも対応しています。
モバイル環境だと、自動的にHTMLデータにメタ情報をセットして、ビューポートの調整までやってくれます。
（ただし、バグっぽい現象があるので後述します）
画面の横幅についてはCraftyが対応してくれるからよしとして、問題は縦幅になります。
ソースコード上では320px × 480px を基本に考えて設計するのが無難かな、といった印象を受けました。
ただし、アドレスバーやステータスバーがあるのでブラウザの実効画面これより上下に小さなものになります。
私は
こちらのサイトの数値などを参考にしましたが、日本でメジャーなiPohneを基準に考えると、実際に使える画面サイズは320px × 444pxくらいと考えるのが無難です。
なお、HTML5ではスマートフォン等の画面の回転を抑制する方法はありません。
回転しても大丈夫なように設計するか、ユーザーが自分でどうにかするだろうということで、スパッと割り切るか、のいずれかになります。
Retina対応を考えると、コード上の設計は横幅320pxでも、画像データ等は横幅640pxを前提に準備しないと、画面上でぼやっとした感じになるので気をつけてください。
なお、Craftyではゲーム画面は実行時は<div id="cr-stage"></div>内部に置かれるので、cssで
#cr-stage {
text-align: center;
padding-left: 0;
padding-right: 0;
margin-left: auto;
margin-right: auto;
display: block;
}
と書いておけば、ゲーム画面をセンタリングすることができます。
モバイル対応について（音）
こちらは絶望的な状況です。
Craftyに問題があるのではなく、スマホ側の問題です。
こちらの記事が参考になります。
iOS/Android で HTML5 の audio/video を任意のタイミングで再生する方法
ユーザーが何らかのアクションを起こさない限りは audio/video を使用できず、さらにプレロードも制約されます。
とてもではありませんが、簡潔に実用的なコードを書ける状況ではありません。
オーディオスプライトを扱うライブラリを別途用意するか、マニフェストを用意してHTML5アプリケーションにしてしまうか、潔く音は諦めるか、することになります。
HTML5アプリケーションにすると、それはそれで面倒なメッセージが画面に表示されることになるので、私は今回は音は諦めることにしました。
モバイル対応について（入力）
Craftyのソースを調べてみて分かったのですが、タッチパネルからの入力は、Craftyではマウス入力のイベントに自動的に読み替えられます。
タッチすると、MouseDown、離すとMouseUp、動かすとMouseMoveのイベントが発生します。
なので、Clickも含め、これらのイベントに対応するようにコードを書いておけばそれでOKです。
バグについて
Craftyでプログラミングをしていて困ったのはモバイル対応の部分でした。
特に音の部分については散々悩まされたあげく、「あきらめる」という対応をとらざるを得ませんでした。
将来のバージョンでモバイル対応のいいサウンドライブラリが用意されるのを待つのみです。
ところでもう一つ、モバイル開発の画面まわりで、どうもCraftyのバグらしいものが見つかっています。
モバイル環境だとCraftyが自動的にビューポート制御のメタデータをHTMLデータに組み込んでくれることは上で説明しました。
この部分の制御で、Craftyはデスクトップだとcssで <div id="cr-stage"></div> に postition:relative を設定しているのですが、モバイルでは「敢えて」これを設定していません。
で、これを信用してモバイル環境で開発すると、見事に背景とゲーム画面の位置がずれてしまいます。
下手にcssで調整しようとすると、今度はタッチイベントの検出位置がずれてしまい、使い物になりません。
要はこの「敢えて」がどうもバグっぽいのです。
Crafty 0.6.2 の場合、12,188行目から始まる if ブロックがこれに該当します。
12,209行目の「else {」が余計なのでこれと、12,215行目の「}」を削除し、モバイルかどうかに関わらず「elem.position = "relative";」以下の実質4行が生きるように書き換えると問題は解決します。
ただし、この件については私は公式フォーラム等に問い合わせたわけではありません。
次のバージョンアップでまだこの「else」が残っていたら、本格的に問い合わせをしてみようと考えています。
