見出し画像

ツクールMV製ゲームの軽量化を頑張ったまとめ（MZの話も追加）

はら

ツクールMV製ゲームの軽量化や、表示ラグ対策の話です。
作っているゲームを軽量化したいツクラーさん向けの内容になってます。

そもそも軽量化って基本的にはしなくても大丈夫だと思うんですけど、
例えばPCでプレイしてて動作が重いとか、
PCで大丈夫でもスマホからプレイしてみたらヤバかったとか、
ゲームがよく落ちるとか、
BGMの再生までにやたら時間がかかるとか、
たまに画面がカクつくな～とか、
そういう事で困っているなら、軽量化やその他の小細工で解決できるかもしれません。


はじめに

この記事は、よく分かってない人が色々調べてやってみた事のまとめです。
自分と同じくらい分かってなくて困っている人がいたら、その人があちこち調べ回る手間を減らせるかもと思って書いてます。
やってみた事の効果を正確に検証せず感覚で語ったり、現時点で既に古い情報があったりもするので、間違っている所がありましたらコメント等で教えていただけると嬉しいです！！

軽量化、表示再生ラグ対策、トラブル解決の手がかりになれば幸いです。
あと、書いてる人はツクールMVユーザーです。
記事の内容はすべてMV基準の情報です。
（2024/4/29追記、MZユーザーになりました。新しい情報もある程度追記していきます）

以下、やってみた事です。

1.プラグイン編

音声ファイルを削減、読込高速化

①【oggOnly】(くらむぼん様制作)
　音声ファイル削減

②【AudioStreaming】(くらむぼん様制作)
　音声ファイル削減＋読込高速化

③【AudioCache】(トリアコンタン様制作)（2024/4/29追記）

ツクールMV標準では音声素材１つにつき、M4AとOGGの２種類のファイル形式で用意しなくてはいけないそうなんですが、それをOGGのみでいいようにしてくれる神プラグインです。①【oggOnly】②【AudioStreaming】どちらにもこの機能がついてます。
動作の重さには関係ないと思うんですけど、用意するファイルが半分になって楽だし、全体のファイルサイズを大幅ダイエットできます。
(MZでは標準機能になっているそうです。良い)

②には更に読込み高速化機能があり、音声再生の遅れを軽減できます。
詳しい仕様、導入方法はリンク先でご確認ください。

①の上位互換が②なのにどうして①も紹介するのかというと、②では稀に不具合が起きることがあるそうです。
自分たちのゲームも②では一部のBGMでプツプツとノイズが発生してしまい、①だと問題なかった、ということがあったので両方紹介させていただきました。

②の高速読込みを使わない場合は、このあとの「3.音声ファイル編」で再生遅れ対策を紹介しているので見てみてください。

（2024/4/29追記）
③【AudioCache】
プラグインコマンドから手軽に音声ファイルの事前読込が出来ます。
BGM1を流しながらBGM2を読み込んでおきスムーズに切り替える、みたいなことができます。最高～！
最近登場したプラグインなので、MZ専用かもしれません。

キャッシュ上限設定（クラッシュ対策）

【Community_Basic】(公式プラグイン)

色々設定できるプラグインなのですが、画像のメモリへのキャッシュ上限設定についてだけ紹介します。

キャッシュ自体の説明 
(「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典様)

（ツクールにおいてのキャッシュについて私もあんまり分かってないんですけど、もっと分からない人へ向けたフワフワな説明だけ書いておきます。説明不要の方はこの段落はとばしてください。
読込んだ画像はキャッシュに次々と蓄えられ、上限いっぱいになって押し出されるまではキャッシュに残っているので、また必要になった時にキャッシュから素早く取り出せる＝表示が速くなる！ という感じのものらしいです。
読込んだ画像をいっぱい蓄えておきたいけど、持ちすぎるとゲームが止まってしまう原因になるので、程よい上限を設定する必要があるそうです）

キャッシュ上限設定の目安ですが、携帯端末向けブラウザゲームなら10MPix(メガピクセル)、PC向けなら30MPixが目安、という話を見たことがあります。どちらも安全を見た数値だそうです。
(参考・・・ツクール初期設定、プラグイン初期設定は10MPix)
これはどこかで見た情報のメモなんですけど、元のページが見つからなくなってしまいました…2017年のブログだったはずなので、古い情報です。(現在2022年)

自分たちのゲームでは20MPixを上限に設定しています。
ブラウザ版でもキャッシュ上限のせいでゲームが止まったことはまだないようなので、これくらいなら大丈夫みたいです。たぶん。

セーブファイル軽量化

【TN_LightSaveData_Map】(terunon様制作)

セーブファイルを軽量化してくれます。ゲームアツマールに投稿する場合、とっても頼りになります！
（アツマールでセーブ領域を多くとると、他のゲームの分を圧迫してしまって申し訳ないので）
詳しい仕様はリンク先でご確認ください。

2.画像ファイル編

画像ファイルの事前読込み（表示遅れ対策）

大体の画像は必要になったその時に画像ファイルを読込むので、読込みが終わるまで表示が遅れることがあるそうです。
それまでに読込み済みでキャッシュに残っている画像なら、遅れ無しで表示できます。

キャラクター画像の場合
プレイしていてキャラ画像が一瞬消えたり、表示が遅れることがあったら、イベントコマンドの「スクリプト」から画像を事前に読込む方法で解決するかもしれません。
（一瞬なら気にしないのも全然アリだと思います）

ImageManager.loadCharacter('ファイル名');　// キャラクターフォルダから読込み

ピクチャ画像の場合
ピクチャでも、表示遅れが気になる所があったら事前に読込んでみてください。

ImageManager.loadPicture('ファイル名');　　// ピクチャフォルダから読込み

この「ImageManager.load～」を、イベントの最初の方や、場面切替の暗転中などの隙に忍ばせる感じで使うと丁度いいと思います。

◆スクリプト：ImageManager.loadCharacter('キャラファイル名');
：　　　　　：ImageManager.loadPicture('ピクチャファイル名');

よく使いそうなキャラクターとピクチャだけ書きましたが、遠景画像も敵画像でも顔画像でも、ほとんどの画像はこの感じで手動で読込みができます。(MVでもMZでも使えます)

読込みが完了するまで絶対に処理を進めたくない場合は、画像読込み待ちのコモンイベントを用意して、「ImageManager.load～」の後にコモン呼び出しすると便利です。(MVでもMZでも使えます)
↓コモンイベントの内容。

◆ループ
　◆条件分岐：スクリプト：ImageManager.isReady()
 　　◆ループの中断
 　　◆
 　：分岐終了
 　◆ウェイト：3フレーム
 　◆
 ：以上繰り返し

ウェイト数はお好みで。多分1でも大丈夫なんですけど、1フレームごとに「画像読み終わった？！」と確認するのも申訳ないかなあという感覚で私は3くらいにしがちです。
ピクチャ表示の事前読込み、ラグなどについてはツクマテの こちらの記事 がとても参考になりました！
画像の事前読込みをしてもまだ表示が遅い場合の原因や解決策も載っています。

画像ファイルの軽量化（読込みが速くなる）

ファイルが軽いと読込みも早い！キャッシュも圧迫しない！はず。

画像が重い！→トリミング・減色
画像ファイルが重たい場合はいらない部分を切り落として小さい画像にしたり、減色をしてファイルサイズを軽くできます。
減色ができるソフトが無くても、「png 減色」で検索すると減色してくれるサービスが見つかります。

画像素材を小さく作って拡大表示
欲しいサイズよりも小さいサイズで用意した素材を、プラグインなどで欲しいサイズまで拡大して表示する方法です。濃縮還元。
素材としては軽くなるので、読込みが速くなるみたいです。
やり方が複雑だったり、素材によっては細部が潰れてしまったりと、あまりおすすめはできないので詳細な説明は省きます。
自分たちのゲームではないんですけど、スマホからのブラウザプレイでもアニメーションPNGを素早く安定して再生できるように、素材を小さく作ってプラグインで拡大表示する方法をとっている制作者さんのお話を伺ったことがあります。

画像の縦横がでかすぎて表示できない！→分割
これは自分たちのゲームを公開した時に起きた問題なんですけど、縦横サイズの巨大な遠景画像が端末によっては読み込めないということがありました。
具体的な現象としては、プレイ中に巨大遠景画像が設定されたマップへ移動するとマップが真っ黒になって遠景もキャラも表示されない、メッセージウインドウは表示される、操作もできる、音声も通常、という状態でした。
(「画面黒くなってプレイできないんですけどー！」とandroid端末から数件の報告をいただき発覚)
巨大素材を２つに分割し、プラグインで並べて表示する事で解決しました。
分割前・・・5760×720px、240KBの画像１枚
分割後・・・2880×720px、130KBの画像を２枚
ファイルの重さだけではなくて、縦横のサイズも大きすぎるとダメということでした。学び。
これも特殊なケースだと思うので、解決方法の詳細な説明は省きます。

3.音声ファイル編

音声ファイルの事前読込み（再生遅れ対策）

BGMなどを事前に音量ゼロで再生することで読込んでおく方法です。
BGM・BGSは基本一度に１つずつしか再生できない(BGMを２つ、またはBGSを２つは再生できない)ので、BGMが途切れる瞬間を作りたくない場合などは難しい方法かもしれません。

この読込みのやり方は こちらのページ (はどはど様ブログ) がとても分かりやすいです！

SEは大体ファイルが軽いので心配いらないかもしれないんですけど、狙った再生タイミングからズレるとあまりに悲しいので、私は出来るだけ事前再生してました。
SEはBGMと違っていくつも一緒に再生できるので、気軽に事前再生できますし。

MEはあまり使わないのでよくわかりません。

（2024/4/29追記）
「1.プラグイン編」に追記している③のプラグインで、音声ファイルの事前読込がとても簡単に出来るようになりました。おすすめです！

音声ファイルの軽量化(？)

以前BGMに使わせていただいたOGGファイルが結構重めだったので、ダメ元で更にOGG変換にかけてみたらファイルサイズがかなり小さくなったことがあります。
自分は音質には疎いんですけど、音が変になったとかは感じられませんでした。
うまいこと軽くできたのは、配布素材が古めの物だったからかもしれないなとなんとなく思っています・・・

紹介しておいてですけど、あまりいい方法ではない気がします。
ハァこういうパターンもあるんだね～ということで・・・

4.マップ編

マップ内のイベント数を減らす（動作が軽くなる）

マップ内のイベントは少ない方が動作が軽いです。
以前、PCプレイで普通、スマホプレイで歩き回るのがちょっと重たいレベルのマップの軽量化を頑張っていた時、イベントを減らすとどんどん動作がマシになって「イベント数が重さに直結してるって本当なんだ・・・！」と、ちょっと感動しました。
(ツクールの事が大好きなので些細なことで感動します)

１つのマップにイベントが集中しすぎないように、気を付けながら制作するのもテクなんだろうな・・・とイベントを減らしながら思いました。

並列処理を減らす（動作が軽くなる）

よく言われてるやつです。
同時に実行している並列イベントが複数あるなら、できるだけまとめられると良いと思います。

移動時のフェードの処理落ち対策

イベントの多い重めのマップに移動する時に、移動終わりのフェードインが処理落ちしてカタついた事がありました。

マップ読込みはマップにイベントがあればあるほど忙しいそうです。
その処理でツクールが忙しい最中にフェードインが始まってしまうので処理落ちが目立つ、という状態だったようでした。たぶん。

その重めのマップを軽くするのが一番いいんですけど、この時はもう色々イベントを組んでしまった後でちゃんとした改善は大変そうだったので、別の方法である程度誤魔化すことにしました。
「場所移動」のオプションにあるフェードは使わずに、通常のイベントコマンドの「フェードアウト」「フェードイン」を使います。

◆画面のフェードアウト
◆場所移動：屋上 (18,12) (フェード: なし)
◆ウェイト：30フレーム
◆画面のフェードイン

フェードアウト中にマップ移動して、移動先のマップの読込みが落ち着くくらいウェイトで待ってからフェードインするので、カクカクフェードインが起らなくなりました。
ウェイト時間はお好みで調節してください。

その他の重い処理と回避方法

色調補正

色調補正は比較的重たい気がします。
「画面いっぱいの大きな画像に60フレームかけて色調変更」をやった時に、PCプレイでも処理落ちが目立ったことがありました。

この時はイベント内で、「じわじわ色調補正」と「キャラのホコグラを歩かせる」「画面をスクロールする」を同時にやっていたので、それぞれのタイミングをずらして処理落ちが目立たないようにして誤魔化しました。
それとあわせて、色調補正対象の画像素材を小さく作り直して、それを拡大表示することで色調補正の処理を軽くしようとしました。(これに効果があったかは謎)

色調補正は画像１pxごとに処理が入るから重たいのかなと思っているんですが推測の域です。

スイッチ、変数の処理

デフォルトではスイッチの操作時にはマップ上のイベントやコモンイベントに変化が無いかが走査されます。
このため、イベントが多いマップなどではスイッチをonにすると一瞬カクつくということが起こります。

http://rpgmaker-script-wiki.xyz/switch_mv.php
(村人A様)

スイッチ、セルフスイッチ、変数を操作すると大きな処理(マップのリフレッシュ)がおまけで付いてきます。
スイッチを例にあげると、イベントコマンドを使った時や、
◆スイッチの操作：#0075 スイッチ = ON
スクリプトで「setValue」を使った時が当てはまるようです。
◆スクリプト：$gameSwitches.setValue(75, true);

スクリプトを使う人は、以下の書き方で余分なリフレッシュを回避しているのかな、と思っています。

// マップのリフレッシュをしない書き方

$gameVariables._data[3] = n;　　// $gameVariables.setValue(3, n) のリフレッシュ抜き

$gameSwitches._data[5] = true;　　// $gameSwitches.setValue(5, true) のリフレッシュ抜き

この書き方だとコモンイベントの条件や、変数・スイッチをイベントページの出現条件にしている場合すぐに反映されませんが、そうじゃない時にだけ使えば丁度いいのかなと思います。
「_data」を直接いじるこの書き方はあんまり見かけた事がないんですけど、１度だけ神の書いたコードで拝見したことがあるので、使い所に気を付ければいいやつなのかなと思っています。

あとプレイ中に中身を入れたことのない変数・スイッチからこの書き方で中身を取得しようとすると「0」ではなく「undefined」が返ってきてエラーの原因になったりします。恐ろしいですね。
取得時は「$gameSwitches.value(5)」のようにvalueを使った方が安全みたいです。

なんで？！なんか重い時

その他のコーナーです。
ゲ制するようになって初めて知ったんですけど、PCに負荷かけすぎるとフワーーーーーン！！！！！！って唸りだすんですね…！
以下は私がよく遭遇する、プレイしていてなんだか重かったりPCが唸りだした時の原因のパターンです。
なんか重い！の原因探しの助けになれば嬉しいです。

並列イベント
　ウェイトを入れ忘れている。
　並列イベントは最後に「ウェイト1フレーム」を。

ループ処理
　ループ内にウェイトを入れ忘れている。
　ループを抜けるまでのループ回数が多すぎる。
　ループから抜けられていない。

PC自体が重い
　他のソフトを閉じる。
　デスクトップを掃除する。
　PCを再起動する。



おまけ～軽量化したくなった経緯～

※ここからは雑談です！

今まで自分がツクールMVで制作に携わって公開したゲームは３本、どれもブラウザ版とダウンロード版の２種を用意してきました。

軽量化等をなにもしていない状態でスマホからブラウザプレイしてみると、PCの時と比べてBGMが遅れたり、ピクチャの表示が遅れたり、色んな動きが処理落ちでカタついたり、少し気になる動作でした。
持っている最古のタブレット(8年物)からプレイしてみたら、マップによってはプレイヤーの歩行も困難でプレイどころじゃない処理落ちで笑いました。

ここまで古い端末でのプレイは想定しなくてもいいと思うんですけど、ブラウザゲームはプレイする側の通信環境も影響するはずなので、できるだけ軽くして動作を安定させたいなと思ったのでした。

実際に軽量化等をがんばってみた結果、効果はちゃんと感じられて、公開したゲームをプレイしてくれた方に「動作軽いね！」とほめていただいた事があります。
公開前までは動作が少し重いゲームだったので、すごく報われた気持ちでした。

↓ほめていただいたゲーム。(宣伝)

(追記、2023/11/16)
アツマールがサービス終了してしまったので以下リンクからどうぞ。
ドールハウスクール体験版(プリシー)

長い記事になってしまいました・・・
ここまで読んでいただいてありがとうございました！
軽量化・ラグ対策は、製作者さん自身がど～～～しても気になるとかじゃない限りわざわざやらなくてもいい所だと思っているし結構手間なので全然おすすめはしないんですけど、どうしても気になる製作者さんの参考になれば幸いです。

この記事が気に入ったらサポートをしてみませんか？