自分のゲームも含めて一番オーソドックスなRPGというのは
雑魚戦→ボス戦の繰り返しで成り立っているわけだけど、
ゲームクリアまでに数十～数百回と繰り返すことになる
雑魚戦のエンカウント形式について少し考えてみようかな、という話。

RPGツクールにおけるエンカウント形式には様々な方法があるが、
本項ではこれを大きく3つに分けて考察していきたいと思う。

-----—
①ツクールデフォで設定できるランダムエンカウント
・メリット:
Aデフォルトの機能を使うため、他のイベントと競合しない
Bエンカウント歩数の変更もイベントコマンドで簡単に行える
・デメリット:
a戦闘の前後にイベントを挟むことが難しい
b勝利した時/逃走した時などの分岐を作ることが出来ない
c実際のエンカウント歩数は揺れ幅が非常に大きい
-----—
最も簡単に導入できるのがこの①。
メリットAのおかげでバグが発生することもほとんど無く軽量だが、
デメリットa/bなどの理由でスイッチ技の後処理などを導入するのは逆に難しい。
そして最も問題なのがデメリットc。
推察※が正しければ極端な話、出現歩数を999に設定したとしても
1歩でエンカウントする危険性があり、状況によっては非常にストレスフルになる。
短編処女作「輝石少女」ではあんまり考えずにこれを採用したが、
時間が許すならあんまりやりたくない。

-----—
②自作システムによるランダムエンカウント
・メリット:
A戦闘の前後にイベントを挿入したりすることが簡単に可能
B勝利した時/逃走した時などの分岐を作ることが出来る
Cエンカウント歩数を一歩単位で自由に決めることが出来る
・デメリット:
aマップごとの設定に手間がかかる
b個別に設定しない限り先制攻撃/不意打ちが絶対に行われない
c並列処理を使うため、他イベントとの競合が起きやすい
-----—
「弾丸少女」「夢幻少女」で採用しているのがこの②。
導入の理由はひとえにメリットA/Bのため。
戦闘の前後にイベントを挟むことで称号による能力上昇や以前触れたスイッチ技の処理、
また「戦闘勝利時のみ図鑑に登録される」ことを再現している。
一方、エンカウントについてはアイテムで有無を選択できるようにしているように
あんまりこだわりはなかったりする。
しかしながら自作ゲームにはフェイスチャットやダッシュといった他の並列処理が
存在しているため、製作中にはイベントの割り込み等のバグが起こってしまっている
など、デメリットcによる問題点などもある。
単純に並列処理が増えて動作が重くなるのも困りもの。

-----—
③自作システムによるシンボルエンカウント
については明日。
というのも見た目には大きく違うけど自作ゲームで採用するには②とそう変わりはなく
個人の好みの問題が非常に大きいから。
-----—

※推察
ツクール2000/2003のエンカウント計算式は不明だが、
スクリプトの閲覧/編集が可能なXP/VXでは以下のようになっており、
エンカウント歩数計算式は1～設定歩数×2であることが分かる。
本項では体感的/経験則より200Xも同様の計算式であるという推論の上で考察を行う。

　def make_encounter_count
　　if $game_map.map_id != 0
　　　n = $game_map.encounter_step
　　　@encounter_count = rand(n) + rand(n) + 1
　　end
　end

（VXスクリプトエディタからの引用です。）