Star RubyとDXRubyの似ているところと似てないところ

数あるRuby用ゲームライブラリの中でも、Star RubyとDXRubyはなんだかよく似ている。
英語圏でメジャーなrubygameとかgosuとかまで含めるとまた色々あるのかもしれないが、ちょっと見た限りではシンプルではあってもあんまり似ていなかった。
どこが似ていてどこが違うのか、考えてみよう。

とりあえず似た点はこんな感じだろうか。
(a)高度なオブジェクト指向技法やRubyの機能は使わず、シンプルにまとめる。
(b)初心者にやさしいと思われる方向性。
(c)最低限必要だと思われる機能のみ実装する。
(d)Ruby用ゲームライブラリの中でどういう位置づけを狙うのか特に考えていない。

違う点はこんな感じ。
(A)全てをテクスチャとして単一に扱うか、DirectX流に描画・データを切り分けるか。
(B)SDLかDirectXか。
(C)表現力の目標。
うーん、あんまり無いｗ

んじゃあそれぞれ。
(a)については、難しいことをすると使うのが難しくなるのだ。
例えばクラスを継承して使うことを前提にすると、それだけで初心者は理解できなくなる。
このあたりは(b)にも通じるものがあるが、Rubyの組み込みクラスを使う程度の感覚で扱えるライブラリであるのがポイントとなる。
だから基本的な機能はメソッドベースだし、クラスがあってもせいぜいnewして使ってね、ぐらいだ。
描画系にしても、Star Rubyで言うTexture、DXRubyで言うImageは、自分自身に何かを描画するメソッドを持っている。
自分自身を画面に描画するメソッドでは無いところがミソで、こういうところがメソッドベースであり、基本設計レベルの思想が似ているから、全体として似てくる。
そしてそれが複雑さを軽減し、初心者でも理解しやすいものになるはずだ、という考え方も。
(c)も発想としては同じで、機能を削ってシンプルすることで理解しやすくなるはずだ、というところから来ている。
機能を満載しても使われないものが多いだろうし、ちょっとしたものでも、大掛かりなものでも、それを理解するコストよりも、Rubyなら自分で書くコストのほうが低い。
自分で自分用のライブラリを組み上げていったほうが速い、というのはLispに通じるものがあり、そのへんはRubyならではって感じだろう。
ただし、ほんとに初心者であれば、どうやって作ればいいのかもわからないだろうから、そのあたりをどうサポートするかが課題だ。
(d)は、だいたいもともとそんな大きなことを考えて作り始めたわけでもない。
星氏がどういう目的で作っているのはさすがにわからないが、俺は自分で使いたかったからという単純明快な理由であって、似たような考えを持ちつつ、自分で作れない人がいたら使うかもしれないなーと公開しているわけで、本気でRubyゲームプログラミングの世界を変えようとは思っていない。
せっかくだから使う人が増えるにはどうしたらいいのか、とかは考えてはいるが。

違う点について。
(A)は結構なポイントだ。
DirectXは、レンダーターゲットに対する書き込みを描画として、それ以外のサーフェイスに対する書き込みは描画用のデータ作成として切り分けている。
だから、レンダーターゲット向けはDrawPrimitiveで高速で、デバイスロストで消えるし、それ以外のサーフェイス向けはロックなどしてソフト描画するから低速だ。
DXRubyはDirectXに特化しているから、Window.draw系は描画、Imageクラスのメソッドはデータ作成用という、DirectXと同じ切り分け方になっている。
これに反することをしようとすると、Imageクラスの機能拡張みたいに、とんでもない苦労をすることになるわけだ。
一方、Star Rubyは最終描画用画面までひっくるめて全てのテクスチャに対して「描画」する。
全てがテクスチャというより、全てが描画メソッドなのだ。
SDLがどういう思想で作られているのかはわからないから、これが単純に(B)と関連するのかはわからないのだが。
(B)は実行環境に大きく影響を与える。言うまでも無い。
それは逆に言えば、実行環境を制限することで、Microsoftの定義するAPIに合致したビデオカードが存在し、最適化されたパフォーマンスをたたき出すことを可能とする。
実際、DirectXが描画とデータ作成を切り分けているのは純粋に実行速度を稼ぐためなわけで、全てを描画メソッドとして扱うStar Rubyと、DirectXに沿った設計をしているDXRubyでは、根本の部分で実行パフォーマンスに差が出るのは当たり前の話なのだ。
これはもう、マルチプラットフォームを取るか、Mircosoftの世界で最適化するか、という単純な選択でしかない。
最後に(C)。
Star Rubyは明確に「スーパーファミコン」としている。わかりやすい。
そういえば今までDXRubyの目標を書いたことがなかったが、ついでだからここに書いておこう。
まず、3Dは捨てる。
3Dを扱うには、言語側の優れたパフォーマンスか、ガチガチに固めたフレームワークが必要だ。
Rubyで扱いやすいライブラリという時点で無理だ。
2Dでゲーム機というと、スーパーファミコンになってしまうが、狙いはそこではなく。
スーパーファミコンでも、例えばアーケードゲームを移植しようとしたらかなり表現を落とさなければいけなかったわけで、つまり2D表現にはその上がある。
俺がDXRubyで目指すのは、2D表現でやりたいことが自由にRubyで実現できる環境だ。
作りたいと思ったゲームが思ったとおりに作れる環境。
Rubyでやろうと思うと、これだけ最適化していてもまだちょっとPCのスペックが足りないのだが、そこは更なる努力とアイデアでカバーということで。
だから実は疑似3D表現というのも微妙に焦点から外れる。
俺にとって、DXRubyにとって、仕様をややこしくしてまでサポートすべきものではないのだ。

長くなってしまった。
でも実際使う側の視点で見ると、どっちを使うか悩むだろう。
確かに似ている。
違うところは主に裏側だし。
一番大きな違いは、「実行環境の数」と「実行パフォーマンス」なのだろう。
つまりDXRubyはパフォーマンスの良さをアピールしないとダメだということか。
ふーむ・・・