IT牛人博客聚合

这段时间项目进展还算顺利，叮当同学在盯项目进度，我专心解决程序上的各种小问题。

最近我在协助解决 NPC （包括地图上的怪物）的行为控制以及 AI 的问题。

目前，我们的进度还处在玩家可以通过客户端登陆到服务器，可以在场景上漫游，以及做一些简单的战斗和技能动作的阶段。按最初的设计原则，我们的每个玩家是在服务器上有一个独立的 agent 服务的。目前写到现在，和中间想过的一些实现方法有些差异，但大体上还是按这个思路进行的。
关键是在于去除大部分的回调方式的异步调用；编写的控制流程自然完整，不需要太多的去考虑 agent 行为之外的交互性。

如果丝毫不考虑性能问题，我很想把每单个怪物和 NPC 都放在独立服务中。但是估算后，觉得不

查看全文: http://www.udpwork.com/item/7308.html

前段时间为策划提供过一些技术上的支持, 设计过一个简单的 DSL 。但随着更多策划加入团队，我觉得这个思路不能很好的贯彻下去。

策划更喜欢通过 excel 表格来表达他心中的数值关系，而不是通过代码语言。我需要找到另一种更切合实际的方案来将策划的想法转换为可以运行的代码。

研究了一下策划历史项目上的 excel 表格后，我归纳了一下其需求。我们需要把问题分步解决，excel 表格到程序可以利用的数据结构是一项工作，而从表达了数据之间联系的结构到代码又是另一项工作。

对于数值运算，有怎样的需求呢？

我更多看到的是一种声明式的表达，而不是过程式的。比如，策划会定义，“血量”这个属性，实际上是等价于“耐力 * 10”。我们把后者定

查看全文: http://www.udpwork.com/item/7131.html

这几天，安排新来的王同学做数据持久化工作。一开始他是将 sharedb 里的数据序列化为文本储存的。这步工作做完后，开始动手把数据放到 Redis 数据库中。我们的系统主干由 Lua 构建，所以需要一个 Lua 的 Redis 库。google 来的那份，王同学不满意。三下五除二自己重写了一个。据说把代码量减少到了原来的三分之一（开源计划我正在督促）。唯一的问题是，如果直接采用系统的 socket 库，不能很好的嵌入我们的整个通讯框架。我们的 skynet 全部是通过异步 IO 自己调度的，如果这个数据服务单方面阻塞了进程，会使得别的进程获得不了时间片。

蜗牛同学打算改进 skynet 增加异步 IO 的支持。

我今天在考虑现有

查看全文: http://www.udpwork.com/item/7057.html

这几天我的工作是设计未来游戏服务器的热更新系统。

这部分的工作，我曾经在过去的一个项目中尝试过 。这些工作，在当时一段时间与广州网易其他项目交流时，也对网易其他项目的设计产生过一些影响，之后，也在实战中，各个项目组逐步发展出许多热更新的系统来。

我最近对之前所用到的一些方案，如修改 lua module 的加载策略，增加一些间接层，来达到热更新代码的系统设计做了一些思考。感觉在处理热更新这个问题时，还不够严谨。经过两天的思考，我按我的构思实现了新系统的雏形。

在函数式编程语言中，热更新通常比较容易实现。erlang , lisp 都把热升级做为核心特性之一。函数副作用越小的语言，越容易做热升级：你只需要简单的把新写的函数替换

查看全文: http://www.udpwork.com/item/7043.html

总结一下最近的工作，修改 bug 以及调整以前设计的细节是主要的。因为往往只有在实现时，需求和问题才会暴露出来。

pbc 自从开源以来，收到了公司之外的许多朋友的反馈。因此找到了许多 bug ，并一一修复了。一并感谢那些在不稳定阶段就敢拿去用的同学。我相信 bug 会初步趋进于零的，会越来越放心。

之前的 RPC 框架 经历了很大的修改，几乎已经不是一开始的样子了。简化为主。几乎只实现了简单的一问一答的远程调用。但在易用性上做了更多的工作。coroutine 是非常重要的语言基础设施，所以这个很依赖 lua 。主要就是提取出函数定义的元信息，把远程调用描述成简单的函数调用，把函数的参数以及返回值映射为通讯协议中的消息结构。这部分

查看全文: http://www.udpwork.com/item/7016.html

今天例会，梳理了工作计划后，发现要开始实现 AOI 模块了。

所谓 AOI ( Area Of Interest ) ，大致有两个用途。

一则是解决 NPC 的 AI 事件触发问题。游戏场景中有众多的 NPC ，比 PC 大致要多一个数量级。NPC 的 AI 触发条件往往是和其它 NPC 或 PC 距离接近。如果没有 AOI 模块，每个 NPC 都需要遍历场景中其它对象，判断与之距离。这个检索量是非常巨大的（复杂度 O(N*N) ）。一般我们会设计一个 AOI 模块，统一处理，并优化比较次数，当两个对象距离接近时，以消息的形式通知它们。

二则用于减少向 PC 发送的同步消息数量。把离 PC 较远的物体状态变化的消息过滤掉。PC

查看全文: http://www.udpwork.com/item/6948.html

最近两周，陆续有些新同事到岗，或即将到岗。所以我不想过多的再某个需要实现的技术细节上沉浸进去了。至少要等计划的人员齐备，大家都有事情做了以后，个人再好领一块具体事情做。所以属于我个人的代码不多。我主要也就是维护一下前面我自己实现的模块，以及把之前写的一些代码交接给下面具体负责的同学。

哦，这里值得一提的是，我写的 protobuf C 库 慢慢算是可用了。自从提交到 github 上后，有两处 bug 是不认识的网友指出的。当然我自己在用的过程中发现修正的 bug 更多。现在算是基本完善了吧。接下来还会大量使用到，等整个项目做完，应该就基本没问题了。目前主要是用它的 lua binding 。为了用起来更方便，昨天我甚至自己实现了

查看全文: http://www.udpwork.com/item/6925.html

离上一次写 开发笔记 快有一个月了。当然，中间我们放了 10 天的长假。

项目的进展比较缓慢、主要是解决一些琐碎的技术问题，客户端的比较多，服务器这边就是节前的一些 bug 修改和功能完善。大部分工作都不是我自己在做。由于感到人手不足，小规模私下的做了一点点招聘工作。也算物色到一两个同学可以过来一起干的。好久没做招聘工作了，都不知道怎么开始谈。唉，我们这里条件不算好，要求还多，都不好意思开口。

可写的东西其实也不少。今天挑一点来记录一下。

话要说回 开发笔记第六篇 ，我谈过结构化数据的共享存储。这个模块细化其实有挺多工作要做。核心部分我自己完成了，没有用太多时间。然后，有位华南理工的同学想来实习。想到他们学校距离我们办公室仅有

查看全文: http://www.udpwork.com/item/6838.html

今天很早就起床了，以至于到了办公室还不到 11 点。中饭前有一个多小时可以做各种杂事。

我把周末做的工作和蜗牛同步了一下信息，然后得到了几个新需求。主要就是还是需要在协议定义中加入 protobuf 中等价于 service 的东西。思索了一下，觉得有必要，就花了一个小时把特性加上。 C Binding API 方面还有一点疏漏的地方。大概是源于基于 Erlang 框架下的一些小困难。略微修改了下 C 接口协议就 OK 了。然后很 happy 的去食堂吃饭。

然后我暂时就可以转向 Client 方面的一些需求分析以及解决了。

在生成动画树的数据方面，我们的交换格式使用了某中文本中间格式，最终利用 protobuf 来做二进制持

查看全文: http://www.udpwork.com/item/6676.html

开始这个话题前，离上篇开发笔记已经有一周多了。我是打算一直把开发笔记写下去的，而开发过程中一定不会一帆风顺，各种技术的抉择，放弃，都可能有反复。公开记录这个历程，即是对思路的持久化，又是一种自我督促。不轻易陷入到技术细节中而丢失了产品开发进度。而且有一天，当我们的项目完成了后，我可以对所有人说，看，我们的东西就是这样一步步做出来的。每个点滴都凝聚了叫得上名字的开发人员这么多个月的心血。

技术方案的争议在我们几个人内部是很激烈的。让自己的想法说服每个人是很困难的。有下面这个话题，是源于我们未来的服务器的数据流到底是怎样的。

我希望数据和逻辑可以分离，有物理上独立的点可以存取数据。并且有单独的 agent 实体为每个外部连接服务。这

查看全文: http://www.udpwork.com/item/6532.html

这周我开始做场景模块。因为所有 PC 在 server 端采用独立的 agent 的方式工作。他们分离开，就需要有一个模块来沟通他们。在一期目标中，就是一个简单的场景服务。用来同步每个 agent 看到的世界。

这部分问题，前不久思考过 。需求归纳如下：

每个 agent 可以了解场景中发生的变化。

当 agent 进入场景时，需要获取整个世界的状态。

agent 进入场景时，需要可以查询到它离开时自己的状态。关于角色在场景中的位置信息由场景服务维护这一点，在 开发笔记1 中提到过。

大批量的数据同步对性能需求比较高。因为在 N 个角色场景中，同步量是 N*N 的。虽说，先设计接口，实现的优化在第二步。但是接口设计又决定了

查看全文: http://www.udpwork.com/item/6484.html

话接 开发笔记1 。我们将为每个玩家的接入提供一个 agent 服务。agent 相应玩家发送过来的数据包，然后给于反馈。

对于 agent 服务，是一个典型的包驱动模式。无论我们用 Erlang 框架，还是用 ZeroMQ 自己搭建的框架，agent 都会不会有太多的不同。它将利用一个单一的输入点获取输入，根据这些输入产生输出。这个输入点是由框架提供的。框架把 Agent 感兴趣的包发给它。

我们会有许多 agent ，在没有它感兴趣的包到来时，agent 处于挂起状态（而不是轮询输入点）。这样做可以大量节省 cpu 资源。怎样做的高效，就是框架的责任了，暂时我们不展开讨论框架的设计。

下面来看，一旦数据包进入 agent

查看全文: http://www.udpwork.com/item/6459.html

这篇很淡疼的文章来源于我在微博上的争论。需要列数据，字数限制不合适，所以单列一篇了。

昨天翻出了元帅同学的一篇旧文，游戏数值设计(1)：定义与目标 , 转发到微博上。我一向是喜欢看他吐槽的，这篇吐国内的 MMORPG 游戏策划分工的文章，深得我心。

我一直对国内 MMORPG 制作把设计人员分为 文案策划、系统策划、数值策划不以为然。文案拆分出去做倒还说得过去，这所谓系统策划和数值策划的拆分简直就是莫名其妙了。现代电子游戏从桌面游戏一路发展过来，怎样让玩家享受规则，一直是一个整体。如果一个人来设计一个游戏，那么脑子里必然要逐步形成这个游戏做出来是什么样子的，然后细化里面的细节，玩家在他设计的规则下怎么进行游戏。所谓数值设计，是这

查看全文: http://www.udpwork.com/item/6315.html

接上回，按照我们一期项目的需求，昨天我简单设计了数据库里的数据格式。数据库采用的是 Redis ，我把它看成一个远端的数据结构保存设备。它提供基本的 Key-Value 储存功能，没有层级表。如果需要两层结构，可以在 Value 里保存一组 Hashes 。

这是我第一次实战使用 Redis ，没有什么经验。不过类似的设施几年前自己实现过，区别不大。经过这几年，有了 Redis 这个开源项目，就不需要重造轮子了。但其模式还是比较熟悉的。也就是说，是按我历史经验来使用 Redis 。

一期项目需要比较简单，不打算把数据拆分到不同的数据服务器上。但为日后的拆分需求做好设计准备。以后有需要，可以按 Key 的前缀把数据分到不同的位置。

查看全文: http://www.udpwork.com/item/6307.html

折腾了好久，终于可以开始正式项目开发了。

之前的这段日子，我们陷落在公司的股权分配问题中，纠结于到底需要几个人到位才启动；更是反复讨论，到底应该做个怎样的游戏。林林总总，终于，在已经到位的几位同学的摩拳擦掌中，叮当决定自己挂帅开始干了。

就这么不到十个人，空旷的办公室，跟我们起先想像的情况不太一样。尤其是主策划还没有落定。我说，叮当，你好歹也是一资深游戏玩家，带了这么多年的游戏部，跟了这么多成功的项目，没吃过猪肉总见过猪跑吧，我就不相信你干着会比别人差。若不是我必须盯着程序实现这块，我都想自己做主策划了。不过有你干，我放心。

主策划的位置，咱们可以先空着，前期工作不能延。产品经理代理一下游戏主策划的位置也是创业公司必须的；正如

查看全文: http://www.udpwork.com/item/6297.html

由于在筹备做新的项目，所以关于网络游戏方面的讨论，在朋友圈子中多了许多。前几天和投资人吃饭，说起前几年盛大提出所谓免费游戏的策略转型，问道有没有可能在未来几年出现新的收费模式。从这个话题引开，饭桌上我跟叮当讨论了很久。

回想那一年，所谓免费游戏之风逐步侵蚀中国网络游戏市场之时，网易的开发团队起初是有所抵触的。我刚到杭州不久，远离广州的开发团队，静心思考了许多。所谓公平的游戏，我想我比大多数人都在乎。把玩游戏变成一个金钱投入的游戏，我是万般不愿意的。但我相信道具收费的方式有它内在的逻辑。实际上，在网易成熟的时间收费游戏，梦幻西游中，点卡交易系统早就存在，并良性运作了很久了。许多玩家已然在游戏中花掉了远远超过时间收费收取的金钱。

那

查看全文: http://www.udpwork.com/item/6101.html