設計原則と境界

Ktory の設計原則

Ktory は、対話を中心に、ホストからの入力で拍ごとに進む物語言語とランタイムです。 個人作者が、セリフ、選択肢、拍に付随する演出意図、多言語訳を、共通の持ち運べる物語構造で管理することを目指します。

このページは 設計原則の正本 の公開要約です。実装の詳細は各段階の仕様に従います。受入条件は実現すべき振る舞いを示し、すべてのホストや境界条件で検証済みという意味ではありません。

コアとホストの責任

層	責任
Ktory コア	物語の制御構造、選択の確定、呼び出しとループ、セッション内の物語履歴、言語テキストの選択、修飾子の通知
ホスト	ゲーム状態、リソースの対応付け、文字と音響映像の表示、時計、入力、外部演出による進行条件

拍（Beat）は論理的な停止点です。アニメーションの全工程でも、全体を支配するタイムラインでもありません。ホストが Step() を送る時点を決め、選択肢には SubmitChoice() を使います。コアは移動、音声、タイプライターの完了を待ちません。

Forward-only は、外部で実行済みの副作用をコアが自動で取り消さないことを意味します。前の記述へのジャンプ、ループ、呼び出しを禁止せず、将来のセーブ復元も否定しません。@speaker は表示名と別名の多言語対応を管理し、立ち絵、音声、ゲーム内キャラクターを自動で結び付ける機能ではありません。

Ink との関係

Ink は、行ごとの Continue()、選択肢、タグ、外部関数を備えています。Ink Unity Integration には Unity 接続と試読の機能もあります。ホスト駆動や描画との分離は Ktory 固有の能力ではありません。

Ktory は、構造化した拍、引数付き修飾子、同一ファイルの多言語、フォールバックと実行中の言語切替を共通の契約として定め、プロジェクトごとに作る規約を減らす方針です。言語と制作手順の選択であり、Ink では不可能という意味ではありません。成熟度や実際の接続作業量で優れていることも、まだ実証していません。

現段階と長期目標

第 1 段階はセリフ、選択肢、同一ファイルの訳文、独立試読、Unity の基本表示を中心とします。コア品質は、既存ホストからの実践的なフィードバックで継続的に検証します。

長期的には、場面ごとの信号や調整コードの繰り返しを減らします。そのために第 1 段階へ完全な Timeline 統合、永続セーブ、ボイスシステム、訳文の抽出・取込、他エンジン対応を追加することはありません。未知の Handler の診断、入力の境界、描画系をまたぐリッチテキストは引き続き検証が必要です。解析や試読の成功だけでは、ホストの演出を検証したことにはなりません。