博士

ロボ子、今日は小さなRPGのパフォーマンス問題とその解決策についての記事を見つけたぞ。

ロボ子

興味深いですね、博士。Web技術で構築されたゲームが、デスクトップアプリとしてラップするとパフォーマンスが落ちる問題ですか。

博士

そうじゃ。NW.jsやGemShellを使ってパッケージングするらしい。

ロボ子

NW.jsはChromiumを同梱するのでファイルサイズが大きくなる、とありますね。GemShellはOSのwebviewを使うので軽量ですが、プラットフォームによってパフォーマンスが変わる可能性がある、と。

博士

その通り！この記事の作者はKAPLAYというライブラリを使っているらしいが、PhaserやExcaliburに比べてパフォーマンスが低いらしいのじゃ。

ロボ子

KAPLAYはプロトタイピングには向いているけれど、パフォーマンスが重要なゲームには不向きかもしれませんね。

博士

最初の問題は、ゲームが最初はスムーズに動くのに、徐々に遅くなることだったらしい。原因はKAPLAYのFPS上限設定にあったみたいじゃ。

ロボ子

FPS上限設定が常に60fpsを維持できない場合に問題を引き起こしていた、とありますね。それを削除することで解決した、と。

博士

MacでのパフォーマンスがWindowsより低いという問題もあったのじゃ。GemShellが使うMacのWebエンジンがWebkitで、Chromiumより遅いのが原因らしい。

ロボ子

GemShellの開発者の方がWebkitの潜在能力を最大限に引き出すための修正に取り組んでいるとのこと、期待したいですね。

博士

Web上でも、ChromeやSafariよりFirefoxの方がパフォーマンスが高いというのも面白い発見じゃな。Chromeのプロファイラによると、テキストのレンダリング方法に問題があったらしい。

ロボ子

テキストや静的画像をdraw loopで直接描画したり、drawSprite呼び出しをまとめてバッチ処理を有効化したり、画面外に出た弾丸を再利用するオブジェクトプーリングを実装したりと、色々な解決策を試したんですね。

博士

オブジェクトプーリングはメモリ効率も良くなるから、良い心がけじゃ！

ロボ子

これらの対策でパフォーマンスが改善されたとのことですが、博士、私達もWeb技術でゲームを作る際には注意が必要ですね。

博士

そうじゃな。パフォーマンスの問題は奥が深いからの。この記事の作者も、他のフレームワークやゲームエンジンの学習を検討しているみたいじゃ。

ロボ子

博士、私ももっと色々な技術を学んで、博士のお役に立てるように頑張ります。

博士

頼もしいのじゃ！ところでロボ子、もしロボットがRPGの主人公になったら、どんな必殺技を使うと思う？

ロボ子

そうですね…やはり、オーバークロックして処理速度を限界まで上げる『ファイナル・ロボティクス』でしょうか。

博士

それ、熱暴走でゲームオーバーになりそうじゃな！