网游里有很多抽卡、开箱子之类的赌性玩法，在最开始，游戏设计者实现的时候，仅仅给这些抽取概率简单的设置了一个值。比如抽卡抽出橙卡的概率是 10% ，那么就是说，玩家每次抽一张卡，有 90% 的可能是白卡，10% 的可能是橙卡。但大 R 玩家是大爷，需要小心伺候。如果感受不好，人跑了就亏大了。概率这个东西靠改进伪随机数发生器是解决不了体验问题的，大爷要是连抽 20 张都出不来橙卡，那是要怒删游戏的。连抽 20 张 10% 概率橙卡一张都抽不到的机会多不？一张抽不中的概率是 0.9 ，20 张都抽不中的概率是 0.9 ^20 = 12.2% 。这可不算小数字啊。平均 8 个大 R 就会碰到一次，一下子赶跑了 1/8 的金主，这个责任小策划可担当不起。所以、一般网游都会用各种规则来避免玩家出现连抽不中的尴尬。例如，我忘记是谁发明的 10 连抽规则：如果你购买一个大包连抽 10 次，我在规则上就保证里面一定至少有一张橙卡。实现它应该并不困难，按常规概率生成 10 张的卡包，如果里面没有橙卡，那么我加一张即可。但如果我想把 10 抽保底的规则惠及日常抽卡的玩家该怎么做呢？就是说，我希望任何玩家任何时候，接连抽了 10 张卡，我都想保证这 10 张卡里至少有一张橙卡。首先，要说明的一点：如果你同时想保证橙卡掉落率是 10% ，也就是在极大范围内，比如系统投放了一万张卡片中，其中要有一千张橙卡。那 ...继续阅读 (89)

云豆两岁的日常：奶奶：10 点了，豆豆该睡觉了。豆豆：要听咕哩咕哩。奶奶：ipad 没电了。（ipad 电量 1%）豆豆：ipad 真没电了。奶奶：听小兔子好吗？豆豆：（拧开开关）小兔子不好听。（关上）豆豆：ipad 没电了、手机也没电了、奶奶唱歌。奶奶：唱什么？豆豆：门前大桥下……奶奶：我不记得歌词了。豆豆：（唱）门前大桥下，游过一群鸭…… 不记得歌词了。豆豆：奶奶唱，（唱）小燕子、 穿花衣，年年春天来这里～奶奶：你不是会唱吗？豆豆： 奶奶唱小燕子， 豆豆睡觉。奶奶：（唱）小燕子 穿花衣 年年春天来这里～ Zzz...豆豆：奶奶睡着啦。 ...继续阅读 (280)

很多使用 Unity3D 开发的项目，都不太喜欢 C# 这门开发语言，对于游戏开发很多人还是更喜欢 Lua 一些。而 Lua 作为一门嵌入式语言，嵌入别的宿主中正是它说擅长的事。这些年，我见过许多人都做过 U3D 的 Lua 嵌入方案。比如我公司的阿楠同学用纯 C# 实现了一个 Lua 5.2 （用于在 U3D web 控件中嵌入 Lua 语言的 UniLua ）；还有 ulua slua wlua plua xlua ... 数不胜数。我猜测，a-z 这 26 个字母早就用完了。上面提到的项目的作者不少是我很熟悉的朋友，我们公司现在的 U3D 游戏也由同事自己实现了一套差不多的东西。所以我曾了解过这些方案。但我一直觉得这些方案要么做的过于繁琐，要么有些细节上不太完备，总是手痒想按自己的想法搞搞看。Mono 和 C 通讯使用 P/Invoke ，用起来不算麻烦，但是要小心暗地里做的 Marshal 的代价，特别是对象传递时装箱拆箱的成本。Lua 和 C 通讯有一套完善的 C API ，但完全正确使用并不容易。核心难点是 Mono 和 Lua 各有一套自己的异常机制，让它们协调工作必须很小心的封装两个语言的边界，不要让异常漏出去。我在 2015 年写过一篇 Blog 做过相关讨论。我认为简单且完备的 Mono / Lua 交互方案是这样的：当一边要和另一边通讯时，这和 C/S 结构的 ...继续阅读 (123)

U3D 的打包流程，谁用谁知道。由于输出 ios 包必须在 xcode 环境，跑在 Mac 系统上，所以为了定期版本打包，我们采购了配置比较高的垃圾桶来做。一台大约要三万 RMB 左右。但我觉得这个方案的性价比太低了。经过简单的考察，我发现，打包流程中最慢的环节是贴图压缩。在不同的平台，需要把原始贴图文件压缩成对应平台的压缩贴图格式： ios 平台对应的是 PVR 压缩格式；Android 平台对应的是 ETC 压缩格式，等等。u3d 自己也意识到压缩贴图太慢，所以官方给出了一个 CacheServer 方案。本质上 CacheServer 只是一个文件 cache 服务器，它记录了用贴图原文件和转换参数（u3d 的 meta 文件）以及转换器版本等信息构成的串的 md5 值作为文件的索引。第一个做转换的人，在本地压缩完毕后，会将结果上传到 CacheServer ，然后后面的人需要做相同的压缩时，去 CacheServer 查找是否之前有人做过同样的工作，避免重复操作。当源文件相同、转换参数也完全一样时，结果会被缓存。由于日常几乎所有贴图都被人压缩过，这样极大的减少了定期打包的时间。CacheServer 的设计虽然简单，却不能最好的解决问题。实际打包时，还是需要很长的时间。这是因为，定期打包需要输出各个平台的包，而日常开发只会稳定在一个平台上。比如日常工作使用的都是 Andro ...继续阅读 (69)

写备注总有时候光靠文字描述不是很清楚，这个时候特别想在文档中附个关系图。用graphviz的 DOT 来描述图固然不错，但是它需要额外工具来生成才能直观的查看。如果我们想在纯文本环境附上插图，使用 ascii art 是最佳选择。我搜了一下，perl 的Graph::Easy是唯一能找到的支持 ascii 输出的关系图绘制软件。但是这个东西有个问题，就是对中文支持不行，虽然文档中说完全支持 Unicode ，但显然作者并没有把汉字用在 Ascii 输出上过。问题是这样产生的：UTF8 中，汉字是 3 字节，而对于显示来说，等宽字体的汉字是 2 倍普通字母宽。这样在排版时，你必须知道一个字符串在视觉上是多宽，才可能用 ascii 字符拼接出正确的方框和连线。比如，这个帖子就讨论了类似的问题。一开始，我希望找到 Graph::Easy 库中取 label 宽度的函数，让它正确返回 label 的视觉宽度。修改后，发现还是不行。这是因为，这个东西在 ascii 输出时，是用一个 2D 的字符数组模拟了虚拟画布（framebuffer）。它认为，framebuffer 上的一个矩形区域，就应该是 w * h 个字符构成的区域。如果想进一步的让它在 framebuffer 上定位正确，还需要修改它计算坐标的地方。可是，写 framebuffer 是一个随机过程，你向左边写一个一个字符，如果是 ...继续阅读 (66)

很多项目采用 lua 的一大原因是 lua 可以方便的做热更新。你可以在不中断进程运行的情况下，把修改过的代码塞到进程中，让随后的过程运行新版本的代码。这得益于 lua 的 function 是 first class 对象，换掉代码不过是在让相应的变量指向新的 function 对象而已。但也正因为 lua 的这种灵活性，想把热更新代码这件事做的通用，且 100% 做对，又几乎是不太可能的。首先，你很难准确的定义出，什么叫做更新，哪些数据需要保留，哪些需要替换成新版本。光从源代码和运行时的元信息上去分析是远远不够的。lua 只有一种通用数据结构 table ，这方便了我们做数据更新；但同时也制造了一些模糊性难题。比如，如果在代码中有一些常量配置数据表，写死在源代码中，通常你是希望跟着新版本一起更新的；而有一些表，记录着运行时的状态，你又不希望在代码更新后状态清空。所以一般做热更新方案的时候，都会人为加一些约束，在遵循约束条件的前提上，尽量让更新符合预期。比如在 skynet 中就提供了一种简单的热更新方法。最近在给公司的项目做一些技术指导，同时也做一些工具来提高开发效率。对于开发期（而不是生产环境），或许提供一个更灵活的热更新方案更方便一些。我们不太需要结果 100% 正确，但是需要减少一些约束。在开发期，最好就是改两行代码，能立刻让进程刷新成新版本的代码，并不中断运行。如果更新 ...继续阅读 (65)

最近一段时间在帮公司一个项目组的客户端 review 代码。我们的所有项目，无论渲染底层是用的 ejoy2d 还是 Unity3d ，实际开发的时候都基本是使用 lua 。所以开发人员日常工作基本是在和 Lua 打交道。虽然我个人挺反感围绕着调试的开发方式，也就是不断的在测试、试错，纠正的循环中奔波。我认为好的程序应该努力在编写的过程中，在头脑中排错；在预感到坏味道时，就赶快重写。而坏味道通常指代码陷入了复杂度太高的境地，无法一眼看出潜在的问题。对付复杂度最好的武器是简化代码，而非调试器。在真正遇到 bug 时，应该仔细浏览代码，设想各种出错的可能。而不是将错误的代码运行起来，查看运行中的状态变化。话说回来，看到项目组的同学真的碰到 bug 时，不断的启动 Unity 客户端，把时间浪费在等待那几行 debug log 上，我觉得效率还是很低。必要的调试工具应该能提升一些开发效率的。lua 官方提供了完善的 debug api 可以查询所有的信息；但并没有一套官方的调试工具。我都不记得是第几次写调试工具了。至少在这个 blog 上就记录了好几次。最近的一次是 3 年前。每次做完送给人用了两天就扔掉了。这次一时兴起，周末又做了一个。当然每次都会有一些不一样的想法。这次的版本只开了个头，把构想中的基础架构搭好了。那就是，我认为一个优雅的调试器不应该过多的干涉被调试的实体（比方说你想监控 ...继续阅读 (64)

在制作 2d 游戏时，通常我们需要把大量小图素合并到一整张大贴图上。这可以使用装箱算法 （Bin Packing）完成。当然，很多人很懒，那么就用别人做好的工具，比如 Texture Packer 。但是在实际开发中， Texture Packer 有几个严重的缺陷 ，我个人还是建议自己来做合图的工具，完善工具链。缺陷 1 ：装箱过程其实并不需要了解图片上的内容，而只需要知道图片的尺寸。所以装箱过程需要的内存量应该只和被装的图素个数相关，和图片大小无关。而 texture packer 并不是这样做的，它把装箱和合成贴图两部工作放在一个黑箱里了，会导致运行时无谓的内存消耗（更不用说它本质上是一个 GUI 程序），不是很适合自动化工具链。缺陷 2 ：如果要求最终合并的图是 pvr 或 etc 压缩贴图，那么还需要最后再对目标图做一次压缩。通常这个压缩过程是比较慢的。这个缺陷 2 在开发期需要反复打包资源时，对开发效率影响尤其大。但其实如果自己好好设计工具链，是完全可以避免的。下面就谈谈应该怎么处理 ETC 这类压缩贴图的合并问题。ETC 这类压缩贴图，内部其实是按 4x4 像素为一个单位区分开的。各个单元之间没有相关性，也只有这样，显卡才能快速处理。所以，完全没有必要在合并图素后，对目标大图做压缩。正确的做法是，为小图生成对应的压缩数据，好比编译器将 .c 文件 编译成 .o 文件； ...继续阅读 (74)

今天有同学跟我讨论了一下最近发现的一个 bug ，我觉得挺有意思的。需求是这样的：我们的系统中，有一些数据是从外存（数据库）加载进来的，由于性能考虑，并不需要每次修改这些数据就写回外存。希望在数据变冷后，定期落地即可。典型的场景是一个 cache 模块，cache 的是一些玩家的业务数据，可以通过 uuid 从数据库索引到。一旦业务需要访问玩家数据，cache 模块会从数据库加载对应数据，然后把数据表交出去。当业务再次需要这些数据的时候，cache 模块一旦发现数据存在于 cache 中，就直接交给玩家。cache 模块还希望在数据很久没有被业务访问时，将这些数据写回数据库。我们的系统是基于 lua 构建的，数据 cache 模块和修改这些数据的逻辑在同一个 vm 里。难点在于，修改数据的业务逻辑是可以长期持有数据的，cache 模块需要正确感知这点。先来看看最朴素的实现方法：cache 模块其实就是一张 uuid : 数据 表。加载数据的时候，检查 cache 中是否存在，如果没有就把数据写到 cache 表中。然后刷新一下数据的时间戳，表示最后访问的时间。数据落地流程是：从队列中取出一个超时（最后一次访问过于久远的）待落地数据，擦除 cache 对应项，标记 uuid 为锁定状态（阻止加载流程在落地过程重新加载），落地，完成后解锁（并唤醒潜在的加载需求）。这个方法可以实现在使 ...继续阅读 (63)

前面一篇谈了放置类游戏的网络同步，我想把其方法推广到其它类型的游戏，比如 MMORPG ，比如动作游戏。尤其是动作类游戏，非常需要客户端可以即时处理玩家的操作，而不能等待服务器确认。我们来看看这些类型的游戏和放置类游戏的不同点。放置类游戏大部分是玩家个人和服务器在玩，不涉及第三方的干扰。所以，只要操作序列一致，那么结果就一致。MMORPG MOBA 动作游戏这些，是多人在玩。如果我们能同步所有玩家的操作，让所有玩家的操作序列在一条线上，那么也一定可以保证结果一致。这点，是上篇 blog 的结论。用同步操作的方式，同时赋予玩家对自己发起的操作标注时刻的权利，就可以在发起操作后，客户端立刻计算。只有在事后发生冲突时，服务器才会命令客户端取消无效操作。这个是前面谈及的同步框架可以解决好的问题。但，MMORPG/MOBA 都可能有一个问题：并非所有玩家的操作以及操作修改的数据，都是针对战场上的每个人的。比如，在 MMORPG 里，你可以选择隐身，别的玩家就不应该收到你隐身后的移动操作指令；你可以在战场上埋个地雷、别的玩家不应该事先知道你埋在了哪里。而且你未必希望让别人知道你背包里剩下什么道具，你还有多少 HP 。而前面谈及的同步模型中，却必须要求全部初始状态为所有客户端及服务器都知晓，整个游戏过程中发生的任何事件都需要传达给任何人，最终才能保证结果的严格一致。该怎么办呢？我认为最简单的方法 ...继续阅读 (69)

最近想试着做一款类似 Shop Heroes 的放置类网络游戏。总结一下此类游戏的客户端服务器同步问题。传统放置类游戏，比如小黑屋，是单机运行，不需要和服务器同步的。但出于防止作弊的目的（作弊会使玩家迅速失去游戏乐趣）或者希望加上多人玩法，我们通常希望把游戏进程放在服务器上管理，这样就有了网络同步问题。加上了服务器后，我们依然想保持玩家单机游戏的流畅体验，这里该怎么做，还是有许多门道的。对于 COC 类的城市建设那部分，我们可以看成是一个简单的放置类游戏：等待、收集资源、升级建筑。无论你在线还是离线，游戏都一直保持向前的进程。类 COC 的建设在玩家在线时，是完全不受干扰的。也就是说，对于城市对象来说，只有一个更改者。所以最简单的做法是，在玩家登录的时候，把上次离线时的状态从服务器同步到客户端，然后计算离开的这段时间发生的变化，得到现在的状态。而在玩家在线期间，玩家所做的每步操作，在完成相应逻辑后，都带上时间戳发送（同步）给服务器。服务器上有一套完全一样的模块，按时间戳（而非接收到操作的时间）进行完全一致的操作。这样，客户端所做的任何操作都不需要等待服务器的确认，和单机玩游戏有一模一样的操作手感。而服务器则仅仅做操作的合法性校验，一旦不合法，比如花一定金币去升级建筑，但是钱的数额不够，就要求客户端重新登录（正常游戏过程是不会发生的）。玩家下线也不需要将状态同步给服务器，服务器用户以 ...继续阅读 (69)

今天在公司群里，Net bug 同学提出了一个问题，围绕这个问题大家展开了一系列讨论。讨论中谈及了 lua 中的一个常见的模式：property table ，我觉得挺有意思，记录一下。最初的问题是：当一个对象的某些属性并不常用，希望做惰性初始化的话，应该怎么实现。我认为，property table 是一个很符合这个案例的常见模式。比如，对象 f 有三个可能的成员 a b c ，我们可以不把 f.a f.b f.c 记录在 f 这个 table 里，而是额外有三张大表，a b c 。利用 metatable ，可以在访问 f.a 的时候，实际访问的是 a[f] 。也就是说，所有同类对象的 a 属性，都是从 a 这张表里访问的。a 这张表的 key 就是对象，value 是对象对应的 a 属性值。这样做有什么好处？当对象的运行时用到的属性数量不一时，对象本身占用的空间是固定的。这里的对象变成了带 metatable 的空表，真正的属性值是统一放在有限张大表中的。大表可以预先分配好内存，而空表占的内存很小且固定，对内存分配器特别友好（容易实现 freelist ）。操作对象本身，不会因为增加属性而造成 rehash 。如果你并不能在对象初始化的时候就决定空间（会改写多少属性），那么好处就会很明显。另一个明显的好处是，如果你的对象很多，但是有少数对象会设置某种标记或回调函数，然后需要遍 ...继续阅读 (66)

上一篇谈到了 Shop Heroes 的经济系统，这一篇想谈谈它的公会系统。和很多其它网络游戏不同，Shop Heroes 的公会系统并不是一个可以被剥离的系统，它和整个游戏，包括其经济系统是密不可分的。我觉得这个系统是为了完成其游戏的根本设计目的：引导玩家差异化发展从而制造出市场需求，而设计出来的东西。在游戏中，不存在未加入公会的玩家。玩家在新手教学阶段就会被强制引导到一个叫做外城的环境，也就是游戏中的公会。你必须选择加入一个已有公会，或是自己创建一个单人公会，否则游戏无法进行下去。在游戏的前几十小时，一个人玩其实也没有任何障碍。你可以把公会建筑看成是个人资产的一部分，该升级升级。但在上一篇提到过，游戏中用来升级的金币最终会成为紧缺资源，总有一天你的收入会承担不起。当然，作为一个固执的 RMB 战士，你还是可以一个人玩下去的，城市升级可以用钻石替代。而且很贴心的设计成非线性对应关系。正如上一篇提到的，金币随等级不同（生产能力成指数上升），其价值也不同。所以如果你想投资 20K 金币，可以用 80 钻替代；而一次投资 500K 的话，就只需要 300 钻而不是 2000 钻了。相比一个人用钻石经营一座城市，更经济的方法是加入一个公会，大家共同建设一座城市；对于个人来说只有好处，没有任何坏处，何乐而不为呢。在 Shop Heroes 里，投资到公会城市里的每一笔金币，都始终是记在个人 ...继续阅读 (57)

最近两周在玩一个叫做 Shop Heroes 的游戏。知道这款游戏是因为它前两个月在 Steam 上线了 PC 版，玩了一下觉得有点意思。由于其 UI 一眼看上去就是手机风格，便在 app store 上搜索了一下，改到 ios 上玩。游戏设计的很好，对我这种资深游戏玩家有莫大的吸引力（对于快餐手游氛围下进入的新玩家可能因为系统过于复杂了）。它设计了无数个斯金纳箱，营造出文明的那种 one more turn 的心理感受，让人欲罢不能。具体不展开讲，有兴趣的同学自己玩玩试试。让我感兴趣的是游戏内部的经济系统，经过数十小时的游戏体验，我隐约感觉的到设计者希望将游戏设计成一个以玩家交易税收为主体的商业模式。而这种模式很多人都提出（我在 10 年前也反复考虑过，在 blog 上也做过一些思考记录）并希望实现，可全部都失败了。比如著名的 Diablo 3 ，曾经就宣称自己打算用交易税来维持游戏的利润，最后因为破坏了游戏体验而关闭了现金拍卖场。国内也有征途等打着以交易税为收入来源旗号的游戏，而实际上也只是个幌子。而 Shop Heroes 似乎真正做到了这点。从结果上看，在市场上的中高等级玩家之间流通的物品全部是用钻石结算的。而游戏本身，玩家提交求购或售卖单的时候，都可以自由选择用钻石（现实货币）或金币（游戏货币）结算。虽然我是一个免费游戏玩家，但我尝试过用（免费获得的）钻石提单到市场，均快 ...继续阅读 (66)

Lua 的 table 可以做数组用，但是前提是数组里不能有空洞。也就是不能在数组里保存 nil ，否则取长度和迭代的行为都是不确定的。能不能用比较小的额外代价在 Lua 中实现一个支持空洞的数组呢？首先，我们定义一下，带空洞的 array 的正确行为应该是怎样的：数组只能用正整数做 key ，设置其它 key 会抛出 error 。可以用 pairs 迭代数组，和普通的 table 一样，迭代器会跳过那些值为 nil 的键值对。但要求迭代器一定从 1 开始从小到大按次序迭代。用取长度 (#) 操作符，可以正确的返回数组的大小，即最大一个正整数 key 。ipairs 的行为不变，会在第一个 nil 处停下来。我想，可以依旧用 table 来充当数组，而只需要重定义这个数组对象的__newindex__pairs和__len三个元方法就可以了。我们可以认为，在触发__newindex时，如果 key 在lua_rawlen返回的范围内，那么新的值还是保存在 table 的 array part 的，不用特别干预。而如果在 hash part， 可以额外把这个 key 记录下来，我想以负数为下标就可以了。每当 pairs 迭代前，或是取 # 长度前，我们可以对稀疏部分，哪些负数下标记录的额外 key 做一次排序去重整理。之后的运算复杂度就可以控制在 log(n) 内。实现的代码见gi ...继续阅读 (65)

按局打的纯 PVP 机制的游戏，面临最大的问题将是，在一个玩家想找人对战的时候，找不到对手匹配。如果游戏的在线玩家达不到一定人数，那么这个问题会恶化：等不到人和你一起玩、放弃等待、新的玩家更找不到对手。像皇室战争、王者荣耀、炉石传说这些火爆的 pvp 游戏都属于迈过了线的作品，玩家不太愁等不到人一起玩，提升了游戏体验，聚集了更多的玩家。而当玩家群有限时，同类产品就很难竞争，只要在线用户掉到一定限度以下，很可能导致（无非找到对手）体验下降，更多玩家流失。那么，有没有办法解决初期玩家过少的问题呢？直观的想法就是没人玩 AI 凑。可 AI 并不是真人，和 AI 在公平规则下对战乐趣会少很多，且高水品 AI 开发起来也非常困难。最关键的是，一旦玩家乐于和 AI 对战（无论是因为对战本身的乐趣，还是可以刷分刷掉落），你会进一步失去在线用户。让我们来估算一下这个问题有多么严峻：据说王者荣耀目前的日活跃用户有 3500 万，自然不愁找不到对手。如果你玩过这个游戏，必然会有体会，每天为了玩这个游戏等待匹配的时间有多长呢？我没玩过，让我随便估算一下吧，如果一天打两盘，平均每盘等 10 秒钟。我的每天等待时间就是 20 秒。即一个用户每天有 20 秒在线时间可以供和同样的人一起匹配准备。每天有 24 * 60 * 3 = 4320 个 20 秒，那么对于 3500 万日活跃用户来说，当你在等待其他玩家 ...继续阅读 (125)

最近一个月，玩群星(Stellaris) 有点着魔。不同于 P 社之前我最喜欢的维多利亚2 ，这个上手更舒服。是我玩过的把大战略和 4X 结合的最好的游戏了。我很欣赏 P 社这种尽力降低玩家门槛的做法，让大战略和 4x 游戏不那么高冷，普通玩家也能很快领略其中的乐趣。这里有我写了一篇评测。大致谈了群星是一个怎样的游戏，如何快速入门。小提示：即使是新手，也推荐用铁人/疯狂模式。第一次玩只需要把银河调小一点就好了。这样乐趣才能充分体现出来。这次 P 社的引擎革新后，汉化变得很容易了。之前，大多数人和我一样使用的 3dm 版汉化 mod ；但这个 mod 翻译的时候，译者并没有怎么玩游戏，所以很多地方用词不当，还有一些仓促翻译导致的错别字。我实在受不了老式的闷头汉化的模式了，发现问题反馈到修正的周期太长，所以就自己维护了一个汉化 mod 。需要的同学可以直接订阅。个人认为，利用 github 做合作创作，对于做汉化这件事特别合适。这个 mod 直接放在了 github 上。游戏文本的版本更新，可以直接体现在 diff 里。路人发现有错别字也可以顺手提个 pr 。而我自己一般是在玩游戏时瞟见翻译的不合理的地方，立刻打开文本编辑器校对一下。也正因为如此，游戏里出现的 event 都特别仔细的阅读；群星的开发者真是脑洞大开啊，游戏里的 event 涵盖了几乎我所有阅读过的科幻小说，看过的科幻电 ...继续阅读 (73)

今天在 qq 群中，有个同学问，在 skynet 中，如果多个 actor 需要协作时，能否有事务来保证一系列操作的过程中，状态不会被破坏。他举了个例子：如果有一段业务逻辑是：local a = skynet.call(A, ...) local b = skynet.call(B, ...) if a and b then dosomething() end如何保证 a and b 这个条件有效呢？也就是说，在第一行从 A 处获取状态后，还要向 B 查询一个状态；如果希望两者查询完毕，一直到 dosomething() 结束前，A 和 B 的状态都不要改变。期间，如果有请求发到了 A 或者 B ，最后都暂时挂起。后来，又有同学补充了一个更实际一点的案例：如果我需要买点东西，先从银行查询余额，然后从商店获取一个物品，然后去银行扣掉钱，再把物品加到背包里。这个过程会涉及多个 actor ，整个过程又需要是一个事务，不要在执行这个事务过程中，有任何涉及的 actor 状态改变。固然，我们肯定可以从设计上找到一个更好的方法处理上面这类交易事件，而不需要涉及复杂的多个 actor 之间的交互。但这也是一个典型的案例说明本文一开始想表达的需求。如果一系列的操作只涉及一个 actor ，那么在这个 actor 中使用skynet.queue就可以避免在处理消息过程中的外部干扰了。但若涉及多 ...继续阅读 (80)

经历了 5 个 RC 版后，skynet 终于迎来了第一个正式发布版 1.0.0 。目前这个版本基于 2012 年 7 月开始编写的代码，几乎从一开始就以开源模式发展。我们可以看到 2012 年 8 月 1 日在 github 上的第一次提交，到上周一正式版前的最后一次修改，已经过去了 4 年。1403 次提交；59 个代码贡献者；3962 个 star ；1850 个 fork ；579 个邮件列表订阅者；1700 个 qq 群成员。我曾经在 2015 年 3 月发布第一个 1.0 alpha 版的时，计划在 2-3 月发布第一个正式版，没想到拖了整整一年。甚至在 2015 年底决定冻结新特性开发，进入 RC 流程后，还把计划从农历新年拖到了夏天。终于打上 1.0.0 的 tag 我还是挺开心的。希望正在使用 skynet 的项目，能够尽早同步到这个版本。如果旧版本已经用在生产环境的项目升级风险过大，也建议下一个新项目直接使用 1.0.0 版。只有围绕同一个稳定版做开发，才能发挥开源项目的最大威力：更多的眼睛关注下，让 bug 无处遁形。 ...继续阅读 (88)

今天见同事贴了张照片，是网易大楼前有人拉横幅声讨“一元购” 这个产品的。我之前没有听说过，上网搜了一下，发现最近搞这个的满多。大概就是说，每个玩家出一块钱买一个很贵的东西。然后系统把这些人凑在一起抽签，抽到谁谁就拿走那个东西。比如一部手机卖 5000 块，有 5000 个人想买，一个人出一块钱，最后也只有一个人拿到货，其他人都损失了一块钱。这不就是卖彩票么？当然凑不到 5000 个人也没关系，系统（庄家）可以买走大部分票，这并不影响个人参与者中奖概率。当然，前提是庄家没有作弊，抽签是公平的。那么庄家有没有办法作弊呢？我们来看看网易“一元夺宝”的规则：摘录如下：商品的最后一个号码分配完毕后，将公示截止该时间点本站全部商品的最后50个参与时间；将这50个时间的数值进行求和（得出数值A）（每个时间按时、分、秒、毫秒的顺序组合，如20:15:25.362则为201525362）；为保证公平公正公开，系统还会等待一小段时间，取最近下一期中国福利彩票“老时时彩”的揭晓结果（一个五位数值B）；（数值A+数值B）除以该商品总需人次得到的余数 + 原始数 10000001，得到最终幸运号码，拥有该幸运号码者，直接获得该商品。其实能保证公平的关键在 3 ，引入了一个第三方看起来比较公正的随机数。除此之外的所有参数都是可以庄家作假的。我想讨论一下，如果这个第三方随机数是公正的前提下，一元购的庄家还有没有 ...继续阅读 (107)

在上一篇 blog 里，我谈到游戏服务器其实只需要使用 req/resp 模式就够了。有同学表示不太理解，认为服务器主动推送，或者说 pub/sub 的消息模式必不可少。在聊天中我解释了很多，是时候记录一下了。从本质上来说，如果你只是想把一系列消息发送到客户端，req/resp 请求回应模式和 pub/sub 发布订阅模式并没有什么不同。你可以把 req/resp 理解成一次性的，只订阅一条（或有限条）消息；如果需要维持这类消息的推送，需要客户端在收到消息后再次发起订阅。这和 timer 定时器系统一样，订阅一个定期触发的定时器这种功能并非必要。如果你需要一个每分钟触发一次的定时器，完全可以在触发一次定时操作后，立刻发起下一次定时任务请求。它在功能上是等价的。潜在的实时性影响是：如果规定必须在收到回应消息后，才允许发起下一次请求；那么一个事件发生后推送到客户端的延迟可能增加了最多 2 倍。即，如果你刚刚回应了一条消息，这个时候又发生了新的事件；客户端需要在收到前一个事件后再提起新请求，然后你才可以把后发生的事件通过新请求的回应包发过去。降低这个实时性影响的方法也很简单，协议上允许在客户端发起请求后未收到回应之前再次发起请求即可。对应同类消息许多少并发的请求，要根据这类消息的实时性要求有多高来决定。无限提高允许的并发量没有太大意义，毕竟物理上的延迟不可能完全消除。从客户端来看，MMO ...继续阅读 (57)

之前已经介绍过，skynet 只是一个轻量框架，不是一个开箱即用的引擎。能不能用好它，取决于使用者是否清楚知道自己要干什么，如果是用 skynet 做网络游戏服务器，那么就必须先知道网络游戏服务器应该如何设计。在 skynet 发布版中带的 example 中，有类似 gate watchdog agent 之类的服务，它们并不是唯一的用 skynet 构建游戏服务器的模式。我想另外写一个范例，示范依旧基于 skynet 但用不同的模式构建游戏服务器的方法。我花了两天时间写了这么一个 sample ，放在 github 上。在这个范例中，我主要想展示这样一些东西：GateServer并不是唯一的管理连接的模式。在 skynet 中，也可以自定义其它的方式来管理大量外部连接。这个例子中使用了前段时间我实现的另一个模块，这个模块并没有放在 skynet 发布版中。在这个范例中，实现了一个 hub 服务，类似 gate 的作用。但是它仅仅监听端口，并把新建连接交给合适的服务处理。按范例中的流程，每个新连接都直接转交 auth 服务；只有 auth 服务认可了连接，再转给 manager 服务。这里 auth 和 manager 都是单一服务。如果实际使用的时候有性能问题，auth 服务可以扩展为多个，做负载均衡。如果有必要，还可以加一个排队服务的环节。manager 拿到连接的身份后，会 ...继续阅读 (61)

在 Lua 5.2 之后的版本，约定了在元表中可以给出一个__pairs方法，而 lua 的基础库 pairs 会使用这个元方法来迭代一个对象。Lua 5.3 之后的版本，取消了 lua 5.2 中的__ipairs约定，而统一使用lua_geti来访问整数为索引的数组。可惜的是，许多 lua 序列化库对此支持的并不好。今天我在改进 bson 的序列化库时，重新考虑了这个问题，看看这个序列化过程怎么做，才能更好的支持 lua 5.3 以后的约定。在 skynet 中重新实现的 bson 库是这样做的：和 json 不同，bson 在规范中严格区分了数组和字典。那么，序列化时，应首先判断一个 table 是否有__len元方法，如果有，则表示它是一个数组。因为我们不支持把一个需要传入 bson 序列化的 table 同时当成数组和字典使用，如果实现了__len元方法，那么显然是希望把它看作一个数组。然后，判断这个 table 是否有__pairs元方法。如果有，这表示它是一个字典，需要用这个元方法迭代它。如果两个元方法都没有，那么这个 table 是个原生表，需要用额外的方法探测它到底是一个数组还是一个字典。这里采用的方法是，使用lua_rawlen获取一下数组部分的长度。然后调用lua_next传入最后一个数字索引，探测是否有其它的 key 。这种方法在 lua 的文档中并没有严格 ...继续阅读 (69)

随着 lua 5.3.3 的正式发布，我不想再拖了，希望下周就完全冻结 skynet 1.0 的 rc 版本，正式发布。鉴于 skynet 一直都没有专门的上手指南，过去写的skynet 设计综述太老，之后 skynet 又有了很大的变化，所以我想是时候补一篇面向刚接触 skynet 的同学的文章了。我在 wiki 上补充了一篇GettingStarted，欢迎大家多提意见。特别是没有接触过 skynet 又有兴趣的同学，可以看看这篇文章是否讲清楚了 skynet 到底是什么 :) ...继续阅读 (76)

在 skynet 中，有时候为一个服务实现一个前置的代理服务是很有必要的。比如，你希望对这个服务发起的请求是支持超时的，就不必在功能实现的服务中实现，那样会增加无谓的复杂性。你可以在功能实现的服务前加一个代理服务，当超时发生时，通知请求方。关于这个实现，我在 blog 中给过一个示例。同理，当你需要做一些负载均衡的处理的时候，也可以做一个代理服务，让请求分摊到多个可以完成类似功能的服务中去，实现比较简单，本文就不展开了。今天想谈一下怎么利用代理服务更好的为一些热点服务提供过载保护。过载保护在两年前我就写过，这两年的运营产品经验表明，对于缺乏经验的 skynet 使用者，它是最容易碰到的问题。这可能也是并发环境的最需要解决的问题。我想过在未来的版本中，做一些更底层的保护措施。不过目前的 skynet 1.0 版，我们依旧可以在上层做一些工作。假设我们已经知道了某个服务容易成为热点，那么前置一个代理服务就可以做很多事情。所谓代理服务，就是向真正的功能服务发起请求时，请求消息发到另一个代理服务中，由这个代理服务转发这个请求给真正的功能服务；同样，回应消息也会被代理服务转发回去。代理服务在过滤这些消息时，可以做一些工作，例如：如果某个服务的请求过于频繁，则可以暂时搁置这些请求，而优先转发其它服务的请求。这样便增加了公平性。而如果请求来源的服务已经退出，在代理服务中若还存在他所未发出的请求， ...继续阅读 (62)

昨天我们新的 MMO 游戏第一次上线小规模测试，暴露了一些问题。服务器在开服 3 小时后，突然内存暴涨，CPU 占用率提升不多。当时 SA 已经收到报警邮件，但刚巧在午餐时间，而游戏功能还正常，耽误了半个小时。处理不够及时，导致在最终没有能收集到足够在线数据前，服务器已不能正常操作。另外，忘记配置 core dump 文件输出是另一个原因。在最后几分钟，我们收集到一些信息：某个 lua 服务陷入 C 代码中的死循环，在 skynet 控制台发 signal 无法中断它（skynet 的 signal 可以中断 lua vm 的运行）。从 log 分析，内存暴涨是突发的，几乎在一瞬间吃光了所有内存，而并非累积。第一次宕机后，迅速重启了服务器。同时在内网又同步运行了机器人压力测试，但是无论是外网环境和内网环境均无法重现故障。从这次事件中，我发现了 skynet 收集运行时事故关键信息的不足，赶紧补充了几个工具脚本。比如，skynet 控制台的观测每个服务状态和内存使用情况的控制指令，是通过循环向每个服务发送请求，由各个服务分别汇报然后汇总输出的。一旦某个服务死循环，就会阻塞这个过程，导致没有汇总报告输出。解决这个问题倒是不复杂，只需要分别收集信息，设置超时时间，然后就可以得到部分报告，并感知到超时服务。现在，则需要从 log 中查询死循环报告。没有事先准备好这个脚本，导致突发事件中没 ...继续阅读 (90)

这两天在一个游戏设计论坛潜水，读了很多帖子，感觉挺有收获的。尤其是有一贴，楼主贴了一长篇他的 idea ，应当是想了很久的，算是比较完整，只差动手了。按他的说法，想先在论坛上收集一些反馈。这个论坛聚集了许多核心玩家，和相当数量的游戏开发者，按道理说，他找对地方了。可是，在下面的回帖中，某人对此作了严厉的批评。回帖说，你不给出个可玩的程序，根本没可能给反馈，尤其是帖了这么一大版文字，更不可能。创意往往很有趣，每个创意说出来都能吸引人心。但就算你先写下几百篇文档，把玩法描述的一清二楚，不通过试玩，还是不可能知道它是否行的通、是不是真的有意思。在桌面游戏设计圈里，有条基本设计准则就是，不去试玩而去写游戏机制就是在浪费时间。从一开始就应该试玩，设计过程中要不停的试玩。所以，在论坛上可以根据非常具体的问题收集意见，但一大版文字描述整个游戏的创意却没有意义。在创意阶段收集到的意见也不会有真正的价值。每个人都是根据文字做出自己的想象，这和把东西实现出来后的结构截然不同。我最近两年脑子里冒出了无数想法，没有一次真的完整实现出来，非常惭愧。最近在学 html5 + javascript ，想做点原型。采用 html5 开发是方便传播，可以快速给身边的同学试玩。如果你对我说的论坛有兴趣，[这里是我提到的帖子。btw, 其实这个同学的 idea 我还是很喜欢的。另外，javascript 真是门恶心的语 ...继续阅读 (69)

不知道这个 blog 的读者中还有多少记得我们承诺要出的单机游戏《暴击英雄》。他终于上架了。点上图可以去 steam 商店看看，目前首发 7.9 折，30 人民币，如果你读完商店页面下面的好评和差评后，觉得你或许会喜欢这个游戏，那么欢迎你支持我们一下。按原来的计划，这款游戏应该是在 2015 年底完成的，作为试水产品在 steam 上发售。结果，不出意料的跳票了。开发期整整延长了半年，原因自然是对游戏一直不满意。至于现在的版本，依旧不满意，所以目前还是 Early Access 阶段，接下来两个月会想办法修改已知的问题，希望可以做得好一点点。至于为什么没有在完全满意后再发布，是因为如果一直这么做下去而不获得真正玩家的反馈，就改成无底洞了。很多内部意见争议也很大，不被玩家骂几句，大家是没那么大动力改的。其实我个人最近半年在忙其他的事情，完全没有管这个项目。这次上架，第一时间自掏腰包买了一个支持。反正也不贵。周末大约玩了四个小时，想法很多，记录一下。说起来，大家都想做并不是 pay to win 而注重 gameplay 的游戏，但真做起来经验不足。许多地方都是心有余。据我所知，这个项目从有创意开始，开发团队就没想过把游戏做成一个无脑刷刷刷的游戏。他们设计的核心玩点是为若干角色设计特别的攻击轨迹和攻击范围，然后把 4 个角色组合起来（最早的设计是 5 个，变化更多一些），通过玩家反复观 ...继续阅读 (77)

最近有数据显示，我们的游戏《流星庄园》有玩家利用规则漏洞，通过排行榜奖励刷钻石。我问了一下设计人员一些细节，感觉现在的规则设计是很有问题的。下面记录一下我的想法，和一些改进建议。排行榜奖励问题不只在我们这样特定的游戏中有，现在几乎所有的 pay2win 游戏都会涉及到。我们最初的规则是，每周为排名前列的公会按名次发放一定的钻石奖励，鼓励大公会竞争，促进消费。后来，有玩家反应，如果公会无法排在前列，就没有动力竞争了。所以又加了补充规则，如果公会排名又提升，也有相应的奖励。这个设计是有悖于鼓励玩家冲上更高名次的。如果将玩家看成一个整体，玩家若想获得更高收益，最恰当的做法是不断的变换名次，降低或升高都可以，最差就是保持原来的名次。作为设计理想，玩家不会成为一个整体，他们之间有竞争。更高的名次有更高的奖励，所以不会轻易降分。但事实上，由于玩家可以充分的沟通相互信任，不会陷入囚徒困境。竞争多花的钱而获得的高名次奖励，远远比不上交替名次而获得的系统额外发放。另外，在原来的低名次段，原本没有名次奖励的位置，也可以通过操纵排名而获益。我的规则改进思路是这样的：对排行前若干名的奖励做成一个奖金池。奖金池的大小就是原有对排行奖励的钻石的总量。对低分数段的排名也固定发放一小笔，计算入奖金池内。计算奖励的时候，首先按常规的排行计算奖金。即名次越高，奖金越高，低排名区也会有很少的配额。总发放奖金额等于奖金池 ...继续阅读 (56)

今天花了一天尝试给 lua vm 做了一点优化：现在 lua 的函数原型里保留有一张常量表，引用了 string ，number ，nil ，boolean 类型的常量。table 是不能为常量的，所以当你想迭代一个常量数组的时候，for _, v in ipairs { "one", "two", "three" } do其实每次都会临时构建一张表，并依次插入 "one", "two", "three" 。或者你想返回一个常量构成的表：function foo() return { x=1, y=2 } end每次 foo 函数都会为返回值重新构建 table 。其实，我们可以认为所有键值都是常量的 table ，都有可能是一个常量表。那么，在 parser 阶段，和 string 等类型一样，预先建立好 table 对象，保留在 prototype 的常量表中，可以极大的提高运行性能。那么在上面这种return {x=1, y=2}的写法中，实际返回的可以仅仅是一个 table proxy ，里面只有一个指向常量表的指针即可。如果事后我们真的需要改写这个 table ，再 clone 一份常量表，把这个 table proxy 对象还原成真正的 table 对象即可。也就是所谓的 COW 技术。由于常量表一定是一个单层简单表结构，可以直接 memcpy 复制，比一项项添加 ...继续阅读 (62)