RPG ゲーム機能 ロードマップ

kaedevn は ノベルゲームと RPG ゲームのどちらも作れるプラットフォームを目指しています。

• 🖋️ ノベルゲーム：テキスト・分岐・ブロックで物語を編む。VRM / Live2D キャラをシーンに配置。稼働中
• 🗺️ RPG ゲーム：Database（アクター・スキル・敵・アイテム）、タイルマップ、イベント、ターン制バトル。開発中（本ページ）

ノベル単体・RPG 単体・そして両方を組み合わせた作品が同じプラットフォームの中で作れるのが最終的な狙いです。「ノベル本編の途中にミニ RPG を挟む」も「RPG の会話シーンをノベルで演出する」も、どちらも同じ方向から支えられる設計になっています。

⚠️ このページで説明する RPG 機能はまだ開発中です。現時点で作者の皆様は利用できません。 ノベル側の機能は マイページの使い方 / エディタ完全ガイド から今すぐお試しいただけます。

---

RPG ゲーム機能で何ができるようになるか

完成時に作者が扱える機能群です。RPG ツクール MV/MZ と同等の表現力を目指していますが、内部設計は別物です（→ 設計思想）。

🎭 Database — ゲームの登場要素を定義

🗺️ マップエディタ — 歩ける世界を作る

• タイル配置：草・壁・通路・水・境界などのタイルを 20×15 マスに塗る
• イベント配置：NPC・宝箱・ワープ扉などを座標指定で設置
• リージョン：範囲ごとに BGM やエンカウントレートを設定
• マップ間遷移：transfer_player イベントで別マップへジャンプ
• ミニマップ / UI：プレイヤーの位置をリアルタイム表示

🎬 イベントコマンド（21 種） — RPG の "動き" を書く

RPG ツクール MV/MZ と同等の 21 種のコマンドを実装済み：

• セリフ表示 / 選択肢
• スイッチ・変数操作（= / += / −= / ×= / ÷=）
• セルフスイッチ（A〜D）
• 条件分岐（then / else、ネスト無制限）
• マップ転送（プレイヤーを別マップへ）
• 戦闘開始（結果で勝利 / 敗北分岐）
• BGM / SE 再生
• ゴールド・アイテムの増減
• パーティメンバーの入替
• 全回復
• ウェイト / コメント

これらは Kaede Script（KS / KSC）とは別系統のビジュアル DSLとして設計されており、ドラッグ&ドロップで組み立てられます。裏側の実装は TypeScript の discriminated union で型検査が通った状態のコマンドツリーが常に保たれます。

⚔️ コマンドバトル

• ターン制：素早さ（SPD）順に行動
• コマンド選択：攻撃 / スキル / アイテム / 防御 / 逃げる
• ダメージ計算：(ATK × power) − DEF、命中判定、属性倍率
• 状態異常：毒・麻痺・スタンの処理、持続ターンの管理
• 勝敗判定：敵全滅 / 味方全滅 / 逃走 / 継続
• 決定論的：シード付き乱数により、同じ入力で同じ結果を再現可能（デバッグ・動画撮影に便利）
• simulate() 関数：バトル全体を高速シミュレーションして勝率・期待ダメージを事前計算

詳細は バトルシステムガイド。バトルパッケージ自体は外部依存ゼロで、ネイティブエンジン（Switch 移植）にもそのまま持ち込めます。

🎯 Graph ビュー — 依存関係の可視化（ツクールにはない）

「この変数は誰が書き込むか」「このスキルは誰が覚えるか」「このイベントを削除すると何が壊れるか」をワンクリックで表示する Graph ビューを搭載予定。選択した要素から 3 段階先までの影響範囲を力学演算でリアルタイム可視化します。

RPG ツクールでは grep するしかなかった依存関係が、最初からビルトインで見える設計です。

---

いま何ができていて、何ができていないか

実装済み（内部のみ・作者非公開）

• イベントコマンド 21 種 — apps/editor/src/types/eventCommand.ts に型定義、EventInterpreter.ts で実行
• Database バックエンド（@kaedevn/entity-graph）— アクター・スキル・敵・アイテム・変数・マップイベントすべて同じ Entity 型で管理、67 tests all-pass の安定品質
• 静的解析：未使用変数検出、バランスシミュレータ（ダメージ公式パース → ワンショット・0 ダメージ検知）
• RPG Studio アプリ（apps/rpg-studio）— Database / Map / Events / UI Layout / Graph / Analysis / Play Game の 7 タブ構成の試作 UI（2026-04-21 にブラウザ動作を確認）
• サンプルデータ：アクター・スキル・敵・クエストフラグ・イベントのリファレンス実装
• バトルシミュレータ — 決定論的な simulate() 関数
• 永続化レイヤ — ブラウザ用 LocalStorageAdapter と CLI 用 FileStorageAdapter を同一 StorageAdapter インターフェースで実装

未実装（作者が触れるようになるまで）

• ノベルエディタ ↔ RPG Studio のシームレス統合 — 1 つのプロジェクトで両方のゲームタイプを切り替え
• バトル画面の演出 — スキルエフェクト・カメラワーク・ダメージ表示アニメ
• 公式 RPG アセット — キャラチップ・タイルセット・戦闘エフェクト・効果音
• モバイル最適化 — タッチ操作、仮想スティック
• プレイヤー視点の完成 — rpg-studio のデータを読み込んで実際にプレイする画面（現在はサンプルハードコード）
• Switch 移植の検証 — Core コマンドセットに収まるパフォーマンス予算を確認

---

完成時の作者体験

以下の 3 つのパターンで、RPG 要素を使った作品が作れるようになります。

パターン A：ノベル本編 × ミニ RPG ゾーン

〔ノベルシーン〕 主人公が町に到着
    ↓
〔RPG ゾーン〕 町を歩き回って NPC と会話、ダンジョンへ
    ↓
〔バトル〕 コマンドバトル
    ↓
〔ノベルシーン〕 バトル結果に応じたエンディング分岐

パターン B：RPG 本編 × ノベル演出シーン

〔RPG フィールド〕 ダンジョン探索・レベリング
    ↓
〔ボス戦〕 コマンドバトル
    ↓
〔ノベル演出〕 勝利後のイベントを VRM / Live2D で演出
    ↓
〔RPG フィールド〕 次のマップへ

パターン C：両方が対等に混ざる作品

どちらもエディタ内で自由に行き来可能。変数・フラグ・アセットはすべて共通の Entity として管理されるため、「ノベル側で立てたフラグ」が「RPG 側の条件分岐」に直接使えます。

作者の作業フロー（想定）

1. Database（アクター・スキル・敵・アイテム）を定義
2. マップにタイルを配置し、NPC・ワープ扉・宝箱イベントを置く
3. イベントにコマンド（セリフ・条件分岐・戦闘開始・マップ転送）を並べる
4. ノベル側からは call ブロックで RPG シーンを呼び出し、戻ってくる

---

設計思想

「RPG ツクール MV/MZ と同等の機能を提供しつつ、内部設計は別物」 — これが kaedevn の RPG の立ち位置です。同じような作品体験を作れるように外見は揃えつつ、以下 4 つの本質で根本的に異なるアプローチを採っています。

1. すべてが Entity、参照はすべて Relation として明示

ツクールでは Actor / Skill / Enemy / Item が固定スキーマのテーブルに入り、相互参照は数値 IDで表現されます（「変数 #42」「スキル #5」等）。@kaedevn/entity-graph はこれをグラフ構造に置き換えました。

// packages/entity-graph/src/types/entity.ts
export interface Entity {
  id: string;
  type: string;           // "actor" / "skill" / "map_event" / "variable" ...
  properties: Record<string, unknown>;
}

export interface Relation {
  sourceId: string;
  targetId: string;
  type: string;           // "learns" / "writes" / "reads" / "unlocks" ...
}

アクターもスキルもマップイベントも変数も、すべて同じ Entity 型。依存関係は Relation として明示的に記録されます。

// apps/rpg-studio/src/sampleData.ts
createRelation(hero.id, slash.id, "learns"),       // Hero が Slash を覚える
createRelation(oldMan.id, questFlag.id, "writes"), // 老人イベントが questFlag に書き込む
createRelation(gateGuard.id, bossFlag.id, "reads"), // 門番が bossFlag を読む

→ 「この変数、どこから書き込まれるの？」「このスキル、誰が使える？」が store.getRelated(id, type, dir) でクエリできる。ツクールでは grep するしかなかった依存関係の可視化が、ビルトインで成立します。

2. Schema 駆動 UI（エディタが自動生成される）

ツクールでは新プロパティ（例：アクターに「職業」を追加）を入れると、editor.js / database.json / game.js を全部書き換える必要があります。

kaedevn では スキーマ定義を 1 か所変えるだけ で、TableView / DetailView / PropertyEditor / CommandEditor がすべて自動対応します。

// packages/entity-graph/src/types/schema.ts
export interface EntitySchema {
  type: string;
  properties: PropertyDef[];       // UI はここから生える
  allowedRelations: RelationDef[]; // 「Actor は Skill に learns する」等
}

3. 型安全なイベント DSL

ツクールのイベントコマンドはプリミティブな value オブジェクトの配列で、パラメータの型チェックは実行時まで無い。kaedevn はこれを TypeScript の discriminated union で書き直しました。

// apps/editor/src/types/eventCommand.ts
export type EventCommand =
  | ShowTextCommand
  | ConditionalBranchCommand
  | ControlVariablesCommand
  // ... 21 種
  ;

export type ConditionalBranchCommand = {
  type: 'conditional_branch';
  condition: BranchCondition;
  thenCommands: EventCommand[];     // 再帰型：ネスト無制限
  elseCommands?: EventCommand[];
};

• 各コマンドが独立した型（IDE 補完・型検査が効く）
• 条件式も union 型：{ type: 'switch'; ... } | { type: 'variable'; ... }
• thenCommands が再帰的な EventCommand[] なので、ネストに制限なし

4. 静的解析・バランスシミュレータがビルトイン

ツクールには「未使用変数を検出」「ダメージ計算式を事前評価」といったツールは基本ありません。プラグインで頑張る領域でした。

kaedevn の packages/entity-graph にはこれがパッケージ機能として内蔵されています：

• analysis/staticAnalyzer.ts — 未使用変数、未書き込み変数、循環呼び出しを検出
• analysis/balanceAnalyzer.ts — ダメージ公式をパースして「ワンショットキル」「0 ダメージ」のバグを検出
• analysis/impactGraph.ts — 選んだエンティティから BFS で 3 段階の影響範囲を可視化

Graph ビュー はこの impact graph をリアルタイムで力学演算グラフとして表示するためのビュー — ツクールには存在しない概念です。

---

比較表（ざっくり）

設計のトレードオフ

---

なぜ完成に時間がかかっているか

上記の設計はエディタ側 UI（rpg-studio）とバックエンド（entity-graph）の両方を同時に作り込む必要があり、既存ツクールの fork より労力が大きくなっています。具体的には：

1. バックエンド（entity-graph）は 67 tests all-pass の品質で安定
2. フロントエンド（rpg-studio）の各機能（Database / Map / Events / Graph）は個別に動くが、「ユーザーが作ったゲームデータを読み込んで実際にプレイできる」までの配線（Phase 1-3）が未完
3. fileStorageAdapter.ts が Node fs を使っているためブラウザで動かない → 2026-04-21 解消済み（バレル export から除外し、ブラウザ側は LocalStorageAdapter のみ読み込む構成に）

作者公開への次のハードルは「エディタで作ったゲームデータを実際にプレイできる画面」の完成（Phase 1-3）です。

---

関連資料

• エディタ完全ガイド — 現在利用できるノベルエディタの機能
• ブロック型リファレンス — 既存のブロックと、将来的にイベントコマンドと統合されるもの
• Kaede Script 概要 — 2 記法（KS / KSC）の使い分け
• KSC（コード記法）仕様書 — RPG ロジックの一部はすでに KSC で記述可能
• バトルシステムガイド — 実装済みのバトルパッケージ
• 3D マップ / オープンワールド ロードマップ — 3D フィールドとの接続計画
• ロードマップ 2026 — プロジェクト全体の年間計画