决定要写这玩意的起因
最近琢磨着把《凪光》这个项目的介绍和更新日志彻底理顺一遍。别看只是个文档活儿，里头弯弯绕绕的事情，真是一肚子火。这个项目是我当初带头做的，但中途我因为家里有点急事，回家休养了一年多，项目就交给团队里的小李管着。小李那小子，技术挺就是对文档，那是能糊弄就糊弄。
游戏每迭代一次，他就随便写几句话扔到内部论坛，对外根本没个统一的说法。搞得新玩家一头雾水，老玩家也天天在群里吵架，问到底改了我前阵子回来了，发现玩家社区都快炸了，投诉信堆了一大堆。老板火上房了，直接把这活儿扔给了我，说：“你是创始人，你最清楚历史，赶紧给老子弄个官方版出来！”我当时心里就骂娘了，但这活儿除了我，没人能接得住。
扒拉更新日志那叫一个痛苦
要写“游戏介绍”简单，最多就是措辞好听点，把游戏核心玩法讲明白。但要搞“更新日志”，简直是噩梦。小李那帮人，提交代码的时候，日志写得跟鬼画符似的。什么“修复了一个Bug”，“提升了性能”。具体是哪个Bug？提升了多少？没人知道。他们倒是提交得勤快，可就是没法用。
我只能从头开始，翻箱倒柜，挨个儿翻SVN记录和邮件存档。这工作量，比重写一遍游戏还累。我花了三天时间，把过去两年所有更新记录，从那些含糊不清的提交信息里硬是给榨了出来。甚至有几个关键的数值调整，我不得不亲自去问负责设计的同事老王。老王那记性，比鱼还差，问他上次削弱那个技能是为他反问我：“我削弱过吗？”
我当时就想，这哪里是写日志，这是在考古，还是在审讯犯罪嫌疑人。
最终的《凪光_游戏介绍_更新日志》是怎么出炉的
折腾了一周，我才算把内容敲定。这个文档必须能服众，不能让玩家说我们在敷衍。为了让玩家看清楚，我设计了三段式结构，简单粗暴：
- 第一部分：游戏介绍（定稿）：这部分是固定的，用最通俗的话把游戏核心玩法讲明白。这部分是给新人的。
- 第二部分：近期重大更新（醒目）：只列出最近三个月内，对玩法产生巨大影响的改动。平衡性调整和新增内容，必须用
粗体
强调，免得他们又说没看到。 - 第三部分：历史更新日志（归档）：把那些琐碎的Bug修复和老旧的平衡调整扔进去。爱看不看，反正我有记录了，能保证数据的追溯性。
我把这个文档甩给老板看，老板扫了一眼，说：“这回总算像点样了。” 但我心里知道，这只是个半成品，是被那帮不负责任的队友逼出来的产物。不过没关系，现在至少我们有东西可以拿出去堵住玩家的嘴了。接下来的维护，我打算自己抓着，谁要是敢再瞎写提交记录，我直接让他回炉重造。