RPGツクール2000/バグ・エラー
■処理落ちに関するページ
(更新:2014/08/30)


主人公の移動がスムーズにできない。
または自分のパソコンでは問題なく動いているけど、
他の人のパソコンでは処理落ちが発生している。
このような場合に考えられる原因とその対策について紹介します。

なお、主人公が全く動かせない時には、以下のページをご覧ください。
【主人公が動かなくなった時に見るページを開く】



☆処理落ちに関する基礎
処理落ちは、マップ上に多くのマップイベントがあったり、
マップイベント内に大量のページがあったり、
定期的に並列処理するで大量のイベントコマンドを処理しますと、
処理落ちが発生しやすくなります。

複数の定期的に並列処理するが同時に動いている場合や、
ラベルの設定繰り返し処理などを用いたループ処理がありますと、
処理落ちが発生しやすくなります。

定期的に並列処理するピクチャーの表示BGMの演奏などを連続的に実行しますと、
たった1個のイベントコマンドでも処理落ちが発生します。

処理落ちは使用するパソコンの性能(処理能力)によっても処理落ち度が異なります。
そのため、下記の☆重い処理落ちが発生するに書かれている通りに行っても、
見た目では処理落ちが感じられない可能性があります。

処理落ち対策は、多くのプレイヤーに快適なゲームを提供するための対策であり、
制作しているパソコンではスムーズに動いていても、
出来る限り処理落ちしそうな設定は避けた方が良いでしょう。



なお、処理落ち状態と言うものを確認したい場合は、
以下のマップイベントを作成してください。
■マップイベント
イベント開始条件:定期的に並列処理する
◆BGMの演奏:フィールド1
◆BGMの演奏:フィールド1
◆BGMの演奏:フィールド1
◆BGMの演奏:フィールド1
◆BGMの演奏:フィールド1
◆BGMの演奏:フィールド1
◆BGMの演奏:フィールド1
◆BGMの演奏:フィールド1
◆BGMの演奏:フィールド1
◆BGMの演奏:フィールド1

※パソコンの処理能力によっては、もう少し「BGMの演奏」を増やさないと、
 処理落ち状態が確認できないかもしれません。




☆重い処理落ちが発生する
ゲームのプレイが困難になるほどの重い処理落ちが発生する、
その原因と処理落ちの対策方法を紹介します。



■ピクチャーの連続表示を行っている
定期的に並列処理するの中で、
◆ピクチャーの表示:1,地図,(50,20)
などと、ピクチャーの表示常に実行し続けている設定を行いますと、
主人公の移動がスムーズに行えなくなるような処理落ちが発生します。

このような場合は、1回だけ実行する設定にすると良いでしょう。
▼設定例
◆条件分岐:スイッチ[0001:ピクチャー表示済み]がOFF
 ◆スイッチの操作:[0001:ピクチャー表示済み]をONにする
 ◆ピクチャーの表示:1,地図,(50,20)
 ◆
:分岐終了


複数の画像を順番に表示していくアニメーションを行いたい時には、
予め必要な画像を透明度100%で表示しておき、ピクチャーの移動を使って、
表示させたい画像の透明度0%(消去は再び透明度を100%)にして、
ピクチャー画像が見えるようにします。
▼設定例
◆条件分岐:スイッチ[0001:ピクチャー表示済み]がOFF
 ◆スイッチの操作:[0001:ピクチャー表示済み]をONにする
 ◆ピクチャーの表示:1,揺れる木01,(160,120)(透明度:100%)
 ◆ピクチャーの表示:2,揺れる木02,(160,120)(透明度:100%)
 ◆ピクチャーの表示:3,揺れる木03,(160,120)(透明度:100%)
 ◆
:分岐終了
◆ピクチャーの移動:3,(160,120),0.0秒(透明度:100%)
◆ピクチャーの移動:1,(160,120),0.0秒(透明度:0%)
◆ウェイト:0.1秒
◆ピクチャーの移動:1,(160,120),0.0秒(透明度:100%)
◆ピクチャーの移動:2,(160,120),0.0秒(透明度:0%)
◆ウェイト:0.1秒
◆ピクチャーの移動:2,(160,120),0.0秒(透明度:100%)
◆ピクチャーの移動:3,(160,120),0.0秒(透明度:0%)
◆ウェイト:0.1秒



■半透明のピクチャーを表示
半透明(透明度1〜99%)のピクチャーを表示させますと、
処理落ちが発生しやすくなります。
複数のピクチャー画像を半透明にして、重ねて表示するような設定は、
なるべく控えた方が良いでしょう。



■BGMの演奏を連続的に実行している
定期的に並列処理するの中で常に、
◆BGMの演奏:町1
の設定を実行し続けますと処理落ちが発生します。

このような場合は、1回だけ実行する設定にすると良いでしょう。
▼設定例
◆条件分岐:スイッチ[0001:BGM演奏済み]がOFF
 ◆スイッチの操作:[0001:BGM演奏済み]をONにする
 ◆BGMの演奏:町1
 ◆
:分岐終了




■ラベル、繰り返し処理を使っている
定期的に並列処理するの中で、
ラベルの設定繰り返し処理を使ってループ処理を作った場合、
そのループしている間にウェイトの設定が無いと処理落ちが発生します。
繰り返している処理の中に、
◆ウェイト:0.0秒
を設定しますと、処理落ちが起こらなくなります。

▼設定例(自作のキー待ち処理)
◆ラベルの設定:1番
◆キー入力の処理:[0001]
◆条件分岐:変数[0001]が0
 ◆ウェイト:0.0秒
 ◆指定ラベルへ飛ぶ:1番
 ◆
:分岐終了


※ウェイトを設定しますと、ループ処理の処理速度は遅くなります。
※「ピクチャーの移動」などにあるウェイトの設定でも同様の効果が得られます。



■指定動作の全実行を連続的に実行している
定期的に並列処理するの中で指定動作の全実行を連続的に実行させますと、
処理落ちが発生する事があります。
定期的に並列処理するキャラクターの動作指定を実行させる時には、
指定動作の全実行の代わりにウェイトを設定します。



■マップイベントが多い
マップイベントが多いと処理落ちが発生しやすくなります。
またマップイベントが大量に設定してありますと、
別のマップからそのマップへ移動して来る時間がかかる事があります。

マップイベントの数が少なくても、
マップイベントの中にたくさんのページが設定してありますと、
マップイベントを大量に設定した時と同様に処理落ちが発生します。

1つのマップに大量のマップイベントを設定するような制作は、
なるべく控えた方が良いでしょう。



■イベントの一時消去を実行したマップイベントを呼び出した時
イベントの一時消去によって消えているマップイベントのページを、
イベントの呼び出しで呼び出して実行しますと、
マップイベントに設定されているイベント実行内容の処理速度が遅くなります。

この現象は、定期的に並列処理するの中で、
イベントの呼び出し(消えたマップイベントの呼び出し)を実行した時に発生します。

遅くなる時間は、イベントコマンド(◆)1つを処理する度に、
60分の1秒(ウェイト:0.0秒)」の時間がかかります。

条件分岐の場合は、通過するだけで「60分の2秒」。
条件分岐の中を通過する場合は、
60分の3秒+中のイベントコマンド」の時間が遅くなります。

このバグの対策は、以下のものがあります。
イベントの一時消去で消したマップイベントのページは呼び出さない。
イベントの一時消去を使わずにイベント出現条件を使って消去する。
●マップイベントのイベント実行内容コモンイベントへ移動して、
 マップイベントにはイベントの呼び出し(コモンイベントを呼び出す)を置く。



☆処理負担を軽減させるテクニック
処理負担を軽減させるテクニックの紹介です。
イベント設定に慣れていない方は、無理に実行する必要はありませんが、
巨大なイベント実行内容を動かしているなど、処理落ちが気になる方は、
実施された方が良いかもしれません。



■一括の活用
ツクールの処理では、イベントコマンドを1つ1つ処理していきますので、
イベントコマンドの数が多ければ多いほど、処理落ちの問題が発生しやすくなります。

スイッチの操作変数の操作では、一括と言う設定方法があります。
例えば、
◆スイッチの操作:[0001]をOFFにする
◆スイッチの操作:[0002]をOFFにする
◆スイッチの操作:[0003]をOFFにする
◆変数の操作:[0001]代入,0
◆変数の操作:[0002]代入,0
◆変数の操作:[0003]代入,0

と言った設定と、
◆スイッチの操作:[0001〜0003]をOFFにする
◆変数の操作:[0001〜0003]代入,0

と言った設定では、処理の結果としては同じになりますが、
一括で処理した方が処理負担が軽減されます。

同様に主人公の現在位置を取得する時には、
◆変数の操作:[0001]代入,主人公のマップID
◆変数の操作:[0002]代入,主人公のX座標
◆変数の操作:[0003]代入,主人公のY座標

を設定するよりも、
◆現在の場所を記憶:[0001],[0002],[0003]
を設定の方が処理負担が軽減されます。

但し、マップIDを取得するだけの設定の時や、
複数の変数に一括でX座標を代入するような設定の時には、
現在の場所を記憶を使わずに変数の操作を使った方が良いです。



■1回のイベントコマンドの処理数を減らす
1回の処理(60分の1秒単位の処理)でのイベントコマンドの処理数が少なくなれば、
当然ながら処理負担は軽減されます。

例えば、主人公がいるマスの地形IDイベントIDを調べて、
地形ID=1番イベントID=0の時に効果音を鳴らすイベントを設定する時には、
定期的に並列処理するの中には、以下のように設定します。
◆変数の操作:[0001:X座標]代入,主人公のX座標
◆変数の操作:[0002:Y座標]代入,主人公のY座標
◆指定位置の地形ID取得:(V[0001],V[0002]),[0003:地形ID]
◆指定位置のイベントID取得:(V[0001],V[0002]),[0004:イベントID]
◆条件分岐:変数[0003:地形ID]が1
 ◆条件分岐:変数[0004:イベントID]が0
  ◆効果音の演奏:カーソル1
  ◆
 :分岐終了
 ◆
:分岐終了

一見問題の無い設定のように見えますが、
この設定では地形ID取得結果(地形ID1番であるかどうか)に関係なく、
必ずイベントIDを調べる設定になっています。
イベントIDの情報は、地形ID=1番の時のみに必要なので、
処理負担の事を考えると、
◆変数の操作:[0001:X座標]代入,主人公のX座標
◆変数の操作:[0002:Y座標]代入,主人公のY座標
◆指定位置の地形ID取得:(V[0001],V[0002]),[0003:地形ID]
◆条件分岐:変数[0003:地形ID]が1
 ◆指定位置のイベントID取得:(V[0001],V[0002]),[0004:イベントID]
 ◆条件分岐:変数[0004:イベントID]が0
  ◆効果音の演奏:カーソル1
  ◆
 :分岐終了
 ◆
:分岐終了

と設定した方が良いでしょう。

なお、地形IDイベントIDを取得する変数の番号同じ番号にしても、
イベント処理は問題なく処理されます。
◆変数の操作:[0001:X座標]代入,主人公のX座標
◆変数の操作:[0002:Y座標]代入,主人公のY座標
◆指定位置の地形ID取得:(V[0001],V[0002]),[0003:ID]
◆条件分岐:変数[0003:ID]が1
 ◆指定位置のイベントID取得:(V[0001],V[0002]),[0003:ID]
 ◆条件分岐:変数[0003:ID]が0
  ◆効果音の演奏:カーソル1
  ◆
 :分岐終了
 ◆
:分岐終了

同じ変数番号にするのは、あくまで使用する変数番号を少しでも減らしたいと言う、
こだわり派の方の設定方法であり、無理に同じ変数番号にする必要はありません。



■定期的に並列処理するは出来る限り1つにする
自作システム(自作戦闘)を作る方の中には、
1つの定期的に並列処理するにまとめられるようなイベント実行内容を小分けにして、
複数の定期的に並列処理するでイベントを処理する方がいます。

一見小分けした方が処理効率が良いように思えますが、
複数の定期的に並列処理するに小分けにしても、
1回の処理(60分の1秒単位の処理)の合計のイベントコマンドの数が変わらなければ、
処理負担は変わりません。
逆に定期的に並列処理するの数が増える事で処理負担が増します。

定期的に並列処理するの設定は、
出来る限り1つの定期的に並列処理するにまとめた方が良いでしょう。



■イベントの呼び出しで処理を分けても速くならない!?
定期的に並列処理するのイベントの中で、
常にイベントの呼び出しで他のイベントを呼び出している設定を行う方がいます。

見た目は、処理を分けた方が処理効率が良いように見えますが、
1回の処理(60分の1秒単位の処理)イベントコマンドの処理数は変わらない上、
イベントの呼び出しの処理が加わってしまい、処理負担が増してしまいます。

このような時には、以下のように1つにまとめた方が良いです。




■高速で処理する必要の無いものにウェイトを設定
高速で処理する必要の無い定期的に並列処理するには、
出来る限りウェイトを設定すると良いでしょう。

監視イベントは、マップイベント(監視イベント)の目の前に主人公がいた時に、
主人公を発見したと判断するイベント処理になります。
【監視イベントのページを開く】

監視イベントは、一見高速で処理する必要性がありますが、
主人公が標準速(ゲーム開始時の速度)で歩いている時には、
主人公が1マス移動するのに、60分の8秒の時間がかかっています。
定期的に並列処理するは、60分の1秒単位の処理なので、
監視イベントとしては、主人公が1マス移動している間に、
監視イベントの前方に主人公がいるかどうかを8回調べている事になります。
仮にウェイト:0.0秒を設定して処理速度を半分に落としたとしても、
主人公が1マス移動している間に4回調べている事になり、
監視イベントの処理としては、十分な処理速度が保てます。
但し、主人公や監視イベントが4倍速で移動(向き変更)している時には、
ウェイトの設定は行わない方が良いかもしれません。

ウェイトの設定とは少々異なりますが、
例えば、2つの監視イベントの処理を1つにまとめて、
◆変数の操作:[0001:主人公のX座標]代入,主人公のX座標
◆条件分岐:スイッチ[0001:主人公のX座標]が9以下
 ◆〜監視イベントA〜
 ◆
:それ以外の場合
 ◆〜監視イベントB〜
 ◆
:分岐終了

と設定する方法もあります。
この場合、主人公のX座標が9以下の時には、監視イベントAのみが動き、
X座標が10以上の時には、監視イベントBのみが動きます。
このように主人公から離れた監視イベントの処理を止めておくのも、
処理負担の軽減に繋がります。



■時には逆転な発想で乗り切る!
監視イベント前方3×3のマスを調べる敵キャラを10体設定した場合、
ウェイトなどの設定が無ければ、
60分の1秒ごとに90マスの主人公の有無を調べる事になります。

一見改善の余地が無いように思えますが、しかしよく考えてみれば、
敵イベントから3マス先に主人公がいるとしたら、
主人公から3マス先に敵イベントがいると言う事になります。
つまり主人公の周り4方向(36マス)に敵キャラがいるかどうかを調べれば、
敵キャラ1体ごとに主人公を監視する設定は必要無くなります。

但し、敵キャラごとに監視する範囲が異なるなど、
同じ1つのシステムでは処理できない場合は、この方法では対応できない事もあります。



■無用な「それ以外の場合」は設定しない
制作者によっては、条件分岐を設定する時に、
◆条件分岐:スイッチ[0001:効果音を鳴らす]がON
 ◆効果音の演奏:あたり1
 ◆ウェイト:1.0秒
 ◆
:それ以外の場合
 ◆
:分岐終了

と言ったように、無意味な「それ以外の場合」を設定している方がいます。
一見「それ以外の場合」が有っても無くても変わらないように見えますが、
それ以外の場合」がありますと、「それ以外の場合」の中に、
イベントコマンドが設定されているかどうかを調べる処理が発生しますので、
不要な「それ以外の場合」は設定しない方が良いでしょう。



■無意味な注釈は設定しない
注釈は、イベント実行内容に設定しても、
ゲーム画面では全く反映されないものですが、一応イベントの処理上では、
これは注釈である → 次のイベントコマンドへ移動
と言った感じに処理しています。
必要な注釈までを無理に消すほどの事ではないですが、
あまりに無意味な注釈の設定を行うのはお勧めできません。



◎関連ページ
 ●主人公が動かなくなった
 ●ツクールの仕様に関するページ


YADOTトップ  このサイトは何?  気紛れな空間へ戻る  メール