sproto 由于主要供 lua 使用，是不能在协议定义中描述缺省值的。所有不编码的字段都呈现为 lua 中的 nil 。注：这里还有个实现上的小问题。如果一个数组为空，也会呈现为 nil 而不是空表，所以应当注意处理。我最近给 sproto 增加了一个新的 api ，可以为一类消息生成一个全部为缺省值的 table 。这样，使用者就可以方便把这个 table 作为别的 table 的 metatable 中的 index 方法了。相当于实现了原来在 protobuf 中的缺省值的特性。只不过，缺省值不能主动定义。所有的 integer 缺省为 0 、boolean 缺省为 false 、string 缺省为空串、子类型为空表，并附加有一项__type为子类型的名字。无数据的数组也缺省为一个空表。使用方法为：sproto:default( typename )给出消息类型名，就可以返回一个全部填有缺省项的表。你也可以用它来取得一类消息中有哪些项。这个 api 也可以用来取协议对应的消息类型，用法是sproto:default(protoname, "REQUEST" 或 "RESPONSE")第二个参数必须为 "REQUEST" 用来取对应协议的请求类型；或是 "RESPONSE" 来取对应协议的回应消息。如果对应消息并不存在（sproto 运行协议不定义请求消息类型或回应消息类型 ...继续阅读 (92)

写这个东西的起源是，前段时间我们的平台组面试了一个同学，他最近一个作品叫做luajit.io。面试完了后，他专门找我聊了几个小时他的这个项目。他的核心想法是基于 luajit 做一个 web server ，和ngx_lua类似，但撇开 nginx 。当时他给我抱怨了许多 luajit 的问题，但是基于性能考虑又不想放弃 luajit 而转用 lua 。我当时的建议是，不要把 lua/luajit 作为嵌入语言而自己写 host 程序，而是想办法做成供 lua 使用的库。这样发展的余地要大很多，也就不必局限于用户使用 lua 还是 luajit 了。没有这么做有很多原因是设计一个库比设计一个 host 程序要麻烦的多，不过麻烦归麻烦，其实还是可以做一下的，所以我就自己动手试了一下。Lua 的多任务库有很多，有兴趣的同学可以参考一下 lua user wiki。一般有几种做法：要么不使用操作系统的线程，只用 lua 本身的 coroutine 来模拟多任务。用 lua 写一个调度器即可。由于 lua 目前允许从 debug hook 中 yield （但暂时需要用 C 来实现 hook），所以甚至你可以实现一个抢占式的调度器；另一种流行的做法是在每个 os thread 里都开启一个独立的 lua vm ，然后用消息通讯的方式协作。大多数库实现出来都是为了解决类似 web 服务这种 ...继续阅读 (68)

最近，我们的合作方 陌陌 带了他们的一个 CP 到我们公司咨询一下 skynet 做 mmo 游戏项目中遇到的一些问题。因为他们即将上线一款 MMO ，在压力测试环节暴露了许多问题。虽然经过我们的分析，有很多问题出在他们的压力测试程序本身编写的 bug ，但同时也暴露出服务器的设计问题。核心问题是，他们在实现 mmo 服务器时，虽然使用了 skynet 框架，但却把所有的业务逻辑都放在了同一个 lua 服务中，也就是一切都运行在一个 lua states 里。这样，几乎就没能利用上 skynet 原本想提供的东西。压力是一定存在的。我花了一下午探讨了应该如何设计一个 MMO 的服务器。下面记录一下：业务的拆分：我认为业务拆分的原则是数据的交互频率。如果数据相互独立，那么就应该用独立的服务去处理；如果交互密切，就不要拆分它们。尽量不让一个服务承担太多热数据的处理，而冷数据或不需要高频响应的数据处理则可以堆积在一起。例如：在 MMO 游戏中，玩家身上的背包管理，基本上只和玩家相关，那么处理背包的逻辑就可以放在玩家的 agent 中处理。即使背包中的物品的操作会影响到其他人或场景，也应该由 agent 和外部交互。对于拍卖行、玩家摆摊等这些，提取出来放在一个或几个交易服务中去完成是没有问题的，但应该避免和场景服务合在一起。虽然拍卖行和摆摊的入口看起来放在场景里，但那仅仅是外在表现，玩家从 ...继续阅读 (82)

sproto是我自己设计, 用在我们新项目中取代过去用到的 google protocol buffers 的东西。为什么不用 protobuf ? 这个问题我有足够的发言权。在 lua 语言为主的项目中，sproto 更合适。google 官方并没有给 protobuf 加入 lua 支持。现在在网上流传的 protobuf lua 方案，被人用的最多的两种，一个是pbc的 lua binding ，另一个是protoc-gen-lua。前者是我在开发维护，并使用了多年；后者是在我过去的项目中，项目中的同事因为需要而开发的。另外，在我的项目的副产品中，还有开源的 protobuffer 的 as3 库以及 erlang 库，都有许多用户。所以，我相信我对 protobuf 有足够长时间的使用经验以及对它有足够的了解。这也是放弃 protobuf 而转向自己设计的 sproto 的底气所在。在这一篇 blog 中，不想讨论 protobuf 的优劣，只谈谈 sproto 中如何使用 rpc 的 api 。这是 sproto 的 api 文档中没有写明，而很多想用它的同学问起的问题。对于 request/response 的 RPC 方案，除了消息本身打包外，还有两个重要的信息需要传输。它们分别是请求的类型以及请求的 session 。不要把请求的类型和消息的类型混为一谈。因为不同 ...继续阅读 (104)

作为一个 X-COM 老系列的爱好者（1994 年开始一直玩了 3 年），新的官方重制版是满足不了我的。Xenonauts作为原作的精神继承者，我很喜欢。本来这个游戏上手了以后是不太依赖文字的，只是可惜了它写的不错的文案。我在网上搜了一下汉化包，几乎都是机器翻译的，读那个真不如读英文啊。游戏的官方没有能力做中文化，但是在官方论坛提供了翻译的指引。我按指引用文泉驿制作了游戏用的字体文件，发现游戏引擎本身对中文支持是没有什么问题的，差的只是文字翻译了。但是这个游戏文字量极大，而且不太容易翻译。我在 github 上创建了一个项目，希望可以集众人之力来完成这个大工程。项目的地址在https://github.com/cloudwu/xenonauts。我在百度贴吧、新浪微博、和 steam 动态上分别发了信息的一天后，居然真有志愿者了。我的想法是这样的，我们先从最难的，也是最有价值的游戏内百科开始翻译。如果顺利再继续界面、向导等部分。原始文件是单个大的 xml 文件，很不利于协作。所以我昨天写了个 lua 脚本把它按条目拆分好了。也有脚本可以合并成最终的文件。ps. 在 github 上协作翻译还是满有意思的。我认为这是一个非常好的协同创作平台，可以专心做校对工作。如果以后游戏策划可以用 md 或 adoc 格式直接写策划案就好了。也就可以搬到 github 上来供大家针对性的讨论了。如 ...继续阅读 (65)

skynet 中使用了一个 hash 表结构来保存服务和 32bit 数字地址的映射关系。一个 skynet 的服务，其实是一个 C 对象。在有沙盒的系统中，尤其是并行构架，我们很少直接用 C 对象指针来标识一个 C 对象，而是采用数字 id 。用数字做 handle 可以让系统更健壮，更容易校验一个对象是否还有效，还可以减少悬空指针，多次释放对象等潜在问题。比如，操作系统为了把用户程序隔离在用户态，像文件对象就是用数字 id 的形式交给用户程序去用的。和操作系统通常管理文件句柄的方式不同，skynet 尽量不复用曾经用过的 id 。这样，当你持有了一个已经不存在的 id ，不太会误当作某个新的对象。（操作系统的文件 handle 很容易造成这样的问题：你记住了一个文件，在别的流程中关闭了它，然后又打开了新文件，结果复用了过去的 handle ，导致你操作了错误的文件。很多年前，我就在自己的线上产品中碰到过这样的 bug。）但是，一旦尽量不复用 id 。用简单的数组来做映射就很难了。必须使用 hash 表来保证映射效率。在 skynet 中我是这样做的：每次分配新的 id 时，首先递增上次分配出去的 id （允许回绕，但会跳过 0 。0 被当成无效 id ）。然后检查 hash 表中对应的 slot 是否有冲突，若有冲突就继续递增。如果 hash 表的池不够用了，则成倍扩大池，并将 ...继续阅读 (88)

上次提到过抵抗组织：阿瓦隆的辅助工具的一个想法。主要是用手机帮助大家减少天黑请闭眼环节的繁琐工作。参加游戏的人只需要看一眼手机，就可以了解游戏局面。这样就不需要额外的主持人不停的叫大家闭眼，某某睁眼确认等等了。另外，也可以简化投票任务这些环节（如果是杀人，那就是确认杀掉谁，指认谁等过程）。一旦去掉了额外的道具，我们就不再需要桌子来玩。可以方便的在饭桌上打发时间了。我在 github 上创建了一个项目。初步的计划是做成一个 web 网站，当然以后改成手机 app 也可以（可以只需要一个 app 做 host，其他玩家还是继续用浏览器访问它，这样就不依赖互联网连接了）。因为我几乎没有 web 开发的经验，所以之搭了个简单的框架，剩余的部分是同事参与来做的。目前之完成了进入房间分配身份的部分，进度比较慢。如果能有经验的同学加入会好一些 :)btw, 我是基于 skynet 开发的。没有什么特别原因，就是因为我之前没做过 web 开发，什么 web 框架都没用过，skynet 比较熟而已。目前这个也谈不上什么特别的设计，目前是怎么简单怎么来。如果要把 skynet 发展成一个可以用的通用 web 框架，我也没经验去想应该怎么搞，所以千万不要把这个当成 skynet 应用的 example :)仓库的地址是https://github.com/ejoy/avalon。如果你觉得这个小项目有点 ...继续阅读 (95)

skynet 的 1.0 版已经发布了 3 个 alpha 版，等稳定以后将发布 beta 版本。最近的问题主要集中在一些我们在老项目中没有使用到的特性上面。尤其是 sproto 这个模块，我希望它将来作为 skynet 推荐的通讯协议，但我们老的项目开始的比 sproto 的项目早，所以早期项目全部使用的是 google protocol buffers （以及我自己做的实现）。 随着新项目的开展，我们公司内部开始大面积使用 sproto ，也就发现了一些 bug ，在最近集中修复。由于 skynet 使用多 lua VM 结构，为了不在每个 VM 里重复加载 sproto 协议，最近增加了 sproto 协议对象的共享。这个作为未写入 sproto 文档的特性提供，当然也不影响 sproto 在其它领域的使用。不过加这个特性比较匆忙，第一次提交时在 gc 方面遗留了一个 bug ，有可能导致多个 VM 重复释放 C 对象，问题已经在仓库最新的提交中修复。另一个为了 skynet 的应用而特别加上的特性是让 sproto 的 decode 可以接收指针（lightuserdata）。固然只接受 string 会让实现更稳固一些，不过在 skynet 里很多地方 string 和 lightuserdata + size 是通用的，所以就顺带支持了。这样可以减少一次内存拷贝。根据使 ...继续阅读 (89)

昨天下午约了一帮同事去密室，由于在最后 40 秒成功破关，大家都很兴奋，决定再换个地方欢乐一下，结果就在地图上找了家附近的桌游店。一开始有 8 个人, 我知道这么多人想开桌游实在没有什么好的选择。玩了两局赛马后又来了三个人。一开始，我实在不想再玩 bluffing game 了。无论是狼人或三国杀，还是抵抗组织，都在三年前玩伤了（开桌游店的日子里，长达半年的时间，每周两个晚上抵抗组织）。这时发现桌游店里有一盒阿瓦隆。一直听说抵抗组织出了这么一个扩充并且口碑非常的好（bgg 上 party game 分类第一），所以饶有兴趣的读了一下规则书。的确有那么一点意思，就组织大家开了几局。正好 11 个人，我可以做主持人。（当然抵抗组织和杀人狼人不同，玩熟了后，完全不需要额外的主持人的）对没玩过抵抗组织的同学来说，我有必要简单介绍一下抵抗组织的规则。熟悉规则的同学可以跳过这一段。简单说就是个不死人的杀人游戏。和所有 bluffing game 一样，由游戏规则决定，将一些线索隐藏在游戏者之间，鼓励玩家制造（和推理识破）谎言来达成胜利目标。和杀人游戏不一样，它解决的重大问题是：不会在整局游戏结束前，有人提前退场。就这一点来说，我偏爱抵抗组织的规则越胜过杀人（狼人)。而且游戏过程中没有黑夜杀人环节，也就不需要额外的主持人了。（当然杀人游戏有个生推变种也不需要）抵抗组织游戏人数 5 到 10 人， ...继续阅读 (89)

花了两天给sproto增加了 unordered map 的支持。问题是这样的：sproto 支持数组，但很多情况下，业务处理中，我们并不用数组来保存大量的相同类型的结构数据。因为那样不方便检索。比如你要配置若干地图表、NPC 表等等的信息，固然可以用 sproto 的 array 来保存。但是在运行时，你更希望用定义好的 id 来检索它们。如果 sproto 不支持 unordered map 的话，你就需要在 decode 之后，对 array table 做一次遍历，用一张新表来建立索引。google protocal buffers 2 也有这个问题，据说第 3 版要增加 map 用来兼容 json ，这个话题最后再说。为了解决这个问题，最简单的方法是在 sproto 的定义中增加一个特性，允许给 array 定义一个主索引。建议编码器在编解码这个数组的时候，按类型的主索引去处理这张表。比如.Person { name 0 : string id 1 : integer email 2 : string .PhoneNumber { number 0 : string type 1 : integer } phone 3 : *PhoneNumber } .AddressBook { ...继续阅读 (75)

在 skynet 中，有一个叫 monitor 的内部模块，它会监测是否有服务可能陷入了死循环。工作原理是这样的：每次处理一个服务的一个消息时，都会在一个和服务相关的全局变量处自增 1 。而 monitor 是一个独立线程，它每隔一小段时间（5 秒左右）都检测一下所有的工作线程，看有没有长期没有自增的，若有就认为其正在处理的消息可能陷入死循环了。而发现这种异常情况后，skynet 能做的也仅仅是输出一行 log 。它无法从外部中断消息处理过程，而死循环的服务，将永久占据一个核心，让系统整体性能下降。采用 skynet 的 kill 指令是无法杀掉死循环的服务的。当服务用 lua 编写时，我们则有可能做多一点工作。对于正统的 lua 程序，我们可以给正在运行的 coroutine 加上一个 debug hook 。在 debug hook 里，则可以检查有没有外部通知说需要中断运行。由于 skynet 的 lua 服务都由一个 coroutine 的调度器管理，的确可以作到为每个请求都加上这个 debug hook 。但问题是，加上 debug hook 后，对正常运行状态的性能影响很大。尤其是 lua 版本的 debug hook ，比直接调用 C API 设置一个 C 版的 debug hook 有更大开销。我认为这个特性对于解决 bug, 尤其是线上解决问题很有帮助，如果能比较 ...继续阅读 (103)