设计原则与边界

Ktory 设计原则

Ktory 是对白优先、宿主驱动的按拍叙事语言与运行时。 它面向独立作者，把对白、选择、按拍触发的演出意图和同文件多语言组织在可移植的基础剧情中。

本页是公众摘要。设计原则权威文档 记录项目定位与取舍；实现细节由仓库中的阶段规格约束。验收要求描述应该成立的行为，不意味着每个接入端和边界情况都已经验证。

核心与宿主各自负责什么

层次	责任
Ktory 核心	剧情拓扑、选择提交、调用与循环、会话内叙事记录、语言文本选择，以及修饰符分发
宿主	游戏世界状态、资源绑定、文字与音画呈现、时钟、原始输入，以及外部演出造成的推进条件

拍（Beat）是逻辑停止点，不是一次动画的完整生命周期，也不是全局时间线。宿主决定何时发送 Step()；选择菜单需要 SubmitChoice()。核心不等待角色移动、音频或打字机完成。

Forward-only 表示核心不自动撤销已经发生的外部副作用。它允许向前文跳转、循环与调用，也不否定未来的存档恢复能力。@speaker 只管理本地化名字和别名，不自动创建或绑定立绘、音频与游戏角色实体。

与 Ink 的关系

Ink 已有逐行 Continue()、选择、标签和外部函数，Ink Unity Integration 也提供 Unity 接入与试读工具。宿主驱动、文本与渲染解耦并非 Ktory 独有能力。

Ktory 的取向是把结构化的拍、带参数的修饰符、同文件多语言，以及回退和热切换规则作为共同契约，减少不同项目各自约定的包装层。这是语言与工作流的选择，不能据此认定 Ink 做不到，也尚未证明 Ktory 更成熟或在实际项目中一定更省接线。

当前阶段与长期目标

第一阶段围绕对白、选择、同文件译文、独立试读与 Unity 基础呈现。核心质量需要结合现有宿主接入的实际反馈持续验证。

长期目标是减少作者逐场景维护信号和协调代码的负担。第一阶段不因此引入完整 Timeline 集成、持久化存档、配音系统、翻译提取回填工具或其他引擎适配。未知 Handler 的诊断、输入边界和跨渲染器富文本仍需持续核验；可解析或能试读不等于宿主演出已经正确实现。