Jewel-mmo開発日記

RubyでMMORPGを作る過程を記録する日記。 Yokohama.rb 発起人。
2009-05-20

[Ruby]Rubyのグラフィックライブラリの漠然とした案(2)

いや、今回は特にRubyに限った話じゃないんだけど。

引き続き、render(とかdraw)をいちいち呼ばないというのを考えてみる。

画面に描画するオブジェクトをクラスとして設計して、 オブジェクト自身に移動処理や描画処理(renderメソッド)を持たせてしまう、 というのはPSのゲームを作っていたころたどり着いた形で、 当時(3年前)この方向性の理想系として設計したのがMyGame(Rubyで手軽にゲームを作るためのライブラリ)だ。

ライブラリを実装するとき、 描画処理を描画オブジェクトのrenderメソッドとして シンプルに実装できる場合はいいのだけど、 現実問題そう出来ないこともある。 renderの前後である手続きが必要で、 その手続きが複数の描画物をまたがざる終えないような場合だ。

開発環境によっては、 MyGame型のAPIにうまく収まらない状況を何度か経験していて、 結局状況に応じてアドホックな実装を行う破目に。 具体的にはrenderメソッドの呼び出し前後で思いっきりネイティブなライブラリ関数を呼んだり。 いちいち対応すれば、無理やりオブジェクトの中に処理を隠蔽できそうな気はするが、 面倒なのででそこまではやらない。

結局やりたいことは、キャラクターをコントローラや移動アルゴリズムで操作するようなレイヤーから 次のことを隠蔽したいわけだ。

  • 描画物生成・破棄のメモリ管理
  • 描画物生成・破棄の煩雑な手続き
  • 描画の煩雑な手続き

MyGame型の設計では、表示物ひとつひとつを描画プリミティブとしてオブジェクトとして管理していた。 オブジェクトの中に煩雑な処理を隠蔽していたわけだ。

が、最近の考えているのは、描画処理全般を一枚岩で実装して、 外部にはシンプルはAPI(コマンド)を公開する形。 新しい環境で開発をするときは、結局描画クラスを毎回実装することになるのだから、 それなら一枚岩のほうが、汎用的なAPIが楽に実装できるんじゃないかと。

……と思ったけど、改めて考えるとやっぱり描画プリミティブをオブジェクトにするメリットはでかいんだよなあ。 何もかもをオブジェクトにしようと意識しすぎていただけかもしれない。 要はバランスの問題か。