kaedevn - ノベルゲームを作れるプラットフォーム

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

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

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

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

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

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

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

カテゴリ	内容
アクター（味方）	HP / MP / ATK / DEF / SPD、覚えるスキル、装備
スキル	攻撃／回復／バフ／状態異常、威力、MP コスト、対象範囲（単体・全体）、属性、命中判定
エネミー	HP / パラメータ、行動 AI、ドロップするアイテム・経験値・ゴールド
アイテム	消費アイテム / 武器 / 防具 / キーアイテム、効果、入手方法
ステート（状態異常）	毒・麻痺・スタン等、持続ターン、付与確率
変数 / スイッチ	グローバル・マップスコープで共有される状態フラグ

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

タイル配置：草・壁・通路・水・境界などのタイルを 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 するしかなかった依存関係が、最初からビルトインで見える設計です。

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

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

RPG Studio プロトタイプ — Database タブ

イベントコマンド 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 側の条件分岐」に直接使えます。

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

Database（アクター・スキル・敵・アイテム）を定義
マップにタイルを配置し、NPC・ワープ扉・宝箱イベントを置く
イベントにコマンド（セリフ・条件分岐・戦闘開始・マップ転送）を並べる
ノベル側からは 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 をリアルタイムで力学演算グラフとして表示するためのビュー — ツクールには存在しない概念です。

比較表（ざっくり）

観点	RPG ツクール MV/MZ	kaedevn
作れるゲーム	RPG 単独（ノベルは別ツール）	ノベル × RPG を 1 プロジェクトで
データ構造	固定テーブル + 数値 ID 参照	Entity + Relation（任意の type）
エディタ UI	言語でハードコード	Schema から自動生成
イベントコマンド	プリミティブな value 配列	TypeScript discriminated union
条件式	文字列／ID ベース	型付き union（switch / variable / item ...）
変数追跡	grep 頼み	Relation クエリで即時
バランス検証	プラグイン任せ	コア機能（balanceAnalyzer）
依存可視化	なし	Graph ビュー（impact graph）
スクリプト拡張	Ruby / JavaScript を自由に書く	Kaede Script（KS / KSC）の DSL 経由

設計のトレードオフ

得たもの	失ったもの
✅ 依存関係がすべて explicit で解析可能	❌ ツクールユーザーが慣れた「数値 ID」の手軽さが減る
✅ スキーマ変更の影響範囲が最小	❌ スキーマ定義のメタデータが増えて学習コストがある
✅ 型安全なイベント DSL	❌ TypeScript の union 型に慣れが要る
✅ 静的解析で事前にバグ検知	❌ 「まず動かす」までの実装量が多い

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

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

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

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

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

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

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

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

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

⚔️ コマンドバトル

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

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

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

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

完成時の作者体験

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

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

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

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

設計思想

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

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

3. 型安全なイベント DSL

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

比較表（ざっくり）

設計のトレードオフ

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

関連資料

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

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

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

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

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

⚔️ コマンドバトル

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

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

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

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

完成時の作者体験

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

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

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

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

設計思想

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

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

3. 型安全なイベント DSL

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

比較表（ざっくり）

設計のトレードオフ

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

関連資料

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