2013/12/10(火) [n年前の日記]
#3 [dxruby][game][web] DXRubyとWeb記事
今日も DXRuby を使って何か書いてみますよ。と言いたいところなんですけど、ゴメンナサイ。とうとうネタ切れです。書けそうなネタが思いつかない…。
なので、今回はちょっと違う話というか、自分の勝手な印象論だけでも、この際書き残しておこうかなと。
ここ数日、DXRubyを使って、2Dゲームのアレコレを書いてはみたものの。「DXRubyってWeb記事が書きづらいなあ…」と毎回感じていまして。「記事」を書きづらいわけではなくて、「Web記事」が書きづらいという話ですが。
要するに、実行結果をWebブラウザ上で表示できないあたりが、インターネット全盛の現代では結構痛い気がするなと。もちろんそのあたりは、書籍等、紙に印刷された記事も、同じデメリットを抱えているのですけど。
例えば、以下の言語・環境を使えば、サンプルプログラムの実行結果を、Web記事と同時に閲覧してもらうことが可能になるわけです。
それらと比べてしまうと、DXRuby、あるいは、Ruby/SDL、PyGame、HSP等々、Webブラウザ上では動かせない言語や環境は、ちとWeb記事が書きづらい。閲覧者に、「なるほど、こういう動きかー」と瞬時に理解してもらうための手段を持ってないですから。 *1 せいぜいできることがあるとしても、実行結果をキャプチャして、GIFアニメにして記事に貼るのが関の山。しかし、実際の実行結果に近づけてみたくて、GIFアニメのフレームレートを高くしていくと、あっという間に数MByte超えの画像ファイルに。それでいて、容量が大きい割に、全くインタラクティブではないわけで。
ですので、昨今、プログラマーさんが書くblog等においても JavaScript 等が大流行なのは、分かる気もするのでした。Web記事を書く手軽さで、実行結果も見せられるのだから、そりゃ強いよなと。それに触れ続けるためのモチベーションも維持しやすいだろうと。
とは言え。
ローカルでしか動かせない言語・ライブラリは、パフォーマンスが確保しやすいというメリットがありますし。例えば、DXRuby などは、若干酷いソースの書き方、雑で無駄な描画の仕方をしていても、意外と60FPSでヌルヌル動いちゃう。こういう点は、強みだろうと。
そんなわけで、こういったあたりもトレードオフなのだろうなと。Webブラウザ上で動きは披露できないけど、その分、ローカル上ではもうヌルンヌルンのグリングリンで、コレ、キンモチイイイイーッ、フォーーッ！ みたいな。
しかし、ActionScript や WebGL もヌルヌル動きますし。Unity も2D機能を強化してきましたし。将来的には、2Dゲーム云々は、どれもそのあたりに集約されていくのかなと思う時もありますが。Haxe のように、最終的には ActionScript か JavaScript の形で出力する、そんな言語・環境が生き残ったりするのかなと。2Dのアーケードゲームも JavaScript で動いてますよ、てな状況が当たり前に、とか。
まあ、コンピュータ関係の未来なんて、どうなるのかさっぱり予想できないですよね…。
なので、今回はちょっと違う話というか、自分の勝手な印象論だけでも、この際書き残しておこうかなと。
ここ数日、DXRubyを使って、2Dゲームのアレコレを書いてはみたものの。「DXRubyってWeb記事が書きづらいなあ…」と毎回感じていまして。「記事」を書きづらいわけではなくて、「Web記事」が書きづらいという話ですが。
要するに、実行結果をWebブラウザ上で表示できないあたりが、インターネット全盛の現代では結構痛い気がするなと。もちろんそのあたりは、書籍等、紙に印刷された記事も、同じデメリットを抱えているのですけど。
例えば、以下の言語・環境を使えば、サンプルプログラムの実行結果を、Web記事と同時に閲覧してもらうことが可能になるわけです。
- ActionScript (FLASH) ... PC向けブラウザ上でのプラグイン普及率が半端ない。処理速度も期待できる。
- HTML5 + JavaScript ... 対応ブラウザさえあればプラグイン無しでも見れる。スマホ上でも閲覧できる可能性有り。ただし、処理速度は怪しい。
- Unity ... ファイル容量が大きめだし、プラグイン普及率も今一つなので、blog記事内にドーンと貼り込むのは難しい。それでも、PCブラウザ上で動作するサンプル公開は一応可能。見た目は一番ド派手。
- Java Applet ... アプリ起動がやたらと遅いこと、セキュリティホールがボロボロ見つかったことで死亡寸前。ではあるけれど、状況によっては使えなくもない。
- Processing (Proce55ing) ... たしか Processing 2.0 以降は、JavaScript で書き出す機能がついたはず。
- Haxe ... ActionScript や JavaScript で書き出しができる。
それらと比べてしまうと、DXRuby、あるいは、Ruby/SDL、PyGame、HSP等々、Webブラウザ上では動かせない言語や環境は、ちとWeb記事が書きづらい。閲覧者に、「なるほど、こういう動きかー」と瞬時に理解してもらうための手段を持ってないですから。 *1 せいぜいできることがあるとしても、実行結果をキャプチャして、GIFアニメにして記事に貼るのが関の山。しかし、実際の実行結果に近づけてみたくて、GIFアニメのフレームレートを高くしていくと、あっという間に数MByte超えの画像ファイルに。それでいて、容量が大きい割に、全くインタラクティブではないわけで。
ですので、昨今、プログラマーさんが書くblog等においても JavaScript 等が大流行なのは、分かる気もするのでした。Web記事を書く手軽さで、実行結果も見せられるのだから、そりゃ強いよなと。それに触れ続けるためのモチベーションも維持しやすいだろうと。
とは言え。
ローカルでしか動かせない言語・ライブラリは、パフォーマンスが確保しやすいというメリットがありますし。例えば、DXRuby などは、若干酷いソースの書き方、雑で無駄な描画の仕方をしていても、意外と60FPSでヌルヌル動いちゃう。こういう点は、強みだろうと。
- 一定のフレームレートを確保しやすい環境は、ゲームの仕組みを学習する上では、シンプルさがある分、メリットがある。可変フレームレートって、ちょっと混乱しちゃう時があるので。
- ヌルヌル動くゲームと、ガクガク動くゲームでは、前者のほうが面白く見えるはず。
そんなわけで、こういったあたりもトレードオフなのだろうなと。Webブラウザ上で動きは披露できないけど、その分、ローカル上ではもうヌルンヌルンのグリングリンで、コレ、キンモチイイイイーッ、フォーーッ！ みたいな。
しかし、ActionScript や WebGL もヌルヌル動きますし。Unity も2D機能を強化してきましたし。将来的には、2Dゲーム云々は、どれもそのあたりに集約されていくのかなと思う時もありますが。Haxe のように、最終的には ActionScript か JavaScript の形で出力する、そんな言語・環境が生き残ったりするのかなと。2Dのアーケードゲームも JavaScript で動いてますよ、てな状況が当たり前に、とか。
まあ、コンピュータ関係の未来なんて、どうなるのかさっぱり予想できないですよね…。
*1: HSP には、HSPLet という、Java Applet 化して公開する手段もあるのですが。Java そのものが排除される方向にあるので、ちょっと厳しいかなあ、という気がしています。Java Applet に関しては、Processing (Proce55ing)も 2.0 以降、Java Applet で書き出す機能をサポート外にして、JavaScript で書き出す方向になりましたから…。どうやらWeb上では、全体的に、Java Applet をあらゆる場所から排除していこう！ という流れになってきた、そんな印象がありますね…。
*2: 例えばこれが、JavaScript を使ったゲームライブラリの enchant.js あたりだと、デフォルトフレームレートが30FPSですし。ちょっとガクガクしちゃうよなと。もっとも、60FPSも指定可能ですが、低スペックのPC・スマホにも対応させないといけないので、わざと遅くしてるそうで。世の中に非力なハードウェアがゴロゴロしてるのがいかんのや…。まあ、少し前なら、「JavaScriptでそんなことするなよ。無茶だよ」と笑われてたはずで、そう考えると、恐ろしい時代になってますけど。
*2: 例えばこれが、JavaScript を使ったゲームライブラリの enchant.js あたりだと、デフォルトフレームレートが30FPSですし。ちょっとガクガクしちゃうよなと。もっとも、60FPSも指定可能ですが、低スペックのPC・スマホにも対応させないといけないので、わざと遅くしてるそうで。世の中に非力なハードウェアがゴロゴロしてるのがいかんのや…。まあ、少し前なら、「JavaScriptでそんなことするなよ。無茶だよ」と笑われてたはずで、そう考えると、恐ろしい時代になってますけど。
[ ツッコむ ]
以上です。