自作のマダミスシナリオをテストプレイに出したとき、「あれ、このキャラはこの情報をいつ知ったんだっけ？」という矛盾を指摘されて冷や汗をかいたことはありませんか？
マダミスは、複数のキャラクターが同時並行で情報をやり取りする「非常に複雑なシステム」です。これはもう、ほぼプログラムと同じです。今回は、個人開発者としての視点も交えつつ、シナリオの「デバッグ」をプログラミング的にどう進めるかをまとめます。
マダミスは「並列処理されるプログラム」である
マダミスのプロットは、一人の主人公の目線だけで進むミステリー小説とは根本的に違います。
- 登場人物それぞれが「別スレッド」として独立に動く
- シーンごとに情報の「共有・非共有」が発生する
- プレイヤーの選択によって分岐が起きる
これはもう、並列プログラミングそのものです。つまり、小説の校正ではなく、ソフトウェアのバグ潰しの手法 のほうが、マダミスのデバッグには相性がいいと私は考えています。
デバッグの基本：「変数表」を作る
私がシナリオを組むとき、最初にやるのが 「登場人物×情報」のマトリクス を作ることです。
横軸に「明らかになる情報」、縦軸に「キャラクター」を並べ、各セルに「どのシーンで知ったか」を書き込みます。これが、マダミスにおける「変数の状態遷移表」になります。
- 誰が、いつ、何を知るのか
- その情報は、他のどのキャラに伝達可能か
- プレイヤーのHOにはどこまで書かれているか
このマトリクスを埋めていくと、「このキャラ、この情報を持っているはずなのに、HOには書いていない」といった 未定義の変数 がポロポロ見つかります。
ありがちな3つの「バグ」と対処法
1. 「時系列バグ」：情報が時間を遡って流れる
「Aはシーン3で初めて知る情報を、シーン2の発言でほのめかしている」パターン。これはマダミスで最も多い事故です。キャラクターの行動表を時刻単位で並べる と、ほぼ確実に発見できます。
2. 「デッドロック」：誰も情報を持ち出せない
全員がその情報を「他の誰かから聞く予定」になっていて、誰も第一発信者になっていない、というパターン。情報ソースを1つに限定し、そこから放射状に伝達経路を引く のが基本です。
3. 「到達不可能コード」：開示されないフラグ
証拠品や調査結果として用意したのに、通常のプレイ進行では絶対に見つからない情報があるパターン。テストプレイでその分岐に実際に到達したかを確認 し、しない場合は削るか、別の経路を用意します。
私がやっている「単体テスト」と「結合テスト」
プログラミング的に言うと、マダミスのテストは次の2層に分かれます。
単体テスト：キャラ1人分のHOが成立しているか
- そのHOだけを読んで行動可能か
- 自己矛盾はないか
- 最低限のゴール（勝利条件）は理解できるか
結合テスト：全員が集まったときに整合するか
- 情報の出入りタイミングに矛盾はないか
- キャラクター同士の記憶の食い違いが意図的なものか
- 全員のHOを並べたときに、誰にも知られない「孤立した真実」 が残っていないか
私は以前、単体テストとしては完璧だったHOを複数組み合わせたら、結合テストで「全員が同じアリバイを主張できてしまう」という致命的な穴が見つかったことがあります。一人ずつ見ているだけでは絶対に気づけないバグでした。
「リファクタリング」の勇気を持つ
バグを潰すためにその場しのぎの修正（例：急遽、証人キャラを追加するなど）を重ねると、シナリオはどんどん複雑で壊れやすくなります。
コードと同じで、根本から構造を作り直す「リファクタリング」が必要なタイミングが必ず来ます。「このプロット、全体を書き直したほうが早いかも」 と感じたら、勇気を持って書き直すほうが、最終的に良いシナリオになります。
まとめ
マダミスシナリオのデバッグは、感覚と気合でやるものではなく、明確な手順で進められる工程です。
変数表を作る、単体テストと結合テストを分ける、リファクタリングを恐れない。プログラミングの現場で当たり前にやっていることをシナリオ制作に持ち込むだけで、完成度はかなり上がります。次のシナリオでは、ぜひ「情報マトリクス」から作り始めてみてください。