今天工作上的事情弄的比较晚，没留出足够时间来继续写这个。本来打算直接回家睡觉的，想了想还是继续写点。凡事可以坚持做下去，往往靠的不是兴趣，不是责任，而是习惯。我不想让这些对过往的记录成为今天的负担，但也担心一旦放下就会拖上好久。反正腹稿都已经打好了，无论内容多少，还是保持着一天一更新的习惯吧。让我顺利把这件事情做完。
Dingdang 具体哪天加入的游戏开发组我已经记不清了。因为他做的是服务器那块，我不太关心。大约是在《大话西游》项目中后期吧，他说，服务器这边进度太慢，就过来了。他以前玩过 mud 挺有兴趣。但是其工作主要还是在底层。
网易的同事们完全扔掉 mudOS 这根拐杖是到 大话3 的事情了。主要还是因为太多逻辑代码用 LPC （mudOS 内置的一种类 C 的脚本语言）实现。大家一点点的改造，先是将文本通讯协议改成对数据流量更节约一些的二进制方式，为特殊的需求添加一些代码（例如定时数据持久化），再做一些底层的优化，把 select 的网络模型改为 epoll ，等等。直到全部更替。这些工作持续了 4,5 年。
大话的服务器最早是搭建在 mudOS 上的，一个开源的东东，用在各种文字 mud 上。做文字 mud 通常还会用一个中间层，叫做 mudlib 。早年传说中的方舟子一帮人等做《侠客行》，就是指做了一套 mudlib ，被后人用在各种中文文字 mud 上。听说大话的开发人员也自己做了套 mudlib （听说而已，micro 似乎跟我提过他们没用侠客行的代码，太久远的事情不想证实了），不过我对使用 mudOS 却不以为然。什么年代的东西啊，都 21 世纪了，还在用。也就那么点代码，就不能放弃掉自己写一个吗？而且原本为几十个人同时游戏设计的框架，用在这么多人同时在线的网游上合适么？
一开始，当然做不了这么许多。大家还是主要在完成游戏的进度。dingdang 坐我的旁边，中间靠走道的拐角处。桌子上没什么东西，上班时就带一个笔记本，在那里敲敲打打。
我对那段时间在工业园的记忆不多。因为每天，周围的人都是一个情景，闷头做事。晚上，走的晚的人倒不是很多，我和 dingdang 加班的次数比平均水平高一点。
他那个时候好象在热恋中，晚上经常窝在椅子上，捏着手机很小声音的讲电话，每次都很久很久。工业园的办公室晚上都是不开顶灯的，大家都很享受在黑暗里办公，显示器亮亮的，四处安静的很。
也偶有喧闹的时候，那是古越的 client 和 ten 以及 dingdang 联合调试。我没关心技术细节，只是从他们的对话中感觉有无数的 bug 改不完。有点忧虑，但无能为力。从一开始就没有参加到这块的逻辑中去，我只能好好做我那块东西。
记得当时 client 和 server 都有严重的内存泄露问题。client 这边我想了很多方法帮古越定位。server 那 dingdang 也在想办法。我们讨论过这个问题，渐渐的就谈到了内存管理器。dingdang 说他实现了一个 伙伴（Buddy）算法的内存分配器，主要是想减少一些内存碎片。自己写的内存管理器也可以有效的侦测到内存泄露的发源地。另外希望以合理的内存布局，让一些 bug 引起的内存越界访问时，减少服务器崩溃的几率。我在这方面是完美主义者，觉得根本就不应该允许 bug 的存在，但是 dingdang 显得很无奈。绕开这个有争议的话题，我们还谈了许多。只是现在都不记得了。
client 这边的分工倒是慢慢的很明确了。古越在配合服务器组实现 client 对应的逻辑。我来做底层，几乎不用搭理游戏是什么。比如大话西游那么丰富的场景和人物角色，开发期间只看过两三个，都是用来调试engine 用的。果子做了一部分跟图形无关的 client 底层，主要是网络包的分发处理。现在的眼光来看，设计的并不好，采用了多线程结构徒增了一些复杂度。如果追究原因的话，我想是因为当时我们 client 没有一个好的软件架构人员统筹安排，基本上都是各个人想怎么做就怎么做造成的。
特别推荐 热点文章 最新文章
当前位置：
