沉浸创作
用 HTML/JS 构建完全自定义的互动游戏，通过 Storvia SDK 接入 AI 聊天和属性
沉浸创作允许你用 HTML + JavaScript 编写完全自定义的游戏界面和逻辑，通过 Storvia SDK 接入平台的 AI 对话、角色管理、状态追踪等能力。
和轻量创作、深度创作不同，沉浸创作不使用平台内置的聊天界面 —— 你可以自由设计任何形式的交互：直播间、社交平台、卡牌对战、文字冒险……只要你能用网页实现。
核心概念
存档隔离（每局游戏完全独立）
这是最重要、最容易被误解的一点，请务必先读懂。
玩家每开一局游戏，平台都会为这一局创建一个全新、独立、空白的会话（即一份存档）。你通过 SDK 读写的所有数据——世界状态、玩家属性、角色、关系、物品、扩展属性（custom）、游戏存档（save）、永久记忆（memory），以及所有 topic 下的聊天历史——都被平台自动绑定到当前这一局会话，互相之间天然隔离。
- 不同存档之间永远读不到对方的数据。 A 玩家的存档、B 玩家的存档、同一玩家开的第二局，都是彼此独立的容器。
- 没有"重开游戏会残留上一局数据"这种情况。 新开一局 = 一份全新的空白存档，
save.get()返回{}，各属性回到创作台配置的初始值，聊天历史为空。上一局的任何数据都不会"漏"进来。 - 存档隔离由平台自动完成，作者代码不需要、也不应该自己实现。
不要自己用 sessionId / Date.now() / 玩家 ID 之类给存档 key 加后缀来"隔离不同存档"。 这是一个常见误解。平台已经按会话隔离了一切，你只要用固定的 key（如 storvia.save.set({ ... }) 用固定结构、custom 用固定字段名、topic 用固定字符串）即可。每一局游戏里这些固定 key 读到的都只是本局自己的数据，绝不会串到别的存档。
自己加 sessionId 后缀不仅多余，反而会制造真正的 bug：同一局游戏内换了后缀就读不回自己刚存的数据，导致看起来像"数据丢失"。
一句话：会话 = 存档 = 隔离边界。固定 key 存、固定 key 取，隔离的事情交给平台。
topic（见下）是会话内部再细分聊天历史用的，和"存档之间的隔离"是两码事。
Storvia SDK
SDK 是你的游戏和 Storvia 平台之间的桥梁。它提供：
- AI 对话 — 发送消息获取 AI 回复，支持流式输出
- 消息管理 — 独立保存消息、请求 AI 生成回复
- 属性 — 读写世界状态、玩家属性、角色属性、关系、物品、扩展属性
模型选择与游戏设置（回复长度、温度等）由平台（网页端 / App）的界面提供，SDK 不渲染任何内置设置 UI；玩家在平台切换模型后，SDK 会自动应用到后续对话。
Topic（话题隔离）
每次 AI 对话可以指定一个 topic，不同 topic 的对话历史互相隔离。比如：
dm_npc1— 和角色1 的私信dm_npc2— 和角色2 的私信group_chat— 群聊
AI 在回复时只看到同一 topic 下的历史消息，不会混淆不同场景的对话。
Scene Key（场景上下文）
每次 AI 调用可以传入 sceneKey，引用创作台预设的场景设定。比如「私聊场景」「直播场景」「群聊场景」等。Scene Key 对应的设定会注入到 AI 的提示词中，但不会保存到历史记录。