装備スロットを自由に変更【RPGツクールMZ&MVプラグイン】

2023年12月31日

 装備スロットを自由に変更します。


 標準では装備タイプとアクターの装備スロットは1対1ですが、自由に変更できるようにします。
 例えば、装飾品を複数装備できるようになります。

 さらにはアクター、職業、武器、防具、ステート、スキル毎に、装備スロットを追加する設定が可能です。
 具体的には以下のようなシステムを実現できます。

  • 装備毎に装飾品スロットを追加する。(いわゆるマテリア)
  • 魔道士のみが魔道書を複数装備できる。
  • 習得すると装備スロットが増えるパッシブスキル。

 ※ミスティックスターで採用している装備や魔珠のスロット追加機能をプラグイン化したものです。その他にも色々と応用が考えられます。

 ※なお、装飾品などを複数装備可能にした場合、店画面の表示に違和感が出てしまいます。その場合は、店画面をカスタマイズするプラグインをオススメします。

目次


導入方法(Install)

更新履歴(History)

使用方法(Usage)

同一系統の装備を禁止(Equip Unique)

別ページに表示(Another Page)

プラグインパラメータ(Plugin Parameters)

初期スロット構成(DefaultEquipSlots)

初期装備を自動調整(AdjustInitEquip)

二刀流の位置(DualWieldPosition)

ページ切替する装備タイプ(PagingEquipmentType)

[MZ]ステータスの表示スロット(StatusShowSlots)

同一防具タイプの装備禁止(ArmorTypeUnique)

謝辞(Acknowledgements)


導入方法(install)


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

 NRP_EquipSlot.js ver1.09(2023/12/31)

更新履歴(History)


2023/12/31(ver1.09)

  • スロット数が減少する場合に外れる装備が増殖してしまう不具合修正。

2023/10/30 -> 2023/10/31(ver1.08 -> 1.081)


2023/08/09 -> 2023/09/26(ver1.07 -> 1.071)

  • 途中のスロットが増加した際、下の装備品の位置がズレる不具合修正。
  • スロット数を増加させる装備をした状態で、最強装備を行うとエラーになる不具合修正。(2023/09/26 ver1.071)

2023/05/31 -> 2023/07/25(ver1.06 -> 1.061)

  • 『ページ切替する装備タイプ』に該当するスロットが歯抜けになっていた場合も、次の装備タイプでページ切替するように修正。
  • ステータスの表示スロットがMVでは機能しないので注記を追加。エラーが出ないように調整。(2023/07/25 ver1.061)

2023/02/12(ver1.05)

  • スロット数変更時に装備品の位置がズレる不具合修正。

2023/01/12(ver1.04)

  • 別ページに表示機能の不具合を色々と修正。

2022/08/26(ver1.03)


2022/07/16(ver1.02)


2022/07/11(ver1.01)


2022/07/09(ver1.00)

  • 公開!

使用方法(Usage)


 以下をアクター、職業、武器、防具、ステート、スキルのいずれかのメモ欄に記入してください。
<AddEquipSlot:[装備タイプ]>

 指定した装備タイプのスロットが追加されます。
 例えば『05:装飾品』ならば<AddEquipSlot:5>です。

 さらにカンマ区切りで数値を追加すれば、スロット数を指定できます。
<AddEquipSlot:5, 2>

 これで装飾品のスロットが2つ追加されます。
 ※スロット数はマイナスも可能です。
  ただし、プラスとマイナスを組み合わせた場合の挙動は保証しません。


 複数の装備タイプを追加したい場合は以下のように記述できます。
<AddEquipSlot:5, 2>
<AddEquipSlot2:6, 2>
<AddEquipSlot3:7>

 ※無印, 2, 3の順序であることにご注意ください。

 なお、スロット構造を変更した場合、イベントコマンドの装備の変更ではうまく対応できない場面があると思います。その場合は装備変更プラグイン(ver1.02〜)をご利用ください。

同一系統の装備を禁止(Equip Unique)


 装備の系統名を指定します。

<EquipUnique:[系統名]>


 これにより、同じ系統の装備を同時に装備できなくなります。
 この系統名は『防具タイプ』や『装備タイプ』とは無関係です。
 例えば、全ての防具を装飾品のように自由に装備できる作品において、頭防具(帽子と兜)のように重複して装備すると違和感がある組み合わせを禁止できます。

 その場合は、全ての頭防具のメモ欄に同じ系統名を設定してください。

別ページに表示(Another Page)


 装備画面を複数のページに分割することが可能です。
 例えば、着脱可能なスキルシステムを当プラグインで実現する場合など、通常の装備とは別ページにすると分かりやすいです。


手順

 『ページ切替する装備タイプ』に装備タイプを数値で設定してください。
 5を指定した場合、5以降の装備タイプが別ページに表示されます。

 「4,6」というように複数指定も可能です。
 この場合「1~3」「4~5」「6~」の3ページに装備タイプが分かれます。

 なお、ページは左右で切り替えできます。
 マウス操作ではホイールで切り替えできます。
 ※ただし、スクロールはできなくなるため、一画面に収まるようにしてください。

 ただし、標準ではプレイヤーが気づきにくいかもしれません。
 また、MVでは少し表示が怪しいです。

 ウィンドウをページ化するプラグイン(NRP_PageWindow.js)と組み合わせれば、切替記号を表示することも可能です。

プラグインパラメータ(Plugin Parameters)


初期スロット構成(DefaultEquipSlots)

 装備スロット(装備タイプ)の初期構成です。
 同じ番号を複数指定すれば重複装備も可能です。
 例えば[1,2,3,4,5,5,5]ならば、『05:装飾品』を三つまで装備できるようになります。

 空欄の場合はツクールのデフォルトになります。

初期装備を自動調整(AdjustInitEquip)

 装備タイプと初期スロット構成の順序が不一致な場合、初期装備が有効にならない問題に対処します。

二刀流の位置(DualWieldPosition)

 二刀流の際に武器を装備する位置です。
 標準では二番目になります。

 なお、『初期装備を自動調整』がオフの場合は変更が機能しませんので注意。あまり変更することはないと思いますが……。

ページ切替する装備タイプ(PagingEquipmentType)

 指定の装備タイプ以降を別ページに表示します。
 複数指定可能です。(例:4,6)

[MZ]ステータスの表示スロット(StatusShowSlots)

 ステータス画面に表示する装備スロット(装備タイプ)です。
 空白時はウィンドウに収まるまで全表示します。
 ※この機能はMVでは動作しません。

同一防具タイプの装備禁止(ArmorTypeUnique)

 防具タイプが同じ装備を複数装備できなくします。

謝辞(Acknowledgements)


 このプラグインの作成に当たり、以下のプラグインを参考にさせて頂きました。
 
EquipSlotAddTrait.js(装備スロット追加特徴)(Yana様)

 https://w.atwiki.jp/pokotan/pages/3.html

 また、パッシブスキル機能についてはプラカヴィ様よりアドバイスを頂きました。

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

リスト形式のスキル習得システム【RPGツクールMZプラグイン】

2023年12月11日

 リスト形式のスキル習得システムを実装します。


 獲得したスキルポイントを消費し、表から覚えたいスキルを選択するシンプルな仕組みです。

 スキルポイントは敵から入手したり、レベルアップ時に入手したりといった方法を選択できます。


 あまり複雑な機能はありませんが、工夫次第では擬似的なスキルツリーなども作成できます。

目次


導入方法(Install)

更新履歴(History)

スキルリストの作成

スキルポイントの設定

敵キャラのメモ欄

アイテムのメモ欄

スキルツリー

おすすめプラグイン

プラグインコマンド(Plugin Commands)

シーン開始(SceneStart)

スキルポイントの増減(ChangeSkillPoint)

スキルリセット(ResetSkill)

プラグインパラメータ(Plugin Parameters)

スキルセットのリスト(SkillSetList)

<スキルポイント>(<SkillPoint>)

スキルポイントの表示名(SkillPointName)
スキルポイントの最大値(MaxSkillPoint)
スキルポイントの保有方法(SkillPointType)
スキルポイントの変数(SkillPointVariable)
スキルポイント獲得文(SkillPointMessage)
敵スキルポイントの既定値(DefaultEnemySkillPoint)
SP有効化スイッチ(SkillPointSwitch)
控えの獲得率(BenchSkillPointRate)
レベルアップ時のSP(LevelUpSkillPoint)
<スキルリスト関連>(<SkillListWindow>)

習得済スキルの表示方法(LearnedSkillDisplayStyle)
アイコンを表示(UseIcon)
スキルポイントの色(SkillPointColor)
習得済の表示文(LearnedText)
習得済の色(LearnedTextColor)
隠しスキルを表示(ShowHiddenSkills)
隠しスキルの記号(HiddenSymbol)
ヘルプの行数(HelpLines)
隠しスキルのマスク(HiddenSkillMask)
ヘルプを隠す(HiddenHelp)
<アクターウィンドウ関連>(<ActorWindow>)

アクターウィンドウの横幅(ActorWindowWidth)
アクターウィンドウの縦幅(ActorWindowHeight)
アクターの変更無効(ActorChangeInvalid)
<確認ウィンドウ関連>(<ConfirmWindow>)

確認メッセージ(ConfirmMessage)
OKの文言(ConfirmButtonOk)
キャンセルの文言(ConfirmButtonCancel)
確定時のSE(ConfirmOkSe)
<メニューコマンド関連>(<Menu Command>)

メニューコマンド挿入位置(ShowMenuCommandPosition)
メニュー表示名(CommandName)
表示許可するスイッチ(MenuCommandSwitch)
マスク文字列(MaskString)
禁止するスイッチ(DisableSwitch)

スキルセットのパラメータ(Plugin Parameters SkillSet)

メモ(Note)

スキルリスト(SkillList)

<条件>(<Condition>)

アクター(Actor)
スイッチ(Switch)
スクリプト(Script)

スキルデータのパラメータ(Plugin Parameters SkillData)

メモ(Note)

スキル(Skill)

スキルポイント(SkillPoint)

表示名(DisplayName)

ヘルプに追記(HelpPostscript)

習得済スキルの表示方法(LearnedSkillDisplayStyle)

<条件>(<Condition>)

スキル(ConditionSkill)
スイッチ(Switch)
スクリプト(Script)

導入方法(install)


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

 NRP_LearnSkillList.js ver1.05(2023/12/11)

更新履歴(History)


2023/12/11(ver1.05)

  • プラグインコマンドでアクターを指定した場合にアクターの切り替えを禁止できるようにした。
  • プラグインコマンドでパーティにいないアクターも指定できるようにした。

2023/10/04(ver1.04)


2023/08/06(ver1.03)


2023/06/19 -> 2023/06/25(ver1.02 -> 1.021)

  • スキルポイントの保有方法がパーティ共有制の場合、エラーになる不具合修正。
  • スキルポイントを減らした場合、マイナスにならないように修正。(2023/06/25 ver1.021)

2023/05/01 -> 2023/05/03(ver1.01 -> 1.012)

  • スキルポイントの最大値を設定できるようにした。
  • スキルポイントの保有方法が『パーティ共有』の場合、スキルポイントの増減を行うとエラーになる不具合修正。
  • アクターのスキルポイントを0で初期化するように修正。
    (2023/05/03 ver1.012)

2023/04/23 -> 2023/04/30(ver1.00 -> 1.001)

  • 公開!
  • 『スキルポイントの表示名』が反映されない不具合修正。
    (2023/04/30 ver1.001)

スキルリストの作成


 まずプラグインパラメータの『スキルセットのリスト』にスキルセットを登録し、その下へさらにスキル情報を登録してください。

 スキルセットには対象とするアクターなどの条件を指定できます。
 条件を指定しなかった場合は全員共通のスキルとなります。

 他にも、スキル毎に前提スキルなどの条件を指定できます。

 メニューから『スキル習得』のコマンドを選択すれば、スキル習得システムの画面が表示されるようになります。

スキルポイントの設定


 スキルポイントの保有方法として『アクター毎』と『パーティ共有』の二種類から選択できます。
 パーティ共有の場合は変数内に格納するため、イベントコマンドの『変数の操作』での制御が可能となります。

敵キャラのメモ欄


<SkillPoint:?>

 獲得できるスキルポイントを指定します。

 また、プラグインパラメータで既定値を指定することもできます。
 細かい指定が面倒なら、経験値やレベルに比例する値にしてしまえば楽です。

 ※標準では敵キャラにレベルは存在しません。何らかの外部プラグインで設定する必要があります。

<SkillPointRate:?>

 獲得できるスキルポイントを指定した%に変更します。
 例えば、200ならば200%(2倍)になります。
 既定値とのセットで使うことを想定しています。

アイテムのメモ欄


<AddSkillPoint:?>

 アクターのスキルポイントを数値分増加させます。

スキルツリー


 当プラグインにはスキルツリーなどの複雑な構造を作成する機能はありません。
 ……が、擬似的にスキルツリーっぽく見せることはできます。


 やり方は単純で『スキルデータのパラメータ』の表示名に手入力で全角スペースと記号を入れているだけです。
 画像の例だと『 └%2%1』というようになります。
 ※%2はアイコン、%1はスキル名です。

 あくまで簡易的なものなので、複数のスキルを条件とする場合など複雑な設定には向きません。

 ※条件を満たしていないスキルを表示させたい場合は隠しスキルを表示をオンにしてください。

おすすめプラグイン


上位スキル習得時に下位スキルを消去

 無駄にスキルを増やしたくない場合は便利です。

 ただし、初期スキルの条件の指定には工夫が必要です。
 スクリプトで『!a.isLearnedSkill(1) && !a.isLearnedSkill(2)』というように「上位スキル全ての未習得」を条件にしないと下位スキルが一覧に復活してしまいます。
 つまり、「ヒールUとVの両方を習得していない場合のみ、ヒールTを習得できる」というようなイメージです。

スキルの性能を変化させる

 パッシブスキルの作成などにどうぞ。

プラグインコマンド(Plugin Commands)


シーン開始(SceneStart)

 スキル習得画面を呼び出します。
 アクターを指定しない場合は、アクター選択画面も表示します。

スキルポイントの増減(ChangeSkillPoint)

 アクターのスキルポイントを増減させます。
 なお、0未満にはなりません。

スキルリセット(ResetSkill)

 習得したスキルを全て忘れて、スキルポイントを元に戻します。
 あまりないと思いますが、当機能で習得できるスキルと同一のスキルをアクターが他の手段で覚えていた場合、そちらもリセットされてしまいます。

プラグインパラメータ(Plugin Parameters)


スキルセットのリスト(SkillSetList)

 習得するスキルセットを定義します。
 詳細は『スキルセットのプラグインパラメータ』をご覧ください。

<スキルポイント>(<SkillPoint>)

 スキルポイントに関する項目です。

スキルポイントの表示名(SkillPointName)

 スキルポイントを表す表示名です。

スキルポイントの最大値(MaxSkillPoint)

 スキルポイントの最大値です。
 これ以上の値にはなりません。

スキルポイントの保有方法(SkillPointType)

 スキルポイントの保有方法です。
 アクター毎かパーティ共有かを選択できます。

スキルポイントの変数(SkillPointVariable)

 スキルポイントを格納する変数です。
 保有方法にパーティ共有を選んだ場合のみ有効です。

スキルポイント獲得文(SkillPointMessage)

 スキルポイントの獲得文を表示します。
 %1=数値, %2=スキルポイントの表示名となります。

敵スキルポイントの既定値(DefaultEnemySkillPoint)

 敵が落とすスキルポイントの既定値を設定します。
 数式可。
 例えば、『1 + Math.floor(a.exp() / 100)』ならば、1+経験値÷100(切捨)の値をスキルポイントにします。

SP有効化スイッチ(SkillPointSwitch)

 指定のスイッチがオンの際、スキルポイントの増減を有効化します。
 空白なら常に有効。

控えの獲得率(BenchSkillPointRate)

 控えメンバーのスキルポイントの獲得率です。
 数式可。
 空白の場合は通常経験値と同率を使用します。

レベルアップ時のSP(LevelUpSkillPoint)

 レベルアップ時に獲得できるスキルポイントです。
 数式可。
 例えば、『a.level』ならば上昇後のレベルと同値のスキルポイントが手に入ります。

<スキルリスト関連>(<SkillListWindow>)

 スキルリストウィンドウに関する項目です。

習得済スキルの表示方法(LearnedSkillDisplayStyle)

 習得したスキルの表示方法です。

アイコンを表示(UseIcon)

 アイコンをスキル名の前に表示するかどうか?

スキルポイントの色(SkillPointColor)

 スキルポイントの文字色です。
 システムカラーの番号を指定してください。

習得済の表示文(LearnedText)

 習得済スキルに表示する文言です。
 スキルポイントの場所に表示されます。

習得済の色(LearnedTextColor)

 習得済スキルに表示する文言の色です。
 システムカラーの番号を指定してください。

隠しスキルを表示(ShowHiddenSkills)

 条件を満たしていないスキルを表示します。
 条件表示する場合はヘルプの行数は3以上に。

隠しスキルの記号(HiddenSymbol)

 隠しスキルに表示する記号です。
 スキルポイントの左に記号を表示することで「他に条件があるから、ポイントが足りていても習得できないよ!」ということを示します。

 条件についてはヘルプに追記のところで入力してください。

ヘルプの行数(HelpLines)

 ヘルプの行数を変更します。
 基本的には、行を3以上に増やすことで隠しスキルの条件表示を行うことを想定しています。

隠しスキルのマスク(HiddenSkillMask)

 隠しスキルを指定した文字列(?など)で隠します。
 条件を満たすと表示されるようになります。

ヘルプを隠す(HiddenHelp)

 隠しスキルのヘルプ(追記除く)を隠します。
 条件を満たすと表示されるようになります。

<アクターウィンドウ関連>(<ActorWindow>)

 アクターウィンドウに関する項目です。

アクターウィンドウの横幅(ActorWindowWidth)

 アクターウィンドウの横幅です。

アクターウィンドウの縦幅(ActorWindowHeight)

 アクターウィンドウの縦幅です。
 空白の場合は最大まで伸ばします。

アクターの変更無効(ActorChangeInvalid)

 プラグインコマンドにて、アクターを指定して呼び出した場合はアクターの変更を禁止します。

<確認ウィンドウ関連>(<ConfirmWindow>)

 スキルシステムを習得する際の確認ウィンドウに関する項目です。

確認メッセージ(ConfirmMessage)

 スキルの習得確認メッセージの内容です。
 %1=スキル名、%2=アイコン、%3=スキルポイントです。

OKの文言(ConfirmButtonOk)

 スキルの習得確認メッセージを確定する際のボタンの表示です。

キャンセルの文言(ConfirmButtonCancel)

 スキルの習得確認メッセージをキャンセルする際のボタンの表示です。

確定時のSE(ConfirmOkSe)

 スキルの習得を確定した際の効果音です。

<メニューコマンド関連>(<Menu Command>)

 メニューコマンドにスキルシステムを表示する際の関連項目です。

メニューコマンド挿入位置(ShowMenuCommandPosition)

 メニューコマンドにスキル習得を挿入する位置です。
 0が先頭。
 不要ならパラメータの一覧からDELキーで消去してください。

メニュー表示名(CommandName)

 スキルシステムの表示コマンド名を設定します。


 スイッチがオンの時のみコマンドを表示します。
 空白なら常に表示します。

マスク文字列(MaskString)

 表示許可するスイッチがオフの際、指定した文字列でコマンドを表示します。
 例えば、機能を解放する前のコマンドを「????」というように表示できます。

 空欄ならコマンド自体を非表示にします。

禁止するスイッチ(DisableSwitch)

 スイッチがオンの時のみコマンドを禁止(灰色)します。
 空白なら常に許可します。

スキルセットのパラメータ(Plugin Parameters SkillSet)


 スキルセットのプラグインパラメータです。
 スキルセットとはスキルのまとまりです。主にアクター単位でスキルを管理することを想定しています。

メモ(Note)

 識別用のメモです。

スキルリスト(SkillList)

 スキルリストを定義します。
 詳細は『スキルデータのプラグインパラメータ』をご覧ください。

<条件>(<Condition>)

アクター(Actor)

 スキルセットを表示するアクターです。
 空欄なら全員共通になります。

スイッチ(Switch)

 スキルセットを表示する条件となるスイッチです。

スクリプト(Script)

 スキルセットを表示する条件となるスクリプトです。

スキルデータのパラメータ(Plugin Parameters SkillData)


 スキルデータのプラグインパラメータです。
 ここに習得できるスキルの情報を設定してください。

メモ(Note)

 識別用のメモです。

スキル(Skill)

 習得するスキルです。

スキルポイント(SkillPoint)

 習得に必要なスキルポイントです。

表示名(DisplayName)

 習得画面での表示名です。
 %1:スキル名,%2:アイコン。
 空白ならスキル名をそのまま使用します。

ヘルプに追記(HelpPostscript)

 ヘルプに追記する文章です。
 主に習得条件の記述を想定しています。

 必要に応じて『ヘルプの行数』を設定してください。

習得済スキルの表示方法(LearnedSkillDisplayStyle)

 習得したスキルの表示方法です。
 こちらはスキル個別の設定です。
 空欄だと全体設定を適用します。

 普段は『力強化T→力強化U』というように習得したスキルは非表示にして上位スキルを表示。ただし、最高ランクのスキルだけ習得時にCompleteの表示を残すーーというような運用を想定しています。

<条件>(<Condition>)

スキル(ConditionSkill)

 指定のスキルを習得している場合のみスキルを表示します。

スイッチ(Switch)

 スキルを表示する条件となるスイッチです。

スクリプト(Script)

 スキルを表示する条件となるスクリプトです。

 例えば、スキル1とスキル2の両方を覚えている必要がある場合は『a.isLearnedSkill(1) && a.isLearnedSkill(2)』となります。

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

【RPG制作講座】ゲーム性を意識したシナリオ

2023年12月08日

 小説、映画、漫画、アニメ……ストーリー性を持った媒体は様々に存在するが、ゲームもその一つである。
 ゲームにもRPG、シミュレーション、アクション、ADVというように様々なジャンルが存在する。

 シナリオは媒体やジャンルによって、最適なものを書く必要がある。
 というわけで、RPGのゲーム性を意識した上で、どのようなシナリオを書けばよいかを考えてみたい。
 逆に「シナリオを活かすために、どのようなシステムを用意すればいいか」という観点もいくつか書いている。

 筆者は個人制作者なので、もちろんゲームデザイナー兼シナリオライターという立場である。
 現代のプロのゲームクリエイターは専門化されていて、両方に精通している人は希少らしい。なので、両方をやっている人間でしか得られない観点を出せればと思っている。

 そのまま個人制作で活かしてもいいし。ゲームデザイナーとシナリオライターで分業する時の注意点として活かしてもよいかと思う。

 なお、過去にも以下のような記事を書いているが、今回はより詳細に掘り下げている。

媒体としてのRPGを考えてみる

 https://newrpg.seesaa.net/article/367906483.html

目次


仲間の存在

仲間の加入

仲間は徐々に増やす

成長システムとの兼ね合い

仲間の離脱

仲間の人数

かわいい子には旅を

戦闘

ストーリーとゲーム性の一致

ボス戦を意識する

プレイヤーの操作を尊重しよう

イベントバトルの功罪

ストーリー進行

ゲームテンポを殺さない

メッセージ表示は快適に

ダンジョン

町人を活用しよう

仲間との任意会話

自由度

目的は明確に

エンディング

主人公の活躍

無口主人公

主人公の能動性

成功体験


仲間の存在


 RPGのシナリオを考える上で、まず大事なのは仲間の存在である。
 多くのRPGでは主人公は数多くの仲間を引き連れて、冒険することになる。


 仲間はプレイヤーにとって、ゲームシステム上の駒である。だが、そこにストーリー性が紐づけば、仲間は単なる駒を超えた存在にもなる。
 魅力的な仲間達を操作できるということは、RPGの大きな魅力だ。これを活かさない手はない。

仲間の加入

 仲間の加入はストーリー的にもゲーム的にも、大きな見所となる。魅力的なキャラクターが仲間になった時は、プレイヤーにとっても強い喜びとなるはず。
 さらには、加入した仲間が戦闘でも大活躍できる性能だった時は、大いに盛り上がるだろう。

 そんなわけで、ゲーム序盤は仲間の加入イベントを用意するのがセオリーとなる。
 ヒロインとの運命の出会いや、頼りになる相棒との出会いを、華々しく演出しよう。

 活躍機会を与えるためにも、仲間の加入は遅すぎないほうが望ましい。中盤ぐらいまでには、大半のキャラを仲間にできるぐらいが目安だろうか。

 特に注意したいのは序盤の仲間の加入だ。
 多くのRPGでは一人旅を含めた少人数では、取れる戦術が限られてしまう。

 その中でも、回復役がいない状況がずっと続くのは厳しい。回復役は比較的、早めに加入させておこう。ドラクエシリーズのように、主人公にある程度の回復技を覚えさせておくのもセオリーの一つだ。
 なお、ポケモンのように回復技を前提としたゲームバランスになっていない作品はこの限りではない。

 その他の仲間についても、ゲーム性に合わせて調整したい。
 例えば、通常攻撃しかできない少人数の旅がずっと続いてしまうと、プレイヤーも退屈に感じてしまう。早めに魔法など戦術の広がるスキルを持った仲間を加入させてあげよう。

仲間は徐々に増やす

 ならば、冒頭から大勢の仲間を加入させてはどうか?
 ……と、思うかもしれないが、そちらも避けたほうが無難だろう。

 というのも、一人一人に焦点を当てる機会が減るので、プレイヤーがキャラクターを把握しづらくなる。
 また、システム的にもいきなり大勢の仲間を管理する必要が出るので、慣れない内からプレイヤーの負担が大きくなってしまう。

 単純にストーリーのネタが減ってしまうのも厳しい。仲間の登場と加入のイベントはそれだけで強い牽引力があるので、活用しないのはもったいないと思う。

 もっとも、この辺は作品の狙いによって様々なやり方があるので、柔軟に考えて欲しい。
 例えば、冒頭からいきなり多人数パーティにした代わりに、徐々に仲間を掘り下げていくというスタイルもある。

成長システムとの兼ね合い

 成長・強化システムと仲間の加入・離脱には相性がある。ストーリーを作成する上で無視できない部分だ。
 これについては、過去の記事でも詳しく書いている。

パーティ編成による分類

 https://newrpg.seesaa.net/article/302353840.html

 例えば、ドラクエ6〜7の職業システムが有名だろう。
 両作品の職業は戦闘回数によって、呪文・特技を習得するようになっている。
 後半、仲間になったキャラは職業の初期レベルが固定になっており、扱いづらくなってしまう。

 また、レベルアップボーナスのようなシステムがある作品だと、後半に高レベルで仲間になるキャラは不利を受けてしまいがち。
 このようなシステムはそもそも採用しないほうが無難だろう。

 逆に言うと昔のドラクエのように、レベルと装備だけで能力が決まるような単純な設計ならば、加入時期は遅くとも大きな問題は起きない。

 あるいはドラクエ8や11のように、ポイント振り分け型のシステムも問題は起きにくい。仲間になってから自由にポイントを振り分けられるようにしておけばいいだろう。
 ただし、あまりにも振り分けに時間がかかるようなシステムだと、プレイヤーの手間が増えてしまうことには注意したい。

仲間の離脱

 ストーリー上の都合で、頻繁にパーティ編成を変えてしまうと、結果的にシステムを十分に体験できなくなってしまう。(FF13の前半など)

 さらに厳しいのは仲間の永久離脱だ。
 成長システムが凝ったものになればなるほど、仲間の離脱は好まれなくなる。せっかく手間をかけて育てたのにストーリーの都合で離脱されてしまっては、腹立たしくもなるというもの。

 こういった作品の場合は、ゲームシステムの段階でフォローをしておきたい。
 FF5では離脱した仲間の能力を引き継いだ後継キャラが加入する。
 FF7ではマテリアシステムによって、モノを成長させる仕様になっており、離脱による戦力低下が痛手にならないようになっている。

仲間の人数

 仲間の人数が多い作品は、単純に管理の手間が増えるため、複雑な成長・強化システムとの相性が悪い。

 例えば、軌跡シリーズには数十人という膨大な仲間が登場する作品もある。それらがストーリー展開によって加入・離脱するのだが、その度に多数の装備を組み直さないといけないようになっている。
 場合によっては、パーティ分割ダンジョンなどで12人以上の装備を整える必要があったりするが、これはプレイヤーにとって無視できないストレスになる。

 仲間になる人数が多い作品でも、戦闘に参加する人数が少なく、限られたキャラだけを整えればいいなら手間は軽減できる。
 無理に大勢の仲間を使わせるようなストーリーおよびシステムを作ると、それだけ手間がかかることは気をつけておきたい。

かわいい子には旅を

 仲間として旅に参加するキャラクターは、ゲーム的にもシナリオ的にも出番がとても多くなる。
 故郷で主人公の帰りを待つヒロインと、主人公と共に戦うヒロインならば、後者のほうが圧倒的に愛着が湧くはずだ。

 漫画やアニメ、ADVならば、「戦士として敵と戦う主人公」の裏で「王女として政治に奔走するヒロイン」を描いても十分に魅力を出せるだろうけれど、RPGにおいてはこれも厳しい。
 RPGでは、プレイ時間の大半が主人公の周辺の出来事として描かれるためだ。特に戦闘や探索の占める割合は大きい。

 それらの際に、主人公に同行していないヒロインは圧倒的に描写が不足してしまう。同行するヒロインと比較して、プレイヤーの目に触れる時間に100倍以上の差がつくことすらある。
 ヒロインは主人公の幼馴染で小さい頃からずっと仲良くしていた――なんて説明をされたところで、プレイヤーはその体験を共有していないのだから仕方ない。

 ヒロインを例に挙げたけど、他のキャラクターも同様である。
 敵キャラならば、実際に何度も戦って苦戦した相手のほうが印象も強くなる。
 キャラクターの印象を強くしたいなら、ゲームシステム上の出番を用意してあげよう。

戦闘


 一般的なRPGでは戦闘がゲーム性の肝になる。


 RPGのゲーム性とは事実上戦闘であり、それを意識せずしてストーリーは作れない。必然的に、ストーリーも戦闘を意識したものにする必要がある。
 ※戦闘のないRPGのようなごくわずかの例外もありますが、今回は置いておきます。

ストーリーとゲーム性の一致

 例えば、戦いを否定する平和主義的なストーリーを作りたいとしよう。主人公やヒロインはひたすら暴力を否定し、敵との対話を模索し続ける。

 このようなストーリーのコンセプトと、ひたすら敵を倒すことを要求するゲームシステムとの相性の悪さは直感的に分かると思う。
 綺麗事を言っていても、結局は戦闘で物事を解決するならば、どこか偽善的な印象をプレイヤーに与えてしまうだろう。

 ならば――と、戦闘の回避を推奨するようなシステムを導入してしまうと、今度は戦闘システムを作り込む意義がなくなってしまう。
 
 そんなわけで、オーソドックスにRPGを作るならば、ストーリーは戦いを前提にすることが無難だろう。

ボス戦を意識する

 多くのRPGではボスを倒すことが物語の目的に直結している。

 ボスには中ボスからラスボスまで色々とあるが、ボス戦こそがRPGの華だと言ってもよいだろう。
 従って、RPGのストーリーもボス戦を意識して作成することが望ましい。

 そのためにも、必要なのは魅力的な敵キャラだ。
 非道な悪党でも、悲劇の悪役でも、正々堂々としたライバルでもいい。魅力の出し方は様々である。
 ベタではあるが『四天王』のような敵幹部を用意するのも王道だ。

 敵キャラには出番と対決の機会が欠かせない。顔見せ的なイベントを作ったり、複数回の対決機会を設けたりして、印象を強めていこう。
 こういったストーリー上の宿敵との激戦は、ゲームでしか得られない熱さがある。

 ありがちなのは、各エリアの最後にその場限りのボスが現れるばかりというパターン。そうならないように、敵キャラはしっかり意識して描こう。

プレイヤーの操作を尊重しよう

 ゲームである以上、プレイヤーが操作する戦闘は大切であり、尊重しなければならない。ストーリーの都合でプレイヤーの操作をないがしろにするような展開は、なるべく避けたいところだ。

決着のつかないボス戦

 プレイヤーが戦闘でボスを倒しても、ボスがピンピンしてるパターン。
 「なかなかやるな。今日はここまでにしよう」などと宣って、ボスは颯爽と去っていく。閃の軌跡などで散々に見せられた一幕だ。

 一度の戦闘だけで決着をつけてしまうと、敵キャラの掘り下げができないため、ある程度は仕方ない。
 とはいえ、このような展開は「プレイヤーが勝利した」という達成感を損ねてしまう。こういった展開があまりにも多すぎると、戦闘がどんどん茶番じみていくため、プレイヤーもあまり気分はよくないはず。

イベントシーンによる戦闘

 ゼノブレイド2〜3では、プレイヤーが介入できない戦闘ムービーが非常に多い。
 プレイヤーが戦闘でボスを倒したのにも関わらず、それがなかったかのように長い戦闘ムービーが挟まれる。通常の戦闘画面では不可能な派手な演出で、敵との決着を大いに盛り上げる。

 ……が、その一方で、プレイヤーの操作する戦闘は、シーンの合間に挟まれるミニゲームの如き有様である。個人的には「プレイヤーの操作はいらなくね?」「アニメでも見たほうがよくない?」という印象すら受けてしまった。

 こういった問題は戦闘とムービーの落差を小さくすれば、ある程度は違和感を抑えられるかと思う。例えば、戦闘の延長であるかのように決着演出を実行すればよい。

イベントバトルの功罪

 強制敗北戦闘や強制勝利戦闘といったイベントバトルは、RPGの定番である。

 例えば、圧倒的な強さを持ったボスに強制敗北させることで、将来の再戦への期待を持たせることができる。
 ドラクエ5における少年期の最後のシーンは有名だが、強く印象に残った人も多いだろう。

 一方でデメリットもある。イベントバトルは原則、プレイヤーの操作によって結果を覆せない。
 プレイヤーがどんなにキャラを鍛えて的確な操作をしても、意味がないということでもある。その点では、あまり喜ばしいものではないだろう。
 ※一応、ある程度ダメージを与えないとゲームオーバーになるといった調整にすることでゲーム性を付与できるが、負けたという印象は残る。

 個人的に気になったのはFF9。
 この作品では、ストーリーの山場を三度に渡って強制敗北戦闘で潰している。しかも、相手はタダの人間なので、わざわざ何度も強制敗北させる理由はよく分からない。
 FF9ではこのせいもあって、ストーリーの高さに反して盛り上がるボス戦が少なくなっている。非常にもったいないように思う。

 そんなわけで、強制敗北を使うにしても乱用は避けたいところだ。
 なお、強制勝利戦闘も「やらされている感」という点では同じだが、こちらを多用する作品はあまり見ないので問題になることは少ない。

ストーリー進行


 ゲームの特徴は双方向性があること――つまり、プレイヤーが操作できることである。そのため、ストーリーもそれを意識したものを作りたい。

 ADVのようなジャンルならば、ゲーム性を重視しない作りにしてしまうのも一つの手ではあるが、この記事ではあくまでゲーム性との両立を目指したシナリオを考えていきたい。

ゲームテンポを殺さない

 イベントがあまりにも長すぎると、ゲームのテンポを削いでしまう。
 極端なものになると、ゲームをやっているというより動画を見ていると揶揄される作品(いわゆるムービーゲーなど)まである。

 SFC時代のドラクエ5やFF5〜6を改めてプレイすると、ストーリー性は高いのにセリフが簡潔なことに驚く。
 容量の制約という事情もあって、削れるところをバッサリと削った結果かもしれないが、個人的には一つの理想系だと思っている。

 そこまで思い切るのは難しいにしても、セリフを簡潔にしたり、適時プレイヤーの操作を挟むことによって、ゲームテンポを損なわないようにしたい。

 ただし、プレイヤーの操作を挟むにしても、『フラグ立て』や『たらい回し』が多いとそれはそれで問題だ。「あっちへ行け」「こっちへ行け」と延々と本題に入らないようではストレスになってしまう。
 短いイベントなら、場面転換を挟みながらサクッとまとめてしまってもよいだろう。

 コツはそもそも、ストーリーを複雑化しすぎないこと。
 ストーリーを複雑にすればするほど、プレイヤーに対して必要な説明は増えていくので、こういった問題も増えていく。
 時にはバッサリ切り捨てる決断も必要だ。

メッセージ表示は快適に

 あまり指摘されることは少ないけれど、メッセージ表示のシステム周りは大事にしたい。

 メッセージ表示が遅かったり、立ち絵を表示する度に時間がかかったりする作品は、それだけでかなりテンポが悪く感じられる。文字が小さかったり、横長のメッセージウィンドウいっぱいに表示するのも非常に読みづらい。
 さらに酷い例になると、白っぽいウィンドウに白文字(さすがに黒縁つき)という嫌がらせのようなものすらある。

 RPGにおいて文章を読む時間はとても長いので、しっかりと注意を払っておこう。

ダンジョン

 RPGに欠かせない要素としてダンジョンの存在がある。
 ダンジョンに潜り、大勢の雑魚敵を倒しながら、奥のボスを倒すことが毎度の目的になっているRPGは数多い。

 ストーリーを考える上で、どのようなダンジョンを登場させるかも考えておこう。
 ひたすら洞窟ばかりではなく、バリエーションを確保したいところだ。ストーリーの山場ならば、それにふさわしいダンジョンが欲しい。

 これについても過去に考察している。

ダンジョンバランス@ 面白いダンジョンとは?

 https://newrpg.seesaa.net/article/210530419.html

町人を活用しよう

 ゲームシナリオの特徴は双方向性だと既に述べたが、その中には「読んでも読まなくてもよい」という自由度も含まれている。

 特に一般的なのは町人の存在だろう。
 町人に話しかけるかどうかは、プレイヤーの判断に委ねられている。

 古いRPGでは、町人に話しかけないと次の行き先も分からないような作品も多かった。現在ではメインストーリー上で常に行き先を明示するのが一般的である。

 ともあれ、現在のRPGでも町人は有効活用していきたい。
 例えば、メインストーリーで垂れ流すと冗長になってしまうような細かい説明を、町人に任せてしまおう。
 このようにすれば、テンポよくゲームを進めたいプレイヤーと、じっくり文章を読みたいプレイヤーへのアプローチを両立できる。

 なお、過去に以下の記事を書いている。

町人のセリフ・配置

 https://newrpg.seesaa.net/article/383233037.html

仲間との任意会話

 ここでいう『仲間との任意会話』とは、ドラクエシリーズのように仲間と会話するシステムを指している。
 ドラクエのようにメニュー画面から呼び出せてもいいし、拠点や酒場、ダンジョン内の安全地帯などで話しかけられるようにしてもいい。


 扱いとしては上述の町人との会話と同じだが、仲間の存在感を高めることができる。目指す方向によっては採用してみよう。

自由度

 ゲームには自由度があるので、それに沿ったストーリーを作ることもできる。

 選択肢によるストーリー分岐や、攻略が任意のサブクエストなどが代表的だろう。あるいは仲間との恋愛要素を設ける作品もある。

 これについては、過去に以下の記事を書いている。

自由度

 https://newrpg.seesaa.net/article/377351764.html

 なお、必ずしも無理にそのような要素を盛り込む必要はない。
 ストーリー分岐があると周回プレイが前提になりがちだが、ゲーム部分は大半が同じなので飽きやすくなってしまう。サブクエストは基本的に寄り道なので、メインストーリーのテンポが悪化する。

 メインストーリーに注力するから分岐やサブクエストは必要ない――というのも立派な判断だ。

目的は明確に

 次にどこへ行けばいいのか分からないシナリオは、プレイヤーを困惑させやすい。

 現代のRPGではメインストーリーで行き先を明示するのが大半だ。もちろん町人との会話など、プレイヤーが自発的に情報収集することをも求めてもよい。
 どちらの方針を取るにせよ、何も考えなかった結果、単なる不親切になったという状況は避けたい。

 以下はありがちな不親切である。

  • 目的地の名前は明示していても、肝心の場所がノーヒント。
  • メインストーリー上の説明を見落とすと、以降説明が読めなくなる。

 今時の作品は、システムの機能で目的地を知らせてくれるものが多い。メニュー画面のあらすじやクエスト一覧などが一般的だろう。

エンディング

 特にこだわりがないなら、ゲームのエンディングはハッピーエンドを用意すべきだと考えている。

 小説などの他媒体でも、基本的にハッピーエンドのほうが無難だと思うが、ゲームは特にその必要性が高い。
 というのも、プレイヤーに労力を要求する点が、ゲームと他の媒体との決定的な違いだからだ。
 そして「プレイヤーの操作によって困難に打ち勝つ」のがゲームの基本構造であるため、「どうあがいても絶望」というのは、それに反してしまう。
 何十時間も苦労した上で強制バッドエンドを見せられるのは、プレイヤーにとって相当な苦痛となってしまうだろう。

 もちろん、選択次第でバッドエンドになるような要素もあってよい。バッドがあってこそ、ハッピーが際立つという考えもある。
 ただし、長いプレイ時間が無に帰すような仕組みはやめたほうがいい。

 酷い例としてはペルソナ1が有名だろう。
 このゲームは途中の選択肢を誤ると、バッドエンドに分岐して物語の途中で終了してしまう。取り返しは一切つかない。
 分岐点まで普通にやると50時間程度かかるので、当時何人ものプレイヤーが心を折られた。……というか、エンディング分岐があると気づかないままゲームを終えたプレイヤーもいたとか。

 直前でもフラグを満たせばハッピ―に分岐できるとか、短〜中編で最初からやり直してもそこまで苦にならないとか、バッドを見るとすぐに分岐からやり直せるとか、何らかの配慮が欲しい。

主人公の活躍


 RPGの多くは基本的に主人公(=プレイヤー)を中心とした一人称の物語である。ゆえに、その物語も主人公を中心とすることが望ましい。きちんと活躍の機会を設けてあげよう。
 ※群像劇など、特定の主人公を定めない作品もあります。

無口主人公

 注意が必要なのは無口主人公を採用した場合だ。
 ゲーム以外の媒体では、まず見ることのないタイプの主人公だが、その扱いは意外と難しい。

 特に仲間がよく喋る作品だと、主人公の存在が希薄になりやすい。仲間同士の会話中心で物語が進んでしまうと、主人公が何のためにいるのか存在価値が疑わしくなってしまう。
 これについては、以下の記事で書いているので割愛。

無口主人公の考察

 https://newrpg.seesaa.net/article/295119708.html

主人公の能動性

 意外とありがちなのは、敵の思惑やその場の状況に振り回されているばかりで、主人公達が能動的に行動していないというケース。

 ゲームである以上、主人公が自らの意思で目的へ向かっているという感触は欲しい。
 主人公(=プレイヤー)の行動によって、事態を改善しているという実感が得られないようでは達成感が乏しくなってしまう。

成功体験

 もっと言うと、プレイヤーにははっきりと成功体験を与えてあげよう。

  • 悪役の撃破
  • 目的の達成
  • ヒロインや仲間からの信頼獲得

 当たり前のことなのだが、こういった当たり前がおろそかになる作品は珍しくない。

  • 倒しても倒しても、ボスが余裕綽々で去っていくので勝った気がしない。
  • 状況に振り回されるばかりで、気づいてみれば何も成し遂げていない。
  • 何をやっても裏目に出て失敗続き。
  • ストーリー後半になっても、パーティがギスギスしている。
  • ていうか、ヒロインが他の男とくっついた。

 上記のような作品に遭遇した経験のある人もいるかと思う。
 このような例はむしろ、ストーリー性の高い作品で遭遇しやすい印象すらある。話に凝りすぎたばかりに、基本がおろそかになっているのかもしれない。

 なお、この反対の失敗体験が駄目なわけではない。
 むしろ、アクセント的に失敗を入れたほうが成功は際立つ。特に序盤で急激に落として、そこから盛り上げていくようなストーリー構成は定番だと言えるだろう。

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