文字互动游戏构建器

概述

小红书文字游戏构建工作流

把短剧的节奏与题材，转化为可上传的小红书小工具（纯前端离线 H5）。

何时使用

• 用户要做一个新的文字游戏 / 互动小说 / 文字冒险小游戏
• 用户想把某个短剧题材改编成小游戏
• 已有文字游戏需要加背景图、图标、结局卡
• 需要判断某个题材适不适合做文字游戏

前置依赖（必读）

推荐先加载容器规范技能 minitool-zip-builder（小红书小工具构建指南，独立发布物，需另行获取）。它提供容器规范的权威定义：

• 目录结构、index.html 模板、路径规则
• 可用 / 不可用能力清单
• Chrome 61 基线与回退写法、ES2017 上限
• window.xhs.miniTool.* 原生能力
• 官方体积门禁脚本 audit_artifact.py

若该技能不可用，按下列核心约束自查（本技能可独立完成创作与打包）：

合规扫描是全量文本扫描，注释里出现上述词同样会命中——注释也要按最严标准写。

scripts/build.py 已内置这份禁用能力扫描 + 打包，可直接使用。

本 skill 只负责创作与整合，容器合规一律以官方规范为准。

一、选题：先过决策矩阵

两个轴：题材热度趋势 × 文字游戏适配度。

适配度判断标准：情节是否主要靠信息差而非视觉奇观推进。零美术资源能讲清楚的，适配度就高。

热度数据查 DataEye 微短剧月报（题材热力值 TOP20）。

二、能借 / 不能借（认知对齐，最重要的一节）

能借

1. 节奏结构 — 钩子密度、集尾悬念 → 直接映射为决策点
2. 情绪曲线 — 爽点位置、每 30 秒一次转折 → 决策点密度
3. 题材配方 — 题材 × 情绪的搭配关系

不能借

1. 画面冲击 — 短剧靠巴掌特写、镜头推近、配乐起；文字游戏只能用信息差。这是最大的坑
2. 长线连载 — 小红书小工具无持久存档，必须一局通关。60-80 集要压成 8-10 个决策点（每 6-8 集 ≈ 1 个决策点）
3. 3 秒一爆的极限节奏 — 短剧划走成本为零；游戏用户已付出注意力，节奏可略慢

三、核心方法：把"看到"换成"意识到"

短剧靠"看到"，文字游戏靠"意识到"。

两种已验证有效的具体手法：

1. 数字咬合 — 多个细节互相印证（例：领标「第 89 天」+ 工牌「入职第 90 天」+ 排班表九行名字八道划痕 → 玩家自己推出「一班只上十天」）
2. 首尾呼应 — 开场的一句话，在结局以相反的方式重现（例：开场别人说「这顿你请」，结局主角自己说「这顿我请」）

爽点应当是"意识到"的瞬间，不是事件本身。

四、五步转化法

1. 选题 — 过决策矩阵
2. 拆骨 — 剧集压成 10 个决策点（每 6-8 集 ≈ 1 个）
3. 换血 — 按上表把视觉冲击改写成信息冲击
4. 埋钩 — 每个决策点末尾留悬念，且选项本身要带信息差（不是「打/跑/说」，而是「看监控 / 听门外 / 拉开门」）
5. 收口 — 3 个结局按线索阈值判定，绝不做 729 条真分支

伪分支（关键设计约束）

节点线性推进，选项不改变主线走向，只改变两件事：

• 是否获得线索（决定结局档位）
• 玩家看到的反馈文本（echo）

否则 10 个决策点 × 3 选项 = 59049 条路径，文本量指数爆炸。

五、剧本结构规范

剧本写成单个 story.js，导出全局 var STORY：

var STORY = {
  start: 'n1',
  clueTotal: 10,
  meta: {
    title: '游戏名',                         // 开场屏主标题 + 文档标题 + HUD 品牌
    subtitle: '文字现代都市小游戏 · 多种结局等你探索',
    hint: '游戏名',                          // HUD 右侧
    footer: '文字现代都市小游戏'              // 结局卡底部
  },
  nodes: {
    n1: {
      chapter: '01 / 章节名',
      lines: [
        { t: '正文一行' },
        { t: '需要强调的行', c: 'warn' },      // c 可选：warn 红 / sys 灰 / sep 分隔
        { t: '——', c: 'sys' }
      ],
      choices: [
        { label: '选项文字', to: 'n2', clue: true, echo: '选后反馈。n用 \n 分行。' },
        { label: '另一个选项', to: 'n2', echo: '不给线索的选项。' }
      ]
    },
    // ...
    end_true: {
      chapter: '结局 · 名字',
      cardQuote: '结局卡上的金句',
      ending: true,
      lines: [ /* 结局正文 */ ]
    }
  }
};

结构硬性要求：

• 每个 scene 节点 3 个选项，其中 2 个给线索、1 个不给（制造取舍）
• 所有 scene 节点的选项最终汇聚到同一个下一节点（伪分支）
• 结局按 clues 阈值三分：>= 8 真结局 / 4-7 中结局 / <= 3 坏结局
• 单次通关可见字数目标 2000-2800 字，预计时长 8 分钟
• 每行 ≤ 25 字，一屏 8-10 行
• 台词口语化；写完念一遍

结局设计：三个结局要有质的差别，不是「成功/失败」两档加一个中间值。坏结局不该是惩罚，而应是另一种合理的选择带来的不同代价。

六、文件结构

<游戏目录>/
├── index.html      # 入口，相对路径引用
├── style.css       # 从 assets/engine.css 复制，有背景图时改 body 的 background
├── app.js          # 从 assets/engine.js 复制，通常【零改动】
├── story.js        # 唯一需要原创的文件
└── bg-xxx.jpg      # 背景图（可选）

app.js 是通用引擎，题材相关的文字全部从 STORY.meta 读取，做新题材不需要改引擎。

七、背景图（可选）

必须后处理才能用，否则文字读不清：

1. 裁掉水印（AI 生成图右下角通常有）
2. 亮度 ×0.50、饱和 ×0.82
3. 加径向暗角（在 64×88 缩略图上逐像素算，再 BICUBIC 放大到全尺寸 — 直接遍历百万像素会极慢）
4. 缩到 900 宽，JPEG q80，目标 < 100 KB

CSS：

body {
  background-color: #0B0D10;
  background-image: url("./bg-xxx.jpg");
  background-size: cover;
  background-position: center top;
  background-repeat: no-repeat;
}

生成后的必做验证：用 Pillow 在图上叠加真实游戏文字，检查可读性。

八、图标

规格：1024×1024 PNG，1:1。

固定骨架（保证系列感）：深底 #0D1114 + 居中主符号 + 红色横标 #E24B4A。

直接用附带脚本生成，无需手写绘图代码：

# 汉字 / 短文本主符号
python scripts/make_icon.py --text 单 --out icon-1024.png --thumbs

# 小票（清单）图形
python scripts/make_icon.py --style receipt --out icon-1024.png --thumbs

# 货币 / 符号
python scripts/make_icon.py --style currency --text "¥" --out icon-1024.png --thumbs

--thumbs 会同时导出 256 / 48 / 32 三个尺寸，必须目检 32px 版本。

字体选择必须做小尺寸实测（72 / 48 / 32 px）：

• 主符号是数字 → 无衬线粗体即可
• 主符号是 ≥2 个汉字 → 必须用粗字重（微软雅黑 Bold）。宋体、细体在小尺寸下笔画会糊成一片
• 不要只看大图选字体，大图上精致的细体缩小后往往不可读

脚本内置跨平台字体候选（Windows 雅黑 / macOS 苹方 / Linux Noto CJK），自动取第一个可用的。

九、打包与校验

# 1. 合规自检 + 打包（脚本已内置禁用能力扫描）
python scripts/build.py <游戏目录> <输出.zip>

# 2. 官方体积门禁
python <minitool-zip-builder>/scripts/audit_artifact.py <输出.zip>

# 3. 语法检查
node --check app.js && node --check story.js

打包要求：zip 根目录直接放文件，不套一层文件夹。脚本已处理。

注意：合规扫描是全量文本扫描，注释里出现禁用关键词（如 new Function、WebAssembly）同样会命中——注释也要按最严标准写。

十、交付前自查

• [ ] 首屏 3 行内抛出冲突（无标题页、无「开始游戏」按钮，开场屏只需 1 秒读完）
• [ ] 10 个决策点，每个 3 选项（2 给线索 / 1 不给）
• [ ] 每个决策点末尾有钩子
• [ ] 选项文字本身带信息差，不是「打/跑/说」
• [ ] 全部选项汇聚回主线（伪分支，无指数展开）
• [ ] 3 个结局有质的差别
• [ ] 单次通关 2000-2800 字
• [ ] STORY.meta 四项齐全
• [ ] 禁用能力扫描通过；注释中无禁用关键词
• [ ] 官方体积门禁 PASS；zip < 2 MB
• [ ] 图标做过 32px 小尺寸实测
• [ ] 背景图做过文字可读性验证（如使用）

十一、脚本清单与边界

附带脚本

用法见对应章节。build.py 退出码：0 = 通过，2 = 命中禁用能力（会列出文件名与行号）。

这个技能不做什么

• 不提供容器规范的权威定义 —— 那是容器规范技能（如 minitool-zip-builder）的职责；本技能只做创作与整合
• 不生成美术资源 —— 背景图、图标是可选增强；核心玩法必须靠"信息差"成立，零美术资源也能通关
• 不做真分支叙事 —— 明确使用伪分支（选项不改变主线走向），这是设计约束而非能力限制
• 不涉及需要联网、登录、持久存档的玩法 —— 容器纯本地离线，无持久存档，必须一局通关
• 不产出短剧剧本 / 视频脚本 —— 只做"短剧套路 → 文字游戏"的转译