DXRubyとDXRubyFrameworkの関係

Rubyのような高級言語において、拡張ライブラリの役割は大きくわけて3つ。
これは前にも書いたが、
(a) できないことを可能にする。
(b) できるけど面倒なことを楽にする。
(c) できるけど遅いものを速くする。
DXRubyは基本(a)で、DXRubyFrameworkは(b)(c)となる。
MyGameのようなRuby製フレームワークは(b)だ。
Ruby/SDLはとことんSDLラッパなので完全に(a)だが、DXRubyは純粋なDircetXラッパではないので、かなり(b)(c)が混ざっている。
同様にStarRubyも(a)(b)(c)混在と言えよう。

(a)のライブラリはRubyの機能を拡張し、(c)のライブラリはRubyの性能を拡張する。
言い換えれば、(a)はRubyの利点を伸ばし、(c)はRubyの欠点を解消する。
Rubyは多機能で便利な言語である代償として実行速度の遅さがあるわけだから、(c)のタイプのライブラリは速度を出すための代償として、Rubyの便利な機能をある程度制限する必要がある。
こういう言い方もできそうだ。
(a)はRubyの幅を広げ、(c)はRubyを尖らせる。

DXRubyは実行速度を重視した開発をしているが、アクションゲーム専用というわけではない。
たとえばRPGを作るにしても、マップ3レイヤをアニメーションさせつつ描画して街の人がたくさんうろうろしているだけで重いとか、そういうレベルでは困るのだ。
かなり実行速度はでるようになっているが、もともと(a)を目指したライブラリだから(b)のような便利機能はほとんど無い。
そういったものは後から用途に合わせて作ればいいからだ。

ところが、用途によってはRubyで書いていては遅い場合がある。
まあ、ようするに弾幕ゲーが作れない。
そこで、「キャラをスプライトとして管理する」「動きをある程度パターン化する」といった感じに、Rubyの柔軟性を制限することで性能を加速させるDXRubyFrameworkの必要性が出てくるわけだ。
速度も激しいが制限も激しいDXRubyFrameworkはできないことが多い。
だからライブラリ側に機能をいろいろ持たせて、Rubyから操作はできないけどライブラリでサポートすることでごまかす。
極端に(c)に寄ったライブラリは、(b)も併せ持っていなければ使い物にならない。
また、Rubyによる処理を省くことで速度を稼いでいるのだから、Rubyによる柔軟性とは相容れない。
オーバースペックな性能が出てくれれば余分な性能を削って柔軟性を得ることもできるだろうが、限界速度でも俺基準でギリギリなため、なかなか難しいことになってしまっている。

dan5yaさんの日記（http://dgames.jp/dan/?permalink&date=20090721_03）で、

今現在DXRubyFrameworkと呼ばれている、大量のスプライトを扱うフレームワークがポイントじゃないかな。これを本体に組み込んでこの機能をメインに売り出すといいと思うのだけど。

と指摘されているのだが、(a)を目指したDXRubyのメインを(c)に特化したDXRubyFrameworkとするのは、俺としては悩むところだ。
たしかにいい宣伝にはなるだろうけど、DXRubyFrameworkがメインになると、Rubyのいいところを活用しようとしたDXRubyの、実行速度以外の利点が無くなってしまいそうな気がする。
DXRubyFrameworkはDXRubyの実行速度に焦点を当てて最大限に引き出すもので、例えば実行速度以外のいいところを引き出すような別のフレームワークも用意してもいいのかもしれない。
弾幕ゲーが作れるスペックなんて普通のゲームには必要ないし。
そう考えるといかにもDXRubyの代表的フレームワークですよみたいな感じで、DXRubyFrameworkは名前が悪い。
周辺ライブラリの展開を考えて名前を考え直したほうがよさそうだ。