不堪被 windows 升级弹窗骚扰，终于升到了 windows 10 。最不能忍受的是新的中文输入法，之前用的智能 ABC 已经完全不能用了。btw, 我爹他老人家就是因为没有 ABC 完全输入不了汉字，又重装了系统，退回 windows 7 去了。我没那么能折腾，所以还是想别的招。很多年前我就写过，为什么我需要智能 ABC，到今天观点还是没有变。我听说 QQ 拼音加入了 ABC 模式，其实就是加了 5 个笔画，其实并没有理解 ABC 为什么那样设计，所以做的并不好。并不是说 ABC 设计的多完美，如果我来设计我期望的中文输入法，肯定有很多想法和 ABC 的设计不同。但是其核心是一样的：那就是，赋予每个汉字更多的编码形式，结合词（不是句子）尽可能的减少重码。从读音看，汉字有 10 多个常用音节，30 多个次常用音节，60 多个不太常用音节。一共 100 多个，用来表示 3000 多个常用字已经是 20 倍以上的重码率了。所以对于一些同音字多的音节上，一次 10 个候选字都需要排好几页。光用拼音输入单字肯定是效率非常低下的，这也是为什么早期有很多形码输入法的原因。如果以词为单位输入，即使仅靠读音，已经可以大大减少重码率。但问题在于不断有新词出现，尤其是很多谐音词，本身就是刻意和传统词同音的。如果我们为了行文需要去修改已有词里的单字，只靠单字的读音来索字就会变得输入效率及其低下。大 ...继续阅读 (81)

今天有同事问到，能不能不关闭 skynet 进程，直接重新加载一个 lua 服务。简单的回答的不能。如果要详细回答，并非完全不行，但这个需求需要使用 skynet 的人自己定制出来。其实，这涉及服务的热更新问题。由于 lua 的函数是 first class 对象，所以，它即好做热更新，又无法做成业务完全无关的。容易做的一方面在于，lua 函数本身就是一个对象，只要你找到 lua vm 里的需要更新的函数对象被哪些地方应用，就可以生成（通过 load 新的脚本代码）新对象，取代值前的引用即可。不容易做的一方面是，lua 完全不区分什么是代码，什么是数据，所以没有 C 语言中所谓符号表。所以并没有统一的地方可以查找 lua vm 里已有的函数。甚至函数也没有名字，你不能用名字索引出新版本的函数，替换掉老版本的。除非你的业务框架做了适当的约定。另外，在 lua 中，所有函数都是闭包。如果你只想替换闭包中函数原型的实现，那么还需要做 upvalue 的重新关联。这是一个繁杂的过程，如果没有适当的约定，也无法彻底做对。btw,snax里就做了一些约定，可以一定程度的做到热更新。那么，直接把旧服务杀掉，启动一个新服务行不行？如果服务是无状态的，或是你可以在停止服务前把状态保存再安全的地方，新服务启动后可以恢复状态的话，这是个不错的思路。但是，对 skynet 框架而言，还有一个障碍：新的服务 ...继续阅读 (64)

skynet 的核心并没有规定怎样处理 TCP 的数据流，但在开发网络游戏时，我们往往需要按传统，把 TCP 连接上的数据流分割为一个个数据包。将数据流转换为数据包，比较常见的做法是给数据包加一个长度信息，组装在数据流中。我个人比较推荐使用两个字节表示包长度。在 skynet 中提供了一个GateServer的模板来帮助用户实现这样一个网关。这个网关模板采用推送的模式，一旦用户初始化完毕，就会自动分割连接上的数据流，按协议（两字节长度加内容）分割为数据包，回调处理函数。在回调函数中，你可以为新连接启动一个独立服务来处理这个连接上的请求，也可以在单一服务中处理。这些不在本文中讨论。今天，我想介绍另一个模式来做这个分包的业务，下面给出的 example 相比套用 GateServer 模板可能更适合用户改造合适自己游戏的模块。skynet 中启动和维持一个 C 服务都是非常廉价的。当然 lua 服务本质上也是一个 C 服务，但它之所以不那么廉价，是因为服务中启动了一个 lua VM 。如果 C 服务的数据结构简单，那么无论从内存角度，还是从 skynet 的消息调度器角度来看，都没有太大的负担。我们可以为每个 TCP 连接都启动一个 C 服务来管理这个连接。对于连接上的输入数据流，这个服务负责解读两个字节的包头，并分割出数据包；对于输出数据流，这个服务负责给内部数据加上 size 打包 ...继续阅读 (63)

这几天 AlphaGo 4:1 战胜了李世石，围棋积分网站给了 AlphaGo 一个世界排名。在 3:1 的时候是世界第四，4:1 后上升到了世界第二。我很好奇这个网站是如何给棋手打分的，便顺着链接指引翻了下 wikipedia 读了几篇 paper 。下面是我的一些理解，由于我的数学基本功不太扎实，难免有错误，所以有兴趣的同学最好自己读论文。首先，如何定义等级分这个东西？在一对一竞技类游戏中，假设规则是公平的，对战双方如果都能给出最优策略，那么胜负概率是完全均等的 50% 。如果我们假定冥冥之中存在一个绝对实力值，而实力高的人可以少犯错误，那么他就能以超过 50% 的概率战胜对手。简化胜负结果背后复杂的过程，我们把全体选手按绝对实力值排名，排名靠前的选手对排名靠后的选手，胜率都是大于 50% 的。由于实力强的人不一定对实力弱的人必胜，所以这个绝对实力值其实是一个概率相关数。胜率的高低可以看成是实力差异大小。根据若干比赛的结果，我们可以推算出代表实力值得后验概率。比如有两个选手的实力为 A 和 B ，则 A 胜过 B 的概率就为 A / (A+B) 。（不考虑平局的情况）有一组选手和足够的他们相互之间的比赛成绩的话，我们就可以根据Bradley Terry 模型推算出一组实力值，尽可能的符合他们之间的对战结果。如果直接采用这样的数值表示实力（等级分），存在一个问题：在人类的大多数游 ...继续阅读 (72)

本文分三个部分：一，什么时候有可能采用 UDP 通讯而不是用 TCP 更好；二，一个可靠的 UDP 通讯模块的 API 接口该如何设计；三，一个简单的实现。首先，我一直是非常反对在 UDP 协议上实现一个可靠传输协议的，即类似 TCP over UDP 的东西。TCP 已经够复杂了，几乎不太可能重新设计的更好。如果用 UDP 再实现一个可靠传输协议，而表现的比 TCP 效果更好，那么多半只是在部分情况下的优势；或是霸道的占用了过量的资源，而 TCP 在设计时则是很友好的，以整个网络的通畅为更高准则的。对于后者，我心里相当排斥。如果大家都想独占网络带宽，那么只会让每个人都无法获得高质量通讯。在网络游戏，尤其是移动网络上的网络游戏制作圈里，不断的有人期望基于 UDP 协议通讯来获得更快的响应速度，而又想让通讯流像 TCP 一般可靠。我也时常思考这个问题，到底该怎么做这件事？如果基于 UDP 可以做的比 TCP 更好，那么一定是放弃了点 TCP 需要做到的东西。一条路是寄希望于业务逻辑上允许信息丢失：比如，在同步状态中，如果状态是有实效性的，那么过期的状态信息就是可丢失的。这需要每次或周期性的全量状态信息同步，每个新的全量状态信息都可以取代旧的信息。或者在同步玩家在场景中的位置时可以用这样的策略。不过在实际操作中，我发现一旦允许中间状态丢失，业务层将会特别难写。真正可以全量同步状态的场合 ...继续阅读 (87)

过年回武汉家中，只有一台 2000 块的一体机可以用，自然是跑不动 3d 游戏的。我挑了一款 Invisible Inc 玩，居然很流畅。这是款 XCOM like 的策略游戏，场景是 isometric 的。但是用 Q E 两个键可以旋转场景，虽然静止下来只有四个方向，但是旋转过程却以动画方式呈现。这让我一度认为它的场景是基于 3d 模型制作的。但令人惊讶的是，在低配置的一体机上却非常流畅。相比较，我最近在玩的 XCOM 2 却在 GTX 550 显卡上也有卡顿。我仔细观察后，发现其实 Invisible Inc 的场景里的物件都只是 2D 图片。甚至只有正面和背面两张图，通过左右镜像得到了四个视角。它的旋转速度很快，并加了一定的模糊效果，欺骗了人眼。其实只有地板和墙壁是真正旋转的，其它物件只有坐标在做旋转，而图片本身在旋转过程中并没有变化。也就是说，它的引擎其实是基于 2D 制作的，模拟出了 3d 才有的视觉效果。我对墙壁的旋转很感兴趣，一开始以为是预渲染了若干张图。后来试着解开了 .kwad 资源包（可自行 google 到工具）发现里面的资源图片只有一或两张。ps. 图片是用 zlib 压缩过的 RGBA 位图，格式也可以 google 到。以门为例，只有正面（或背面）的矩形图片。想来是在引擎中变形为斜视角下需要的平行四边形。我简单推倒了一下变换矩阵，需要一点初中平面几何知 ...继续阅读 (557)

在 ejoy2d 里，我将 sprite 的结构信息储存在一组叫 sprite pack 的结构中。其中包括动画的 frame 数据，sprite 由若干部分组成，每个部分的变换矩阵，对应贴图的编码和坐标等等。通常这些数据不会太大，所以我建议一次加载到内存就不再删除。而动态生成的 sprite 对象则直接引用这些数据，不必做引用计数。这些数据之间的交叉引用（可以像搭积木一样用很多部件构成复杂的 sprite ）也不需要额外记录。但如果保存了大量的动画信息，或 sprite 是由非常多的小部件构成，数据量也可能非常可观。在我们的心动庄园里，达到了数十 M 内存之多。前几天同事提到这个问题，我便动手做了一点简单的优化，居然省出了几十兆内存。其实方法很简单。在 64bit 平台上，我将 sprite pack 结构中的指针都改成了一个 32bit 的相对 pack 头的偏移量。在设计之初，我就是把整个 sprite pack 存放在连续单个内存块上的。为之做了一个非常简单的 bump allocator ：资源打包的时候，统计整个要用的内存数量，然后在包加载时就分配出来，然后每个小对象都紧贴在一起保存。这样可以节省下大量小内存块的头，并将常规内存管理中可能出现的内存碎片率减少到零。由于原本就是连续内存块，把指针更替成偏移量不需要修改太多代码。把指针体积减少一半后，数据结构对齐也会变得更紧 ...继续阅读 (54)

在 ejoy2d 里，我将 sprite 的结构信息储存在一组叫 sprite pack 的结构中。其中包括动画的 frame 数据，sprite 由若干部分组成，每个部分的变换矩阵，对应贴图的编码和坐标等等。通常这些数据不会太大，所以我建议一次加载到内存就不再删除。而动态生成的 sprite 对象则直接引用这些数据，不必做引用计数。这些数据之间的交叉引用（可以像搭积木一样用很多部件构成复杂的 sprite ）也不需要额外记录。但如果保存了大量的动画信息，或 sprite 是由非常多的小部件构成，数据量也可能非常可观。在我们的心动庄园里，达到了数十 M 内存之多。前几天同事提到这个问题，我便动手做了一点简单的优化，居然省出了几十兆内存。其实方法很简单。在 64bit 平台上，我将 sprite pack 结构中的指针都改成了一个 32bit 的相对 pack 头的偏移量。在设计之初，我就是把整个 sprite pack 存放在连续单个内存块上的。为之做了一个非常简单的 bump allocator ：资源打包的时候，统计整个要用的内存数量，然后在包加载时就分配出来，然后每个小对象都紧贴在一起保存。这样可以节省下大量小内存块的头，并将常规内存管理中可能出现的内存碎片率减少到零。由于原本就是连续内存块，把指针更替成偏移量不需要修改太多代码。把指针体积减少一半后，数据结构对齐也会变得更紧 ...继续阅读 (220)

这是个老问题，但是公司不同的同学先后被坑，所以必须记录一笔。这样可以增加事后被 google 到的概率，千万别来第三次了。我原本以为 opengl 在 bind VBO 后，如果修改了 VBO 的数据，是不需要重新 bind VBO 对象的。所以早先的 ejoy2d 在这里的处理就做了一点优化，并没有重复 bind ，可以减少一些 API 调用。大约在 2015 年 6 月左右，由于需要跟进 mac osx 的系统更新，ejoy2d 增加了对 VAO 的支持。我再修改相关实现的时候发现在某些设备上，出现了 bug 。当时猜想可能是新的手机的驱动做了一些过去没有做的奇怪的优化。我没有太多确认 opengl 是否对次有要求，不知道是否是驱动的 bug ，不过还是做了一些修改。在这个 patch中，我在更新 VBO 的数据后，设置了脏标记，最后提交时会重新 bind VBO 。当时并没有刻意做为一个独立 commit 提交，所以被同事疏忽了。前不久，我们的心动庄园在新版锤子手机上出现花屏，同事追查过原因，发现只需要更新 ejoy2d 就解决了。定位了一下原因，就是上面提到的 patch 解决的。前几天，另一个同事自己用 ejoy2d 开发的小游戏爆裂方块在 360 平台审核时被报告有显示 bug ，又查了好久，今天终于定位到是同一问题。在同样的问题上浪费时间真是不划算。所以：要勤作记录并 ...继续阅读 (90)

一般游戏会把所需要资源数据打包成一个大文件，游戏运行时可以像访问普通文件一样，访问包内文件。如何打包如何更新资源包，是设计重点。现在有很多资源包直接使用通用打包（压缩）格式，比如 zip 。也有自行设计的，多半是为了一些特殊需求。比如资源间有引用关系等。如果资源数量过多，通常还会对原始资源文件名做一次 hash 索引，加快包内文件检索效率。像暴血的 mpq 格式，还有 unity3d 的 asset bundle 格式都是这样的。一旦资源打包，原始文件名信息就不再需要了。应用程序可以在运行时通过文件名的 hash 值索引到包内文件。（所以第三方的 mpq 解包工具需要提供一份额外的文件名列表）既然是 hash ，那么就应该在包格式设计中考虑 hash 冲突的解决方案。asset bundle 的设计人这方面经验欠缺，他们在生成 Deterministic 包的时候，遇到 hash 冲突就直接放弃打包。这显然是不合理的。对于一般几千个文件的包， 32bit hash 值肯定是够用的，但 hash 冲突绝对不能忽略。一个简单的方法是加盐做二次 hash 。比如你在打包时发现有两个不同的文件名 A 和 B ，他们的 hash 值相同，比如 hash(A) 和 hash(B) 都是 H 。那么，在文件索引表中，就不应该在 H 名下记录数据，而是记录一个冲突标记，并引用一个 salt 。然 ...继续阅读 (58)

一般游戏会把所需要资源数据打包成一个大文件，游戏运行时可以像访问普通文件一样，访问包内文件。如何打包如何更新资源包，是设计重点。现在有很多资源包直接使用通用打包（压缩）格式，比如 zip 。也有自行设计的，多半是为了一些特殊需求。比如资源间有引用关系等。如果资源数量过多，通常还会对原始资源文件名做一次 hash 索引，加快包内文件检索效率。像暴雪的 mpq 格式，还有 unity3d 的 asset bundle 格式都是这样的。一旦资源打包，原始文件名信息就不再需要了。应用程序可以在运行时通过文件名的 hash 值索引到包内文件。（所以第三方的 mpq 解包工具需要提供一份额外的文件名列表）既然是 hash ，那么就应该在包格式设计中考虑 hash 冲突的解决方案。asset bundle 的设计人这方面经验欠缺，他们在生成 Deterministic 包的时候，遇到 hash 冲突就直接放弃打包。这显然是不合理的。对于一般几千个文件的包， 32bit hash 值肯定是够用的，但 hash 冲突绝对不能忽略。一个简单的方法是加盐做二次 hash 。比如你在打包时发现有两个不同的文件名 A 和 B ，他们的 hash 值相同，比如 hash(A) 和 hash(B) 都是 H 。那么，在文件索引表中，就不应该在 H 名下记录数据，而是记录一个冲突标记，并引用一个 salt 。然 ...继续阅读 (66)

无论是客户端还是服务器，把 lua 作为嵌入语言使用的时候，都在某种程度上希望把 lua 脚本做多线程使用。也就是你的业务逻辑很可能有多条业务线索，而你希望把它们跑在同一个 lua vm 里。lua 的 coroutine 可以很好的模拟出线程。事实上，lua 自己也把 coroutine 对象叫做 thread 类型。最近我在反思 skynet 的 lua 封装时，想到我们的主线程是不可以调用阻塞 api 的限制。即在主干代码中，不可以直接 yield 。我认为可以换一种更好（而且可能更简洁）的封装形式来绕过这个限制，且能简化许多其它部分的代码。下面介绍一下我的新想法，它不仅可以用于 skynet 也应该能推广到一切 lua 的嵌入式应用（由你自己来编写 host 代码的应用，比如客户端应用）：我们可以在第一个主模块加载时，在 skynet 中也就是 require "skynet" 这里，启动一个调度器的 coroutine 。这个 coroutine 只用来管理一个数组，数组里全部是业务逻辑的线程。这个调度器所属的 coroutine 对应的lua_State指针，应该记录在 lua vm 的注册表中，保证只到整个 vm 关闭前都活着，那么，接下来我们就可以放心的把它保存在 host 程序中了。这样，在 host 程序中，除了原有的代表 vm 以及主线程的 L 之外，我们还有 ...继续阅读 (64)

最近在尝试重新写 skynet 2.0 时，把过去偶尔用到的一个对象生命期管理的手法归纳成一个固定模式。先来看看目前的做法：旧文 对象到数字 ID 的映射其中，对象在获取其引用传入处理函数中处理时，将对象的引用加一，处理完毕再减一。这就是常见的基于引用计数的对象生命期管理。常规的做法（包括 C++ 的智能指针）是这样的：对象创建时，引用为 1 （或 0）。每次要传给另一个处地方处理，或保留待以后处理时，就将其引用增加；不再使用时，引用递减。当引用减为 0 （或负数）时，把对象引用的资源回收。由于此时对象不再被任何东西引用，这个回收销毁过程就可视为安全且及时的。不支持 GC 的语言及用这些语言做出来的框架都用这个方式来管理对象。这个手法的问题在于，对象的销毁时机不可控。尤其在并发环境下，很容易引发问题。问题很多情况是从性能角度考虑的优化造成的。加减引用本身是个很小的开销，但所有的引用传递都去加减引用的话，再小的开销也会被累积。这就是为什么大多数支持 GC 的语言采用的是标记扫描的 GC 算法，而不是每次在对象引用传递时都加减引用。大部分情况下，你能清楚的分辨那些情况需要做引用增减，哪些情况下是不必的。在不需要做引用增减的地方去掉智能指针直接用原始指针就是常见的优化。真正需要的地方都发生在模块边界上，模块内部则不需要做这个处理。但是在 C/C++ 中，你却很难严格界定哪些是边界。只要 ...继续阅读 (42)

接前一篇文，谈谈 skynet 消息队列的一些新想法。之前谈到，每个服务的消息接收队列可以是定长的，且不必太长。因为正常运行中，每个服务都应该尽量消化掉需要处理的消息，否则会预示着某种上层设计的问题。但是，在接收队列满的时候直接丢掉消息显然是不合理的。那意味着必须有更健全的错误传播机制，让发送失败方可以出错而中断业务。允许发送消息出错可能使上层结构设计更难。让发送方阻塞在 skynet 中显然也不是个好方案。因为 skynet 的服务是允许阻塞时重入执行另一条新 session 的，这是和 erlang 最大的不同。这可以让单个 lua vm 的性价比更高，可以在要需要的时候，做共享状态，而不必全部业务都通过相对低效的消息通讯来完成；但其负面代价是重入会引发一些隐讳的 bug 。很多已有的 skynet 项目都依赖 send 消息不阻塞这点来保证逻辑正确，不能轻易修改。我的解决方案是给每个服务再做一组发送队列。最接收方忙的时候，把待发消息放在自己这里的发送队列中。这样就可以由框架来确保消息都能正确的依次发送（这里不保证目的地不同的消息的先后次序，但保证目的地相同的消息次序）。这两天，我仔细考虑了这个方案。从单一接收队列改为一个接收队列和若干发送队列。实现复杂度一定是增加了，但并没有达到不可接受的程度。这个方案并不难想到，也不难做到，但 3 年前实现 skynet 时我并没有这么做 ...继续阅读 (56)

这个月 skynet 的 1.0 就会 release 最终版了，除了维护这个稳定版本。我考虑可以对一些不太满意的地方尝试做大刀阔斧的改变（当然不放在目前的稳定版本中）。我对 skynet 解决的核心问题：多服务任务调度以及内部消息传播这块不是很满意，觉得如果换个方式实现可能会好一些。下面先把想法记下来。目前，每个服务都有一个唯一的消息队列，且在内存足够的前提下，会无限增长。也就是说，向一个服务发消息是没有失败的可能的。多数情况下，单个服务的消息队列不会太长，在生产消费模型中，也不允许太长。太长意味着消费速度远远低于生产速度，情况多半会恶化。在历史上发生过多起事故，都是和服务过载有关。虽然 skynet 提供了 mqlen 这种方法供使用者查询当前服务的消息队列长度，以做出应变，但治标不治本。我想做一个大的设计改动来重新考虑这一块。我们可以把每个服务的消息队列实现成固定长度，且固定长度并不需要太长，大约 256 个 slot 这种级别就足够了。一个固定长度的循环队列实现起来要简单的多，且很容易做成进出队列互不影响。因为出队列只发生在一个服务内，不可能并发，根本不需要考虑竞争；而仅仅只需要考虑进队列的竞争问题。当队列满，或有人在入队列操作时，都认为队列忙，不需要做锁，直接失败即可。遇到忙的时候发送方可以自行缓存代发数据。而多方同时写入队列时，对 skynet 来说，其实不需要保证先后 ...继续阅读 (50)

拖了很久，终于决定给skynet1.0.0 封版了。比预期的时间足足晚了半年，好在还是在 2015 年把这个事情启动了。其实已经很久没有对已有特性做修改了，如果的项目是在今年 3 月份以后跟进的 1.0 alpha 版的话，升级到目前的最新版本应该不会有太大痛苦。最近几个月几乎没有增加新的特性，反而是在裁减一些多余的，用的人不多的东西（为了兼容，把这样一些 API 移到了一些独立的模块中，方便废弃）。据我所知，skynet 用于的商业游戏项目（以及一些非游戏项目）早已经超过了 2 位数，收获了不错的口碑。它不再是我们自己公司的内部项目，持续收到不同人的 PR 说明很多同学不仅仅在使用，更是用心在 review 代码，让它真正成为一组公众视野下的代码。我相信这是开源的终极意义：众目睽睽之下， Bug 无所遁形。我们自己的项目也从 skynet 开源经营中获益良多。有好几处来源于外部的 bugfix 都是在错误发生前被堵住，只是可惜的是，我们也有项目未能及时跟进，只到真的出错了才回头发现在主干上早已改过。这些事故反而证明了开源对于提高项目质量的作用。这次发布 1.0.0 正式版本的候选版 (RC) ，并专门公告，就是希望有在使用 skynet 的同学，尤其是已经有项目上线运营的，能够在最后这几天将遗留问题提出来，issue 或 pr 都可以。不要把遗憾留到 1.0.1 :)我希望这次把 ...继续阅读 (62)

skynet 本质上只是一个消息分发器，以服务为单位，给每个服务一个独立的 id ，可以从任意服务向另一个服务发送消息。在此基础上，我们在服务中接入 Lua 虚拟机，并将消息收发的 api 封装成 lua 模块。目前用 lua 编写的服务在最底层只有一个入口，就是接收并处理一条 skynet 框架转发过来的消息。我们可以通过 skynet.core.callback （这是一个内部 API ，用 C 编写，通常由 skynet.start 调用）把一个 lua 函数设置到所属的服务模块中。每个服务必须设置，且只能设置一个回调函数。这个回调函数在每次收到一条消息时，接收 5 个参数：消息类型、消息指针、消息长度、消息 session 、消息来源。消息大致分两大类，一类是别人对你发起的请求，一类是你过去对外的请求收到的回应。无论是哪类，都是通过同一个回调函数进入。在实际使用 skynet 时，你可以直接使用 rpc 的语法，向外部服务发起一个远程调用，等对方发送了回应消息后，逻辑接着走下去。那么，框架是如何把回调函数的模式转换为阻塞 API 调用的形式呢？这多亏了 lua 支持 coroutine 。可以让一段代码运行了一半时挂起，在之后合适的时候在继续运行。为了实现这点，我们需要在收到每条请求消息时，先创建一个 coroutine ，在 coroutine 中去运行该类消息的 dis ...继续阅读 (95)

Rogue's Tale 是个相当不错的硬核 RogueLike 游戏，之前我在 blog 里多次介绍过。前段时间还在 steam 上写了一篇新手上手指南。这款游戏的系统数值公式设计的非常精巧，在官方主页有详细的英文介绍，对熟悉游戏很有帮助。我选取了一部分基础设定翻译成中文。当然不仅仅是为了玩好游戏，也是对类似游戏的设计有所借鉴。以下基于http://rogue.epixx.org/翻译基础系统2D6 系统游戏里所有的行动都使用一套统一规则，其行动结果由对比扔出的两个六面骰数字与目标的难度级别来决定。在和目标难度级别做比较前，扔出的数字通常还会做一次增益或惩罚修正，该修正就是简单的加在扔出的数字上。如果最终修正值大于等于目标难度级，行动成功。如果低于难度级，行动失败。如果骰子扔出两个 1 ，行动被直接视为致命失败而无视修正值。如果骰子扔出两个 6 ，行动则直接判定为暴击而不需要加上修正值和难度级做对比。属性修正属性修正在生物依靠属性去做点什么事情的时候起效果。属性修正还用于修正伤害骰以及一些直接或间接针对生物的事件。正的修正被称为增益，负的修正被称为惩罚。人类的属性修正范围从 -5 到 +5 间线性变化，2 点时修正为 -5 ，7 点时修正为 0 ，12 点时修正为 +5 。属性点可以超过 12 点，此时修正值可以超过 +5 ，但和其它的增益或惩罚合并后，最终的结果会截取到 +5 ...继续阅读 (67)

起因是最近有人在 skynet 邮件列表里贴了段错误 log ，从 log 显示，他在 table.sort 的比较函数里调用了 skynet 的 snax rpc 去获取远程数据。然后被 lua 无情的报了 attempt to yield across a C-call boundary 。就 table.sort 不能 yieldable 的问题，其实在 lua 邮件列表里讨论过。老大的说法是，这个 C 实现是递归的，想要在 C 层面保留上下文非常困难，如果勉强实现，也会大大降低正常不需要 yield 的 case 的性能，非常不划算。通过这件事，我反而觉得 none-yieldable 的限制反而提前阻止了一个错误的实现，其实是应该庆幸的。最容易发现的是性能问题。在《Unix 编程艺术》一书 7.3.2 节讨论 RPC 时，这样批评道：“ a. 无法准确预估出一个指定调用会涉及多少数据的列集和散集，b. RPC 模型往往鼓励程序员把网络交易视为无成本行为。即使在某个事务处理接口上只额外增加一个来回，往往也增加足够多的网络延迟，完全抵消了解析或列集的开销。”这段话的语境是把 RPC 和传统的消息通讯方式相比较，针对那些认为 RPC 的效率更高的观点说的。即使不看效率，单看 RPC 给编程实现带来的方便性，其实最终是增加了，而不是减少了系统的复杂度。原文引用：“支持 RPC 的 ...继续阅读 (119)

起因是最近有人在 skynet 邮件列表里贴了段错误 log ，从 log 显示，他在 table.sort 的比较函数里调用了 skynet 的 snax rpc 去获取远程数据。然后被 lua 无情的报了 attempt to yield across a C-call boundary 。就 table.sort 不能 yieldable 的问题，其实在 lua 邮件列表里讨论过。老大的说法是，这个 C 实现是递归的，想要在 C 层面保留上下文非常困难，如果勉强实现，也会大大降低正常不需要 yield 的 case 的性能，非常不划算。通过这件事，我反而觉得 none-yieldable 的限制反而提前阻止了一个错误的实现，其实是应该庆幸的。最容易发现的是性能问题。在《Unix 编程艺术》一书 7.3.2 节讨论 RPC 时，这样批评道：“ a. 无法准确预估出一个指定调用会涉及多少数据的列集和散集，b. RPC 模型往往鼓励程序员把网络交易视为无成本行为。即使在某个事务处理接口上只额外增加一个来回，往往也增加足够多的网络延迟，完全抵消了解析或列集的开销。”这段话的语境是把 RPC 和传统的消息通讯方式相比较，针对那些认为 RPC 的效率更高的观点说的。即使不看效率，单看 RPC 给编程实现带来的方便性，其实最终是增加了，而不是减少了系统的复杂度。原文引用：“支持 RPC 的 ...继续阅读 (76)

很多人问起，为什么 skynet 的时钟不随系统时钟变更。我的答案是，skynet 系统保证内部的计时机构是单调递增的，有了这个约束，用起来可以回避很多问题。那么怎么做一个定时任务，好像 crontab 那样，而且可以随系统时间调整而变化。我的答案是，这是个纯业务层的需求，你爱怎么做怎么做，根据你的需求（业务量多少，定时是否频繁等）可以有不同的实现方式。但是总而言之，你需要在 skynet 里定制一个服务，可以按时驱动某种消息。而这个服务的定时机构，不应该完全依赖于 skynet 自己的内部时钟。如果你的任务并不多，我可以描述一个最简单的实现方法：在这个服务中，可以维系一张无序表，里面放着未来什么时候将触发什么任务。这些任务是其它位置注册过来的，任务只需要是一个独立的字符串即可，也可以是一个任务名带一个时间，比如 “9 点领奖” 这样。到点可以把这个串发送给订阅者。串中带上时间的好处是，万一哪个环节出了问题，订阅方可以自己去重，丢弃那些已经做过的任务。这样使用的流程就是，任务管理器向此服务注册一系列任务，约定每个任务的串。任务执行者去这个服务订阅对应的串，一旦到时间，就会获得通知。这个服务可以使用一个 skynet 内置的 timeout 回调来触发任务。每个注册的新任务都比较一下历史所有任务，如果时间更进则注册一个新的 skynet.timeout 回调。而每次收到 skynet ...继续阅读 (85)

我不用微信, 不过见过大概是什么样子。以前用过 icq/qq/gtalk ，现在也用的少了。目前流行的社交平台，也就是微博和 twitter 用一下吧。今天有些想法，闲扯几句。我觉得，作为现在安装在手机上为主的社交用软件，主要应帮人解决的基本社交需求是：给特定的人发特定的消息，或两人间讨论问题。这一点，以前手机短信就可以作到，只不过现代软件更可以发语音、视频、图片、地理位置等等，完善了这个用途。在现代软件普及之前，email 是一个对短信非常好的补充，可惜还不够普及。建立新的社交关系。可以是社交场合找到陌生人，也可以是由熟人引见新朋友，还可以是自我推销。在过去只用手机做主要联系方式的时代，很多人利用名片完成这一点。也可以是向人打听手机号码。然后把新社交关系延伸到 1 里。就某些话题在半公开场合一群人聚在一起扯淡。过去的网络论坛，后来的 qq 群，微博、微信，都满足了这个需求。这里提一下微博和 twitter 的主要区别之一，就是微博可以在一个主信息下，一堆人围绕着 po 主进行扯淡，这种信息组织方式和 twitter 很为不同。一开始我总觉得这种设计有些问题，但一直没想太清楚。个人对外发布信息。一部分信息会引导为 3 ，另一部分仅仅是发布而已。就需求 1 来说，点对点消息在通讯比例中应该是越来越少的，但却必不可少。我认为微信在这方面是走了回头路。其实过去手机短信就已经足够好了，你只 ...继续阅读 (70)

我部署在linode上的这个 blog 是 09 年装的 ubuntu 系统。只在 10 年的时候升级到 ubuntu 的 10.04 LTS 版，后来就一直懒得升。其实敲一行指令就可以了，可每次 ssh 上去就是懒得做。今天突然觉得不太妥了，试了一下 do-release-upgrade 居然失败了 :( 。google 了一下，大约是说我这个系统停止维护太久了，早就超过了最后期限，升不了了。痛定思痛，打算亡羊补牢一把。我想了一下，其实最主要的业务就是一个为 codingnow.com 解析域名的 bind9 服务，一个 apache 一个 mysql ，重装一下系统的话，把数据链过来应该问题不大。正好 linode 前些年送了我 8G 硬盘空间，一直懒的用上，正好装新系统。工作进行的比预想的要麻烦的多，这提醒了我，下次一定要及时升级系统，不能再这么折腾了。在新分区上安装 ubuntu 14.04 LTS 倒是很简单，linode 后台一分钟搞定，重新 reboot 就可以切到新系统。然后挂接老分区当数据盘用。我必须把 /home 和 /var 目录指回老的数据盘，否则新分区空间太少了。这个工作倒容易，只是一开始忘记修改 fstab ，导致系统重启后跑不起来（/var 目录被我做了个软连接到未挂接的分区上，导致 log 文件创建失败）。最先折腾 bind9 服务，发现直接复制数据 ...继续阅读 (67)

今天同事提了个需求，他希望可以给部分 lua 代码（由策划编写）做一个沙盒关起来。在 lua 里做沙盒很容易，只需要控制函数的环境就可以了。不过另一个附加需求是，这些代码还可以直接利用 require 加载。而我们又不想去修改系统的 api 接口，那么怎么做到这点呢？首先, 我希望使用的时候看起来像这样：local xxx = require "xxx" (myEnv)和传统的 require 用法不同，可以在后面追加一个参数 myEnv 。这样的话，每次 xxx 模块被 require 时，它其实被重复运行一次，但会绑定不同的_ENV。其次，既然模块会被反复初始化，那么我们甚至还可以约定，每个这种沙盒封装的模块还可以接收 require 的传入的额外参数。做到这点很容易，我们只需要在 package.searchers 里追加一个自定义的 loader 然后并不返回加载的模块 chunk ，而是做一个函数封装。将 chunk 的运行推迟到传入 myEnv 调用之后。这样，load chunk 本身还是依靠 require 的 package 机制缓存代码的，只是每次调用后，重新绑定_ENV生成了一组新实例。我在 gist 上贴了一组代码实现这个特性：延迟绑定环境的 require。 ...继续阅读 (62)

维多利亚 II 这是本月我最喜欢的游戏了，有点老，也不算太老。最后一个 DLC 黑暗之心 是 2013 年出的。在游戏刚出的时候，有一篇著名的介绍文章，推荐一读：维多利亚2（Victoria2）：历史的逻辑。我当初就是看了这篇文章知道这款游戏的，可惜当时没玩进去。经过几年的发展后，现在的版本比当初完善了太多了，所以不用在意文章中说的缺点。下面是我在 steam 上写的评测：陆续买了 P 社很多游戏，都没安下心来玩。知道很好玩，但就是耐不下心来。维多利亚在刚出的时候就玩过，可能是因为没有汉化，没找到乐趣就放下了。这几天看到 DLC 已经出了这么多，网上找的汉化包据说也相当高质量了，就仔细体验了一翻。结论：相当棒的游戏，如果想体验历史战略的感觉，可能目前找不到第二款了。我想推荐给所有没玩进去 P 社游戏的所有玩家，不要怕，你一定玩得懂的。至于 P 社的粉丝，肯定不用我推荐啦。注意，一定要买齐 DLC ，尤其是黑暗之心，这样才是一个完整的游戏。不要图便宜只买原版，那会少太多乐趣。这款游戏很特别，不像文明，有随机地图，还有玩家精心制作的地图 mod 。它只有一张地图，就是一战前的真实世界，但重玩价值非常之高。因为你可以从任意一个国家起手，体验到完全不同的乐趣。游戏把国家的政治经济外交设定的非常真实，而有保留了极高的自由度。游戏大部分按照规则推演却又不失真实。我查看过游戏的事件脚本，触发条件 ...继续阅读 (117)

不断的有人问在 skynet 里怎么给跨服务调用加上超时处理。我不太想再解释为什么在 skynet 这样的系统中，加入超时机制会使得在其上构建的系统增加不必要的复杂度。那只是为了想不到更好的方法而做的一点变通。你应把 skynet 视为一个整体，正如你平常所写的程序，大多数 api 调用的时候不会设置超时一样。只有在明确的特殊需求时，才在上层在封装一层带超时参数的调用（而不是直接使用 skynet.call ）。当昨天再次收到这个特性请求时，我仔细考虑了一下。发现了一个有趣的方案，可以非入侵性的在现在的框架下加上超时返回这个特性，下面做一个记录：修改 skynet.lua 这个基础库很不划算，会改变很多基础的调度代码。另外写一套带超时的 call 又会和已有代码大量重复。其实，如果我们单独做一个代理隧道服务，专门转发请求，超时处理就会简单的多。我们可以实现一个代理服务，它的作用仅仅是将外部请求转发给指定的服务，并将回应包转发回去就够了。在这个代理服务中可以设定一个超时值，一旦转发的请求在指定时间内没有响应，则给调用者一个 error ，并在真正收到回应时忽略掉就可以了。我们甚至可以在这个代理服务中做许多额外的监测和统计工作，易于发现系统中有问题的设计。而代理服务将实际的服务包裹起来后，对调用者来说，是完全透明的。超时设置只在启动时（或写在配置文件中）设置，使用时，完全不需要修改原有 ...继续阅读 (100)

前段时间去希腊旅游，回程埃航的票在开罗转机，停留 10 小时。原来计划并没有打算游埃及，所以也没有办埃及签证。感觉那边革命完没几年，设计应该比较乱，还是在机场待着比较安全。结果一下飞机就被一工作人员领到转机口办手续，说是可以带去酒店休息。一想还有这么好事，可以淋浴睡觉，顿时对埃航好感度提升。由于就是在机场转机柜台办的，放心把护照交给他们了，按吩咐跟着机场的妹子去酒店。原来以为房间就在机场里（因为没有签证，埃及也不是落地签，通常出不了海关），结果莫名其妙就走工作人员通道出去了，只是要把护照压在机场里。当时没多想，出了机场换了个人（确认还是机场的工作人员）说带我们去酒店。等车的时候问要不要去金字塔看看，一个人收 40 刀（车费），可以刷卡。想想既然来了，不去有点可惜就答应了。一路上，他更像是个导游，各种聊天活跃气氛。路上有可以拍照的地方还都停下来让拍完照再上车，直到金字塔附近车突然就拐进一小巷子，把我们拉到一看起来不那么正规的骑骆驼游沙漠的店里。后面就是各种挨宰了。由于连护照都被人押住了，感觉就是非法入镜。离机场又那么远，想想就认命了。看起来人家也只是求个财，最后前前后后被宰了几千埃镑（和 RMB 汇率差不多，略贱一点，应该和港币等值）。全部是刷卡的，最大头是骆驼游，一人要一千多。然后是强卖的阿拉伯头巾，一快破布要 150 。所有人都死命的要小费，给美元还不高兴，要欧元。由于钱包里没几 ...继续阅读 (54)

最近XcodeGhost这个事挺火的，简单说就是有人在 Xcode 里植入了木马，让用这个被修改过的 XCode 编译出来的 ios app 都被插入了一些代码。由于 XCode 几乎是生成 ios app 的唯一手段，且墙内的同学各种诸如用 baidu 搜索，迅雷下载等坏习惯早就根植在基因里了，导致了这份被种马的 XCode 在最近半年里广泛传播，污染了一大批国产 app 。我这里就不提那些中招的所谓大厂了，如果经常听我扯淡的同学早就知道我的观点：即便是大厂，有安全常识的人还是少之又少、反而是所谓大厂因为管理更困难（好多大厂到管事的那级的人更跟不上知识更新），犯安全错误的机会就更大。这种从非官方渠道下载软件使用而中招的事情又不是第一次了。上次putty 被种后门的事情过了也没多久，好了疮疤忘了痛，对吧。种马的手法其实也不新鲜。有点年纪的程序员读书时，课本上一定教过：计算机病毒有四种形式，最后一种就叫源码病毒，感染附着在编译器中。只是估计很少人见过，后来课本就删掉了。其实呢，这个说法的源头是 Ken Thompson 在 1984 年图灵奖演说上提到过的恶作剧。老实说The Ken Thompson Hack的手法比这个高明的多。XcodeGhost 的技术细节就不分析了，网上一搜一大堆。我想说的是这次这个东西危害问题。这玩意有没有害？当然有。你以你名义发布的程序被人插入了一段你不 ...继续阅读 (57)

今天有同学反应 blog 无法留言了，说是不能创建新文件。我试了一下，果然如此。可是 ssh 上去看，磁盘空间还有 30% 。猜想是 inode 用光了，用 df -i 看了一下果然如此。但是一下子没想出来是什么东西产生了大量小文件。只好用二分法筛选目录去看。结果发现是很多年前用 php 写着玩的一个留言本，每次留言都会产生一个新文件。这个留言本没有公开 url ，不知道被什么爬虫爬过了，累积下来居然留了一百万条垃圾信息。删掉后一切正常。另外，最近间歇性的出过 web 访问无法返回的现象。经过排查，是原来用的一个 wiki 系统的某个 bug 导致的死锁。那个系统虽然是开源的，但早就无人维护了，这几年我试着修过几个 bug ，这次真的懒得修了，直接把链接从首页去掉。最后一个问题是 blog 的留言处理的很慢（导致很多同学多次提交），不知道是不是数据太多了，原来的 movable type 的老版本结构没设计好导致的，一时也不想追查。看来是时候换个自己写的 blog 系统了。用这些停止维护的老开源系统真心不如自己搞啊。 ...继续阅读 (51)

《心动庄园》已经开发超过了一年半，其实去年这个时候我们已经在内测了，折腾了很久，改来改去的。之所以项目折腾超过了预期时间这么久都没有被公司砍掉，纯粹是因为开发者对这款游戏是真爱。所有开发人员，甚至包括程序，都花了大量时间玩它，并喜欢它。你可以想想，反复改了一年多还留有爱，那不是真爱是什么？所以即使开发预算超标，公司的管理层也不舍得砍掉它。这是款农场经营游戏，一开始立项是因为我们公司有很多人喜欢玩 hayday 。头三个月，我们也真的是在认真的复制 hayday 。之后，就开始了漫长的修改期。如果你对一款游戏有了深入的了解，你就会去想游戏背后的内在逻辑，是什么导致游戏粘住用户的。当把这些剥离出来，你就可以设计属于自己的东西了。改着改着，这就成了一款我们自己的游戏，虽然新手阶段依然有 hayday 的影子。但不用刻意回避它，毕竟很多基础玩法是被无数用户证明过有趣的，而整个游戏的骨干是经过设计人员思考的，并不是简单的复制。我们在长期的测试过程中，不可避免的一些原创的玩法也陆续被国内一些已经上线的同类游戏借鉴过去，但我们并不在意。抄个表象容易，那些系统的结构却很难复制。另一方面，没玩过 hayday 的玩家依然很多，只要给喜欢这类游戏的玩家带来一个逻辑完整的游戏就好了，不必太在意表层的相似。说了这么多，如果有兴趣试一下的同学，可以在这里下载。游戏官网http://xd.ejoy.com ...继续阅读 (60)