Steam版2003の仕様
ピクチャーは1000枚まで表示できる他、表示オプションが日本版に比べて大幅に増えた。
パラメータの変数指定
従来は変数で指定できるのは表示座標のみだったが、現在は「ピクチャーID」「拡大率」「透明度」
「ファイル名終端」「スプライトシート中で表示するコマ」も変数で指定可能であり、自由度が上がっている。
なお、「透明度」に100を超える値を指定すると色の合成がおかしくなるので注意(演出としても利用可能)。
読み込みのスキップ
ピクチャーの表示において、同じピクチャーIDで同じファイル名の画像が指定されたとき、
読み込み(画像をメモリ上に展開する作業)がスキップされ、高速で再表示されるようになった。
主に後述のスプライトシート機能のための仕様だと思われるが、移動中のピクチャーを同フレーム中に
配置し直し、再び移動させるのにも便利である。
表示優先度の変更
ピクチャーを表示するレベルを10段階で変更できるようになった。
- 表示順は低い順に以下の通り。
優先度 |
---|
遠景 |
M0:遠景の上 |
マップチップの床 |
M1:チップセットより上 かつ主人公より下 |
イベント(主人公よりも下) |
M2:イベントより上 かつ主人公より下'' |
イベント(主人公と同じ) |
主人公 |
M3:イベントより上 かつ主人公と同位置 |
チップセット(主人公よりも上) |
M4:チップセットより上 かつ主人公より上 |
イベント(主人公よりも上) |
M5:イベントより上 かつ主人公より上 |
天候エフェクト |
M6:天候エフェクトより上 |
戦闘アニメ |
M7:戦闘アニメより上 |
メッセージウィンドウ |
M8:メッセージウィンドウより上 |
タイマー |
M9:タイマーより上 |
仮にイベントチップにプライオリティの値をつけ、イベントチップとのプライオリティを図にするとこのようになる
※補足、通行設定☆のくぐり抜けマップチップは3.5
マップ上での演出の自由度が増しただけでなく、単純にピクチャの表示順序としても使うことができる。
ファイル名の末尾置き換え
ファイル名末尾を指定した桁数の変数で置き換える機能。
例えば「number_00」という画像を指定して、置換する桁数を「2」、変数を「v[1]」とし、
ピクチャー表示時点でのv[1]が83だった場合は「number_83」の画像が読み込まれる。
存在しない値の画像を読み込むと当然エラー落ちするので注意。
スプライトシート
一枚のピクチャを縦横に指定した個数に分割し、そのうちの一つのみを表示する機能。
CharsetやBattleなどの素材もスプライトシートの一種だが、こちらはユーザーが規格を自由に変更できる。
分割数は定数のみ、表示するコマは定数・変数で指定できる他、指定の周期で順番にコマを自動的に切り替えて表示していくオプションもある。
存在しないコマを表示した場合は何も表示されなくなる。
200X共通/基本的な仕様
2000・2003共通の基本的な仕様についての解説です。
通常イベント
マップ上およびコモンイベントに配置できるものを指す(バトルイベントは除く)。
「イベントの呼び出し」で呼び出されない限り、出現条件を満たしているものだけが実行される。
「自動的に実行する」「定期的に並列処理する」を実行条件としているイベントは、
一連の処理を実行している最中に出現条件を満たしていない状態になった場合でも
待機時間を含む命令が出るまではそのまま実行し続ける。
- 待機時間を含む命令
「文章の表示」「ウェイト」「指定動作の全実行(動作が指定されている場合)」など、
実行の終了までに一定、もしくはゲーム状況やプレイヤーの入力によって
(1フレーム以上の)何もしない時間を含むコマンドのこと。- 「文章の表示」「数値入力の処理」などはプレイヤーの入力を待つ待機時間を含む命令である。
- 「変数の操作」「キャラクターの動作指定」などは一瞬で終了する待機時間を含まない命令である。
- 「指定動作の全実行」は動作の指定が行われている時のみ待機時間を含む。
ツクールのイベントは1f(フレーム。1/60秒=ウェイト0.0秒)を一連の処理の単位としており、
一つのイベントが1f内に実行できるコマンドは1万ステップが上限である(ステップについては後述)。
なお、Steam版2003の拡張パッチのpfバージョンでは各イベントの処理上限が20万ステップにまで緩和されている。
マップイベント
マップ上に配置できるイベント。
各ページごとに出現条件を設定でき、条件を満たしている最も大きい番号のページのみが出現・実行される。
「変数の操作」「スイッチの操作」「タイマーの操作」など、マップイベントの出現条件に関係するコマンドが
実行された際、出現条件が洗い直されてマップイベントの状態が更新される。
- この更新処理はマップイベントが一つ以上存在する場合にコマンド毎に行われるため、
マップイベントが存在する状態で上記のコマンドを大量に実行すると負荷が掛かり、処理落ちの原因となる。
ピクチャのみで画面を構成する場合はマップイベントを一つも置かないことで大幅に負荷を軽減できる
(ただしManiac Patchを当てたSteam2003のpf版のみマップイベントを置いても重くならない)。
また、マップイベントを使う場合は「条件分岐」などの出現条件を参照しないコマンドを多用するのも有効。
マップイベントの挙動
- 自動的に始まる
出現条件を満たしているイベントのうち最もIDが小さいイベントのみが実行される。
他に条件を満たしているイベントがあっても通常実行されることはない。- ただし、最もIDが小さいイベントの内容に待機時間を含む命令が存在しない場合、
次にIDが小さい自動実行のイベントが割り込んで実行される。
- ただし、最もIDが小さいイベントの内容に待機時間を含む命令が存在しない場合、
最後の行まで実行が終了すると、そのフレームではそれ以上実行されなくなり、
出現条件を満たしている限り次のフレームで再び最初の行から実行される。
- 定期的に並列処理する
出現条件を満たしているイベントがIDが小さい順に順番に毎フレーム一度ずつ実行される。
「自動的に始まる」イベントよりも先に実行され、条件を満たした全ての「定期的に並列処理する」
イベントが終了した時点で、「自動的に始まる」イベントの処理に移行する。
- 決定キーが押されたとき・主人公から触れたとき・イベントから触れたとき
決定キーを押したり接触したりするとイベントが実行される。
上記の二つの開始条件と違い、実行途中でイベントの出現条件を満たさなくなったりなどしても
イベントは一切中断されず、最後の行まで実行される(実行中に別のマップに移動しても中断されない)。
かつイベント側のプライオリティを「主人公の下/上」にしていると、テストプレイのCtrlですり抜けたり
主人公を動作指定ですり抜け状態にしていない限りはイベントの起動が不可能になるので注意。
コモンイベント
データベースの「コモンイベント」に配置できるイベント。
どのマップ上からでも実行可能な他、「変数の操作」などを行っても出現条件の洗い直しがされない利点を持つ。
ただし、出現条件に設定できるのはスイッチのみ。
コモンイベントの挙動
- 自動的に始まる
マップイベントと違い、待機時間を含む命令がない限り限界(1万ステップ)までイベント内容を繰り返す。
例えば、◆変数の操作:[0001]加算、1 ◆
という1行のみの自動実行のイベントを動かす場合、1フレーム経過するごとにv[0001]が
5000ずつ増えていくことになる(空行も1ステップに含まれるため変数操作が1fに5000回実行される)。
無駄なく毎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など読み取りメディアを配慮している可能性がある。
読み取り専用メディア中のゲームを直接起動した場合、ゲームフォルダー中にセーブデータを保存できない。
そのような場合でもセーブデータを保存できるようにするための処置と考えられる。
コメント