好感度とヘイトを同時に持たせる感情モデルを、実装前に設計した理由
今回やったこと
NPCの感情を単一の好感度で表す現行設計に対し、好感度とヘイトを別々に持つ多軸モデルを構想した。この記事では、なぜ複数の感情軸が必要と考えられたのか、そして実装を先送りした判断を整理する。多軸化はまだ実装されていない。
実装ステータス
構想段階。2026-08-24時点の設計意図と現行実装の説明に限る。多軸モデルの動作や効果を実装済みのようには扱わない。
単一の値では表しにくい状態
現行の src/affinity.py は affinity: dict[npc_id, int] という単軸モデルである。NPCごとに好感度を一つの整数で持つ構造なら、状態を簡潔に表現できる。一方で、ひとつの値だけでは方向の異なる感情を同時に記録できない。
たとえば「信頼しているが、過去の行為は許せない」という関係を考える。信頼を評価して値を上げると、許せない気持ちまで薄れたように見える。反対に、怒りを反映して値を下げると、信頼まで失われたように見える。どちらの値を採用しても、二つの状態の片方がもう片方に押しつぶされる。
構想された案は、好感度とヘイトを併存させることだった。「嫌悪と庇護欲が同居する」状態も、二つの軸なら別々に表せる。ここでいうヘイトは敵意・反発を記録する軸としての設計案であり、数値範囲、更新式、閾値などの仕様はまだ決められていない。水滸伝型の人間関係ドラマでは、相反する感情を同時に持てることが表現の核になる、という考えが出発点にある。
| 設計上の表現 | 単一の好感度 | 複数軸の構想 |
|---|---|---|
| 信頼しているが許せない | 片方の感情が値に隠れやすい | 好感度とヘイトを別々に保持できる |
| 嫌悪と庇護欲が同居 | ひとつの方向へまとめる必要がある | 異なる軸の併存を表現できる |
表は概念上の比較であり、実装済みの挙動を示すものではない。多軸にすれば自動的に物語が良くなる、という結論でもない。状態を増やせば、イベントに応じた更新や、行動選択で各軸をどう使うかも決める必要が生じる。
先に脅威対処ループを確かめる
当時の方針では、感情モデルの作り込みより、脅威対処ループが面白く成立するかを先に検証することが優先された。多軸化の仕様を先に詰めると、ゲームの中心となるループの検証が遅れるためである。設計上の魅力があっても、今の開発段階で必要な投資かどうかは別に判断する。
この順序には、先に試すべき仮説を絞る意味がある。まず脅威に対してNPCがどう反応し、プレイヤーがその反応をどう受け取るかを確かめる。感情の細かな状態を増やすのは、その検証に必要だと分かった後でよい。記録では、多軸化を提案・実装するのはユーザーが明示的にその段階へ進んだ後とされている。
将来の実装に残した注意
多軸化へ進む場合も、感情を単一の軸に固定せず、後から軸を追加できる形にするという注意が残されている。ただし、これは将来の設計上の注意であって、現行 affinity の変更計画や実装仕様ではない。軸を増やすなら、保存形式、イベント更新、各行動が参照する軸、既存データとの互換性などを別途決める必要があるが、これらは現時点の素材では未決定である。
今回の判断から得られるのは、「表したい状態がある」ことと「今それを実装する」ことを分けて考える視点だ。現行の単軸モデルは多軸の感情を十分に表現できない。一方、その不足を認識したうえで、より中心的なループの検証を先に行う方針が選ばれている。未実装の設計案を完成品のように説明せず、判断の段階も一緒に記録することが、設計記事の正確さを支える。
更新履歴
- 2026-09-27: 初稿を作成。