2000・2003共通の基本的な仕様についての解説です。

通常イベント

マップ上およびコモンイベントに配置できるものを指す（バトルイベントは除く）。
「イベントの呼び出し」で呼び出されない限り、出現条件を満たしているものだけが実行される。
「自動的に実行する」「定期的に並列処理する」を実行条件としているイベントは、
一連の処理を実行している最中に出現条件を満たしていない状態になった場合でも
待機時間を含む命令が出るまではそのまま実行し続ける。

待機時間を含む命令
「文章の表示」「ウェイト」「指定動作の全実行(動作が指定されている場合)」など、
実行の終了までに一定、もしくはゲーム状況やプレイヤーの入力によって
（1フレーム以上の）何もしない時間を含むコマンドのこと。
- 「文章の表示」「数値入力の処理」などはプレイヤーの入力を待つ待機時間を含む命令である。
- 「変数の操作」「キャラクターの動作指定」などは一瞬で終了する待機時間を含まない命令である。
- 「指定動作の全実行」は動作の指定が行われている時のみ待機時間を含む。

ツクールのイベントは1f（フレーム。1/60秒＝ウェイト0.0秒）を一連の処理の単位としており、
一つのイベントが1f内に実行できるコマンドは1万ステップが上限である（ステップについては後述）。
なお、Steam版2003の拡張パッチのpfバージョンでは各イベントの処理上限が20万ステップにまで緩和されている。

マップイベント

マップ上に配置できるイベント。
各ページごとに出現条件を設定でき、条件を満たしている最も大きい番号のページのみが出現・実行される。
「変数の操作」「スイッチの操作」「タイマーの操作」など、マップイベントの出現条件に関係するコマンドが
実行された際、出現条件が洗い直されてマップイベントの状態が更新される。

この更新処理はマップイベントが一つ以上存在する場合にコマンド毎に行われるため、
マップイベントが存在する状態で上記のコマンドを大量に実行すると負荷が掛かり、処理落ちの原因となる。
ピクチャのみで画面を構成する場合はマップイベントを一つも置かないことで大幅に負荷を軽減できる
（ただしManiac Patchを当てたSteam2003のpf版のみマップイベントを置いても重くならない）。
また、マップイベントを使う場合は「条件分岐」などの出現条件を参照しないコマンドを多用するのも有効。

マップイベントの挙動

自動的に始まる
出現条件を満たしているイベントのうち最もIDが小さいイベントのみが実行される。
他に条件を満たしているイベントがあっても通常実行されることはない。
- ただし、最もIDが小さいイベントの内容に待機時間を含む命令が存在しない場合、
  次にIDが小さい自動実行のイベントが割り込んで実行される。

　　　最後の行まで実行が終了すると、そのフレームではそれ以上実行されなくなり、
　　　出現条件を満たしている限り次のフレームで再び最初の行から実行される。

定期的に並列処理する
出現条件を満たしているイベントがIDが小さい順に順番に毎フレーム一度ずつ実行される。
「自動的に始まる」イベントよりも先に実行され、条件を満たした全ての「定期的に並列処理する」
イベントが終了した時点で、「自動的に始まる」イベントの処理に移行する。

ゲーム開始時、「自動的に始まる」よりも若干早く起動する。

決定キーが押されたとき・主人公から触れたとき・イベントから触れたとき
決定キーを押したり接触したりするとイベントが実行される。
上記の二つの開始条件と違い、実行途中でイベントの出現条件を満たさなくなったりなどしても
イベントは一切中断されず、最後の行まで実行される（実行中に別のマップに移動しても中断されない）。

よくあるミスだが、マップチップをイベントグラフィックにした際に選択したチップ自体が通行不可で、
かつイベント側のプライオリティを「主人公の下/上」にしていると、テストプレイのCtrlですり抜けたり
主人公を動作指定ですり抜け状態にしていない限りはイベントの起動が不可能になるので注意。

コモンイベント

データベースの「コモンイベント」に配置できるイベント。
どのマップ上からでも実行可能な他、「変数の操作」などを行っても出現条件の洗い直しがされない利点を持つ。
ただし、出現条件に設定できるのはスイッチのみ。

コモンイベントの挙動

自動的に始まる
マップイベントと違い、待機時間を含む命令がない限り限界(1万ステップ)までイベント内容を繰り返す。
例えば、
```
◆変数の操作：[0001]加算、1
◆
```
という1行のみの自動実行のイベントを動かす場合、1フレーム経過するごとにv[0001]が
5000ずつ増えていくことになる（空行も1ステップに含まれるため変数操作が1fに5000回実行される）。

処理を毎fに一回のみに抑えたい場合は、上述の待機時間を含む命令を実行すればよい。
無駄なく毎f実行させるには「ウェイト：0.0秒」を使う。

定期的に並列処理する
こちらはマップイベントと同じで、IDが小さい順に条件を満たすものが実行されていく。
自動実行のコモンイベントよりも先に全ての並列処理のコモンイベントが実行されるのも同様である。

ステップ

ツクール200Xにおける処理の最小単位はステップと呼ばれている。
多くのコマンドは1ステップ消費するので、概ね一行ごとに1ステップ消費と考えてもいい
（「条件分岐」などのように消費ステップが状況によって変わるものもある）。
前述の通り、一つのイベントは最大で1fに10000ステップまでしか実行できないように制限が掛かっている。
上限を超えた際は次のフレームに処理が持ち越されてしまい、場合によってはバグの原因となるため
イベントの実行順序が重要なゲームでは、消費ステップ数をある程度把握しておく必要がある。

また、「イベントコマンド」として配置されていない空白の行もステップとして計上される。

◆繰り返し処理
　◆　　　　　//　←1ステップ
：以上繰り返し
◆条件分岐：スイッチ[0001]がON
　◆　　　　　//　←1ステップ
：それ以外の場合
　◆　　　　　//　←1ステップ
：分岐終了
◆　　　　　//　←1ステップ

「ピクチャーの表示」「BGMの演奏」「変数の操作」の一括処理なども消費は1ステップのみだが、
扱うデータが多いほど負荷も増すため、ステップ数の削減が必ずしも負荷の軽減に繋がるとも限らない点は注意。

「一つのイベントは10000ステップまで」ではあるが、同時に複数の並列イベントを動かせば
数万ステップ以上を1f内で実行可能である。
現在、一般的なPCはマップイベントを一切置かない場合は平均7万ステップ程度は余裕で実行できるので
少なめに見積もって1f内の処理を5～6万ステップ程度に抑えれば快適に動くかもしれない。
マップイベントを配置する場合は変数操作のみなら平均1万ステップ程度で限界が来る場合が多い。
もちろん、実際のステップ数の限界は処理内容によって大きく変動する可能性がある。
ステップ数の詳しい消費や削減のコツなどについては200X共通/負荷の低減を参照。

セーブデータの保存場所

Save01.lsdなどのセーブデータは、通常ではゲームフォルダー内に管理される。
ゲーム中でセーブ時やロード時に表示される一覧にも、ゲームフォルダー内のセーブデータが表示される。

しかしRPG_RT.exeが読み取り専用である場合は、マイドキュメント以下にゲーム名のフォルダーが作成され、その中でセーブデータが管理される。
この場合はセーブ時やロード時でも、ゲームフォルダー内のセーブデータは表示されない。
ゲームにセーブデータが同梱されていてもロードできなくなる。
RPGツクールローダー経由で起動する場合、コピー元の実行ファイルが読み取り専用だと同様の現象が起こることに注意。

推測だがこのような動作にしている理由は、CD-ROMなど読み取りメディアを配慮している可能性がある。
読み取り専用メディア中のゲームを直接起動した場合、ゲームフォルダー中にセーブデータを保存できない。
そのような場合でもセーブデータを保存できるようにするための処置と考えられる。

コメント

2000/基本的な仕様

200X共通/基本的な仕様