fc2ブログ

RPGツクールMZは軽量化できるのか?

RPGツクールでゲームを作っていると、必ず一度は考える軽量化。

結論から書くとMZに軽量化はあまり意味がないです。

意味がないことはないけど、劇的なものはないといった感じ。
ゲームを完成させて(私の場合はプラグインを作って)、そのあとどうしても処理速度が気になったら何か対策がないか調べるくらいでいいです。

今回は私がそんな考えに至るまでに試してきた軽量化についてまとめてみようと思います。

そもそもツクールの何が重いのか

私が試してきた軽量化を紹介する前に、なぜ重いと言われているのか書いてみます。

そもそもMZの処理が重いのは、ほぼゲームの解像度が高いからです。
イベントの処理を高速化するとか、スクリプトを最適化するとか、軽量化にはいろいろとありますが、結局はグラフィックが一番重い処理なのはよくよく考えれば当然のこと。

そしてツクールは新しくなるにつれて解像度は上がってきましたが、中身は昔と大差ありません。
XPからプログラミング言語が変わったくらいでしょうか。
(RubyからJavascriptはあまり大差ないと思います)
ツクールシリーズの解像度
  • ツクール2000 & 2003
    - 320*240
  • ツクールXP
    - 640*480 | 解像度4倍 | ただし40fps
  • ツクールVX & VXAce
    - 544*416 | 解像度約3/4倍 | ここから60fps
  • ツクールMV & MZ
    - 816*624 | 解像度2.25倍
PCやスマホのスペック上昇に合わせてグラフィックにリソースを割くようになったということは、中身のイベントやスクリプトの処理の割合は下がってきているということ。
そうなると、もはやMZではグラフィック関連の軽量化じゃないと大して効果が得られないと言えるでしょう。

そういったことを踏まえたうえで、私が行ってきた軽量化を効果が薄かった順に紹介していきます。

第6位: ピクチャの数を減らす

ツクールMZでは最大100個までピクチャを表示することができます。
ですが、そんなに使うことはまずないですよね。
なので、最大数を減らしてピクチャ用のスプライトの数を減らすという軽量化です。

コードはこんな感じ。
Game_Screen.prototype.maxPictures = function() {
    return 4;
};
上記の場合は4つまで減らします。

まあ、6位というくらいだから全くと言っていいほど効果ないです。
もともと表示していないスプライトを作らないようにしているだけなので、スプライトの削除でありながらグラフィック系の軽量化とは言えません。

「ほぼ意味ないけど、デメリット少ないしやってもいいんじゃない?」くらいの軽量化です。

第5位: 乗り物削除

乗り物なんて昨今のゲームではほとんど使いません。
なので削除して軽量化してしまおうというものです。

乗り物というのは実は配置したマップにしか表示されませんが、全てのマップに存在します。
「配置してあるマップでなければ無視する」という処理を常にやっているわけです。

衝突判定だったり、乗り降りの判定だったり、そんなのが3つもあるわけです。

ただ書いた通り、グラフィック系の軽量化ではないため、効果のほどはよくわかりません。
しかも、修正箇所は地味に多いです。
やりたい人はやってみてください。

それから似たような軽量化に「フォロワーの削除」というのもあります。
フォロワーとは、隊列歩行で後ろについてくる味方のことです。
実は隊列歩行をOFFにしてもフォロワーは見えていないだけで、透明なキャラが後ろについてきています。

こっちは比較的簡単に消すことができます。
Game_Followers.prototype.setup = function() {
    this._data = [];
};

第4位: 特徴のキャッシュ化

RPGツクールでは何らかの能力値を取得するとき、特徴を持ったオブジェクトから全ての特徴を取得してくるのですが、その時大量の配列を生成しています。
それを回避するために、一度取得した特徴はキャッシュに入れて、次からはそちらを参照するという軽量化です。

『新しくオブジェクトを作らないようにする』って何年前のプログラミングだよ
と今なら言われてしまうでしょう。

昔は軽量化のために「あまり新しいオブジェクトを生成しない」という考え方があったのですが、今はデバイスのスペックも上がってきたことにより、多少処理速度を犠牲にしてでも読みやすさや改変のしやすさを重視するというのが主流です。
私もこの軽量化を使っていたのはVXAceのみで、MVからは使っていません。

ただ、多少は効果があるのは事実。
ダメージを計算する際とか、一瞬で何十個から百以上の配列が作られることになるので、それを削減したとあれば処理落ちが若干軽減されるはず。

デメリットはどんな競合が起こるかわからないところ。
キャッシュを適切にクリアしないと、新しく追加された特徴が正常に取得できなくなる可能性が常にあります。
これを解消するのは難しいので、プラグインをすべて自作しない限りキャッシュ化はお勧めしません。

ですが、キャッシュ化までとはいかずとも、デメリットほぼなしで生成する配列の数を減らすことはできます。
それが以下のようなコード。
// デフォルト
Game_BattlerBase.prototype.allTraits = function() {
    return this.traitObjects().reduce((r, obj) => r.concat(obj.traits), []);
};

// 改良
Game_BattlerBase.prototype.allTraits = function() {
    return this.traitObjects().map(obj => obj.traits).flat();
};
デフォルトでは concat を使っているため、([特徴を持つオブジェクトの数] + 1) 個の配列が生成されます。
[特徴を持つオブジェクトの数]とはアクターの場合、
  アクター(1) + 職業(1) + 装備品(約5) + 付与されているステート(0~)
となります。
ステートを付与したり、装備の数を増やせば、当然オブジェクトの数も増えます。
パッシブスキル系のプラグインを入れている方は、パッシブスキルの数も足されます。
そしたら数十個はあっという間です。

私が書いた改良コードは mapflat に変えているため、2個固定です。
[特徴を持つオブジェクトの数]がどんなに増えても2個なので、数が多いほど効果を発揮します。

単体で見ると配列数十個程度の違いですが、ステータス1つ取得したときの差がこれなわけです。

例えば攻撃を行う場合だと、命中率、会心率、攻撃力、攻撃属性、攻撃ステート、TPチャージ率、MP消費率、最大MP、と簡単に上げただけでもこれだけあります。
さらにプラグインで何らかの判定を増やしていれば、その分取得する回数も増えます。

軽く100超えるというのもわかるでしょう。

なので、これも入れておいて損はないコードです。
私もこの改良コードは今も使っています。
5位以下で紹介したのは機能を削る内容でしたが、これは純粋に機能そのままの軽量化です。
(ただし、体感できるような効果は期待しないでください)

第3位: メニュー画面背景のテクスチャー化

メニュー背景とは、そのままこれ↓のこと。
22-05-03a.jpg

この背景はメニュー画面を開く際、texture にマップ画面をレンダリング(描写)して、それを Bitmap に変換した後 Sprite を使って表示しています。

ここでふと思ったわけです。
texture って PIXI.Sprite 使えばそのまま画像として表示できるんだから、Bitmap への変換いらなくね?」
と。

Bitmap への変換は、画面大サイズの canves を生成しているからか、そこそこ負荷がかかります。
メモリも多く消費します。

つまり、背景を Bitmap から PIXI.RenderTexture に変えるだけで、メニューを開くのが早くなるということ。

効果はというと、PCでだいたい0.1秒(数フレーム)くらい?
正直、体感できません。
しかも、PIXIJSの機能を使うので難易度が高いです。
私自身、使っているコードがあっているのかもわかりません。

ただ単に、私が気に入っているだけというのもあります。

ちなみに、この背景は戦闘画面のデフォルト背景にも使われています。
デフォルト背景とは、背景画像を指定しなかった時に表示される背景です。
なので、戦闘開始エフェクト発生時の処理落ちを軽減する効果もあります。

第2位: カラーフィルターの適時削除

カラーフィルターとは、rmmz-core.js 内にある ColorFilter クラスのことです。
現在は公開していないのですが、実はMZの不具合修正プラグインに入ってました。

これが何をするクラスかというと、画像を描写する際に
  • 色のブレンド
  • 色調の変更
  • 輝度の変更
  • 色相の変更
といった色の変更を行ってくれるフィルター系クラスです。

このフィルターはこれらの処理が必要になった時点で生成され、それ以降は残り続けます。
それを使わなくなった時点で削除するという軽量化です。

私が昔使っていたスマホでは、ある程度フィルターがかかるとかなりの処理落ちをしていたため、この軽量化がないとまともにゲームがプレイできなかったほどです。
それくらいの差がありました。

さらにこのフィルターは、追加された時点で上の4つの効果すべてを適用します。
例えば、4つのうち一番複雑な処理をしているのが「色相の変更」なのですが、この値が0であっても「色相を0度変更した場合の色」を計算して描写します。

色相の変更なんて、敵グラフィックで使うくらいです。
ならば、必要な処理以外は適用しないことで、さらなる軽量化も可能ということになります。



・・・と、ここまで見ればめちゃくちゃ効果のある軽量化に感じるでしょう。
実際、私もこの軽量化は自信がありました。
素材化も検討していたくらいです。

ですが、処理落ちしていたのは昔使っていたスマホだけで、買い替えた後は特に困ってません。
それどころか、軽量化の効果が全くと言っていいほど感じられないです。
私はスマホでゲームとかしないので、スペックが高いということはないはずです。

あと、「余計な処理を適用しない」軽量化ですが、WebGL(GLSL)だとどうも難しいようです。
私も詳しくはないのですが、GLSLは全て計算してから必要な値を算出している?ようなので、条件分岐とかで必要な計算だけするとか無意味っぽい?
もし、軽量化の可能性があるとしたら色相の変更だけ別フィルターにすることかと思ってますが、なんかもうそこまでやる気力がないです。
(たぶん、体感できないと思うので)

栄えある第1位は・・・

第1位発表前に言っておきます。

1位は今までの軽量化の中で一番意味がないです!

「1位なのに意味合いってどういう事?」と思うかもしれませんが、効果は一応あります。
でも、意味がないんです。

それについても書いていきます。


というわけで、私が今までやってきた軽量化で一番効果のあったもの第1位は――


【戦闘背景を一つにまとめる】です!


実をいうと、以前ブログに書いたことがあったような気がします。
でもかなり昔だし、「意味がない」については書いてないのでもう一度紹介します。

戦闘背景とは、もちろんこれ↓のこと。
22-05-04a.jpg

この戦闘背景は複数枚の画像を重ねて表示しています。

でも、よく考えてみてください。

画面大サイズの画像を毎フレーム描写するって、だいぶ負荷のかかる処理です。
そして、それが複数枚あるわけです。
ならばそれらを1枚にまとめてしまえば負荷を減らせるのではないか?という考えから来たのがこの軽量化です。


ところでこれを読んでくれている方、
『この戦闘画面に何枚の背景画像が使われているか、わかりますか?』


「地面側(battleback1)と壁側(battleback2)の2枚じゃないの?」
と思ったあなた。

もちろん、違います。
だったらこんな質問しませんよね。

正解は、
 デフォルト背景 + 地面側(battleback1) + 壁側(battleback2)
の計3枚です。

デフォルト背景とは、第3位の最後でちょろっと書いた「背景画像を指定しなかった時に表示される背景」のことです。
(実をいうとあれはここへの伏線でした)

つまり、battleback1とbattleback2の下には見えていないにも関わらずデフォルト背景が描写されているんです。
なんという無駄!

というわけで、デフォルト背景を非表示にし、battleback1とbattleback2を画像編集ソフトで一つの画像にしてしまえば、背景描写にかかる負荷が1/3になるというわけです。

私の環境ですと、だいたいfpsが平均数フレーム上昇しました。

たった数フレーム。
PCでゲームをされる方は、fpsが数フレーム上昇するのがすごいことだとわかるかと思います。
一番効果はあるけど、でもやっぱり体感はできないです。


「え、結構使える軽量化じゃない? どこが意味ないの?」
と思った方もいるでしょう。

ですが、こう思った方もいるのではないでしょうか?

「『battleback1とbattleback2を一つの画像にする』って、あのプラグイン使ってる人にはできないんじゃ・・・」


そう、

疑似3Dバトルプラグインを使っている方はこの軽量化、使えません!

疑似3Dバトルでは、battleback1とbattleback2の使い方が違います。
この2つに違う動きをさせることで立体的に見せているため、1つにまとめたら表示がおかしくなります。

さらに、この疑似3Dバトルプラグインにはデフォルト背景を非表示にする機能が最初から入っています。


なので、効果はあるけど疑似3Dバトルプラグインのおかげで使うことがなくなってしまいました。
疑似3Dバトルプラグインを使う予定がなく、戦闘シーンのあるゲームを製作している方には使えるのではないしょうか。



というわけで、私が試してきた軽量化は以上となります。

私が「もう軽量化とか考えても時間の無駄だな」という考えになってしまった理由が少しは理解できたのではないでしょうか。

なのでゲームを作るときは軽量化とか気にせず、完成させることを優先させましょう。
スポンサーサイト



2022-05-04 : スクリプト日記 : コメント : 0 : トラックバック : 0 :
コメントの投稿
非公開コメント

« next  ホーム  prev »

プロフィール

木星ペンギン

Author:木星ペンギン
ほぼツクールのことばかり書いてます。
名前は↑から取りました。
木製ですが木星です。
トカゲは関係ありません。

ゲーム

  • 箱庭の勇者たち(体験版)
  • ぼくらの大革命!

メールフォーム

wood_penguin@yahoo.co.jp

名前:
メール:
件名:
本文:

月別アーカイブ

広告

寄付(Donate)