ゲームループの分解を考える

Rubyでアクションゲームは一般的なイメージとして無謀だ。
ファミコン程度のものであればできそうな感じ。
しかしそれも物によって、ライブラリの得意不得意というものがある。
大きな画像を描画するのが遅ければ全画面スクロールして大きなキャラを動かすのは難しく、そうすると画面の変化が少ない固定画面ものになり、それでも細かいテクニックを駆使して負荷を減らす必要があったりする。
DXRubyは大きな画像に強いから、一枚ものの背景を重ねるぐらいなら余裕だし、DXRubyMapを使えば細かい背景チップを並べることも可能だ。
Rubyが遅いから大量のキャラを動かすのは本質的に難しいが、キャラが大きく少ないゲームなら問題は無い。
全画面スクロールしつつキャラが大きく少ない2Dゲーム、すなわちファイナルファイト系の横スクロール格闘や対戦格闘ものなんかが、DXRubyが最も得意とする分野ということになる。
ほんとはサンプルでシューティングなんか作ってる場合ではなく、得意な分野で性能を最大限に活かしたゲームを作るべきだったのだろう。
誰か絵とか描いてくれないかしらん。

ところで、アクションゲームをターゲットにパフォーマンスを追及しているDXRubyだが、現時点でその仕組みから、根本的に苦手なゲームジャンルも存在する。
ぶっちゃけ、ノベル系をはじめとする非リアルタイムのゲームだ。
毎フレームとりあえず画面をクリアするから、全描画しなおさなければならない。
fpsを落とせば負荷的にも大したことないだろうが、正直言って描画しなおす意味は無い。
アクションゲームを作るための設計でノベルゲームを作るのは無駄が多いのだ。

基本的には入力を更新してチェックするループは必要だが、その中に描画がセットで入っている必要は無い。
現状では問答無用で全部がセットになっているが、それを分解して自分でゲームループを組み立てることができれば、アクション以外のゲームにも適用しやすくなる可能性が出てくる。
マウスやキーボードの操作、タイマなどのイベントから駆動するイベントドリブンタイプのプログラミングもできるようになるから、ツール類も作りやすくなる。
そういった用途向けのコアライブラリを作って提供するのもアリだろう。

少し具体的に考えてみよう。
現在DXRubyのWindow.loopで行っている事は、
・ウィンドウの表示
・画面クリア
・FPS調整初期化
・Windowsメッセージ処理
・入力更新
・ブロック呼び出し
・ウェイト
・描画
だ。
単純にこれら全てをRubyから呼べるメソッドにすればOKかというと、なんとなくそう簡単な話でも無いような気がする。
Windowsメッセージ処理なんて表に出す必要は無いし、非リアルタイムなら最も呼ばれるのは入力更新だろうからそこに含めてしまうのがよい。
ブロック呼び出しは作る意味が無い。
ウェイトもいらないような気もするが、Rubyでゲームループを完成させることができないと片手落ちだから、作っておいたほうがよい。
ただ、現状のFPS調整機能をそのまま呼んでいいのかどうかは、FPS調整初期化と合わせて少し考える必要があるかもしれない。

ゲームループを自分で組み立てることができるようになっても、それがあまりにも難しいようではしょうがない。
内部的な動きを理解してなくても、テキトーに書いて動くぐらいの簡単さが欲しい。
ウィンドウの表示に画面クリアとFPS調整初期化をまとめて、入力更新にメッセージ処理をまとめる。
そうすれば、ループ前にウィンドウ表示をして、ループ内では入力更新と自前の処理、それから必要なときに描画をするだけでよくなる。
基本的にはそんな感じだろう。

ノベル系を考えるなら、ウィンドウ内に文字を一文字ずつ描画していく、いわゆる文字送りがっできないとしょぼしょぼだが、これを簡単にやろうと思うとImageオブジェクトに対するフォント描画が必要になる。
そういう意味ではImageクラスの再設計も同時期にやっておかないといけない。
ツール系を意識すると、ウィンドウ内にウィンドウを作ったりしたいから、それのクリッピング処理は無いと困る。
そうるとViewPortも必要だ。
どうも俺は、長いことやってるくせにWindowsAPIを使ったGUIの思想は苦手なようで、簡単に作れる環境を作ろうと思ってもそれ自体が非常に辛い。
VBぐらい簡単なものなら使えるが、VBを作るのは難しいのだ。
DXRubyを使って簡単なツールが作れるなら、それにこしたことはない。

まあ、このあたりの処理をまとめて作って、次のバージョンアップということになりそうだ。
これでDXRubyの活用の幅と表現力が大きく向上するかもしれない。
うん、かもしれない。