■サイト[SilverSecond]トップ
■開発日誌トップ
■ 2009/03/26 (木)  ウディタ高速化進行中 ■
現在、WOLF RPGエディターの高速化を試みています。
ホントはもっとヒマになったらやろうと思っていたのですが、なぜ今かというと、
発端は第二回ウディコンで、面白そうなのにやたら重いゲームがあったので
それをもう少し快適に遊びたい(し、みんなにも遊んでもらいたい)
という欲求からでした。

実はすでに、「ラベル処理」やごく一部の「変数操作」だけを高速化した
プロトタイプバージョンを、処理が重いゲームを公開している方に
テストしてもらっています。
たとえば高速化したい主な対象だった「夢柱」という弾幕シューティングゲームで
すでに一般公開テストを行っていただいているのですが、
この段階ですでに2倍以上の速度が確保できているようなので
(もと17~25msくらいだったイベント処理時間が、7~10msくらいに!)
ちょっと期待してもいいですよ!
といっても、夢柱は「ラベル処理」がボトルネックだったので、
これを高速化したのが一番大きかったんですけれどね。

この「ラベル処理」は従来版だと、ツクールと同じく、
「イベント内を上から一行ずつ探索して、どこにジャンプ先があるかを調べて、
見つかったらそこへジャンプする」というアルゴリズムで動いていたのですが、
これだとイベントコマンドの量が多い場合、
探索の負荷がバカにならないという問題がありました。
新版はそんなことせず、一瞬で目標地点に
ジャンプできるようになってあるので負荷はほぼゼロになったのです!
(ただし「\cself[3]」などの特殊文字がないことが前提)
といった感じの改善を行っていました。

高速化するにも、参考となるゲームがないと「何が重いのか」「どこがボトルネックか」
という観点での高速化のメドが立たないので、メッチャ複雑な処理を
頑張って組んでくださっている作品は参考にさせていただきたいと思っています。



このウディタの高速化、正式版では「変数操作」と「DB操作」の2つに関して、
約3倍速くすることを目標にしています。

約一ヶ月前までは、高速化に対してうんうん唸っていました。
高速化は、プログラム的な意味での堅牢性を考えると色々問題があって、
これまでの処理が「命綱を付けた上で石橋を渡る」くらいの安全度なら、
新しい高速処理は「崖上のロープ一本の上を何も付けずにダッシュする」
くらい危険なことです。たとえば、変数の指定が間違ってたら、
エラーも何も出ずにゲームが強制終了!という事態が起きかねないのです。
しかも「エラーを判定する処理そのもの」が結構大きい負荷になるので、
高速化を考えた場合、どうしてもエラーチェックを省かざるを得ないんですよ。

それでも、コマンドの指定が間違っている時はエラーを出したいし、
合っているときはエラーチェックせずに処理させたい!
あ、ここでの「エラーチェック」ってのは、例えば変数の指定が間違ってたら
「指定が間違ってるよ!」ってエラーが出るじゃないですか、ああいうのですね。
それをなくしてしまうと、エラーが起きたとき意味不明でデバッグが大変すぎます。
でも速くしたい。この辺りの兼ね合いがあって高速化に踏み切れませんでした。

デバッグ用EXEと高速版EXEファイルを両方用意するという手もありましたが、
それやると、片方でエラーが起きて片方で起きないという意味不明な状況が
起こりかねないので、なるべくそれも避けたいと思っていました。
おそらく両者の処理が全然違うものになるので、デバッグ文が入ってるか
入っていないの単純な差だけじゃ済まないからです。
単純に以後の開発にかかる時間が2倍になるので、それはアホらしい、と。

「処理の安全性を維持したまま高速化する」にはどうすればいいか?
ある日簡単な方法を思いつきました。その方法とは、
「処理が安全であるかどうかをゲーム開始時に全部チェックして、
安全であることが確定したら高速なイベントコマンド処理に変換する。
エラーの危険性がある処理は、これまで通り普通に処理する」

です。あまりに単純な発想ですが、オプション機能がゴテゴテ付きまくりな
ウディタにおいては、これが異様に効果的でした。

ただ新たな問題は、その「安全かどうかのチェック」が間違ってると、
これまたエラいことになってしまうということです。
これはウディタユーザの皆さまにもデバッグを
手伝っていただくことになるかもしれません。
というかこれまでの経験的に言って、何も起きずに終わることは有り得ません。

そんなわけで、より高速になった次回バージョンをお楽しみに!
これでシルフェイド学院物語も低スペックで快適に遊べるといいなあと思います。
関連記事