Updated at: 2014-03-02

krewFramework を何故つくったのか

「ゲームフレームワーク」のレイヤーで手頃なものが無かった

ゲームやアプリケーションをスクラッチで開発する際、 何かしら既存のライブラリを利用することはよくあります。 Web サービスの開発などにおいては、すでに各言語ごとにこなれたフレームワークがあるでしょう。 ですがゲームの分野においては、フレームワークのレベルまで実装方法を規定せずに、 「ゲームのための便利ライブラリ・ツール集」で留めてある ものが多い印象です。 これはゲームというものが様々な形態をとるため、 その実装方法が多岐に渡るという側面があるからだと思います。

ActionScript3.0 で Stage3D を使った 2D ゲームを作るための Starling も、 「ゲーム用ライブラリ」のレイヤーです。 （Flash 標準 API の Sprite などが、Stage3D に対応したものと思えばよいでしょう。） シーン管理やリソース管理など、ゲームの基盤システムの実装は別に持つ必要がありました。

別の言語ですが Cocos2d-x などはフレームワークのレイヤーと言ってよいでしょう。 ちょっと別格ですが Unity もそうですね。 これらのソリューションを使う場合なら、そこの方法論に従ったと思います。 Adobe AIR を選んだのは、僕の好みの問題です。

概念は言語非依存

今回は自分が Adobe AIR 向けにゲームを作ろうと思ったので、 フレームワークは ActionScript3.0 で記述し、内部的には Starling を使用しています。 ですが設計理念とインタフェースのスキームは、特定の言語に依存するものではありません。 もしいつか Adobe AIR が失われて別のものを使わなくてはならなくなったとしても、 僕はそこで同じようなフレームワークを構築するでしょう。

自分はもともとプログラマとして「心地よくゲームコーディングできるフレームワーク」 の一つを自分の手で構築しておきたいという思いもあったため、 今回はフレームワークを自作することにしました。

規定した分、楽に書けるように

フレームワークがなすべきことは、以下だと考えます。

• やり方を制限・規定する
• 規定した分だけ、楽に・安全にする

やり方を敢えて「制限」することには、以下の恩恵があります。

• 「やり方」を自分で考えなくてすむ（やることだけに専念できる）
• 実装スタイルを統一できる
  • 多人数開発において、他のメンバーの実装が把握しやすくなる

また、制限を設けて汎用性を犠牲にする代わりに、「より楽に書ける」環境を提供できます。 設定より規約 （Convention over Configuration） の考え方です。 方法論・実装スタイルを規定する代わりに、ゲームを複数作る際の実装効率を上げることが、 フレームワーク開発の目指すべきところです。