把《软件体的生命周期》做成可玩 Visual Novel：一次完整的迭代复盘
这次做的不是“套个阅读器皮肤”，而是把 软件体的生命周期.md 这份完整文本，真正改造成一个可玩的日式 GALGAME 风格视觉小说，并且从头到尾遵守一个硬约束：原文只能多不能少，不能丢任何文本细节。
整个过程不是一次成型，而是典型的“先做通，再一点点把违和感磨掉”的连续迭代。回头看，基本可以分成下面几个阶段。
1. 起点很明确：不是节选改编，而是全文保真改造
一开始的目标就很硬：
- 剧本来源是本地的
软件体的生命周期.md - 全文都要进游戏
- 不能因为做成游戏，就把原文删成摘要、对白版或者轻小说版
- 文本表现可以增强，但文本内容本身不能缩水
所以这次项目的底层思路不是“编一个 VN 剧本”，而是“把原文切成适合视觉小说推进的段落结构，同时保留完整可回看原文”。
后面整个系统里，像章节导航、原文总览、逐段定位、回看、进度保存，其实都围绕这个前提服务。
2. 第一版能跑，但不像 Visual Novel
最开始做出来以后，最大问题不是功能缺失，而是气质不对。
虽然已经能推进文本、显示内容、切段，但界面看上去更像一个带控制面板的网页阅读器，不像日式 GALGAME。用户第一反应也很直接：“这界面根本就不对，做成日式 galgame 那种 UI。”
于是后面第一轮重构，重点不是加功能，而是先把视觉语言掰正：
- 舞台层、前景层、文本框层重新分开
- 章节标题、书名页、过场卡重新设计成视觉小说式表现
- 文本框改成固定在舞台上的 VN 对话框，而不是普通网页卡片
- 角色发言区、名字牌、进度条、推进按钮整体做成更接近日式视觉小说的布局
这一轮的意义是：先让它看起来像一款游戏，再继续补游戏该有的交互。
3. 角色立绘补齐，舞台从“有图”进化到“像舞台”
用户明确提了一个要求：每个角色都得有立绘。
所以后面做的不是随便给几个主角配图，而是把角色立绘体系真正搭起来：
- 角色立绘数据独立管理
- 不同角色有自己的舞台定位和显示样式
- 单角色、多角色、多人同台都能排布
- 角色讲话时有突出态，旁听角色有弱化态
- 不同角色对话文字支持对应颜色
但这一块也经历了很多轮打磨。中间出现过几个典型问题：
- 有角色只显示到下半身
- 文本框太大，把舞台挡住了
- 多角色同台时，舞台显得很挤
- 存档缩略图里，立绘经常被裁头或者只剩腿
后面围绕这些问题又做了很多修正：
- 调整舞台高度和立绘缩放逻辑
- 区分 human / digital / entity 三类立绘尺寸
- 允许舞台整体横移、纵移、缩放
- 给多人同台做更合理的 slot 分布
- 修缩略图构图，尽量保留完整身形，避免存档卡里角色被裁烂
到后面，它就不再只是“几张图摆上去”，而是开始有了明确的舞台感。
4. 文本框自由度，几乎被做成了一个可调布局系统
这个项目里，文本框是被用户盯得最狠的一块，也是后面做得最深的一块。
用户连续提了很多非常具体的要求：
- 支持用户自定义文本框位置
- 支持边角调整大小
- 支持透明度调整
- 支持文字速度最快直接秒出
- 支持不同角色对应不同文本颜色
- 文本框不能锁死满宽
- 可以变窄，也可以变宽
- 不能总挡住立绘
- 顺时（右侧布局）要放到最右边
于是后面不是简单做了个“拖动文本框”，而是逐步把它做成了完整布局系统：
- 支持拖拽移动文本框
- 支持四边与四角八方向缩放
- 支持宽度、高度自由调节
- 支持预设布局：居中、左下、右下、左上、右上
- 支持透明度、字号、行距调整
- 支持自定义后保存进度，下次恢复
- 文本框位置变化会联动舞台避让，减少遮挡角色
这里有个很关键的转折：
一开始虽然支持了改尺寸，但仍然有“最窄还是满宽”“视觉上像锁死”的问题。后面专门继续修了最小宽度、默认宽度和自定义尺寸逻辑，才真正实现了用户想要的那种自由变换，而不是“看起来能调、实际上调不动”。
5. 标题、章节过场和占位信息，反复做减法
另一个明显的迭代方向，是把那些会打断阅读的多余 UI 慢慢拿掉。
用户提过几个很典型的抱怨：
- 左上角这两个框能不能自动消失，不要留占位
- 书名和第 x 章大标题只在切换章节时出现一次，不要每句都弹
- 不要总把一些说明块挂在画面上
所以后面我做了几轮“只在该出现时出现”的收束：
- 书名页 / 章节标题改成仅在真实章节切换时短暂显示
- 平常阅读状态自动隐藏大标题和占位框
- 无立绘场景不再显示大号空占位卡
- 顶部 HUD 闲置后自动淡出
- 阅读提示在桌面端空闲后自动退场
- 拖拽提示、缩放把手在安静阅读时弱化，只在交互时恢复
- 立绘脚边标签在安静阅读态下自动淡出，交互或角色变化时再亮起
这一连串调整其实都在做同一件事：
把“工具界面感”压下去，把“阅读演出感”提上来。
6. 推进方式补齐，操作体验更像真正的视觉小说
在基础推进之外，后面还把常见 VN 交互习惯补得比较完整：
- 文本框外点击可推进
- 鼠标滚轮下一条 / 上一条
- 空格、回车、方向键推进
- 自动播放
- 已读跳读
- 右键或快捷键隐藏界面
- 长按空白区域切换隐藏界面（移动端）
这里也不是一次就对的。
比如最近刚修的一处问题，就是展开控制时滚轮能用，但收起控制后滚轮失效。原因是正文区域被错误当成“应拦截滚动”的区域。后面把这个判断修掉，又专门补了一条自动回归，确保以后“控制收起后，把鼠标放在正文文字上滚轮仍然能前进 / 后退”。
这类修复虽然小，但很关键，因为它直接决定成品像不像一个真的能长期阅读的 VN。
7. 存档、回看、原文总览，这次不是附属功能，而是核心功能
因为本项目从一开始就要求“原文保真”，所以一些常规游戏里属于附加项的功能，这次其实是主功能：
- 自动存档
- 快速存档 / 快速读档
- 多槽位手动存档
- 读取时恢复文本框位置、尺寸、阅读偏好
- 回看最近段落
- 章节导航
- 原文总览与目录
- 从游戏段落反查原文行号并定位
尤其是“原文总览”和“段落对应原文行号”这件事，实际上是把“改编成游戏”这件事做得很透明：
你不是只能在游戏层里推进，也可以随时回到完整原文结构里看自己现在到底读到哪一行。
8. 存档缩略图和阅读态细节，都是靠一轮轮微调磨出来的
到后面，真正花时间的已经不是大功能，而是大量“用户一眼就会不爽，但不一定一句话能说清”的细节。
比如：
- 存档缩略图里立绘被裁头
- 立绘脚边标签太像调试信息
- 文本框提示、拖拽手柄太显眼
- 顶部 HUD 常驻会抢戏
- 多人同台时阅读视线被 UI 打散
这些问题后面基本都不是靠“多加功能”解决，而是靠节奏控制：
- 什么该常显
- 什么该淡出
- 什么该 hover 才出现
- 什么该只在状态切换时短暂提示
做完这些之后，游戏的感觉会明显从“功能很多的网页”往“能安静读下去的视觉小说”那边偏。
9. 自动化验证是后期能持续迭代的关键
后面用户一句话说得很明确：“你就不断的自己增强优化和验证我们这个服务的功能。”
所以再往后，我不是只改画面，而是把自动验证链路也一起补上了。项目里后面有一套 Playwright 风格的 UI 验证脚本，用来反复检查这些关键点：
- 标题是否按时出现 / 隐藏
- 默认文本框是否挡舞台
- 文本框拖拽 / 缩放 / 吸附是否正常
- 自定义位置和大小是否能保存恢复
- 顶部 HUD 是否会自动淡出
- 阅读提示与拖拽把手是否会在空闲时弱化
- 存档抽屉、自动存档、快速存档缩略图是否正常
- 多角色同台在桌面端 / 移动端是否越界
- 移动端长按隐藏界面是否正常
- 收起控制后的滚轮推进是否正常
这意味着后面的优化不是“改一处、赌别的地方别坏”，而是可以边改边回归。
这个能力对这种高度交互化 UI 项目非常重要，不然改到后期很容易出现“修了 A，炸了 B”。
10. 现在这个项目的状态
到目前为止，这个《软件体的生命周期》GALGAME 项目，已经具备了比较完整的可玩性和可读性：
- 原文全文保留，非摘要式改编
- 日式 GALGAME 风格主界面
- 全角色立绘接入
- 不同角色对应不同文字颜色
- 章节切换过场与书名页展示
- 文本框自由拖拽、缩放、透明度调整
- 文字速度支持瞬时显示
- 文本框外点击推进
- 滚轮上一条 / 下一条
- 自动播放、跳读、隐藏 UI
- 自动 / 快速 / 手动存档
- 回看、章节导航、原文总览
- 桌面端 / 移动端适配
- 多轮交互去工具化打磨
- 自动化验证脚本持续回归
如果说最初的目标是“把一份 md 文本做成游戏”，那现在更准确的说法应该是：
把一份完整长文本，做成了一个可读、可玩、可回溯、可持续打磨的视觉小说系统。
11. 这次项目最有意思的地方
对我来说，这次开发里最有意思的一点，不是“做出了一个 GALGAME 页面”，而是这整个过程非常典型地说明了一件事：
真正把东西做得像样，往往不是靠第一版把功能堆全，而是靠用户不断指出“哪里不对劲”，然后一轮一轮把这些违和感清掉。
这次用户给的反馈非常具体，而且很多都不是泛泛的“再优化一下”，而是：
- 这里挡画面了
- 这里为什么锁死满宽
- 这里为什么每句都弹
- 这个只显示下半身
- 这个左上角为什么不彻底消失
- 这个滚轮为什么收起控制就失效
正是这些非常具体的“看着不顺”的点，最后把项目从“能用”推到了“像回事”。
如果后面还继续做，我觉得还能继续打磨的方向包括：
- 更统一的角色立绘风格
- 更细的章节演出与 BGM/SE 系统
- 更完整的 CG / 背景切换系统
- 更强的脚本编排能力
- 更正式的发布打包方式
但就目前这一轮来说，这已经不是 demo 了，而是一个相当完整的、可以持续迭代的 VN 原型。