以下从我最近两个月发的推文中整理。可可晚上可可读着书在床上睡着了。我没叫醒她，给她盖了被子就睡了。早上醒来时她跟我说，完蛋了，昨天晚上我没有洗澡。我说没关系，别被妈妈发现就好了。然后她蹑手蹑脚的偷偷起来换了身衣服，然后又躺回来睡觉。可可的同学喊她联机 minecraft ，我在隔壁看书，听她们在微信上聊了半天硬是鸡对鸭讲。我过去跟她说，你把电脑屏幕拍个照片给她看不就好了。结果对面喊了句：你怎么玩国际版啊，我玩的是网易中国版，然后安慰可可说，你自己玩也是可以的。我想：到底谁是正版受害者？可可最近在读的一本小说突然就找不到了，她怎么都想不起来在哪里。我花了许多时间引导她回忆，终于想起是周三的课外班落在隔壁班的教室里了。如果缺乏引导，她的记忆是绝对不可能打开的。周五家长会，我特地提前了 5 分钟到学校，和隔壁班主任解释了一番，在教室仔细搜寻了一番，果然找到了。可可很开心。可可最近读书挺认真的，问了好多问题。前几天问了好几个成语的意思，又比问了什么时候用——（破折号），还讨论了为什么小说里要写那么多她觉得并不精彩的情节。可可二年级，我最近发现她数学是真的不行 :( 今天检查作业错了一道题，引导了半天才发现她对 100 以上的数字概念都没建立起来。比如知道 10 个 100 是 1000 ，但她觉得 20 个 100 是一万，而且讲了一个小时才纠正过来。果然，人类天生的感知就是对数的么？本福 ...继续阅读 (6)

今天在网上和人闲扯，说到电梯的交互设计或许是有问题的。一般在楼宇的电梯区，会设置上下两个按钮，让乘客表达自己是要上行还是下行。如果在电梯区显示电梯当前所在楼层的话，就会有人理解为：上是指让电梯轿厢向上运行，下是指让其向下。一旦这样理解，就会输入错误的指令。几乎每个有过在高层办公室上班经历的程序员都参与过电梯调度算法的讨论。看来，在饭点挤电梯是程序员们的共同记忆。（另一个永恒话题是怎样提高厕所的使用效率）我也不例外，20 多年里，我曾经反反复复和人讨论过这个问题。现在再也不用挤电梯了，似乎可以把过去考虑过的方案记录一下。先说说现实存在过的方案：大多数方案都是为了提高电梯的运营效率。要么为了节能，要么为了更快的满足乘客需求，要么为了提高高峰时的吞吐量。大部分高层建筑都把多部电梯按楼层分区。有些电梯只服务低层，有些服务高层。如果楼层更多时可能还会分出更多区间。对于超高层建筑，也有把顶楼超高区单独分割出来，需要转电梯的。这个设计显然是因为对于高层建筑，电梯的需求按楼层分布是金字塔型的。乘客永远都需要从地面进入，越往上，乘客越少，而路程越长。乘客的目的地却是接近均匀分布的，如果让乘客随机进入任意轿厢，最终电梯会在更多楼层停留开门，将乘客预先分组就显得很有必要。另外，为了解决繁忙时段的吞吐量问题，电梯也可能按单双层分组。这样可以把一部分运力转嫁到楼梯上，减少每部电梯的停留时间。类似的方案还有针 ...继续阅读 (15)

我需要一个接口简单的寻路模块，所以今天写了一个。其实之前也写过很多版本，在我上传代码时就发现我自己的 github 账号下早有同名仓库。不过，之前的版本的接口设计不太满意，直接删掉了，用这次的新版本复用老的仓库名字。我希望达到的目标是，C 接口简单易用，且和地图本身的数据结构无关，只提供寻路功能。这样容易拓展到不同应用场景。数据结构简单，内存开销固定，在算法执行过程中不额外分配内存。这可以方便的在多线程环境运行。我不需要处理特别复杂和规模巨大的地图，那种场景应该额外做一些预处理。但在起点和终点的路线结果不长时（即使在大规模地图上），应该有较好的性能。原始的 A star 算法实现最为简单，在大多数情况下有不错的表现，所以我选择了它。我知道算法可以有很多改进方法，但我觉得代码简单最为重要。通常 A star 算法依赖一个优先队列，但我没有选择使用诸如平衡二叉树等复杂结构来实现它，而使用了最简单的单向链表。因为这样可以轻松的把全部数据全部塞在一块平坦内存中。基础数据结构是一个用数组实现的闭散列 hash 表，使用者来决定使用多大的数组，通常使用预期路径长度的平方大小会比较合适。为了减少每次寻路的初始化成本，使用了一个 version 值表示每个 slot 的初始状态，每次调用寻路，都会把 version 递增（ O(1) 操作），这样就可以让整个 hash 表的所有 slot 复位。寻 ...继续阅读 (19)

纯单人游戏在桌面游戏中不太多见，但我很喜欢这种。毕竟，找人一起玩桌游太不容易，虽然多人协作桌游总可以一个人操控多方进行 solo ，但终究不是为单人游戏设计的。今天介绍的两款单人卡牌游戏，我没买到实体版，都只是在桌游模拟器上玩过几盘。第一款是 Legacy of Yu (2023) 大禹治水。老实说，这不是一款卡牌“构筑”游戏。虽然在游戏过程中玩家还是需要从市场列“购买”新卡片，但游戏过程并不是围绕构筑进行的。这些卡牌更像是消耗品。游戏中的工人卡有三种用法：打出后获得卡片上标注的资源，然后进入弃牌堆。销毁一张工人卡，获得卡片上额外标注的一次性资源，卡片将移出游戏。这样获得的资源一定比前一种方法获得的多。把卡牌（常驻）押在版图中已经盖好的房子上，此后的回合每回合获得持续资源奖励。和一般的卡牌构筑游戏不同，卡堆不是越少越好。一般的卡牌构筑游戏，精简卡堆总是好的，因为这样可以加快卡堆循环，能更快抽到自己需要的强力卡。而这个游戏中，当抽牌堆耗尽，游戏进程就会向前推进。一旦准备不足，推进游戏会加快失败进程。虽然，游戏过程中，除非迫不得已，都不要销毁工人卡获得额外资源。游戏中有砖头、木头、粮食、货币（贝壳）四种资源，以及白色劳工、红色战士、黄色弓箭手、黑色骑士、蓝色枪兵五种工人。资源可以用来做建设：砖头+木头+劳工=农场（三个待建），砖头+3x木头+劳工=前哨（四个待建），3x砖头+木头+劳工 ...继续阅读 (25)

最近读了一本书：《数学的雨伞下》。阅读体验非常好，这本书用浅显的语言，科普了许多深刻的道理。这本书所介绍的知识结构比较类似我挺喜欢的另一本《从一到无穷大》，但讲解更为细致一些，以至于如果事先明白这些知识，甚至会觉得有些冗长。但细细品味，会觉得理解能更深一层。我在通读完一遍之后，这几天带着儿子精读。重读第一章中“对数之桥”一节时，我思考了一个问题：当年纳皮尔 Napier 到底出于什么动机制作一张高精度对数表，他制表的计算思路是怎样的。书中并没有答案，所以我又在互联网上翻看了当年 Napier 原著Mirifici Logarithmorum Canonis Descriptio的介绍，感觉收获颇丰。制作对数表的直接原因当然是为了简化大数乘除法的计算。对数概念的提出在幂概念建立之前，而现在的数学教学中，一般却是从幂自然推导到对数的。似乎后者才是自然而然的。这应该是因为，古人研究数学，最初是为了解决现实中的问题。所以，乘法必须有对应的几何意义。比如，计算正方形面积需要把计算边长的平方；立方体的体积需要计算边长的立方。更高次的幂却难有对应的几何意义，有理数幂则更为抽象。现实中，也很难碰到极大的数字，超乎寻常的精度需求也很小，除了天文学。人无法以上帝视角在宇宙空间中做测量，只能以地球为基点。所以，天文尺度的计算都依赖三角学。把天文（以及地理这种地球尺度的）数字问题化为三角函数，然后再加以计 ...继续阅读 (24)

这次介绍两款在国内人气不高的卡牌构筑类桌游。游戏都还不错，可能是因为没有中文版，所以身边没见什么朋友玩。首先是 XenoShyft 。它的最初版全名为 XenoShyft: Onslaught (2015) ，后来又出了一个可以独立玩的扩展 XenoShyft: Dreadmire (2017) 。故事背景有点像星河舰队：由人类军士抵抗虫子大军。简单说，这是一个塔防游戏：游戏分为三个波次，每个波次三轮，一共要面对九轮虫群的冲锋。游戏中有四类卡片：部队、敌人、物品、矿物，另有一组表示玩家所属部门的能力卡，每局游戏每个玩家可以分到一张，按卡片上所述获得能力矿物就是游戏中的货币，用来在市场购买部队卡和物品卡。敌人卡分为三组，对应到三次波次，洗乱后形成系统堆。玩家需要在每轮击败一定数量的敌人，撑过三个波次就可以取得游戏胜利。玩家基础起始牌组 10 张，4 张最低级的士兵和 6 张一费的矿物。根据玩家的部门，还会得到最多 2 张部门所属的特殊卡。市场由部队卡和物品卡构成，其中部队卡是固定的，分三个波次逐步开放购买。物品卡一共 24 种（基础版），但同时只会有 9 种出现在市场上。玩家部门可能强制某种物品一定出现在市场上，其它位置则是每局游戏随机的。在游戏过程中，当一种物品全部买空后，会在市场中随机补充一堆新的物品卡。普通敌人卡按波次分为三组洗乱，然后根据波次再从 6 张 boss 随机分配到 ...继续阅读 (18)

最近的兴趣重心转移，没怎么研究桌游。不过前几个月的笔记还有一点，今天继续整理一下。继续谈谈 PvE 向的卡牌构筑类桌游。Aeon's End (2016) 末日决战是一款偏传统卡牌对战规则的游戏：一开始手牌中只有水晶 (gem) 和基础法术 (spell) 卡。游戏过程中，在一个固定市场（9 种）用水晶购买更强力的卡片升级自己的卡组。游戏的目标是合作（或 solo）击败 boss 或 boss 的仆从。如果被敌人攻击太多次，自己的 HP 减到 0 就失败了。法术卡其实更像是炉石/万智牌中的玩家仆从，只不过是一次性消耗品。需要先部署在桌面，然后才可以攻击。而玩家卡组内的第三种遗物卡（relic）则更像是一般意义的法术：可以即时产生效果。打出法术卡或遗物卡是没有直接费用的，水晶主要用来支付从市场购买新卡的费用。另外，法术卡要生效，需要桌面有空闲的位置（叫做 breach 裂隙）。所以即使手牌中的很多强力法术卡，也不能无限制的一次摆出来。裂隙需要花费水晶费用打开才能使用（摆放法术）。打开 (open) 裂隙在一局游戏中是一次性的，一旦裂隙开启，就可以一直使用（放置法术）。但开启费用较高，也可以 focus 一个关着的裂隙一次性使用。focus 费用较低，但下次使用还需要再次支付水晶 focus 。focus 同一个裂隙 4 次后会自动开启。在开启的裂隙上摆放的法术，玩家可以选择再后续的任 ...继续阅读 (17)

我在 Windows 10 下倾向于通过 store 安装 app ，而不是使用独立的软件安装包。这样安装的 app 会比较安全。但正因为这些额外的安全措施，有些过去很容易做的事情却变得麻烦了。比如，把一个特定类型的文件关联到 app 上。我习惯用 IrfanView64 查看图片。在游戏开发中常见的 .dds 文件它也可以打开（需要额外安装官方插件）。但 IrfanView64 在提交 store 发布时没有提交 .dds 这个后缀名，这导致 windows 10 无法选择用它打开 .dds 文件。在自选打开特定文件类型文件的设置菜单里（设置-默认应用），你会发现怎么都找不到这个应用。通常，你很难找到 store app 的执行文件路径。它在%ProgramFiles%\WindowsApps目录下，这是一个特殊的目录，受 Windows 系统保护。但可以在启动应用后，开启任务管理器，找到对应进程打开文件所在位置找到它。我通过 google 找到了一篇吐槽文，也是谈这个问题。这篇 blog 也是通过这个方法找到了 store app 执行文件的位置。有了这个地址似乎就可以在打开文件的设置菜单设置本地程序路径了。但估计是最近的 windows 更新又进一步增强了安全机制，即使你这样设置打开 .dds 为 Irfanview64 app 本地安装的程序路径，双击 .dds 文件既然 ...继续阅读 (21)

考虑到我想做的独立游戏并不需要以画面效果吸引人，游戏是策略向的，所以 2D 表现就足够了。之前几年做的 3d 引擎对这个需求来说太复杂了，而且这次我也不打算主打移动平台，之前为移动平台做的考虑也没太大意义。所以，最近想花个把月重新搭一个 2d 游戏用的框架。当然，最重要的是：我太久没写代码了，而做这个非常有趣。前天在 github 上开了一个新坑，具体想法写在项目的讨论区了。虽说 2d 游戏在如今的硬件上，性能那是相当富裕。但在具体写代码时，还是忍不住想想怎么设计，性能会比较好。不然总是重复大家都有的东西也是无趣。在现代 GPU 上实现一个最简单的 2d 管线，就是把它当成 3d 网格，一堆顶点数据填进去，绑定贴图，提交渲染即可。所谓 2d 图片，就是两个三角形，看成是 3d 世界里的一个面片即可。所以，每个顶点的数据就是 vec2 pos ，要画一个矩形需要四个顶点，用 vertex buffer 传进去。但是和 3d 游戏不同，2d 图片形状大多不规整，不是边长为 2 的幂的正方形，尺寸也不大。如果每张小图片（2d 游戏中通常称为 sprite）都构造一张贴图的话，会非常低效。通常我们会把很多 sprite 打包在同一张大的正方形的贴图上。这样，顶点数据中还需要定义绘制矩形对应在贴图上的区域，通常称之为 uv 坐标。至此，常规的实现方法中，每个顶点就是 4 个数据量：vec2 ...继续阅读 (23)

这篇谈谈 PvE （玩家对抗环境）向的卡牌构筑类游戏。在桌游中，PvP 向（玩家对抗玩家）的游戏数量明显超过 PvE。我认为这是因为桌游需要靠玩家自己驱动游戏规则，扮演环境的同样是玩家，其规则不能设计的太复杂，通常只能靠简单机械的逻辑驱动。或者，起源于桌游的 RPG ，比如 D&D; ，则由一个玩家扮演环境（城主），这样就可以增加游戏的深度。但毕竟这种不对称规则下，玩家方和环境方很难调配平衡。RPG 这样的游戏，城主也并非玩家的对立方，大家只是在一起享受游戏过程。而在电脑上，则可以通过程序实现更复杂的环境。所以在电脑游戏中，大量的游戏转向 PvE 。毕竟，找到可以一起玩的游戏搭档并不容易。所以，对于卡牌构筑这个具体类别，电脑上的游戏几乎一开始就是 PvE 性质的：比如杀戮尖塔，玩家一直在挑战系统而获得乐趣；而桌游中，从领土（Dominion）开始，就是基于玩家对抗设计的规则。传奇 Legendary 系列是一个比较早的 PvE 向卡牌构筑类桌游系列。最早可以追述到 Legendary: A Marvel Deck Building Game (2012) ，后续几年发布了大量系列作品，并衍生出 Legendary Encounters 系列。关注 Legendary 系列是因为星际孤儿（Stellar Orphans）这个电脑游戏，我特别喜欢。在星际孤儿的玩家社区，有玩家指出这个游 ...继续阅读 (19)

这一篇，我想先谈一个在中文社区比较小众（没有出中文版），但我个人非常喜欢的卡牌构筑游戏：核心世界 Core Worlds (2011) 。相对 Dominion 来说，它的规则和体验已经非常不同了。它的单位牌需要先部署到桌面（战区），而后在从桌面打出，用于征服星球（用于增强能力）。这可以促使玩家做更多跨回合的规划。而不是仅考虑当前回合的手牌怎样打出漂亮的 Combo 。每个回合，玩家可以在回合结束时保留一张手牌（同时也会减少抽牌数量），这点也是为了促进玩家更多的考虑回合间的联系。游戏采用固定轮数，一共 10 轮 5 个阶段。每个阶段的市场牌堆都是独立的。所以，玩家会在每两轮看到不同的牌进入市场，这样会减少卡组构建的随机性，让强牌逐步出现。游戏节奏被设计的更好。 每个轮次翻到市场的卡很少，只玩一两盘恐怕大多数卡片都不会见到，这加强了重玩性。每局游戏都有不同的变化。虽然游戏有 10 轮，但游戏节奏其实是很快的。尤其是到了终局的第五阶段，节奏被刻意加快了：前 8 轮积累的大量能量，而手牌也增加了。没有新的单位卡，而换成了得分用的声望卡以及核心世界卡需要竞争。终局两轮实际是考验的是玩家前面的组卡和布局成果。而在前面的回合，玩家每轮可以做的事情并不算太多。市场上的卡片分为星球卡和单位/行动卡。星球卡需要玩家用之前部署的部队去征服，被征服的星球卡直接放到玩家桌面提供永久能力（通常会增加能量点） ...继续阅读 (17)

上篇提到的 Dominion 和 Ascension 都没有使用传统 TCG 中打出卡片的费用设定。TCG 游戏中给卡片设定不同的费用很好理解：在游戏前自由组卡的游戏，如果不给卡片设定打出限制，玩家只需要尽可能的选择强力卡片放在卡组里，游戏过程中先抽到的人就会占据优势，这就变成了一种运气游戏。卡牌构筑游戏更多的是用购买卡牌的费用来做限制，让强力牌是逐步加入战场的。玩家不能一开始就购入强力卡片，即使到可以购买的中期，卡片也会先进入弃牌堆，相当于等待一段 CD 时间才能抽回手上。但只有这还不够，必须考虑游戏中后期的平衡：在牌组构筑成型后，一套强力组合若能轻易打出，也会让游戏一边倒。所以，还是需要对打出功能卡做出一些限制。Dominion 的做法很简单，默认每个回合，玩家只能打出一张行动卡。如果需要打出多张行动卡，就需要配合加行动次数的行动卡。而且加一行动的卡片只能让自己加入当回合的行动链中，只有加二以上行动的卡片才能拓展行动选择。同时，购买牌的次数也被限制了，必须通过行动卡扩展。Ascension 不一样，它即不限制每个回合打牌的数量，也不限制购买数量。所以几乎每个回合，玩家都会打出手上的所有牌，变化只在于打牌的次序。那么，平衡是怎样实现的呢？这个游戏我玩的不多，只能谈一下粗浅的理解。Ascension 提供了两种得分手段：用符文购买牌时，除了新牌加入牌组增强实力外，还额外附带了 VP ...继续阅读 (24)

现在有非常多的桌面游戏加入了卡牌（卡池）构筑的游戏机制，用来丰富游戏玩法。我想总结一下以卡牌构筑为核心玩法的若干经典桌面游戏的核心规则。要记录的游戏太多，所以我会分成多篇 Blog 来写一个系列。这是第一篇，从历史最为悠久的经典游戏写起。主要谈以卡牌构筑为核心，而没有混杂太多其它机制的游戏，列出其具体的核心规则方便日后参考。首先是开山鼻祖 Dominion (2008) ，官方译名皇舆争霸，在出中文版之前我常称之为领土。它奠定了此类桌游的基础模式：从一组功能简单的手牌开始，在游戏中不断购买新卡加入自己的卡组，在后续回合中这些更为强力的卡牌可以完成更多行动或积分，玩家尝试比对手获得更多 VP 取得胜利。Dominion 起始牌组 10 张，7 张价值 1 的钱币和 3 张 1 VP 积分卡。玩家以 5 张手牌开始，在回合结束弃掉所有未用手牌重新摸 5 张手牌。VP 卡只用于终局计分，在游戏过程中没有用处。钱币卡可以用来购买公共市场中的 10 种每局游戏不同的功能卡以及每局游戏必有的价值分别为 1 2 3 的钱币卡，价值为 1 3 6 VP 的计分卡。每回合未用完钱币同样不累积到下一回合。新购买的卡片置入弃牌堆，不能立刻使用。玩家在回合中默认可以打出一张功能卡并购买一张新卡。单功能卡的效果可能扩展这个能力，允许玩家在一各回合中打出多张功能卡，或购买更多新卡片。回合中打出的卡片不会立刻进 ...继续阅读 (25)

这个月玩了许多游戏，有电子游戏也有桌游。主要是想更好的理解卡牌构筑类游戏的设计点，回答我自己在设计过程中的一些疑问。今天写一篇关于卡牌构筑类游戏的总结。卡牌构筑类的电子游戏引爆于 2017 年的 Slay the Spire 杀戮尖塔，启发了数以千计的类似游戏诞生。追其源头，是从更早的桌游开始。所以，我对这个类型的桌游做了一些研究。对于有兴趣的同学，我推荐 Youtube 上的How to design a DECK BUILDING board game，它做了非常不错的总结。我也是在看完这个视频后了解到一些过去没玩过的桌游。桌游中的卡牌构筑机制，始于 2007 年的星际争霸。这是当年我最喜欢的桌游之一，曾经几个周末都和朋友玩它。它的缺点是需要特别大的桌面空间，还有几个肯花一下午事件玩上一盘游戏的朋友聚在一起。如今，大场地易得，玩友却几乎无法筹齐了。当时在玩的时候，尚未意识到其中的战斗卡牌玩法开创了一个新机制，只是觉得有趣：在游戏中，随着科技升级，可以从卡池中购买一些新的高级的战斗卡放到自己的牌库中，增加或增强自己战斗获胜的几率。这似乎是一个比扔骰子更好的随机方案，在此之前，同样需要花一整天玩的桌游 Axis & Allies ，就需要反复在骰子塔中哗啦啦的扔骰子。真正第一个围绕这个游戏机制设计的桌游是 2008 年的 Dominion 领土。在领土之前，也有诸多用不同卡牌构筑成 ...继续阅读 (28)

这个月我一直在做具体的游戏设计。因为以前从来没有真正独立设计过游戏，比我预想的难很多。上次提到，我想做一个基于卡牌构筑（ deck building ）玩法的 Roguelike 游戏，但并非杀戮尖塔这样的卡牌战斗 （card battler ）游戏，而更接近缺氧这种生存建造为主的玩法。游戏的题材还是之前的构想：维护一艘太空飞船在银河中探索。经过一长段时间的思考，在本子上涂写了半本手稿后，我感觉在这个游戏的设计上又推进了一点，现在有了一些更具体的玩法设计。今天总结记录一下：这是一份核心玩法的草稿：这是一份核心玩法的草稿：在有限回合内，通过组合手牌中的配方卡和物资卡，进行物资转换，最终获取需要的推进点通关。同时需要生成食物点维持游戏不败（生存元素），并获取科技点升级卡组（卡牌构筑）。游戏里有如下概念使用数字而不是卡片表示：食物：每天扣除，一旦归零，游戏失败。热量：控制一天（一个大回合）能执行的行动次序。超过这个次数会导致飞船过热，强制结束一天。能量：控制一天能执行的弃牌次序。推进：一个关卡需要的进度指数。科技：用来完善卡组，获得更高的效能。游戏进程以关卡形式进行。每个关卡分为大轮（天），每天分为若干小轮。游戏过程比较接近小丑牌，大轮相当于小丑牌中的一小局，小轮相当于小丑牌中的一次出牌或弃牌行动。在每个关卡开始时，系统会产生一些事件卡放入环境。事件卡时一种特殊的配方卡（后面会介绍），在 ...继续阅读 (30)

十月底的周末带娃去岩馆抱石时就觉得不太对。左脚的大拇指根部隐隐作痛，爬了几条线就歇着了。第二天自己去爬高墙，好像更严重了点，干脆回家休息。这几年体检查出来尿酸过高（500+）。医嘱是注意饮食，已经没再喝酒，也不吃海鲜和动物内脏这些高嘌呤食物了，虽然我挺喜欢吃的。这次不算是第一次疼，去年疼过一天就好了。但这次比较严重。感觉和那几天有朋友从江苏快递了几只大闸蟹有点关系。接下来几天左脚明显肿了，几乎无法走路。脚很疼，不过尚在可以忍受的范围内，比不了那次尿道结石的痛苦。我乐得在家打游戏，反正出门是不用想了。果然和网上说的一样，大约 3 天就消肿，5 天左右就不是很疼了。走路时还能感觉到没完全好，但不影响出门散步。中间去岩馆了两次，爬些不太难的线路问题不大，但如果动作过于依赖左脚时，一发力还是有点疼。上周末赵青约我去英西野攀，我估计问题不大。这周二出发。英西今年三月出了一起安全事故，一个商业团体阻止小孩攀岩时，落石砸死了下面的一个小孩。在餐馆吃饭时听老板八卦，事后带团的、学校、以及当地政府等几方一起一共赔偿了三百万，然后政府便禁止了野攀活动。最著名的大庙岩场被封了起来，运动攀线路上的挂片也拆掉。这事过了快一年，据说现在政策有所松动，明年或许能恢复。现在一些过去不常去的岩场也逐步恢复了。我们依旧住在纹图石。周二只有我们两个住客，原计划上燕子岩的，老板 BoBo 推荐我们去小庙，她最近修复了那里 ...继续阅读 (31)

在马山攀岩的最后一天，异星工厂的太空时代扩展包发售了。回到家中就开始玩，肝了 300 个小时，前天晚上终于通关了。准确说是系统告诉我赢得了游戏，但我知道后面还有很多事情要做。和原版一样，虽然发火箭名义上赢得了游戏，但白瓶科技是在火箭之后才有的；这次抵达了星系边缘就告诉我赢得了游戏，但钷素科技包（黑瓶）的原料都没见到。不过，我得暂时放一放，最近在这个游戏上花掉了所有时间，都没做别的事情。先写一篇总结，最近的体验太多，需要记录一下。不然热乎劲过了就忘了。虽然太空时代最精彩的部分在五个风格迥异的星球，让玩家体验不同的方式玩这个游戏。但我想先谈谈 2.0 在基础系统上所做的工作。去年我们做 Red Frontier 时，我就想去掉玩家操控的角色，以上帝视角来玩游戏。虽然过去异星工厂也有 Brave New World 这样的 Mod ，去掉了玩家角色，但所有的操作都是通过无人机完成的。我试过一下，相比有玩家角色，它的操作并不舒服。虽然在游戏初期，操作一个 Player 在地图上跑来跑去有点烦，但真去掉了这个 Player 反而不知道游戏该怎么玩了。我觉得是因为通过无人机下达指令，反馈不够即时，这有点像 RimWorld 或缺氧那样控制工人间接完成任务，玩起来总有点别扭。而操控 Player 虽然有跑路的烦恼，但同时也限制了同一地点能做的事情。在同一时间，玩家的选择变少了，精力可以聚焦在有限 ...继续阅读 (22)

最近去了一趟南宁马山县。攀岩一周，身体很累，心里很舒服。这周除了爬石头，什么都没想，脑子全部放空了。“一款好游戏，胜过两款伟大游戏”…… 这世上最容易做的就是“多”，如果我们不小心，就可能会把三四款游戏都塞进一个游戏里。有时候，决定什么内容不该加到游戏里，比决定什么内容该加进入更加总要。—— 《席德梅尔的回忆录》这几天，读了本书《席德梅尔的回忆录》：《文明》是在陪产假中诞生的，它一开始更像是《铁路大亨》的延续，一个全球规模的《模拟城市》，一个实时模拟游戏。它开发了很久都没有找到正确的方向，一度项目被搁置。而重新继续这个项目后，经过了搁置期的思考，才试着将其改为回合制游戏。席德还有款失败的作品《恐龙游戏》，他从 1991 年开始鼓捣这款游戏的原型，到 2000 年第 6 届 E3 展后彻底放弃。一开始几个版本像是恐龙版文明，核心玩法是基因衍化，但随机基因突变并不好玩；其后简化了复杂的规则，却变得很无聊。“好像不是你在玩计算机，而是计算机在玩你。如果游戏要一下子表达太多东西，那简化游戏设计会有帮助；但如果你在一款回合制游戏上投入了足够多的时间，你就会希望能够控制所有有趣的决策”。回合制走不通，游戏原型转为了即时制。席德之前就有一款成功的即时制游戏《葛底斯堡战役》。但这个《恐龙争霸》却因为恐龙题材难以嫁接足够多的远程武器以至于无法平衡。然后，这款恐龙游戏又演化成了口袋妖怪，或是更接近恐龙 ...继续阅读 (35)

“首先，设计师创建了一些游戏机制。然后，他们把这些游戏机制用一些具有代表性的虚构元素包装起来。在游戏过程中，这些机制之间会产生一系列事件。这些事件会触动玩家潜意识中的触发器，从而激发出情感。最后，这些情感交织到一起，变成了一种综合的体验。” —— Tynan Sylvester 《Designing Games: A Guide to Enginerring Experiences》我非常认同 Rimworld 作者 Tynan 对电子游戏的定义：游戏是一种制造体验的人工系统。游戏用一种工程手段制造体验，目的是激发人类的情感。在《体验引擎》的书中论述，追踪情感的真正源头非常困难，因为情感的触发由大脑的潜意识处理，自动表达的。即使不知道为什么会产生某种情感，我们的理性还是会想当然的为之安排一个原因。这些想当然的原因往往是错的。这种现象被称为情感错位，因为情感错位的存在，想要了解游戏如何影响我们是十分困难的事情。我最近把游戏开发工作中的具体实现停了下来。因为我意识到，游戏核心固然是设计一些机制，程序实现可以把这些机制做出来并加以测试，但游戏机制只是手段而不是目的。我对游戏设计的理解还不够，所以还需要继续以设计游戏的角度去挖掘游戏深层次的东西。以游戏爱好者的角度去玩那些好评如潮的游戏体会游戏带来的乐趣是不够的，还需要多玩一些毁誉参半但制作者有自己想法的作品。当然，还需要回避一些仅仅是把已 ...继续阅读 (44)

这个月没有写什么程序。月初停下手头的开发工作，花了一周时间，作为 Indieplay 评委试玩了 200 多个参选游戏中的 100 多个。这个工作暂停之后，我就对前两个月对自己想做的游戏产生了许多疑惑。虽然写了不少代码，但仅限于基础玩法的外在功能：我实现了一整套类似边缘世界和缺氧里的工人系统，让小人可以在场景中活动起来，采集物资，建设建筑。让机器可以通上电运转起来，把原料加工为成品。但这些似乎只是一种模拟过程，而并非游戏。我感觉自己对游戏到底想展现怎样的游戏体验没有清晰的认识。虽然在这篇采访中也提到，（缺氧的最初设计是）“希望整个游戏运行在一个开放的（虽然简单的）模拟之上”。但我觉得模拟毕竟不是游戏，难以给玩家提供丰富的游戏体验。或者说，至少对于我这样的玩家，没有清晰的游戏目标和挑战是不行的。而且，实现一个丰富的游戏环境模拟面临的挑战我现在还无法评估，至少在当下，这不是我优先想做的东西。我给游戏定下的基调是基地建设加生存挑战类型，或许应该有一些资源管理和 Roguelike 元素。工人管理或自动化元素是我比较喜欢的，但玩过几千小时类似游戏后，我感觉这些元素只是给予玩家体验的一种手段，并非目的。单独玩某个特定玩法，或许也能有趣，但体验却会大相径庭。比如，我这个月花了不少时间玩 Shapez 2 。这是一个把自动化做到极限的游戏。玩家不再需要考虑能源、制造成本等问题，也没有敌对势力，只 ...继续阅读 (41)

我独自开发游戏已经有三个月了。这三个月里，我是 Ant Engine 唯一活跃用户，这是一个很好的机会来挖掘对于一个独立游戏开发者来说，引擎哪些地方有缺失。现阶段，我还是希望把精力放在游戏开发上多一些，所以引擎方面恰恰够用就好。虽然，完善引擎这件事做起来会更愉快，因为这些工作对于我比较顺畅，容易想清楚，游刃有余；而一个人开发游戏，更多的时候是手跟不上心而产生的烦闷。我还是想挑战一下自己，把游戏设计好，实现好。引擎方面的事情，把想到的东西先记录一下。或许完成手头的游戏项目，沉淀更多，再回头做引擎，愉悦感更强一些。首先，可视化编辑器对我来说不重要。所以暂时就不维护了。我更需要的是一些快速验证眼下游戏设计中想法的功能，这些就在游戏 demo 中顺带实现就好，看起来没必要放在编辑器里。这和现阶段没有美术参与也有关系。因为对我自己做独立游戏来说，我不在乎开发进度，先做美术还是后做美术，区别不是很大。本来我自己就喜欢传统 roguelike ，几个 ascii 字符就能脑补所有的美术表现。我想，游戏原型阶段就不需要美术在编辑器里做创作了，用一些几何体就够用。这也是为什么我在三个月前最先完善的就是Ant 引擎中预制几何体这个功能的原因。我在使用 Ant 引擎的时候，发现因为缺乏具体 API 文档而只能不断的阅读源代码（毕竟有很多模块不是我自己动手写的，无法全部了然于心）。而且并非每个模块的设计都 ...继续阅读 (69)

我在用 C 构建项目，尤其是和 Lua 混合使用时，一直很头疼 C 没有一个统一的模块管理器。Lua 的模块管理虽然简单，但毕竟有且够用。一种方法是把 C 模块封装成一个个 Lua 模块，让 Lua 帮助管理，每个 C 模块是独立的，相互不可见。但当 C 模块之间发生关系时，就比较麻烦。当然，简单的方法是通过链接器把它们都链接在一起，通过函数名前缀以区分。或是利用操作系统的动态库加载器来管理模块。最近有了一点有趣的想法，觉得一个最简的模块管理器其实复杂度并不高。花了半天功夫实现了一下，感觉还不错。https://github.com/cloudwu/cmod/我在设计时，刻意回避了使用 macro 魔法，让它的接口保持原始的 C 风格。而且，实现上也不依赖任何内存分配函数，整个管理器需要的内存是一开始由调用者分配好一大块传入的。这个管理器只管理函数指针，刻意没有去管理其它状态（比如类似事务、COM 管理的就不只是函数接口，还保留对象实例），但还是为每个管理器实例留有一个 userdata 指针，供使用者扩展。其中的 import 函数，也就是通过字符串查找对应的模块，使用的是简单的 O(n) 遍历所有已注册模块的算法。如果接下来有性能需要的话，我会再加一个 hash 表做一些简单的 cache 。 ...继续阅读 (58)

我倾向于在 C 程序里使用整数 handle ，而不是指针。尤其是需要做弱引用的时候。我认为，一个好的 handle 生成算法，应该满足：即使 handle 被销毁了，它这个数字也应该被保留，不应该被新的 handle 复用。posix api 里的文件 id 就不符合这一点。提供一个 api 可以判断一个 handle 是否有效，其时间复杂度为 O(1) 。从 handle 对应为对象的内存地址的时间复杂度应该为 O(1) ，不应该比指针有明显的性能问题。虽然 hash 表理论上可以满足 O(1) 的时间复杂度，但在糟糕的场景（hash 碰撞发生时）并不能保证这一点。构造 handle 时间复杂度也为 O(1) 。handle 的数字位宽最好不要超过 32 bit 。如是长期运行的程序，第一和第四个需求不能同时成立。但对于非长期程序，理论上 32bit 的数字应该是够用了。比较简单的实现方案是用一个自增 id ，然后用一张 hash 表来保存 id 到指针的映射。但 hash 表不是严格的 O(1) 复杂度。在 skynet 中，我使用了一个简单的方法：自增 id 后，如果发现 hash 冲突，就再加一，直到不冲突为止。这个方法不能满足第 4 点需求。当然，同时满足 5 点需求未必有多大的意义，但我最近想到一个有趣的方案，稍微实现了一下，感觉可以做到。前提是：为了让 32bit ...继续阅读 (68)

这两天思考了一下，基于工厂生产的基地建设类游戏给玩家提供的核心体验到底是什么？以及，我们去年被取消的游戏到底还差点什么。接下来我要制作的游戏的注重点应该在哪里。我玩的时间比较长的两个基地建设类游戏：异星工厂和缺氧，它们的玩法其实差异很大，但却给人一些近似的体验。对于这个问题，我想过很多次，得出的结论是，它们的确有一些共通之处：玩家在玩这两个游戏时的情感体验过程非常类似，大致是这样的：玩家开始了解基本规则。对于异星工厂来说，就是采集原料，生产加工，生产科技瓶，推进科研发展；对于缺氧来说，是建造设施用来提供小人的各种生存所需，不要让他们死掉。让玩家了解游戏的终极目标。这通常是建设一项宏伟的工程。异星工厂和缺氧的原版目标，不约而同的都选择了制作并发射火箭逃离所在星球。玩家根据完结游戏的目标和已经了解的游戏规则，在心里做出通关（或是解决阶段性目标）的计划。玩家在实施计划的过程中遇到挫折。这通常是发生了一些未曾预料的意外。这个意外并不是系统额外强加进来的，反而是在已透露给玩家的规则下合理发生的。所以，玩家会觉得是自己对规则理解的不够，而不是来源于设计者的恶意。玩家修正自己的计划，重新理解游戏系统。如果挫折时由游戏规则内在随机性带来的（缺氧中略微多见），玩家学会应对这些随机性，随之增强自己对抗游戏的自信；而异星工厂（尤其是关闭战斗后）是一个无危机的游戏。但还是会随着自己管理的工厂规模变大，需要 ...继续阅读 (62)

游戏行业从业 20 多年，一直在做底层开发，即使是帮助其他团队写上层游戏逻辑，也都是实现某些特定的功能模块。直到最近，我想单独开发游戏，才好好想想架子该怎么搭。从最初的原始 demo 开始，由于缺乏经验，写着写着经常有失控的感觉。好在一个人做，重构的心理负担不大。想改的时候，停下来花上两三天全部重写也不太所谓。最近总算顺畅了一点，感觉需要整理一下思路，所以写一篇 blog 记录一下。任何复杂的软件问题，都可以通过拆分为若干子问题减少复杂度。我认为，游戏的上层逻辑，即 gameplay 部分，主要分为三块：数据模型、外在表现和人机交互。“数据模型”是 gameplay 的核心部分，即把游戏的画面等外在表现以及图形界面、操作控制（鼠标键盘控制器等）等剥离后的东西。如何判断一个模块是否属于数据模型，是否有不属于它的部分没有拆分出去，最简单的方法是看它是否有直接调用游戏引擎的代码。拆分干净后，这块不应该包含任何与图形、界面、时钟、控制输入有关的接口。除了一些必要的文件 IO 接口（主要是用来读取 gameplay 相关的策划数据，写 log ，做数据持久化等），也不应该涉及任何 OS 的 API 。这样，我们就可以方便的对它进行整体或局部的测试。必要时还可以更换游戏引擎，甚至从文本 roguelike 换到 3D 表现都不会受影响。“外在表现”当然是指游戏的画面表现、声音声效等等，通常这 ...继续阅读 (57)

在矮人要塞 like 的游戏中，都有一套基于工人的任务分发系统。玩家通常不能像 RTS 中那样直接操作工人去工作，而是对要做的事情下达任务，等着工人自主去完成。由于任务数量通常远多于工人数量，这个任务分发系统中大多配有优先级设置，可以让诸多任务有条不紊的进行。调整优先级变成玩家主动操控的渠道。初玩这类游戏，会有点不习惯：感觉难以在微观层面直接做自己像做的事情。像捡块石头放进指定仓库这件事，无法像玩 RTS 游戏那样，先点选工人，再针对石头发出拾取指令…… 但习惯之后，恐怕又回不去了。比如我在玩 Ratopia 时，就对操控鼠王直接干活烦躁不已。这类游戏，我玩的时间比较长的有三个，按时长排序为：缺氧 (ONI) 、边缘世界 (Rimworld)、矮人要塞 (DF)。其它如 Songs of Syx 、Prison Architect 等很多也有所涉猎。其实，这些游戏在设计工人任务系统的细节上也有所不同。以我游戏时长最长的缺氧和边缘世界相比较，同样是提供玩家主动操控的能力：Rimworld 可以给工人的任务队列直接下达指令（这更接近 RTS 的玩法），而 ONI 则是通过给单个任务本身排优先级实现的。ONI 设计了警报级任务，可以越过一切优先级设定，强制立刻完成。虽然 ONI 也保留了指挥单个小人移动到指定位置，但实际游戏中几乎没什么用。对于拾取物品，Rimworld 可以封禁、解禁单 ...继续阅读 (57)

像异星工厂、缺氧、边缘世界都有大量的 mod 。可以通过大改游戏机制，把本体游戏改造成完全体验不同的游戏。这些好玩的 mod 几乎都是一个人完成的。所以我觉得，固然游戏的外层玩法决定了整体体验，但其实开发的总工作量并不大。而且，一旦玩法不满意，也容易修改。我的游戏开发计划是先完成一些底层基础系统，再考虑完整游戏的全貌。没有上层玩法支撑，光有底层系统可能玩起来一定寡淡无味，但我认为它们是设计和开发中最重要的一环。在进一步实现 demo 之前，我设计了一下飞船的建造系统。游戏世界中的物质分为三种：建筑，零件，原料。摆放在场景中（飞船）的是建筑，墙体、门、机器、家具这些属于建筑，一旦修建出来就不可任意移动位置。建筑是由零件构成，拆毁建筑会 100% 返还零件。建筑修建是可逆的。零件是由原料在机器中合成出来，这部分和异星工厂相同。并不一定存在逆向的合成配方。例如，铁板可以合成铁丝，但铁丝并不一定存在变会铁板的方法。所以和建筑不同，加工零件可能是一个不可逆的过程。飞船（场景）是由四边形网格构成。每个格子永远只能容纳一种物质，要么是建筑的一部分，要么是一种零件。而原料无法直接存在于场景格中，它们必须存在于容器里。建筑和工人都可以是容器。工人可以在场景格的过道中移动，工人之间不设阻挡。没有建筑的格天然称为过道，部分建筑会占据场景格，成为障碍物。有些建筑将所占据的部分场景格保留为过道。例如门。每种 ...继续阅读 (78)

在设计飞船建造的游戏时，我想做一个空气流动的模拟系统。这里有一个初步的方案，不知道好不好，先记录一下：空间是由二维的正方形格子构成的，有些格子如墙体会阻止空气流动。每个格子有温度属性及气体质量的记录。不同气体可以同时存在于同一个内，质量单独记录。温度传导系统另外设计。每个游戏 tick 对每个格子做一次独立计算，根据温度值给出一个概率，这个概率决定了该格气体向周围扩展的比例。温度越高，越可能将更大比例的气体平均扩散到最多邻接的 8 格空间。当格子因为建墙而导致空间变化时，把该格内气体全部扩散到临接格，当极端情况下无法做到时，空气锁定在墙体内，不会消失，等待以后满足条件后再扩散出去。为什么要做基于格子而不是基于舱室的空气模拟？例如， FTL 的氧气气压模拟就是基于房间的。因为，这个模拟需要结合游戏本身其它玩法的需要。预计之后会做气闸舱，真空室等设定。需要有一个更微观的空气流动模拟，简单的给船舱加上气压的数值是不够的。和 FTL 不同，我希望做一个基地建设风格的游戏，舱室的结构是动态的，难以以房间为单位计算。目前有气体流动模拟的游戏中，最流行是缺氧。为什么不直接使用缺氧的模拟系统?缺氧的基本规则是：每个格子只能有一种物质，这种物质可能有三态：固态、液态、气态。物质会因为温度发生三态转换。不同形态的物质属于不同的东西，每一格不能混装。特殊情况下，气体会直接消失。气体倾向于从高压格流向临近 ...继续阅读 (69)

Ant 引擎的角色动画系统还需要完善。之前我们用 Ant 引擎开发的游戏以机械装置为主，所以并不需要人型角色动画。对于人物角色动作的动画控制，最好有更多的引擎支持。通常，角色逻辑上的属性和动画表现存在一个映射关系。一个角色，它逻辑上的基本属性可能只有在空间中的坐标。我们编写代码控制它时，只关心它在哪里。但是，在做画面表现时，则需要根据空间坐标这组简单属性，转换为动画播放：如果角色静止不动，就播放 idle 动画，如果正在运动，就播放 walk 动画。在引擎底层，每帧只通过坐标这个属性来计算角色该播放哪个动画以及怎样播放，信息是不够的。通常还需要结合过去时间线上的状态变化来推算出当前状态；或是通过几个独立的逻辑属性的组合，得到动画需要的信息。例如，可以通过空间坐标的变化过程计算出速度；根据是否处于战斗状态决定是警戒行动还是自由行动……这种从逻辑属性数据到表现用数据的映射关系，一般使用状态机来实现。Unity 文档对此有一个很好的描述。通过这个状态机，可以生成动画系统底层每帧需要的数据，而开发者只需要简单修改逻辑上的基本属性即可。动画系统底层看到的是 Entity 当前状态下用于动画渲染的基础数据：一个动画片段的当前帧，或是几个动画片段的加权混合。而状态机只用运行当前帧的当前状态关联的转换逻辑去加工那些基本属性输入。因为状态机永远处于单一状态，但对于动画来说，从一种状态到另一种状态通常 ...继续阅读 (80)

因为玩了一些星舰或太空站建造类的游戏，找找灵感。每个游戏都能给我一些启发，因为玩的都不多，所以就不评价了，只做个列表记录，排名不分先后。有些还没有出，先加了个愿望单。CosmoteerSpace HavenStardeusThe Last StarshipFacteroidsAstro ColonyStarsectorRimworld mod : Save Our Ship 2Factorio mod : Space ExplorationFactorio mod : Warp Drive MachineOxygen Not Included DLC: Spaced OutSpace ArchitectStarship TheoryStationeersOstranautsStarmancerSpace SlogThe CrustDeep Space OutpostStarshop ColonyRionag: Survey FleetGeneration ShipAdaptoryFar SectorGeneration Nova ...继续阅读 (64)