第9回：1000回シミュレーションし、ゲーム時間を測った日

公開日：2026年05月11日

試行はAIに任せるべき

この日のテーマは、ゲームがどれくらいで終わるかを測ることだった。実際に遊んでいると、たまに長引くことがある。感覚だけで調整すると、カードを弱くしすぎたり、逆に終わらないゲームになったりする。そこで、AI側で1000回程度のシミュレーションを行い、平均時間や中央値を確認した。

結果として、普通に遊ぶ想定では平均2〜3分台、中央値は2分前後という目安が出た。しかし、最長ターン数がかなり長くなるケースもあり、たまにダラつく問題が残っていることがわかった。

AIには、「1000回くらいシミュレーションして、普通に遊んで何分くらいで1ゲームが終了するか、平均と中央値を出せるか」と頼んだ。ゲーム本体をそのままブラウザで1000回操作するのではなく、ルールをロジック化して試算する形だった。

また、デッキ定義に問題があるかもしれないという指摘も出た。以前追加した60枚デッキが、後ろの簡易版buildDeckで上書きされている可能性があった。実際に確認し、buildDeckの二重定義を解消した。

シミュレーションの結果、現行に近い構成では、1ゲームはだいたい2〜3分で終わるが、たまに6分以上になることが見えた。60枚版が完全に有効だった場合は、平均が少し長くなる可能性もあった。

この結果を受けて、60枚構成をきちんと整理した。会話カード、押し付けカード、操作カード、特殊カードを合計60枚に調整し、ハプニングトークは初期山札には入れず、ドロー時の低確率取得にした。デッキが整理されたことで、カード設計の意図がはっきりした。

ゲーム時間は短ければいいわけではないが、放課後トークの軽いカードゲームなら、5分以内に終わる方が再プレイしやすい。長引く時は、プレイヤーが負けそうな緊張感ではなく、単にカードが減らない疲労感になりやすい。

そこで、ドロー2の重ね出し、誰も話題が出ない時のトレンド変更、先生イベントなど、長引き対策を段階的に入れた。単純にカードを捨てるのではなく、ゲーム内の出来事として短縮することを重視した。

デッキ定義の二重化は、AIと一緒に開発している時に起きやすい問題だった。前のコードを残したまま後ろに新しいコードを足すと、見た目には修正されたように見えても、実際に有効な関数が違うことがある。

この日以降、単に"動くHTML"を見るだけでなく、どの関数が最終的に有効になっているかを確認する重要性を感じた。AIに任せるほど、コードの上書き関係を読む必要がある。

次は、長引き対策をゲーム内イベントとして実装することになった。放課後に長く残っていると先生が見回りに来る。このアイデアが、後の先生イベントにつながる。