项目状态：暂停开发 / 保留试玩版本。
它最初并不叫《潮汐线》
最开始，我只是想给自己的个人网站增加一点可以玩的东西。
当时已经有一个叫 DacAI Yard 的小型网页互动实验。我并没有打算做一款多复杂的游戏，只希望它能成为一个随时可以打开、玩几分钟、随时又可以关掉的小东西。
后来我开始觉得，单纯摆放一些可以点击、拖动和触发反馈的物件，虽然有趣，但很难真正让我产生继续做下去的动力。
我更想做的是一个故事。
不是需要不停练操作的游戏，也不是复杂的解谜，而是让玩家通过选择进入不同剧情，像看一部可以参与其中的悬疑电影。
于是这个项目逐渐脱离了 DacAI Yard，变成了一个独立的剧情游戏。
我给它取名叫：
《潮汐线》。
我真正想做的，其实是一部“可以选择的悬疑电影”
在确定方向的时候，我参考过《隐形守护者》这一类互动叙事作品。
我喜欢的并不是它具体的时代背景或者玩法，而是那种体验：
玩家并不需要不停研究系统，而是在故事中做决定，然后承担决定带来的后果。
好的选择应该让人想：
“如果我当时选了另外一个，会发生什么？”
而不是：
“这道题正确答案到底是什么？”
这两个看起来很接近，实际上是两种完全不同的游戏。
当时我并没有充分意识到这个区别。
从原型到六章
《潮汐线》的开发推进得比我最初预计的顺利。
项目使用 Vite、TypeScript 和 Phaser 开发，完全运行在浏览器中，之后部署到了 Cloudflare Pages。
从最早的序章开始，我一路做了：
- 序章；
- 第一章；
- 第二章；
- 第三章；
- 第四章；
- 第五章；
- 第六章。
最终建立了完整的章节结构和五个结局。
项目中后来也陆续加入了：
- 剧情分支；
- 状态变量；
- 检查点；
- 失败后重试；
- 存档兼容；
- 多结局判定；
- 音效系统；
- 全屏与缩放；
- 桌面端和移动端适配；
- 自动化测试；
- 浏览器实际试玩验证。
到后期，自动化测试已经超过两百项。
从纯粹的工程角度看，它已经不再是一个随手写出来的网页 Demo。
玩家可以从头开始，一直玩到结局。
这也是我第一次真正把一个网页游戏从概念一路推到“可以完整通关”的状态。
但一个问题越来越明显
游戏越来越完整，我却越来越不想玩它。
这是《潮汐线》开发过程中最重要的转折。
刚开始我以为，这只是因为画面还不够好。
于是我继续调整 UI、场景、交互布局、移动端体验，后来又加入音效，希望整体体验更像一个真正的游戏。
这些修改确实让它变得更完整。
但那个“不太对”的感觉并没有消失。
后来我终于确认：
问题不在画面。
甚至也不在代码。
问题出在游戏最核心的设计上。
它逐渐变成了我原本不想做的游戏
《潮汐线》的背景涉及海上设施、灯塔、潮汐、雷达和各种设备。
这些东西最初只是为了制造悬疑环境。
但随着剧情继续推进，我不知不觉开始围绕这些设定设计玩法。
玩家需要调查信息、理解设备、判断线索，然后选择一个看起来“正确”的答案。
从开发者的角度，这似乎很合理。
有线索。
有调查。
有错误选项。
有正确路径。
甚至还能形成一套完整的系统。
但从玩家的角度，事情开始变了。
玩家本来是在看一个悬疑故事，后来却越来越像是在做阅读理解。
而且还是一个关于自己并不熟悉的行业的阅读理解。
当屏幕上开始反复出现雷达、潮汐、设备参数和航行相关内容时，我发现连我自己都开始产生疲劳。
这是一个非常明确的信号。
如果连开发者本人看到这些东西都开始觉得累，那么继续要求玩家去理解它们，并不会因为 UI 做得更漂亮就突然变得有趣。
最大的问题不是“难”，而是“为什么我要理解这些”
这件事后来让我意识到一个很重要的问题。
游戏中的知识门槛并不一定来自知识本身有多复杂。
更大的问题是：
玩家有没有动机去理解它。
如果玩家正在调查一起与自己高度相关的案件，哪怕信息稍微复杂一点，他也可能愿意研究。
但如果游戏只是告诉玩家：
“这里有一个设备，你需要理解它为什么异常。”
玩家很可能只会觉得：
“这跟我有什么关系？”
这就是《潮汐线》后来越来越明显的问题。
为了让世界显得真实，我不断增加背景信息。
为了让调查显得合理，我又不断补充规则。
为了让选择有依据，我继续增加线索。
最后形成了一个很典型的循环：
信息越来越完整，体验却越来越沉重。
还有一个更根本的问题：我开始把“选择”做成了“答题”
这是我后来认为比行业知识更严重的问题。
我原本希望玩家做的是人物选择。
例如：
要不要相信一个人。
要不要告诉他真相。
要不要冒险回去。
要不要隐瞒某件事情。
不同的选择应该改变人物关系和后续剧情。
但《潮汐线》中越来越多的选项实际上变成了：
根据刚才看到的信息，判断哪一个更合理。
这种选择看起来也是“分支”，但本质并不是剧情选择。
因为玩家真正考虑的不是：
“如果我是这个人，我会怎么做？”
而是：
“作者希望我选哪个？”
一旦玩家开始寻找标准答案，互动剧情最重要的沉浸感就已经被破坏了。
为什么不继续把它改好
发现这些问题以后，我其实面临两个选择。
第一个选择是继续。
重写后半部分剧情。
减少设备知识。
增加人物关系。
重新设计选项。
再制作更好的场景素材、音乐和演出。
理论上，这些事情都可以做。
而且因为整个技术框架已经搭好了，继续增加内容反而并不困难。
但我最后没有这样做。
原因也很简单：
这已经不是局部优化能够解决的问题。
如果只是某个按钮不好看，可以改按钮。
如果某一章节奏不好，可以重写一章。
但当我发现整个游戏的核心体验已经逐渐偏离最初目标时，再继续投入，只是在把一个错误方向做得越来越精致。
这时候，“已经做了这么多”并不是继续做下去的理由。
恰恰相反。
它更应该提醒我：
不要因为前面的投入，让后面的投入也失去意义。
所以我决定在已经可以完整通关的时候停下来
这是一个有点特别的项目状态。
《潮汐线》不是因为做不出来而停止。
最后一个正式迭代阶段已经包含：
- 六章完整流程；
- 五个结局；
- 多条路线；
- 检查点与重试；
- 存档；
- 音效；
- PC 与移动端适配；
- 两百多项测试；
- 独立线上部署。
从“能不能做出来”的角度，它已经回答了这个问题。
可以。
但我接下来更想回答另外一个问题：
做出来以后，它是不是我真正想做的东西？
答案是否定的。
所以我把它停在这里。
《潮汐线》真正给我留下了什么
虽然项目暂停了，但我并不觉得这段开发没有价值。
恰恰相反，它让我确认了很多单纯看教程或者讨论游戏设计很难真正理解的事情。
第一，技术完成度不等于作品完成度
一个项目可以没有明显 Bug，可以完整通关，可以有存档、有音效、有移动端适配。
但这些都不能证明它好玩。
工程上的“完成”和作品上的“成立”，是两回事。
第二，不要用机制掩盖故事本身的问题
悬疑故事首先必须有一个值得知道答案的谜。
如果故事本身不够吸引人，再增加调查、线索、设备、状态变量，只会让过程更复杂，并不会让谜底变得更精彩。
第三，互动剧情最重要的是“选择”，不是“判断题”
真正有意思的选择往往没有标准答案。
它应该暴露人物性格，改变关系，制造代价，或者让玩家主动走进一个自己选择的结果。
而不是考察玩家有没有看懂前一页的信息。
第四，剧本应该比程序更早成熟
《潮汐线》的一个重要问题，是我一边开发，一边继续寻找故事。
这种方式在做原型时没有问题。
但对于一个依赖反转和伏笔的悬疑故事来说，非常危险。
因为好的悬疑结构需要提前知道：
谁在撒谎。
谁知道什么。
观众什么时候知道。
哪些信息第一次出现时应该被忽略。
第二次看到时又为什么会突然变得重要。
这些东西很难靠边写边开发自然长出来。
如果我再做一个剧情游戏
我会把顺序反过来。
先不写程序。
先把它当成一部电影。
把底层真相、人物动机、事件时间线、主要反转和结局全部写清楚。
然后从头重新检查一次：
如果玩家完全不需要理解任何专业知识，这个故事本身还成立吗？
如果把所有调查系统都删除，只留下人物和选择，它还好看吗？
如果答案是肯定的，再开始做游戏。
程序应该负责把故事呈现出来。
而不是替故事制造复杂度。
项目现在的状态
《潮汐线》目前已经暂停继续开发。
现有版本仍然保留，作为这次互动叙事实验的阶段性结果。
我没有计划继续给它增加章节，也不会为了让它看起来更像“正式作品”，专门再补一轮画面或者功能。
以后如果重新做类似项目，它更可能是一个全新的故事。
《潮汐线》留下来的，不一定是一款最终完成的游戏。
更重要的是，它让我第一次非常具体地知道：
我不想做什么样的游戏。
有时候，这比知道自己能做什么更重要。
本文整理过程中使用了 AI 辅助。项目判断、内容取舍、代码实现、测试与最终验收均由本人完成。