場・手札・プレイ
デッキ・場・手札・カードのプレイの4つの役割を整理する。
選択肢カードとGMの生成
イベントでは選択肢カードをPLに渡し、そこから選んで出してもらう。選択肢が足りなければPLが提案し、GMがその場で選択肢カードを生成してセッションに反映する。
シナリオデッキ
│
▼
イベント発生
│
▼
選択肢カードを生成
│
▼
PLに提示
│
▼
PLがカードを選んで場に出す
│
▼
世界が変化
│
├── 想定内 → シナリオに従って進行
│
└── 想定外
│
▼
PLが新しい案を提案
│
▼
GMが選択肢カード化
│
▼
場に出してセッションへ反映
│
▼
セッションログ
│
▼
後から人間が発見・評価
│
▼
シナリオ等の進化候補「選択肢カードが存在しない＝選択できない」ではない。従来型のゲームでは、シナリオに書かれていない行動はGMのアドリブに頼るしかなかった。カルタグラフでは、
Aカード、Bカードが提示されている
→ PL「Cもできませんか？」
→ GM「ではCという選択肢カードを作ります」
→ Cカードが場に出る
→ 世界がCを選んだ結果に進むとなる。「選択肢カード」はシナリオの固定された分岐ではなく、その時点でPLに提示されている世界への介入可能性になる。
例：
【イベント】
古びた扉を発見した
↓
┌────────┐ ┌────────┐
│ 開ける │ │ 調べる │
└────────┘ └────────┘
PL「壊してみたい」
↓
GMが生成
┌────────┐
│ 破壊する │
└────────┘
↓
場に出す
↓
【扉が破壊された】場・デッキ・カードの関係
- デッキ ＝ まだゲームに投入されていない可能性・情報のパッケージ
- 場 ＝ 現在のセッションで有効になった情報
- カード ＝ 世界を構成する意味のある単位
場は単なる画面上のUIではなく、現在のセッションで有効になっているカードの集合と定義する。
シナリオデッキ
↓ カードを出す
┌──────────────┐
│ 場 │
│ │
│ NPCカード │
│ 場所カード │
│ 選択肢カード │
│ 状態カード │
│ PL生成カード │
└──────────────┘
↓
カードの移動・追加・除去・反転
↓
セッションの状態が変化「場に出す」と「プレイする」は別の状態
「カードを場に出すこと」と「カードをプレイすること」は区別する。例えば「森」というロケーションカードが場に出ている状態と、「森へ行く」という選択肢カードをPLがプレイした状態では意味が違う。
- 場にあるカード ＝ 現在の状況・可能性
- プレイされたカード ＝ プレイヤーが選択・実行したこと
PLはカードをプレイすることでセッションに干渉する
これを原則として置く。
現在の状況
↓
GMから選択肢が提示される
↓
┌────────────────────┐
│ PLの手札 │
│ ・能力カード │
│ ・アイテムカード │
│ ・特徴カード │
│ ・選択肢カード │
└────────────────────┘
＋
┌────────────────────┐
│ GMから一時的に渡される │
│ 選択肢カード │
└────────────────────┘
↓
PLが1枚選ぶ
↓
カードをプレイ
↓
セッションに干渉
↓
状況が変化「選択肢が提示されている」ことと「選択肢をプレイした」ことは別の状態、という点が重要。
例：
場：
「古びた扉」
GMから提示：
[ 開ける ] [ 調べる ] [ 戻る ] [ 新たな選択肢を提案 ]
PL：
「新たな選択肢を提案」をプレイ
↓
PLが「扉を壊したい」と提案
↓
GMが「扉を破壊する」カードを生成
↓
そのカードが選択肢としてPLに渡される
[ 開ける ]
[ 調べる ]
[ 戻る ]
[ 扉を破壊する ]
↓
PLが「扉を破壊する」をプレイこれにより、「想定外の行動」をゲームシステム上の例外にしなくて済む。
「新たな選択肢を提案」カード
これを単なる便利機能ではなく、正式なカードとして扱う。つまり、
「カードに書かれていないことをする」ためのカードが、最初から存在する。
選択肢カード
├─ 開ける
├─ 調べる
├─ 戻る
└─ 新たな選択肢を提案「カードゲームだからカードに書いてあることしかできない」という閉じた構造ではなく、カードを使って、カードの外側へ手を伸ばせる。これはカルタグラフの思想として重要な部分。
カードのプレイ＝世界への操作
「新たな選択肢を提案」だけが特殊なのではなく、カードのプレイそのものが世界への操作と考えられる。
カードを見る
↓
カードを選ぶ
↓
カードをプレイする
↓
何らかの関係・状態・出来事が発生する例えば：
- 「扉を開ける」→ 場に新しい場所カードが出る
- 「攻撃する」→ エネミーとの戦闘状態になる
- 「調べる」→ 情報カードが公開される
- 「仲間を説得する」→ NPCとの関係が変化する
- 「新たな選択肢を提案」→ 新しいカードが生成される
カード＝選択肢だけではなく、カード＝セッションに対する操作・介入の単位というところまで広げられる。これは カード・デッキの考え方 の「カードはプレイによって生まれる」という考えとも繋がる。
┌──────────────┐
│ カードを持つ │
└──────┬───────┘
↓
┌──────────────┐
│ カードを選ぶ │
└──────┬───────┘
↓
┌──────────────┐
│ カードをプレイ│
└──────┬───────┘
↓
┌──────────────┐
│ セッションが変化│
└──────┬───────┘
↓
┌──────────────┐
│ 新しいカード等 │
│ が生まれる │
└──────────────┘
↓
次の手番この構造なら、セッションそのものがカードを生産する装置にもなる。
カードをプレイした結果として何が変化するのか（決着）
grillingによる深掘りの結果、以下の通り決着した。
選択肢カード＝イベントカード
PLがプレイする「選択肢カード」と、場に置かれる「イベントカード」（シーンに設定されたイベントなど）は、同一の1枚のカードとして扱う。シーンに設定されたイベントも、実体としては場に置かれた（まだプレイされていない）イベントカードである。
カードは次の3要素を持つ。
- 発火条件 — 即時発火型（プレイ＝発火）と条件待ち型（場に置かれた状態で、何らかのトリガーを待つ）の両方があり得る。条件待ち型の条件は、特定のカードがプレイされること・ターン経過・場の状態などをGMが自由記述で設定する。機械的な自動判定にはこだわらず、GMがその都度確認・判断してよい。
- 効果 — 下記「基本操作セット」の組み合わせとして構造化して記述する。
- GM向け補足 — 自由記述のヒント・裁定補足。GMは基本効果を目安にしつつ、状況に応じて采配してよい（コンセプト の進化ループとも整合する）。
効果として場に追加されるカードは、シナリオ作者があらかじめ用意したものでも、GMがその場で生成したものでもよい（カード・デッキの考え方 の「カードはプレイによって生まれる」と一貫する）。
基本操作セット
イベント効果は、以下の基本操作の組み合わせとして表現する。
- 場にカードを追加する
- 場からカードを除去する
- カードを裏返す（裏⇔表）
- カードを別のデッキへ移動する（手札など）
- カードの状態タグを変更する
- PLの手札に（一時的な）選択肢カードを配る
- GM専用ゾーンからPL可視ゾーンへカードを移動する（秘匿解除）
「場への操作」と「手札に配る」は、場（現在の状況・可能性）と手札（PLが選択・プレイできるものの集合）が別概念であることに合わせて、別の基本操作として区別する。
場のゾーン構造（GM専用ゾーン／PL可視ゾーン）については カードの裏表 を参照。
提案の裁定待ちの間の状態遷移（決着）
「新たな選択肢を提案」カードをPLがプレイしてから、GMが採用／却下を裁定して場に反映するまでの間、セッションがどう振る舞うかについて、類似コンセプトの別プロジェクト（tabifuda）との比較から出てきた論点。grillingによる深掘りの結果、以下の通り決着した。
停止の粒度
tabifudaのような、セッション全体が明示的な「休止」状態になり裁定まで一切進めない厳密な状態機械は導入しない。CarTaGraphFantasyは非同期セッションが前提で、GMがすぐ反応できるとは限らないため、「提案に対する返答（採用カード化／却下）が来るまでは、その提案から生まれるはずの新しいカードが手札に用意されない」という緩やかな待ち状態に留める。専用の状態値は新設しない。
元の選択肢は選べるか
提案をプレイした後も、元の選択肢カード（例：「開ける」「調べる」「戻る」）は手札に残り、ドライバーはGMの裁定を待たずに選んで先に進められる。待つかどうかはドライバーの裁量に委ねる（段階的な開示・習熟によるアンロックなどと同じ、機械的な強制より人間の裁量を優先する一貫方針）。GMの裁定が追いつく前に他の選択肢が先に選ばれた場合、提案カードが後から採用されても「今回は使われなかった」扱いとして、次項の却下相当の記録に残す。
却下の扱い
進化候補の却下の扱いと同じ考え方で、削除せず却下ステータスのまま判断理由とあわせて記録を残す。却下された提案とその理由は、GM専用の記録に留めず、PLにも見える形（PL可視ゾーン）に置く。自分の提案がどう扱われたかをPLが知れることを優先する。
タイムアウト
GMの裁定待ちに専用のタイムアウトルールは設けない。非同期セッションの終了条件にある「一定期間、参加者から反応がなければ自動的に『中断』扱いになる」を、GMの裁定待ちにもそのまま適用する。
採用時の検証
tabifudaの「パッチ」のような、構造化された差分と壊れた改編（現在いるシーンを消してしまう等）を機械的に拒否する検証の仕組みは導入しない。GMがその場で選択肢カードを1枚生成するだけでよく、生成されたカードは通常のカードと同じ構造を持つ。壊れた改編を防ぐ判断はGMの裁量に委ねる（「機械的な自動判定より人間の裁量を優先する」という一貫方針）。
カード効果の「対象（Target）」指定方法（決着）
基本操作セットのうち、「PLの手札に選択肢カードを配る」「カードの状態タグを変更する」等、対象を必要とする効果の指定方法について、類似コンセプトの別プロジェクト（tabifuda）との比較から出てきた論点。grillingによる深掘りの結果、以下の通り決着した。
役割参照と実名参照の区別
PCを対象とする指定は、次の2種類に区分する。
- 役割参照 — シナリオ作者が事前に書くシナリオデータの中で使ってよい。シナリオ作者は執筆時点で、実際に参加するPCの実名を知らないため。
- 実名参照 — 特定のPCを名指しする指定。GMがセッション中にその場で使う（提案の採用時のカード化など）専用とし、シナリオ作者データには使わせない。
これはtabifudaの「Party（役割参照）はシナリオ内でOK、Character(id)（実名参照）は上演中専用」という区別と同じ発想。ただしtabifudaと異なり、シナリオデータへの実名参照混入を機械的なlintで検出する仕組みは導入しない。「機械的な自動判定より人間の裁量を優先する」という一貫方針（提案カードの採用時の検証など）に沿い、GM／シナリオ制作者の裁量に委ねる。
役割参照の種類
最初に用意する役割参照は次の2種類。
- Party — パーティー全員。
- Driver — カードをプレイする権限を持つドライバー本人。ドライバーの離脱・交代が起きても、常にその時点の担当者を指す動的な参照とする。
これ以外の役割参照（例：HPが最も低いPCなど条件付き参照）は、tabifudaの「必要になった時点で追加する」方針を踏襲し、必要になった時点で追加する（追加しても既存データは壊れない設計とする）。
NPC・エネミーへの対象指定
PCの「役割参照／実名参照」の区別はPC専用の話とする。NPCカード・エネミーカードはシナリオ作者自身が定義したカードであり、執筆時点でそのカードIDを作者自身が把握しているため、シナリオデータの中で通常のカードID参照として直接指定してよい。
戦闘の対象選択（射程・グループ）との関係
戦闘ルールの「射程・グループ」によるプレイ時の対象選択とは別の仕組みとして扱う。射程・グループはPLが攻撃カードをプレイする瞬間に動的に選ぶ空間的な対象選択であり、今回のTargetはカード定義側があらかじめ記述する配布・状態変更の対象で、目的も決まるタイミングも異なるため無理に統合しない。