4Hえんぴつ｜React＋TypeScriptでWeb RPGを作る

第4章「戦闘・交渉・調査と状態管理」
第17回：戦闘・交渉・調査を別々に作らない――ResolutionTypeで共通化する

連載トップ・第0回はこちら

本連載では、設計・実装・テスト・改善にAIを活用しながら、React＋TypeScriptによるWeb RPG開発を進めています。

1. 今回のテーマ

第3章では、街道で複数のイベントを発生させ、

街道へ入る
↓
イベントが起きる
↓
解決する
↓
次のイベントへ進む

という流れを作りました。

では、その「解決する」はどう作るのでしょうか。

今回のRPGでは、イベントに対して主に、

戦闘
交渉
調査

の3種類から行動を選びます。

最初に考えやすいのは、

戦闘システム
交渉システム
調査システム

をそれぞれ別々に作る方法です。

しかし現在の設計では、そうしていません。

3つを、

「イベントを解決する方法」

として共通化しています。

2. 3種類をそのまま別実装するとどうなるか

例えば、イベント画面で次のように分岐させることもできます。

以下は考え方を説明するため、実装を簡略化しています。

if (choice === "combat") {
  resolveCombat();
}

if (choice === "negotiation") {
  resolveNegotiation();
}

if (choice === "investigation") {
  resolveInvestigation();
}

最初は分かりやすいです。

しかし、それぞれの処理の中に、

能力値を取得する
難易度を取得する
成否を判定する
結果を表示する
HPや評判を更新する
イベントを解決済みにする

といった処理を書き始めると、似たコードが増えていきます。

3. 違うのは「何を使って解決するか」

戦闘・交渉・調査は、ゲーム上の意味は違います。

例えば、

戦闘
→ 力で危険を突破する

交渉
→ 相手と話して解決する

調査
→ 情報や痕跡から答えを探す

という違いがあります。

ただし、プログラム上の流れを見ると、

方法を選ぶ
↓
対応する能力値を見る
↓
難易度と比較する
↓
結果を決める
↓
ゲーム状態を更新する

という部分は共通しています。

そこで、

違う部分だけをデータにして、処理の流れは共通化する

ことにしました。

4. ResolutionTypeを作る

現在は、解決方法を次の型で表しています。

export type ResolutionType =
  | "combat"
  | "negotiation"
  | "investigation";

これによって、

const resolutionType: ResolutionType =
  "combat";

のように扱えます。

文字列ではありますが、任意の文字列ではありません。

例えば、

const resolutionType: ResolutionType =
  "magic";

と書けば、現在のResolutionTypeには存在しないためTypeScriptが検出できます。

5. 文字列を直接使うより意味を限定できる

もし、

type ResolutionType = string;

としてしまうと、

combat
Combat
battle
fight
negotiation
talk

のような表記揺れが入り込めます。

一方、

type ResolutionType =
  | "combat"
  | "negotiation"
  | "investigation";

なら、使える値を型として限定できます。

これは小さな違いですが、ゲーム内の参照箇所が増えるほど効いてきます。

6. AbilityKeyにも同じ考え方を使う

現在のMVPでは、解決方法と主能力を1対1で対応させています。

export type AbilityKey = ResolutionType;

つまり、

combat
↓
戦闘能力

negotiation
↓
交渉能力

investigation
↓
調査能力

という対応です。

能力値も、

export interface AbilitySet {
  combat: number;
  negotiation: number;
  investigation: number;
}

として持ちます。

これによって、選んだ解決方法から対応する能力値を扱いやすくなります。

7. ResolutionTypeから能力値を選べる

例えば、プレイヤーの能力値が、

const abilities = {
  combat: 4,
  negotiation: 2,
  investigation: 3,
};

だったとします。

以下は考え方を説明するため、実装を簡略化しています。

function getAbilityValue(
  abilities: AbilitySet,
  type: ResolutionType
) {
  return abilities[type];
}

すると、

getAbilityValue(abilities, "combat");
// 4

getAbilityValue(abilities, "investigation");
// 3

のように、同じ処理で取得できます。

戦闘用、交渉用、調査用に別々の関数を作る必要がありません。

8. GameEventにも処理を直接書かない

第12回では、GameEventが、

resolutionIds: string[];

を持つことを紹介しました。

イベントそのものには、

戦闘ならこの処理
交渉ならこの処理
調査ならこの処理

とは書きません。

代わりに、

GameEvent
↓
resolutionIds
↓
ResolutionDefinition

と参照します。

ResolutionDefinitionには、解決方法の種類や難易度、結果への参照などを持たせています。

正式設計では、1イベントにつき戦闘・交渉・調査を各1件持たせる構成です。

9. 「戦闘イベント」「交渉イベント」に分けない

この設計では、

戦闘イベント
交渉イベント
調査イベント

という分類にはしません。

一つの出来事に対して、

戦って解決する
話して解決する
調べて解決する

という複数の方法を用意します。

例えば、

街道を塞いでいる相手がいる

という一つの出来事でも、

戦闘
→ 力ずくで突破する

交渉
→ 話し合って通してもらう

調査
→ 別の通路や原因を探す

という違いを作れます。

イベントと解決方法を分けることで、同じイベントを別々の体験として扱えます。

10. 共通化すると結果処理にもつながる

解決方法をResolutionTypeとして共通化すると、その後の流れも共通化できます。

概念的には、

ResolutionTypeを選ぶ
↓
能力値を取得
↓
ResolutionDefinitionを取得
↓
難易度を見る
↓
判定
↓
成功・部分成功・失敗
↓
ResultDefinition
↓
GameStateを更新

となります。

戦闘だけ特別なルートを通るのではありません。

交渉も調査も、同じ「解決」の流れに乗せられます。

11. それでも戦闘らしさは失われない

共通化すると、

戦闘も交渉も全部同じになってしまわないか

という疑問もあります。

ここで共通化しているのは、

内部の判定フロー

です。

表示や演出まで同じにする必要はありません。

例えば、

戦闘
→ 剣や敵を意識した文章・演出

交渉
→ 会話や相手の反応を中心に表示

調査
→ 痕跡や発見内容を中心に表示

とできます。

つまり、

ゲームルール
↓
共通化

見せ方
↓
必要に応じて変える

という分け方です。

12. 共通化しすぎないことも重要

一方で、

共通化できるものは全部一つにする

わけでもありません。

将来、戦闘だけに、

ターン
装備
敵HP
状態異常

などが必要になれば、戦闘専用の仕組みを追加する可能性はあります。

現在のMVPで必要なのは、

戦闘
交渉
調査
↓
能力値と難易度によって結果を決める

という範囲です。

その範囲で共通化しています。

必要になる前から複雑な戦闘システムを作らない

という、プロトタイプから続けている方針でもあります。

13. 型を作ることが、設計を決めることになる

ResolutionTypeは短い型です。

export type ResolutionType =
  | "combat"
  | "negotiation"
  | "investigation";

コードだけを見ると数行しかありません。

しかし、この型によって、

このRPGでは
「戦闘」「交渉」「調査」を
同じ階層の解決方法として扱う

という設計が明確になります。

TypeScriptの型は、単なるエラー防止だけでなく、

ゲームのルールをコード上で表現するもの

としても使えます。

14. 今回のポイント

今回のポイントは3つです。

戦闘・交渉・調査を別々のシステムとして作らず、ResolutionTypeで共通の「解決方法」として表現する
AbilityKeyもResolutionTypeに対応させ、選択した方法から能力値を扱えるようにする
共通化するのは判定の仕組みであり、文章や演出まで同じにする必要はない

最初は、

戦闘
交渉
調査

という三つの別機能に見えました。

しかし処理を整理すると、

方法を選ぶ
↓
能力を見る
↓
難易度と判定する
↓
結果を反映する

という共通構造が見えてきました。

次回は、この中の、

「能力を見る」

部分を詳しく扱います。

15. 次回

次回は、

戦闘・交渉・調査に能力値を対応させる――AbilitySetの設計【第18回】

です。

現在のプレイヤー能力は、

export interface AbilitySet {
  combat: number;
  negotiation: number;
  investigation: number;
}

という形で持っています。

次回は、

なぜ能力値をこの3種類にしたのか
ResolutionTypeとどう対応するのか
職業やスキルとどう分けるのか

を整理しながら、

「プレイヤーが何を得意としているか」をデータとしてどう持つか

を見ていきます。

　
　
この記事を最後まで読んでいただき、ありがとうございます。

「♡ いいね」を押していただけるとうれしいです。これからの記事づくりの励みになります。

もし気に入っていただけましたら、フォローもよろしくお願いします。