2013/12/16(月) [n年前の日記]
#4 [dxruby] Ruby 1.9対応版の DXRuby が欲しいな…
開発版はともかくとしても、せめて、DXRuby 1.5開発版をバックポート(?)した DXRuby 1.4.1 は、Ruby 1.9対応版も欲しい…と思えてきたり。もちろん、技術的に難しいとか、対応がめっちゃ大変、という話なら、仕方ないのですけど。
*1
DXRuby 1.4.0 には、フルスクリーン表示がおかしくなるバグが ―― ゲームアプリ制作においては、結構クリティカルなバグがあった記憶が。 *2 そんなバグ持ちバージョンを、Ruby 1.9 対応の最後のバージョンにされてしまうと、ちと自分は困るので。「DXRubyオススメ」と言えなくなる。もにゃもにゃしてきちゃう。
「Windowsオンリーと言う制限はあるものの、誰でも手軽に使えるのが DXRuby の売り」と自分は思っているのですけど。もし、「Ruby 2.0.0以降のみ対応」という方針になると…。興味を持った方が導入してる Ruby のバージョンによっては、いきなり門前払い食らわせることになるよなと。DXRubyが持っていた、「誰でも手軽に」が無くなっちゃう。
かといって、「Ruby 1.9上で使いたい人は DXRuby 1.4.0 を使って」と言われてしまうと、それはバグ持ちバージョンであることが自分は分かってるから、オススメだの宣伝だのはしにくくなるし。
初心者向けも考慮したい、あるいは、お試しから本格利用まで間口を広げておきたいなら…。Ruby 1.8 はサポート終了してるからともかくとしても、Ruby 1.9 までは、まだ、今のうちは、あくまで当面は、対応しといたほうがいいのでは、と思うのですけど。せめて、バグを取った正式版は、二世代分に対応していただけないものかと。
*1
DXRuby 1.4.0 には、フルスクリーン表示がおかしくなるバグが ―― ゲームアプリ制作においては、結構クリティカルなバグがあった記憶が。 *2 そんなバグ持ちバージョンを、Ruby 1.9 対応の最後のバージョンにされてしまうと、ちと自分は困るので。「DXRubyオススメ」と言えなくなる。もにゃもにゃしてきちゃう。
「Windowsオンリーと言う制限はあるものの、誰でも手軽に使えるのが DXRuby の売り」と自分は思っているのですけど。もし、「Ruby 2.0.0以降のみ対応」という方針になると…。興味を持った方が導入してる Ruby のバージョンによっては、いきなり門前払い食らわせることになるよなと。DXRubyが持っていた、「誰でも手軽に」が無くなっちゃう。
かといって、「Ruby 1.9上で使いたい人は DXRuby 1.4.0 を使って」と言われてしまうと、それはバグ持ちバージョンであることが自分は分かってるから、オススメだの宣伝だのはしにくくなるし。
初心者向けも考慮したい、あるいは、お試しから本格利用まで間口を広げておきたいなら…。Ruby 1.8 はサポート終了してるからともかくとしても、Ruby 1.9 までは、まだ、今のうちは、あくまで当面は、対応しといたほうがいいのでは、と思うのですけど。せめて、バグを取った正式版は、二世代分に対応していただけないものかと。
◎ とは言え現行版にのみ対応するメリットもありそうで。 :
- Ruby はバージョンが上がるたびに処理速度が改善されてる。リアルタイムゲームを作るなら処理速度が速いほうが望ましい。現時点で最速の環境にのみ対応、という考え方も、ライブラリの性質からしてアリなのかも。
- 今後 DXRuby が、Ruby 2.0.0 以降で追加された機能を積極的に活用するつもりなら、Ruby 1.9.x に対応し続けるのは技術的に難しい。
- Ruby 1.9.x を導入してある環境でも、pik を使えば Ruby 2.0.0 がインストールできるので、「お試しインストール」も不可能ではない。そもそも、スターターキットだってある。
- DXRuby は将来的に OpenGL もサポートする、という話もあり…。すると、Windows 限定ではなくマルチプラットフォーム対応のライブラリに変貌していくのかなと。他ライブラリが放置状態の中、DXRuby だけが、最新Rubyに対応済みの2Dゲーム制作ライブラリになり、存在意義が変わってくる可能性も。古いRubyを切り捨てて失うユーザ数より、マルチプラットフォーム対応にリソースを集中して新規獲得できるユーザ数のほうが多い、という展開もありえる。
◎ 余談。 :
このあたり考えていくと、
_Shoes
、
_Processing
、
あるいは
_HSP
のように、「そこで一旦全てを閉じてしまう」方針も、なんだか理解できちゃいますな…。
根幹技術がアップグレードした際に、自分達まで右往左往する状況を回避したい、となると、根幹技術のバージョンを固定して同梱したり、開発に必要なエディタを同梱して強制したり…。そういった手段は有効なのかなと。その代り、開発環境を丸ごと提供し続ける形になるので、開発リソースが分散して、全体の作り込みは今一つになりそうですが。
Processing のエディタの表示バグを眺めてると、「そこはもう、本来 Processingが担当する領域じゃないけど、こういうパッケージングしてるからには、そこにもリソース割かないといかんよな…」と思えてきて、なんとも難しいなと。
根幹技術がアップグレードした際に、自分達まで右往左往する状況を回避したい、となると、根幹技術のバージョンを固定して同梱したり、開発に必要なエディタを同梱して強制したり…。そういった手段は有効なのかなと。その代り、開発環境を丸ごと提供し続ける形になるので、開発リソースが分散して、全体の作り込みは今一つになりそうですが。
Processing のエディタの表示バグを眺めてると、「そこはもう、本来 Processingが担当する領域じゃないけど、こういうパッケージングしてるからには、そこにもリソース割かないといかんよな…」と思えてきて、なんとも難しいなと。
[ ツッコむ ]
以上です。