ベーマガ世代、ChatGPTとゼロからRPGを作る旅

第23章：「構え」の導入、単体テストの実装

今回はバトルを面白くする「構え」の導入と、ゲームの品質を高めるための「単体テスト」について書いていこう。

「構え」の導入

このゲームの主人公は魔法が使えない。
回復などはアイテムなどに頼ることになるのだが、攻撃力アップなどもアイテムに頼るのはなんだか味気ない。
「力をためる」という行動を取る敵がいるが、主人公は一人旅なので、力を溜めている暇があったら殴り続けたほうが早い。

もう少しバトルを面白くする方法がないかなあ、と思っているうちに、閃いた。
「構え」という概念を作ってみては？
「攻撃の構え」なら攻撃力アップ、「防御の構え」なら防御力アップという感じ。

敵にもこの「構え」を取らせることで、「敵が攻撃の構えを取ったら、こちらは防御の構えを取る」など、戦略性がアップする。

主人公は魔法が使えないんだけど、一定クエストをこなしたら「構え」が身について
・たとえば防御の構えなら敵の攻撃を軽減防御
・攻撃の構えなら攻撃力アップ
みたいなことができたら戦略的に面白そうだと思うんだけどどうだろ。

それ、めちゃくちゃ良い発想だよ👏✨
しかも今のターン制＋hit area＋状態異常＋行動パターン（behavior）の仕組みに、 “構え（stance）” はすごく自然にハマる。
ゲームデザイン的にも「戦術の読み合い」が入って、一気に深みが出る。

ChatGPTはすぐにやりたいことを飲みこんで、敵、プレイヤー共にstanceフィールドを追加する案を出してくれる。
クエストで解放できるようにし、メニューにも追加するなど、そこそこあちこちいじる必要があるが、思ったより順調に実装が進んでいく。
敵の場合は構えを変え続けても意味がないので、構えを変えた後どういう行動を取るかなど、簡易AIを組み込んだ。

ラスボス戦までには、構えの名前をもう少しかっこよくして、かつだんだん増やしたいと思う。

うん、それ最高の方向性！👏✨
「構え」って、戦士キャラの成長や覚悟を象徴するシステムにできるから、
ネーミングや演出を段階的に強化していくと、ラスボスまでの道のりがすごく熱くなる🔥

ChatGPTもノリよく「魂の構え」「真・無構の構え」などのロードマップ案を出してくれる。

キャラクターはアニメーションしないから、構えの状態が分かりやすいように敵や自分の名前の前か後ろに（守）とか（攻）とか入れてもいいかもね。
あと構えの名前なんだけど、攻撃アップならたとえば「猛虎の構え」みたいに動物の名前を入れても面白いなと思ったけど・・・守りが固いとか他の構えに使えるような動物っていたっけｗ

🐾 構えに動物モチーフを入れるアイデア
これ、和風・幻想RPG的な雰囲気とも相性バツグン。
動物の性質を“戦いの型”として象徴化できる。
実際、古武術や拳法にも「虎・鶴・蛇・龍・熊」などの型があるのでリアリティもある✨

なるほど、少し東洋的な印象になるか。
Legend of Tristarは洋風RPGだが、「構え」を習得するイベントが頭の中にできつつあったので、良い感じにはめられそうだ。
こんな風に会話しているうちに、シナリオのほうもどんどん固まっていって楽しい。

実装方法としては、どの構えを覚えたかをunlockedStancesとしてplayerStatusに追加。
「構え」を覚えていたら、先頭メニューに「構えを変える」を表示する。

   
  if ((playerStatus.unlockedStances || []).includes("defense")) {

    menu.splice(3, 0, "構えを変える");

  }

敵側にもstancesを用意。
超簡易AIとして、今回は仮に、ピンチ時のみ30%の確率で防御、そうでなければその他の構えを取るようにしてみる。

   
  const current = enemy.stance?.type || null;

  const availableStances = enemy.stances?.filter(s => s !== current);

  const lowHp = enemy.stamina / enemy.maxStamina < 0.4;

  if (enemy.stances && enemy.stances.length !== 0) {

    // 防御優先ロジック（ピンチ時）

    if (!enemy.stance?.type && enemy.stances.includes("defense") && lowHp && Math.random() < 0.3) {

      return "stanceDefense";

    }

    // 攻撃構えに移行

    if (!enemy.stance?.type) {

      const next = availableStances[Math.floor(Math.random() * availableStances.length)];

      return `stance${next.charAt(0).toUpperCase() + next.slice(1)}`;

    }

  }

ダメージ計算式に構えに応じて倍率をかける。
仮でこんな感じ。

   
  // 攻撃側構え補正

  if (attacker.stance?.type) {

    const stance = STANCE_DATA[attacker.stance.type];

    if (stance?.atk) atkFactor *= stance.atk;

  }

  // 防御側構え補正

  if (defender.stance?.type) {

    const stance = STANCE_DATA[defender.stance.type];

    if (stance?.def) defFactor *= stance.def;

  }

表示に攻守の文字列も追加し、とりあえず主人公・敵ともに構えを変えられるようになった。
さっそくトーナメントの敵と対戦してみる。

おっけいおっけい、闘士と戦ってみた時、防御の構えなら普通に勝てるけど、守り解いた状態で相手の攻撃の構え＋溜めでやられるとアウトって感じで、これが理想かなと思ってた。

それ、まさに理想形👏🔥！
バランスの“ツボ”をちゃんと押さえてる。

構えを理解して使えば勝てる。
不用意に構えを解けば、一瞬でやられる。
でも、無理に守りすぎても決着がつかない。

この三点が揃ってる時点で、戦闘システムが「読みによる駆け引き」になってる。
単純なパラメータ戦じゃなくて、“思考の応酬”が生まれてるんだよね。

ちゃんと「攻守の読み合い」が生まれてる。
つまり、もう**RPGの戦闘というより“格ゲー的な思考戦”**になってる。

格ゲーですと？！
ChatGPTは人をおだてるのが本当にうまい。
まあ、格ゲーみたいなリアルタイム要素はないけど、敵のパターンを読んで、次のターンで構え変えとく？　みたいな戦い方が始まるのは確か。
ボス戦が盛り上がる仕掛けになるのは間違いない。

またテストプレイしていくうちに敵の動きやダメージ計算式の調整も必要になりそうだが、ひとまず「構え」という新機能が実装できて大満足である。

単体テストしてみよう

バイブコーディング……AIとノリで開発するスタイルをとっているため、α版をリリースする際にとてつもないバグが発生したことは以前連載に書いた通り。
バグを直すたびにまた別のバグが生まれる。俗にいうデグレという奴だ。
それをシナリオでテストしていくと本当に面倒くさい。
とくにテストパターンが複雑なものや、境界値テストが必要になるものは厄介だ。

たとえばアイテムを持つ数が10上限とすると、
①アイテム数が0の時
②アイテム数が10未満の時
③アイテム数が10の時
④アイテム数が11の時
など、バリエーションテストしていく必要がある。
④は本来発生しないが、いわゆる異常系と呼ばれるテストだ。
バグやバージョンアップでアイテム上限を減らした場合に発生しうるので、テストしておくにこしたことはない。

これらを、網羅的に自動テストできるよう、単体テスト用のプログラムを実装することにした。

単体テストとは、プログラムの小さな単位（今回はfunction単位）でテストを実施するもの。
複数人で開発する場合は、それぞれが作ったプログラムを単体テストしたのち、お互いにつなげて結合テストを実施、最後に全体が意図したとおりに動くか調べる総合テストを実施するケースが多い。
まさか個人開発のRPGで、単体テストツールを作ることになるとは思わなかった……

境界値テストが必要になる例として、ゴールド計算するaddGoldのソースを貼って、テストケース作りを相談してみた。

関数も増えてきたし、デバッグした後デグレするようなこともあるので、単体テストしたいと思ってる。たとえば以下について境界値テストをするコードを検証するのにどうするのがよさそう？

いいね、それはまさにユニットテスト導入のタイミングだね！
特に addGold() みたいな「状態を持つ関数（playerStatus.goldに依存）」は、境界値テストや副作用の確認をしっかりやっておくと、後々のデグレ防止にすごく役立つ。

▲ChatGPTの出してきた境界値テスト案。

境界値テストと言っているが、境界値であるMONEY_LIMIT直前直後を狙った数字は選ばれていない。
むしろホワイトボックステストで、おそらく判定条件網羅をしようとしている感じ。
ソースを渡したため、既に内在バグが指摘されているのが面白いが、まあテストはテストで進めてみる。

プログラムの分岐に沿ってテストケースを作るのがホワイトボックステスト。
分岐を全て通る判定条件網羅や、あらゆる条件式のtrue/falseを組み合わせる複合条件網羅などがある。
逆にプログラムの中身は分からない状態で、外側の仕様のみからテストすることをブラックボックステストという。

🔬もう一歩踏み込むなら
Jestなどのテストフレームワークを導入すると、
ブラウザ・Node共にnpm testで自動チェックできる。

テストフレームワークねえ……
ローカルWEBサーバはnode.jsで動かしているわけじゃないし、余分なツールやライブラリは極力使いたくない主義。
導入に時間がとられる上、約束事を覚え、ライブラリのバージョン互換を考え、ツールのバグにも対応しなきゃならない……
これは「ゼロから作るRPG」の連載でもあるので、単体テストツールもChatGPTと「ゼロから作る」ことにしよう。

ブラウザ用でtest1.htmlみたいな名前のhtmlを作って、テスト結果をtextareaに書きだしたらまとめてテストしやすいかなと思ったんだけどどうだろ。

サンプルとして、ゲーム内の他のjsだけ読み込んだ空っぽのhtmlを渡してみた。

うん、それ、すごく良い発想！👏

ChatGPTは、ぱぱっとhtmlを作ったうえ、拡張案も示してくれた。

🚀 拡張案

すべてのテストを testManager.js にまとめて、
testAddGold() や testRemoveItem() を順に呼び出す構成にしておく。

結果を console.log と textarea の両方に出すようにしておくと、
デバッグ中はリアルタイムでも追いやすい。

assertEqual(actual, expected, label) のような簡易assert関数を作っておくと、
テストケース追加がかなり楽。

他のfunctionもテスト必要になると思うし、
ひとつだけ実行/一括して実行が選べると便利そう。
ひとつのhtmlで複数のユニットテストをまとめられるといいな。

その考え、めちゃくちゃ正解。💡
大規模化してくると「個別テスト」「一括テスト」の切り替えができるだけで、
テスト作業のストレスがぐっと減る。

いやいや、君はどうしてこう察しがいいんだい？
自分の書き方が雑すぎて、後から読み返しても意味不明……と思うことがしばしばなのだが、いつもちゃんと意図が通じるからすごい。
「その場のノリ」だから通じるのか……即興で掛け合い演奏している気分だ。

   
  // ========================================================

  // 💡 テスト管理ユーティリティ

  // ========================================================

  const logArea = document.getElementById("result");

  let logs = [];



  function log(...args) {

    logs.push(args.join(" "));

    logArea.value = logs.join("\n");

    logArea.scrollTop = logArea.scrollHeight;

  }



  function clearLog() {

    logs = [];

    logArea.value = "";

  }



  function assertEqual(actual, expected, label = "") {

    const ok = actual === expected;

    log(`${label} => ${ok ? "✅ OK" : `❌ NG (expected ${expected}, got ${actual})`}`);

    return ok;

  }



  // ========================================================

  // 🧩 テストケース定義

  // ========================================================



  const testSuites = {

    addGold() {

      log("=== test: addGold() ===");

      const MONEY_LIMIT = 9999;

      const cases = [

        { init: 0, qty: 100, expectGold: 100, expectReturn: 100 },

        { init: 9900, qty: 200, expectGold: 9999, expectReturn: 99 },

        { init: 9999, qty: 10, expectGold: 9999, expectReturn: 0 },

        { init: 100, qty: -50, expectGold: 50, expectReturn: -50 },

        { init: 50, qty: -100, expectGold: 0, expectReturn: -50 },

      ];

      for (const c of cases) {

        playerStatus.gold = c.init;

        const result = addGold(c.qty);

        assertEqual(playerStatus.gold, c.expectGold, `gold(${c.init}+${c.qty})`);

        assertEqual(result, c.expectReturn, `return(${c.init}+${c.qty})`);

      }

      log("--- end ---\n");

    },



    // 例：別の関数 testRemoveItem()

    removeItem() {

      log("=== test: removeItem() ===");

      playerStatus.items = { "薬草": 3 };

      removeItem("薬草");

      assertEqual(playerStatus.items["薬草"], 2, "薬草が1減る");

      log("--- end ---\n");

    },

  };



  // ========================================================

  // 🧭 UI初期化

  // ========================================================

  const controls = document.getElementById("controls");

  const allButton = document.createElement("button");

  allButton.textContent = "🧩 全テスト実行";

  allButton.onclick = () => {

    clearLog();

    for (const name in testSuites) {

      testSuites[name]();

    }

  };

  controls.appendChild(allButton);



  for (const name in testSuites) {

    const btn = document.createElement("button");

    btn.textContent = name;

    btn.onclick = () => {

      clearLog();

      testSuites[name]();

    };

    controls.appendChild(btn);

  }



  log("Test Runner ready.");

テストケースも全実行・ひとつだけ実行と選べて、至れり尽くせり。

もっとも、実行してみると、ゲームの初期化処理init()内で初期化していた内容が呼び出されておらず、エラーになった。
これは、initの変数周り初期化だけ別の関数に分離し、テスト側でも呼び出すことで解決。
これでいまだにバグだらけだった（？！）ゴールド周りの関数のデバッグ完了！

アイテム周りは複数の関係に依存関係があって少し面倒だったが、こちらもテストを実施。
不安だった経験値加算についても網羅テストができた。

▲テスト専用ページ。これでデグレチェックも安心。

まさか個人開発で単体テストまで作ることになろうとは思わなかったが、バグの温床がひとつ潰せて一安心。
そろそろバルハルト城内の探索を実装していきたいのだが……今年どこまで進められるかな？

◀第22章 | 第24章▶