戦闘背景やエンカウント率を詳細設定【RPGツクールMZ&MVプラグイン】

2023年10月26日

 戦闘背景やエンカウント率を詳細な条件で設定します。


 上記は橋の上で戦闘背景を変更した例です。
 ちなみにデフォルトでは平原になるという残念っぷり……。

 条件にできるのは『地形タグ』『リージョンID』『タイルID』『オートタイルタイプ』の四種類です。
 もっとも、地形タグは数が限られているし、リージョンは設定が大変です。そこでオートタイルタイプやタイルIDを使った設定をオススメします。

 ※オートタイルタイプとはオートタイル毎に保有する識別番号のことです。
  付属のNRP_DebugTile.jsで確認できます。
 ※戦闘背景の変更はフィールドタイプのタイルセットのみ有効です。


 また、ツクールMV〜MZにはデフォルトで以下の隠し仕様が含まれています。

  • 茂み属性のエンカウント率は二倍
  • 乗船(大型船)中のエンカウント率は半減

 場合によっては、ありがた迷惑になりかねません。これらの仕様を変更することも可能です。

目次


導入方法(Install)

更新履歴(History)

使用方法(Usage)

細かい仕様(Detail)

プラグインパラメータ(基本)

茂みのエンカウント率(BushEncounterRate)

大型船のエンカウント率(ShipEncounterRate)

設定リスト(SettingList)


プラグインパラメータ(設定リスト)

設定ID(Id)

メモ(Memo)

全タイルセットで有効(ValidAllTilesets)


プラグインパラメータ(設定リスト:条件)

地形タグ(TerrainTag)

リージョンID(RegionId)

オートタイルタイプ(AutotileType)

タイルID(TileId)

乗物タイプ(VehicleType)


プラグインパラメータ(設定リスト:内容)

エンカウント率(EncounterRate)

戦闘背景1(Battleback1)

戦闘背景2(Battleback2)


導入方法(install)


 以下のファイルをダウンロードし 、[プロジェクト]\js\plugins に放り込みます。ツクールのプラグイン管理から機能をONにしてください。
 ※いずれのプラグインもMV、MZの両方で有効です。

 NRP_TerrainInfo.js ver1.03(2023/10/26)

オプション

タイル情報をデバッグ表示する(詳細

 NRP_DebugTile.js ver1.01(2021/08/15)

 ※F2を押すだけで、足元のオートタイルタイプやタイルIDを確認できるようにするプラグインです。NRP_TerrainInfoの補助用に使えます。

更新履歴(History)


2023/10/26(ver1.03)

  • ゲームロード直後に場所移動するまで設定情報が反映されない不具合修正。

2023/05/01(ver1.02)

  • MVで動作しない不具合修正。

2023/01/04(ver1.01)


2021/06/04 -> 2021/11/11(ver1.00 -> 1.001)

  • 公開!
  • イベントテストでエラーになる不具合修正。(11/11 ver1.001)

使用方法(Usage)


 プラグインパラメータの設定リストに、条件、エンカウント率、戦闘背景を入力してください。
 登録した『設定ID』をタイルセットのメモ欄に設定すればOKです。
<TerrainSetting:?>

 ?の部分が設定リストに登録した『設定ID』となります。
 また、カンマ区切りによって複数指定も可能です。
<TerrainSetting,B,C>


 設定リストには最初からサンプルが登録されています。
 ツクールのデフォルトのフィールドに合わせた内容になっているので、参考にしてください。

細かい仕様(Detail)


 タイルIDやオートタイルタイプは、上のレイヤーから順番に判定されます。
 設定がないレイヤーのタイルは無視される仕様です。

 例えば、以下のように設定した場合、

  • レイヤー1の平原:エンカウント率100%
  • レイヤー2の森 :エンカウント率200%
  • レイヤー3の町 :設定なし

 レイヤー2の森のエンカウント率(200%)が有効になります。これは戦闘背景についても同様です。

プラグインパラメータ(基本)


茂みのエンカウント率(BushEncounterRate)

 茂み上でのエンカウント率です。100を基準に設定してください。
 初期値は200です。

 これは設定リストの内容と重複するので注意してください。
 例えば、森に茂み属性を付加してエンカウント率を200にした場合、さらに茂み属性の影響で計4倍になってしまいます。

大型船のエンカウント率(ShipEncounterRate)

 大型船に乗っている時のエンカウント率です。100を基準に設定してください。
 初期値は50です。

 こちらも設定リストの内容と重複します。

設定リスト(SettingList)

 エンカウント率の設定の一覧です。

 以下、その詳細設定のパラメータです。

プラグインパラメータ(設定リスト)


設定ID(Id)

 タイルセットのメモ欄からの呼び出しに使う識別子です。
 『全タイルセットで有効』がオンの場合は不要です。

メモ(Memo)

 判別用のメモです。
 処理には使用しませんので、分かりやすい名前を付けてください。

全タイルセットで有効(ValidAllTilesets)

 設定を全てのタイルセットで有効にします。
 特定のタイルセットにのみ設定を反映したい場合は、オフにしてください。

プラグインパラメータ(設定リスト:条件)


地形タグ(TerrainTag)

 対象とする地形タグ(1~7)を指定します。
 複数指定も可能です。(例:1,3~5)

 7つまでしか設定できないのでご利用は計画的に。

リージョンID(RegionId)

 対象とするリージョン(1~255)を指定します。
 複数指定も可能です。(例:1,3~5)

オートタイルタイプ(AutotileType)

 対象とするオートタイルタイプを指定します。
 複数指定も可能です。(例:1,3~5)

 オートタイルタイプとはオートタイル毎に割り当てられる番号です。デフォルトでは戦闘背景の判定に用いられています。
 地形タグと異なり数の制限がないため、自由に設定が可能です。

 ただし、この値は通常確認できません。
 オプションにある「タイル情報をデバッグ表示する」プラグインで確認ができます。

タイルID(TileId)

 対象とするタイルIDを指定します。
 複数指定も可能です。(例:1,3~5)

 こちらはエディタの機能で普通に取得できますが、面倒です。
 こちらも「タイル情報をデバッグ表示する」プラグインでの確認をオススメします。

乗物タイプ(VehicleType)

 対象とする乗物のタイプを指定します。

プラグインパラメータ(設定リスト:内容)


エンカウント率(EncounterRate)

 条件を満たした場合のエンカウント率です。100を基準に設定してください。

戦闘背景1(Battleback1)

 条件を満たした場合の戦闘背景(下)です。
 タイルセットがフィールドタイプの場合のみ有効です。

戦闘背景2(Battleback2)

 条件を満たした場合の戦闘背景(上)です。
 タイルセットがフィールドタイプの場合のみ有効です。

 >RPGツクールMZ&MV目次に戻る
posted by 砂川赳 at 19:35 | RPGツクールMZ&MV | このブログの読者になる | 更新情報をチェックする

DynamicAnimationMZ(戦闘アニメを自動化&超強化)【RPGツクールMZプラグイン】

2023年10月18日

 戦闘アニメを自動化&超強化するプラグインです。
 ※このプラグインはMZ版です。MV版はこちら!

 Click here for the English manual.(By Ryan Bram)

 スキル(アイテム)から自在に戦闘アニメーションを呼び出せます。異なるIDのアニメーションを同時表示させたり、移動させたりすることが可能です。
 非常に自由度の高い仕様になっていますが、テンプレートを呼び出せばメモ欄に一行記述(例:<D-Animation:shot/>)するだけでも動作します。

 さらにDynamicMotionMZと連携すれば、バトラーの動作も自在に設定できます。

 以下は紹介動画です。
※画面が小さい場合は右下の全画面表示をクリックしてください。

目次


導入方法(install)

更新履歴(history)

使用方法(usage)


テンプレートの解説(template)


その他情報(other information)


サンプル技(sample)


MV版との違い(difference from MV)

競合について(conflict)


導入方法(install)


 以下のファイルをダウンロードし 、[プロジェクト]\js\plugins に放り込みます。ツクールMZのプラグイン管理から機能をONにしてください。

 NRP_DynamicAnimationMZ.js ver1.203(2023/10/22)

 ※MV互換データの使用にはNRP_DynamicAnimationMV2MZ.jsが必要です。

オプション

戦闘モーションを自在に制御(詳細

 NRP_DynamicMotionMZ.js ver1.21(2023/10/03)

MV用アニメーションをMZで扱う(詳細

 NRP_DynamicAnimationMV2MZ.js ver1.052(2023/10/22)

DynamicAnimationMZをマップ上で起動(詳細

 NRP_DynamicAnimationMapMZ.js ver1.09(2021/04/24)

DynamicMotionをマップ上で起動(詳細

 NRP_DynamicMotionMap.js ver1.06(2021/05/07)

DynamicAnimation&Motionの定義をtxtから読み込む(詳細

 NRP_DynamicReadTxt.js ver1.06(2021/03/24)

MV用アニメーションの軽量化(詳細

 NRP_LightAnimationMZ.js ver1.00(2020/09/10)

 ※プラグイン同士の配置順に注意してください。上記の掲載順にそのまま配置すれば安全です。

更新履歴(history)


2023/10/02 -> 2023/10/18(ver1.20 -> 1.202)

  • 放物線(ジャンプ)の最初の1フレームで宙に浮いていない不具合修正。
  • ver1.20にて放物線(ジャンプ)の到達後にアニメーションが下に移動してしまう不具合修正。(2023/10/18 ver1.201)
  • lookCourseテンプレート使用時に不透明度を指定すると、最初の1フレームがあらぬ方向を向いてしまう問題に対応。(2023/10/18 ver1.202)
    ※反映にはテンプレート定義の更新が必要です。
  • ver1.202にて、lookCourseテンプレート使用時にアニメーションが見えなくなる不具合修正。(2023/10/22 ver1.203)

2022/04/28 -> 2023/08/26(ver1.19 -> 1.195)

  • MVアニメのセルの部分描画機能を実装。
    詳しくはサンプルをご覧ください。
  • condition指定時、タイミング制御が不安定になる不具合修正。
    (2022/06/12 ver1.191)
  • NRP_DynamicAnimationMV2MZにてbreath型テンプレートが動作しない不具合修正。(2022/07/16 ver1.192)
    ※NRP_DynamicAnimationMV2MZも同時に更新してください。
  • playSeの後ろに注釈(//)を記述するとエラーになる不具合修正。
    (2023/02/17 ver1.193)
  • 残像の後にkeep型をつなげると、位置を引き継げない不具合修正。
    (2023/05/28 ver1.194)
  • ダメージ処理(damage)のフレーム指定が0〜1の場合に機能しない不具合修正。(2023/08/26 ver1.195)

2021/12/11 -> 2022/03/10(ver1.18 -> 1.181)

  • MZ1.4.0の更新に対応。MZエディタ上からMVアニメを設定した場合も表示できるようにした。
    ※引き続き再生にはNRP_DynamicAnimationMV2MZ.jsが必要です。プログラム自体の更新はありませんが、解説のみ更新しています。あちらもご確認ください。
    ※MZ1.4.0にはセルの合成方法を設定できない不具合がある模様です。
     MZにはデータを移さず、しばらく様子見をオススメします。

    ※MZ1.4.1にて解消されました!(2021/12/18追記)
  • condition指定時、条件を満たさなかった場合でもウェイトがかかってしまう不具合を修正。(2022/03/10 ver1.181)
  • ソース整理。(2022/03/10 ver1.181)

2021/08/06 -> 10/15(ver1.17 -> 1.173)

  • プラグインパラメータに『仲間向けは反転しない』を追加。
  • それに伴い、<D-Setting>にMirrorForFriend、NoMirrorForFriendを追加。
    ※NRP_DynamicMotionMZも最新に更新してください。
  • 動作対象を変更した場合、ミラーリングが逆方向に動作する不具合修正。
    ※DynamicMotion側の修正です。(08/07)
  • 途中のセーブデータに対して導入した場合、エラーになる不具合修正。(10/15 ver1.171)
  • ↑の修正が他のプラグインと競合する模様なので再修正。(10/15 ver1.173)

2021/04/24 -> 06/16(ver1.16 -> 1.162)

  • マップ版DynamicAnimationの『途中から再生』に対応。
    ※各関連プラグインも最新に更新してください。
  • 一つのアニメーションが消滅するまでに、プレイヤーがマップ全体の半分以上を移動するとアニメーションの表示が消える不具合修正。(04/28 ver1.161)
  • delay=0の場合、残像機能が動作しない不具合修正。(06/16 ver1.162)

2021/04/21(ver1.15)


2021/04/07 -> 04/14(ver1.14 -> 1.142)

  • システム2の『画面の幅/高さ』を初期値から変更した場合に、アニメーションの表示位置がズレる不具合修正。
  • マップ版DynamicAnimationにて、画面スクロール時に一瞬だけアニメーションの位置がズレる不具合修正。(04/14 ver1.141)
    ※NRP_DynamicAnimationMV2MZも同時に更新してください。
  • コモンイベントの呼び出しが機能しない不具合修正。(04/18 ver1.142)
    ※Motion側のみ動作していた模様です。

2020/11/20 -> 01/21(ver1.13 -> 1.131)

  • アニメーションの位置計算時、対象の拡大率(scale)を参照するように修正。
  • それに伴い『対象の拡大率を考慮』のプラグインパラメータを追加。
    ※DynamicMotionMZも最新に更新してください。
  • フロントビューでアクターの座標を参照するアニメーションが表示されない不具合を修正。(01/21 ver1.131)

2020/11/08(ver1.12)

  • 全体ダメージ(damageAll)のテンプレートを追加。
  • テンプレート一覧の表示情報を整理。テンプレートIDが収まるように調整。
    ※各関連プラグインも最新に更新してください。

    ※テンプレートの追加・修正はプラグインを再登録しないと反映されません。
    ただし、再登録すると全ての設定変更が初期化されてしまいます。
    それを避けたい場合、テンプレート定義一覧からのコピペをオススメします。


2020/11/05(ver1.11)

  • 外部プラグインとの連携用に調整。
  • 全体ダメージ表示が作動しない不具合修正。
  • マップ版DynamicAnimationにて、アニメーションの位置が『画面』の場合もスクロールの影響を受けるように修正。
  • 中央(center)、全体(whole)のテンプレートを追加。
    ※各関連プラグインも最新に更新してください。

2020/10/31(ver1.10)

  • Motion側にあった全体ダメージ処理(damageAll)をこちらにも追加。さらに『damageAll = 10』というように数値指定すると、そのタイミングでダメージ処理を行います。

2020/10/29(ver1.09)

  • MZ v1.1.0で追加されたアニメーションの『下揃え』に対応。
  • アニメーションの頭上表示が反映されない不具合修正。

2020/10/17 -> 10/23(ver1.08 -> 1.082)

  • 戦闘中(ifBattle)、マップ中(ifMap)のテンプレートを追加。
  • マップ版にて複数の命令を組み合わせた場合、不要なウェイトが発生する不具合を修正。および処理軽量化。
  • マップ版にて戦闘時に使用すると、セーブに保存できなくなったり、次回の戦闘開始時にエラーになったりする不具合修正。(10/20 ver1.081)
  • lookCourseテンプレートでアクターを対象にした場合、アニメーションの向きが反対になる不具合修正。(noMirror処理が機能していなかったため)(10/20 ver1.082)

2020/10/15(ver1.07)


2020/10/07(ver1.06)


2020/10/05(ver1.05)

  • DynamicAnimationのマップ対応に伴い調整。
  • 外部プラグインからの変更を想定し、クラス構造を調整。
    ※NRP_DynamicMotionMZと合わせて最新版を取得してください。

2020/10/02(ver1.04 -> 1.041)

  • DynamicAnimationのマップ対応に伴い大幅改修。
    ※NRP_DynamicAnimationMV2MZ, NRP_DynamicMotionMZと合わせて最新版を取得してください。
  • 『limitSound=0』および『limitFlash=0』で効果音やフラッシュを消去できるようにした。
  • 並列処理でのwait指定時に想定した動作をしない不具合修正。(ver1.041)

2020/09/22(ver1.03)

  • 実行条件(condition)をリピート項目に変更。
    例:『condition = b.isStateAffected(10)』で睡眠中の対象のみアニメ表示。

2020/09/15(ver1.02 -> 1.021)

  • タイムプログレス(アクティブ)でアニメ終了前にダメージが表示されてしまう不具合修正。
  • 効果音の先読が失敗していた不具合修正。
  • コマンド中のアクターにアニメ表示のプラグインとMVアニメを合わせると、ダメージ処理のタイミングが乱れる不具合修正。(09/17 ver1.021)
    ※NRP_DynamicAnimationMV2MZも同時に更新してください。

2020/09/09(ver1.01 -> 1.013)

  • MVアニメーションに対応。
  • MVアニメの軽量化プラグインを公開。(09/10)
  • 他プラグインとの競合軽減のため微調整。(09/10 ver1.011)
  • 他プラグインとの競合軽減のため微調整。(09/13 ver1.012)
  • タイムプログレス(アクティブ)で動作が途中で止まる不具合修正。(09/14 ver1.013)

2020/09/05(ver1.00 -> 1.001)

  • ツクールMZ対応版を公開!
  • 対象が複数の際、余分なウェイトがかかる不具合修正。(09/07 ver1.001)

使用方法(usage)


 スキル(アイテム)のメモ欄からテンプレートを呼び出すことでアニメーションの動作が変化します。以下は射撃(shot)型のテンプレートを呼び出した例です。
<D-Animation:shot/>

 このように一行で完結する場合は『/』で閉じます。

 さらにテンプレートに対して、パラメータの追加・上書が可能です。
<D-Animation:shot>
repeat = 5 // 繰返し回数
</D-Animation>

 <D-Animation:shot>と</D-Animation>の間に記述を挟むイメージです。
 HTMLなどの経験がある人なら分かりやすいと思います。
 ※『/』の位置に注意してください。
 ※『//』から右は単なる注釈です。

 最低限の使用法は上記の通りですが、パラメータは非常に多くあります。
 まずは以下の『基本的な使用法』のページから見ると分かりやすいでしょう。
 その後、『テンプレートの解説』や『プラグインパラメータ一覧』を参照していくのがオススメです。

 面倒なら『サンプル技』のページがオススメです。ほぼコピペでスキルが作れるので手っ取り早いです。

 ※ほとんどは元々、MV用に作ったページのままです。多くはそのまま使えると思いますが、合わない部分などは随時MZ用に修正していく予定です。


テンプレートの解説(template)


射撃系テンプレート

 射撃(shot)、乱射(shotRandom)、全乱射(shotRandomAll)
 投射(arc)、乱投射(arcRandom)、全乱投射(arcRandomAll)

ランダム系テンプレート

 ランダム(random)、全ランダム(randomAll)
 円ランダム(randomCircle)、雨(rain)

範囲系テンプレート

 水平(horizontal)、水平射撃(shotHorizontal)、垂直(vertical)
 貫通(pierce)

円系テンプレート

 円周(circle)、渦(vortex)、発散渦(spreadVortex)、公転(revolve)
 移動渦(moveVortex)、発散移動渦(spreadMoveVortex)、ブレス(breath)
 FVブレス(fv_breath)、収束(converge)、放射(radiate)

特殊系テンプレート

 ビーム(beam)、拡散ビーム(diffusionBeam)、継続(keep)
 ブーメラン(boomerang)、魔法発動(spell)

表示系テンプレート

 進路を向く(lookCourse)、回転(roll)、画面(screen)、頭上(head)
 中央(center)、足元(foot)、全体(whole)

制御系テンプレート

 追従(follow)、自分(self)、ウェイト(wait)、ディレイ(delay)
 ダメージ(damage)、戦闘中(ifBattle)、マップ中(ifMap)

その他情報(other information)



サンプル技(sample)



MV版との違い(difference from MV)


 MZではアニメーションの大幅な仕様変更が行われました。それによる当プラグインへの影響をまとめます。
 主にMVからのユーザ向けです。

Effekseerの採用

 MZではEffekseerで作成した3Dエフェクトを表示するようになりました。
 そのため、全体的にアニメーションが何倍も重いです。
 大量生成系のテンプレートをそのまま使用すると、よほどPCスペックが高くない限り処理落ちします。その場合、無理に当プラグインを使うよりも、最初からEffekseer側で編集したほうがよいかもしれません。

 旧来のMV用アニメーションにも対応(詳細)しているため、そちらを使う方法もあります。
 Effekseer側に対応を頂いた結果、大幅(4〜5倍程度)に軽くなった模様です。十分実用に耐えられるようになったのでご検討ください。(2021/02/14)
 https://github.com/effekseer/EffekseerForRPGMakerMZ_Ex

終了フレームが不確定に

 Effekseerのエフェクトは終了時間が一定ではありません。それにより、プラグイン側で終了フレームを予測するのが困難となりました。
 そのため、DynamicAnimationMZでは最後に設定されたフラッシュや効果音の設定位置を、終了フレームの代わりに使用している箇所があります。
 具体的にはshot型テンプレートで対象に到達するタイミングなどです。

パラメータの3D化

 3D化により、拡大率が『scaleX』『scaleY』『scaleZ』の3通りに分割されました。
 MV版では『scaleX』で横幅、『scaleY』で縦幅が変更されましたが、挙動が変わります。
 ※Effekseerへパラメータを渡しているだけなので、作者もよく分かりません。
 単純に全体を拡大したい場合は『scale』の値を変更すれば反映されます。

 また、回転率についても『rotationX』『rotationY』『rotationZ』の3通りに別れています。
 こちらも無印の『rotation』を使えば、MVと同じ用に時計回りに回転します。ただし、MVとはやはり挙動が異なるらしく、想定通りに動かない箇所がいくつかありました。
 『ビーム(beam)』および『拡散ビーム(diffusionBeam)』のテンプレートは思ったように動きませんでした。

1フレームの単位

 アニメーションのフレームが、MZでは1/60秒単位に変更されました。これはMVの4倍速となります。

 ただし、DynamicAnimationMZの初期状態では、4/60秒単位で処理を行っています。そのため、MVの記述をそのまま持ってきてもタイミングは保たれます。
 具体的には『frame』『interval』『motionFrame』『wait』『delay』『arrival』『nextDelay』『afterimageInterval』などの値が対象です。

 もし、変更したい場合は、プラグインパラメータにある『計算レート』の値を『1』に変えてください。
 あるいは個別に『rate』の値を変更することも可能です。

無効となる項目

 『透明度(opacity)』『描画レート(rate)』『色調(color)』の項目がそれぞれ無効となります。Effekseer側で変更を受け付けないっぽいです。(たぶん……)

競合について


 現在『VisuStella BatttleCore』と併用すると挙動がおかしくなることを確認しています。
 しかしながら、あちらのソースが難読化されていることもあり、対応は無理ゲーです。

 モーション系はDynamicMotionを使うか、VisuStella系でプラグインを統一するかを選んだほうがよいと思われます。

 >RPGツクールMZ&MV目次に戻る
posted by 砂川赳 at 08:33 | RPGツクールMZ&MV | このブログの読者になる | 更新情報をチェックする

【RPG制作講座】アイテム合成システムの考察

2023年10月14日

 アイテム合成システムとは、複数のアイテムを組み合わせることで新たなアイテムを生み出すシステムである。
 ドラクエシリーズやアトリエシリーズなどが有名。
 『錬金』『鍛冶』『調合』『料理』『交換』など作品によって呼称が変わるが、基本的には似たようなものとなっている。


※参考:ドラゴンクエストヒーローズの錬金釜

 合成は多くの作品で採用されているが、なかなか難しいシステムだ。
 プレイヤーに要求する手順も多い上に、開発者側に要求される作業量もそれなりに多い。

 そんな合成システムについて、考察してみたい。

目次


合成システムの特徴

合成物

レシピ

性能の変化

合成システムのメリット

ゲーム性の強化

アイテムに意味を持たせる

アイテムの入手を細分化

世界設定の補強

合成システムのデメリット

手順が増える

不親切

アイテム数が増加する

売却が困難となる

素材アイテムのご褒美としての弱さ

バランス調整が困難

古典的システムとの競合

デメリットへの対策

素材アイテムを限定する

合成のルールを単純化する

素材の種類を絞る

アイテム入手時に説明を表示

図鑑でフォロー

素材毎に合成できるアイテムを明示

素材の売却で合成

金欠にする

合成に特化

合成できる種別を限定する

まとめ


合成システムの特徴


 一口に合成システムといっても、作品によって細部は異なっている。
 実際には以下のような要素によって、差別化される。

合成物

 何を素材として、何を合成するか。
 主に装備を中心としたアイテムが合成の生成物になることが多いが、料理なども仕組みはほぼ同じである。

 また、アイテムという枠にはこだわらず、それ以外にも応用可能である。
 例えば、スキルの合成のようなシステムを作成してもよいし、動物やモンスターの配合なども一種の合成といってよいだろう。

レシピ

 レシピ――つまり、合成するアイテムの組み合わせである。例えば、以下のようなパターンに分類される。

  • 店や宝箱、本棚などからレシピを入手するパターン。
    比較的オーソドックスなパターン。仕様上、取り逃しが発生しやすい。
  • 店毎に定められた選択肢で合成できるパターン。
    自由度は下がるが、取り逃しは発生しづらい。
  • 元になる素材があれば、進化先の候補が表示されるパターン。
    例えば、銅の剣を所持していた場合、「銅の剣と鉄鉱石を組み合わせると鉄の剣を合成できる」ようになる。
  • レシピは存在せず、何でも合成できるパターン。
    自由度は非常に高いが、ハズレアイテムも発生しやすい。また、制作者の想定以上に序盤から強力なアイテムが作成できてしまうこともある。

 以降では、どちらかというとレシピが存在するタイプを念頭に置いている。

性能の変化

 同じ生成物であっても、素材や合成する方法によって性能に変化がつく。
 例えば、ドラクエ11の鍛冶ならば『銅のつるぎ+2』というように強化される。
 アトリエシリーズはさらに複雑で、同じアイテムであってもほとんど別物のような性能に変化してしまうことすらある。

 同じアイテムを+1、+2……というように重ねて強化できる場合もある。

合成システムのメリット


 では、どういった狙いがあってゲーム制作者は合成システムを採用するのだろうか?
 そのメリットをまとめてみたい。

ゲーム性の強化

 いかにして強力なアイテムの合成を行うかをプレイヤーに考えさせることによって、ゲーム性を高める。

 目当ての素材が手に入るエリアを探索したり、素材を落とす敵を優先的に狩るといった戦略性が発生する。

 作品によっては、合成したアイテムをさらに新たな合成の素材にすることで、より強力なアイテムを作り出すなんてこともできたりする。
 場合によっては、序盤から強力な装備を作成できるなど自由度の高いゲームプレイが可能になる。

アイテムに意味を持たせられる

 一見して不要なアイテムが重要な素材になったりと、幅を持たせられる。
 これにより、アイテム収集を楽しくする効果がある。

アイテムの入手を細分化できる

 ダンジョンやフィールドの広い空間に何も置かないのは寂しい。あるいは大量に用意したクエストに報酬を用意したい。
 とはいえ、安易に強力なアイテムを放出してしまうと、すぐにインフレしてバランスが崩れてしまう。
 というわけで、アイテムを素材に分割して配置することで、プレイヤーに対する報酬をほどほどにコントロールできる。

 オープンワールドやダンジョンRPGなどの探索を重視する作品、あるいはネトゲやソシャゲなどプレイヤーを長く引き留めたい作品において、相性が良い方法だ。
 近年の作品では頻繁に採用されるので、プレイヤーとして経験があるという人も多いのではないだろうか?

 ぶっちゃけ水増しと言えば水増しである。

世界設定の補強

 作品の世界設定によっては「商人が強力なアイテムを販売する」という状況自体が不自然に感じられる場合もある。
 現代日本を舞台にした作品において、普通の店で魔法の剣を購入できたら違和感があるというわけだ。

 例えば、ペルソナシリーズでは異世界の敵から獲得したアイテムを素材とすることで、現実ではあり得ないような装備を作成しているという設定がある。

合成システムのデメリット


 冒頭で『なかなか難しいシステム』と表現したように、合成システムは扱いの難しいシステムである。
 実際のところ、個人的にはかなりデメリットも多いシステムだと感じているので、その点をまとめてみた。

手順が増える

 合成というシステムは必要な手順が多い。
 例えば、一例を挙げてみよう。

  • 宝箱や店からレシピを入手&購入。
  • レシピを参照し、必要な素材とその所在を確認。
  • 素材を捜索&入手。
  • 合成屋に戻って合成開始。
  • 合成時のミニゲームによって完成度が変化。

 ……というように、なかなか大変である。
 これは比較的、手間のかかる仕組みを想定した場合だ。例えば、どこでも合成を実行できる作品ならば、もう少し手順は緩和される。
 いずれにせよ、お金を貯めて買うだけの古典的な店よりも手間がかかるのは間違いない。

不親切

 合成をしようにも素材の入手先が分からないと「どこで手に入るのかも分からないアイテムを探す作業」になってしまいがち。
 勘や総当たりで探し回るか、攻略を見るか、あるいは成り行きに任せて見つからないなら諦めるしかない。
 このままでは、プレイヤーがシステムを活かすことは難しく、あまりゲーム性も高いとは言えなさそうだ。

 もし、そうならないようにしたいなら、ヒントを出す必要があるが、プレイヤーにとってはそういった情報を確認する手順がさらに増える。

 あるいは、ゲーム進行に応じて、自然と素材が集まるようにすれば手間は削減できる。
 ……が、根本的なことを言うと、それならばこんな手間のかかるシステムを採用する必要性は低い。普通の店――つまり「お金を貯めれば、良いアイテムを買えるシステム」を採用したほうが、手っ取り早い。

 ……と、なってしまうので、やはりプレイヤーに対して、多少の不便や面倒は許容してもらうしかない。その上で、ゲーム性を高める目的で合成システムを採用すべきだとは思う。

アイテム数が増加する

 合成には素材となるアイテムが必要となる。
 必然的にアイテム数が増加し、アイテム一覧が複雑化する。

 プレイヤー視点ではアイテムの管理が大変になり、作品の快適性を落とすことになる。
 制作者視点でも、もちろんデータ設定の手間が増える。

売却が困難となる

 合成システムの存在するゲームにおいては、一見して役に立たないアイテムが思わぬ合成の材料となることがある。
 システムの奥深さを高める効果があるが、一方で不用品の判別が困難になるということでもある。
 つまり、迂闊に不用品を売却できなくなるということだ。

 昔、初期装備の木刀を売り払うと最強武器が手に入らなくなるマイナーRPGがあったが、こういった問題が起こりやすくなる。

 上記の「アイテム数が増加する」と合わさって、さらにアイテム一覧が複雑化してしまう。

素材アイテムのご褒美としての弱さ

 素材アイテムはご褒美としての機能が弱い。

 なぜなら、素材アイテムは単体では機能しないため、入手直後のプレイヤーにとっては「何かよく分からないアイテム」であるためだ。
 そのため、プレイヤーの印象には残りにくい。

 古典的な宝箱から直接装備を手に入れる方式なら、手に入れた瞬間に有用であることが分かる。ご褒美としては非常に分かりやすい。

 お金を貯めて装備を買う方式なら、努力の蓄積が明確に反映されるのが利点だ。ドラクエでコツコツお金を貯めて鋼の剣を買った時は嬉しいもの。
 計画を立てて、それを達成するというのはそれ自体、ゲーム性の高い仕組みなのだ。プレイヤーにとって印象に残りやすい。

 対して、合成システムでは「いつの間にか溜まっていた素材でいつの間にか合成できるようになっていた」みたいなケースはとてもありがち。
 合成システムの存在する作品では、アイテムの入手量自体も増大する傾向にあるので、一つ一つのアイテムの印象も薄くなりやすい。
 わざわざ手間をかけたのに、古典的システムより印象で劣ってしまう――なんてことにもなりかねない。

 なお、他のご褒美の手段としては宝箱にレシピを入れる方法もある。
 レシピなら合成先のアイテムが想像しやすいという利点もある。
 ただし、この場合も即座にアイテムが手に入るわけではないので、やはり古典的方式よりもご褒美としては弱い。

バランス調整が困難

 プレイスタイルによる装備の差は古典的なRPGより大きくなるため、バランス調整の難易度も上昇する。

 序盤から強力な武器を作られてしまった結果、制作者の想定よりもずっと難易度が下がってしまうなんてこともあり得る。
 レシピなどの要素で縛ることで一定の対処はできるが、今度は逆に自由度は下がってしまう。

 一方でプレイヤーがレシピや素材を見つけ出せなかった結果、想定よりも難易度が上がってしまう場合もある。
 DQ10オフラインでは装備のレシピの場所が非常に分かりづらく、中盤の装備のままラスボスと戦うプレイヤーが続出した。

 ……というように、合成とはとにかく手順が多いシステムなので、プレイヤーが『何か』を見落とす可能性は高い。

 アトリエシリーズなんかは典型だけど、複雑な合成システムを使いこなせるかで、体感の難易度が大きく変わる。そのため、同じ作品に対して『簡単』というプレイヤーと『難しい』というプレイヤーが入り混じっていたりする。

 全体的な傾向として、合成システムは『二周目以降のプレイヤー』や『攻略情報を見ながらプレイするプレイヤー』『丹念に探索やシステムの活用を行うプレイヤー』にとって有利なシステムと言えそうだ。
 逆に言うと、攻略を見ずにさっさと進めたいというプレイヤーとはあまり相性がよくない。

古典的システムとの競合

 既に何度か触れたが「お金を払えば装備を買える店」や「装備が手に入る宝箱」といった古典的システムとの併用はどうするか?

 店や宝箱から十分なアイテムが手に入るなら、合成システムはそもそも不要である。

 せっかく手間をかけて装備を合成しても、すぐ次の町やダンジョンでより強力な装備が簡単に手に入るならガッカリしてしまうだろう。
 店や宝箱の品質を落とすのが無難なところだが、それらの喜びは必然的に弱くなる。

デメリットへの対策


 以上、合成システムのデメリットを多数紹介した。
 そこで次は、どうにかデメリットを軽減して、合成システムを活かすための対策案を考えてみたい。

 ※同時にメリットを削ぐようなものも多いので、取捨判断はお任せします。全てを取り入れればよいというものではないです。

素材アイテムを限定する

 「装備品は合成には使えない。あくまで合成は素材専用アイテムでのみ行う」「素材専用アイテムは別のカテゴリに表示される」といったルールを付ける。

 これによって、アイテム一覧が複雑化することを防ぐ。これなら、不用品の売却もやりやすくなる。
 一方で「一見、役に立たない弱い武器が強力な武器の材料に!」というような意外性はなくなるため、システムとしての幅は狭まってしまう。

合成のルールを単純化する

 例えば「ミスリルがあればミスリルソードやミスリルスピア、ミスリルメイルを作れる」というようにルールを単純化する。
 これなら非常に分かりやすい。プレイヤーにとっても「素材の入手は装備の入手に等しい」ということが直感的に伝わるはずだ。
 ※素材が単一のものを合成といってよいかは置いておきます。

 この手法はプレイヤーが使用している武器の種類が不明な場合にも有効だ。「斧を手に入れたけど、斧使いが誰もいない」なんて悲劇を防げる。

素材の種類を絞る

 上の延長線上の発想だが、思い切って素材の種類を厳選してしまおう。

  • 鉄鉱石5個で鉄の剣を合成
  • 鉄鉱石10個で鉄の鎧を合成
  • 炎の魔石10個で火炎の魔導書を合成
  • 炎の魔石50個で灼熱の魔導書を合成
  • 鉄鉱石5個と炎の魔石5個で炎の剣を合成

     というように、素材を厳選すればプレイヤーも素材の種類を覚えやすい。
     このような調整にすると、素材は一種の通貨のように機能する。

    アイテム入手時に説明を表示

     アイテム入手時にその名称だけを表示されても、プレイヤーには何か分からないことが多い。特に素材アイテムの数が多くなってくると、アイテム一つ辺りの入手が軽くなりがち。

     そこで、アイテム入手時に同時に説明を表示することで「いつの間にか貴重な素材を入手していた」という状況をなくす。
     その際、レアリティなどを表示すると分かりやすいかもしれない。

     ちなみに、ブレスオブザワイルドでは初出のアイテムのみ、説明を表示するような仕組みになっている。

    図鑑でフォロー

     アイテム図鑑でアイテムの入手場所を表示したり、魔物図鑑で敵のドロップアイテムを表示する。これによって、プレイヤーが戦略的にアイテム収集&合成をできるようにする。

     当然ながら、実装の手間もそれなりに大きいし、プレイヤーにとっても確認する手間が発生する。
     例えば、魔物図鑑を開き、百種類を超える敵のドロップアイテムを一つ一つ確認していくような作業は、かなりの手間を伴うはずだ。

     ならば――と、アイテム図鑑にドロップする敵を記載したり、検索機能を設ける方法もあるが、実装工数はさらに増えていく。

    素材毎に合成できるアイテムを明示する

     素材アイテムにカーソルを合わせた際などに、そこから合成できるアイテムを表示する。作成したことのないアイテムは????表示にしてもよいだろう。

     これならば、不用品かそうでないかも区別できるので売却もしやすい。
     例によって、実装工数は増える。

    素材の売却で合成

     ペルソナシリーズでは「素材を店に売却することで、それを材料とした装備が店頭に並ぶ」というシステムを採用している。
     ※正確には覚えてませんが、ペルソナ4だけのシステムかも……。
     このシステムでは素材アイテムを手元に残すメリットは全くない。従って、売却も一括でできるようになっている。

     この方法なら素材アイテムを管理する手間が大幅に削減できる上に、アイテムを組み合わせるという合成システムの味も残せている。
     筆者自身、この記事を書くまではあまり意識してなかったけれど、上述した『世界設定の補強』と合わせてなかなか秀逸なシステムだと思う。

     ただし、素材を売却できる店を制限するなどしないと不自然になるかも。例えば、ペルソナ4では武器屋でのみ素材を売却できるようになっている。

    金欠にする

     ゲームバランスを調整し、金欠気味にしておく。
     合成をした場合は、少ない価格でアイテムが手に入るようにする。これにより、店よりもコスパが良いというメリットを与える。

     ドラクエシリーズがよくやっている調整である。

    合成に特化

     装備品など多くのアイテムは基本的に店や宝箱では扱わない。あるいは露骨に性能の低いアイテムのみを販売し、あくまで合成で作るように誘導する。
     これによって、既存システムとの差別化を図る。

     アトリエシリーズがこの調整に近いだろうか。

    合成できる種別を限定する

     例えば、武器や防具は店や宝箱から普通に手に入るが、装飾品は合成でしか作れないようにしてしまう。
     この方法ならば、既存システムとの差別化も自然とできる。

    まとめ


     重ねて述べたように合成システムは扱いの難しいシステムである。
     ……にも関わらず、ここ10〜20年ではかなりの流行をしており、今や大手メーカーのRPGでは採用していないほうが珍しいぐらいだと感じている。

     しかしながら、個人的な意見を言うと、無闇に採用され過ぎではないかとすら思っている。
     例えば、最近プレイしたRPGで「クリアに数十分かかるクエストの報酬が用途のよく分からない素材アイテムだけだった」なんて経験があった。
     これが昔のRPGだったなら、ごく単純に装備品がそのまま報酬になっていたと思う。

     上の例は普通のオフラインRPGなので、そのような仕組みにする意味もあまりないように感じた。システムの複雑化と水増しによって、かえって面白みを失っていないだろうか。

     ……そんなわけで、近年のRPGが必要以上に複雑化&薄味化している要因になっているとも感じるので、採用するにしてもよく考えておきたい。
     例えば、ストーリー重視でサクサク進めて欲しいという作品に、やたら凝りまくった合成システムを採用するのは考えものだろう。
     どちらかというと、システム重視の作品に向いていると思う。

     プレイヤーへの負担を考えても、他のシステムとのバランスも考慮したい。
     例えば、複雑なスキル習得システムを備えた作品に対して、同じく複雑な合成システムを加えると、一層プレイヤーの手間が増えてしまう。
     面倒なシステムになっていると感じたならば、削るべき部分を削ってプレイヤーの負担を抑えるのも一つの選択だ。

     開発効率の面でも、システム実装やバランス調整の工数が大きく増加するので、なかなか大変である。
     メインのシステムとしてガッツリ作るか、あくまでサブのシステムとして簡略化して作るか、方針はしっかり決めておいたほうがよいと思う。

    >RPG制作講座目次に戻る
  • posted by 砂川赳 at 16:09 | RPG制作講座 | このブログの読者になる | 更新情報をチェックする