幕后揭秘：一个没有任何外部依赖的游戏服务器
如果你接触过Web开发，你肯定知道这个段子：一个现代项目的 `node_modules` 文件夹比银河系照片还重。成百上千个外部库叠在一起，没人真正搞清楚它们都在做什么。在用Node.js开发我们的游戏时，我们走了相反的路，这是我们最自豪的开发成就之一：Dovion的服务器启动时零外部依赖。一个都没有，不引用任何第三方库。
具体来说，这意味着什么？
当一个工作室搭建在线游戏服务器，通常的反应是拼接现成模块：一个WebSocket库（负责浏览器和服务器之间的实时连接），一个文件服务库，一个这个，一个那个。初期很快。
我们把所有东西都手写了。包括最让人头皮发麻的那个部分：WebSocket服务器本身——也就是那个在服务器和每个玩家之间实时传输舰船位置、开炮动作和事件的协议。这是99%的项目不假思索直接引入的组件。我们宁愿把它理解到最后一行代码。
为什么折腾自己？
这不是（只是）受虐狂。这个选择有非常具体的优势：
- 可靠性。 每一个依赖都是风险：一次破坏性更新、第三方发现的安全漏洞、作者放弃维护的项目。零依赖 = 不会有来自外部的意外。我们今天的服务器，五年后启动时还是一样的。
- 轻量。 没有中间层：代码只做被要求做的事，不多一点。对一个需要实时模拟整个房间的服务器来说——我们在权威服务器幕后里讲过原因——每一毫秒都重要。
- 掌控力。 当凌晨两点出现Bug，它必然在我们自己的代码里。不需要翻别人写的库的内部逻辑。我们能修好所有问题，因为我们搭建了所有东西。
- 部署极简。 安装服务器就是复制文件然后启动。没有安装包，没有版本冲突，没有魔法仪式。
网络被锁的备用方案
这种掌控力的一个具体例子：某些网络——学校、公司——会阻止WebSocket连接。在大多数游戏里，这会导致一个无限转圈的连接屏幕。因为我们掌控整个网络层，我们能够构建一个HTTP/SSE备用传输方案：如果WebSocket被阻止，游戏自动切换到这条备用路线，你照样能玩。当网络层是个进口的黑盒子时，这种安全网很难建立。
缺点（因为确实有）
说实话，这个哲学有代价：时间。自己写别人一行代码就能引入的东西，需要额外数周工作，要读技术规范，要处理各种边缘情况。这是一个有热情的小项目才有的奢侈；一个有商业截止日期的团队大概承担不起。我们不会声称这对所有人都是正确的方法——这是我们的方法，符合我们的规模。
这种自制哲学不止于服务器：游戏世界本身也是由代码绘制的，没有图片文件，就像我们在吉卜力风格渲染幕后里解释的那样。最终结果：一款轻量、加载快、在低配置机器上也能运行的游戏——证明在低配置运行Dovion里。
所有这些不可见的工作只有一个目的：让你点击就能用。亲自验证：免费畅玩Dovion。