見出し画像

未完成のターン制RPG戦闘演算


はじめに

 この文書は、「ターン制RPG戦闘演算ノウハウ」の次に書かれており、このアイディアについて皆さんが考える際には、先にそちらをお読み頂く事をお勧めします。
 この文書単体でもご参考にして頂けると思いますが、その方がやり深くこの戦闘演算について深く理解できると考えるためです。

この文書の目的

 未完成ではありますが、次のような事を目的としています。

  1. 難易度設計をレベルで指定する事で、全体設計を容易にし、可読性を向上させる。

  2. 戦闘演算を表現される数値からレベルに置き換える事で、1の目的を達成する。

  3. レベル主体とする矛盾点をリスト化し、対処できる箇所は対処方法を示す。

なぜ難易度設計をレベルで指定しようと考えたのか

 話はキャプテン翼2の難易度作成の頃に戻ります。

冨江慎一郎氏

 難易度は少年サッカーチームのコーチもしていた冨江慎一郎氏が担当し、数値の他、選手の移動データの作成などを行い、企画全般の監修も行ってました。
 今で言えば「ディレクター」に近い役割だと思います。
https://ja.m.wikipedia.org/wiki/冨江慎一郎

きっかけ

 そのキャプテン翼2の難易度を冨江さんか作ってる時、二人で話したんです。
 どうも冨江さん、敵の難易度をレベル相対で設定しているようだと気がついた私はこう聞きました。
「敵の数値設定とかレベルで指定できたら、便利?」
冨江さん少し考えてこう言いました。
「便利だと思う。でも今更変更するのはダメだなぁ」
 とかいうような話をしたんじゃ無いかな、と。
 難易度データを作る頃といえば、もう開発も終わりが見えてくる頃ですから、今更そんな変更は出来ません。

レベル相対

 ここで言う「レベル」というのは、主人公キャラクターのレベルです。
 そして敵にも同じようにレベルを設定出来るようなする、という意味です。
 どうやら冨江さんは、この試合の時には主人公達はこれくらいのレベルだから、敵の強さはコレくらい、と主人公達のレベルを基準に敵の強さの数値を設定していたようです。

 ここで注意して頂きたいのは、想定する主人公達のレベルであって、プレイしてその試合の時の主人公達のレベルでは無い点です。
 後者にすると、自動難易度設定となり負けて弱いチームと戦って成長しても、相手もその分強くなってしまうからです。
 この想定する主人公達のレベルは、前著の「ターン制RPG戦闘演算ノウハウ」の中で「年表」と称したものです。

敵のレベル=敵の相対的な強さ+想定する主人公達のレベル

 この敵のレベルを元にして数値を設定していたと。
 だったら難易度データに直接そのレベルを記載出来れば良いじゃないかと言うのが、この演算方式の始まりだった訳です。

このアプローチについて

 これまでのお話からも分かる通り、実際のゲームがある程度か完成してきてからの発想です。ですから、この戦闘演算仕様をベースにする際には、必ず全体設計を行い、相互の矛盾が無いか十分にチェックしてください。

 このアプローチはボトムアップで、「ターン制RPG戦闘演算ノウハウ」の方式はボトムダウンです。
 作り方が180度違うため、相互のチェックが不可欠なんです。
 作っているゲームに合わないた思ったら、きっぱり導入を諦める、そのくらいの覚悟でお願いします。
 勿論、そのままでの導入出来ないとはや思います。

戦闘演算の方法

 ここで少しキャプテン翼の対決解決を簡単に説明したいと思います。
 キャプテン翼では、オフェンスとディフェンスの対決結果を次のように求めています。

結果値=オフェンスの威力÷ディフェンスの威力+乱数

 ちょうどこれはボードゲームの戦闘シミュレーションで戦闘結果を出す方式に近いものです。乱数がサイコロ、その前の式は戦闘比率と呼ばれるものです。ボードゲームでは戦闘比率とサイコロの出目をそれぞれ縦横とした表があり、その中に戦闘結果が記載されています。
 翼では、結果を元に結果テーブルを参照して結果を導きます。

初めの方式

この割り算の箇所威力からレベルに変えて、引き算にしたものを考えた訳です。

結果値=オフェンスのレベル-ディフェンスのレベル+乱数

 この結果値と対応する結果テーブルの結果に、ダメージ量を記述ねすればダメージ計算に応用出来ると思ったのですが、お分かりの通りそれではダメなんです。
 レベルが上がっていくとHPが増えていくためです。
 とすると、と。今度はディフェンスのHPとの比率でダメージ量を出そうと考えました。しかし、今度は弱い敵に大きなダメージを与えた、というテキストの表示が出来ません。敵のHPが少ないからです。
 この段階では、ここでこの方式の検討を諦めました。

再び考える

 そして月日は巡り、機会が訪れます。
 その間にゲーム開発の経験も積み、新しい視点からこの方式を考える毎にしました。
 そうだ。やはりHPの比率じゃなくて値にしよう、と。
 え!?それじゃ初めの時と同じじゃないの? そう思う方もいらっしゃると思います。
 前回の失敗は結果テーブルにダメージ量を直接記載したためでした。
 そこで、結果値から乱数を外し、オフェンスのレベルに結果値を加えたものを基準にダメージ量を割りだす、というものです。
 このテーブルは、オフェンスとディフェンスが同じレベルの時、そのオフェンスはどれくらいのダメージを与えるか、というオフェンスのレベルをキーとしたダメージ量のテーブルになる訳です。オフェンスのレベルが高ければダメージは大きくなり、ディフェンスのレベルが低くなるとダメージは大きくなる、という事になります。

演算式

 計算式を書くと、下のようになります。

ダメージ量=ダメージテーブル[(PCの攻撃レベル-敵の防御レベル)+PCの攻撃レベル]

 解説すると、[]内の式の値でダメージテーブルからダメージ量を取り出す、という事になります。
 C言語系の配列の扱いですね。
 ダメージテーブルの方は、PCの攻撃レベルと敵の防御レベルが同じ場合の時、PCの攻撃レベル順にダメージ量を並べたもの、になります。

装備という問題点

 上手く行った!と思いました。しかし、そう簡単な話だったら良かったのです。
 ご想像の通り問題がありました。
 装備です。
 RPGには装備がつきものです。
 通常、武器や防具はPCがレベルアップしてもその効果は変わりません。しかし、前述の方法では、武器や防具もレベルとして扱っていたのです。

PCの攻撃レベル=PC単体の攻撃レベル+装備レベル

としていた訳です。ですからPCのレベルが上がると、武器の攻撃力もアップしたように見えてしまう訳です。
 特殊な武器ならそれで良さそうですが、これは武器全般に言える事なので、困りました。
 更にこれは武器だけでなく、防具にも言える事だった訳ですから、事態はそれなりの深刻さだった訳です。

今だったら分かる対処方法

 今だったら対処方法が分かります。
 装備に耐久力を設け、武器なら攻撃する度、防具なら防御する度に耐久力が減り壊れる、という基本ルールを設定し、PCとレベル差がある装備はレベル差分耐久力を消耗する、というようにする方法です。
 木の棒でも大きなダメージを与えられる代わりに、すぐ壊れる。
 レベルが上の武器も壊れ易くなるけれど、元々の耐久力が高い。
 耐久力の消耗は、与えた、あるいは受けたダメージに比例するようにすれば良いと。

 それでも武器の攻撃力をパラメータとして表示するのは、実際の計算とは異なるので、少し微妙な気持ちにはなるのですが。
 ああ、武器のパラメータの算出方法の説明を忘れていました。
 ダメージ量の算出と同じような武器攻撃力テーブルを設け、武器レベルから値を求める方法です。

こういう方法だと

 あ、今、PCのレベルから求めたダメージ量と武器パラメータを使って、ダメージ量を求めれは良いと思いませんでしたか?
 その方法だと、調整項目がレベルに統一されず、設計時には良く分かっていても、調整時にはすっかり肝心な設計思想が頭から抜け落ちて、迷宮の入れ口に立っている事に気がつくんです。数値の迷宮を進むためのマップは虫食いだらけ、となってしまっているんです。

まとめ

 一般装備がPCのレベルに応じて成長する世界。
 この難易度設計や戦闘演算には、そういう要求をゲーム世界にしてしまうのでした。
 このように一般化しづらいため「未完成」という事になったのでした。

 この戦闘演算方式の利点は先にも述べましたが次のとおりです。

  • PCのレベルで管理されるため、年表設計方法の利点が直接活かせる。

 次は、実際に運用していないため、確認できていない利点です。

  • 難易度データの可読性が高まる。(はず)

  • 難易度データの作成が比較的容易になる。(はず)

  • 調整する際の問題の切り分けが比較的容易になる。(はず)

 欠点としては次のとおりです。

  • 世界設定に影響を与える。

  • 初期の基礎データ作成が重要になる。

 ここでいう基礎データとは、オフェンスレベルとダメージ量のテーブルの事です。
 このテーブルが演算の基礎となるため、このテーブルの精度が重要となるのでした。
 精度を検証するには、「ターン制RPG戦闘演算ノウハウ」の年表が重要になってくる訳です。

おわりに

 未完成の戦闘演算のお話にお付き合い頂き、ありがとうございました。

 最後に、この演算方式の中で出てきた初めに諦めたお話と関連したのは、PCエンジンの「ネクロスの要塞」であり、その後、再びこの演算方式を考えるきっかけとなったのは、途中で諸般の事情からペンディングとなったとあるRPGでした。このゲームはネクロスの要塞とだいたい同じスタッフで取り組んでいました。
 残念ながら完成には至りませんでしたが。

 このお話があなたの創作の一助になる事を願っています。
 それでは失礼致します。


いいなと思ったら応援しよう!

mTsuruta
宜しければ、ゲーム制作などのクリエーター活動のサポートをお願い致します。