关于桌游设计大赛的介绍

这一篇是前几个月研究桌游规则期间的另一篇小结。因为最近两个多月都在制作 Deep Future 的数字版,没空整理笔记。现在闲下来,汇总整理这么一篇记录。 今年夏天,我迷上了 DIY 类型的桌游。这类桌游最显设计灵感。商业桌游固然被打磨的更好,但设计/制作周期也更长。通常,规则也更复杂,游戏时间更长。我经常买到喜欢的游戏找不到人开。阅读和理解游戏规则也是颇花精力的事情。所以,我近年更倾向于有单人模式的游戏。这样至少学会了规则就能开始玩。但为单人游玩的商业桌游并不算多(不太好卖),而我对多年前玩过的几款 PnP (打印出来即可玩)类单人桌游印象颇为深刻:比如 Delve 和同期的 Utopia Engine (2010) 。 在 7 月初我逛 bgg 时,一款叫做 Under Falling Skies 的游戏吸引了我。这是一个只需要 9 张自制卡片加几个骰子就可以玩的单人游戏,规则书很短几分钟就理解了游戏机制,但直觉告诉我在这套规则下会有很丰富的变化。我当即用打印机自制了卡片(普通 A4 纸加 9 个卡套)试玩,果然其乐无穷。尤其是高难度模式颇有挑战。进一步探索,我发现这个游戏还有一个商业版本,添加了更长的战役。当即在淘宝上下了单(有中文版本)。 从这个游戏开始,我了解到了 9 卡微型 PnP 游戏设计大赛。从 2008 年开始,在 bgg (boardgamegeek) 上每年都会举办 PnP 游戏设计大赛。这类游戏不限于单人模式,但显然单人可玩的游戏比例更高。毕竟比赛结果是由玩家票选出来,而单人游戏的试玩成本更低,会有更多玩家尝试。据我观察,历年比赛中,单人游戏可占一半。近几年甚至分拆出来单人游戏和双人游戏,多人游戏不同的设计比赛。 根据使用道具的限制条件,比赛又被细分。从 2016 年开始,开始有专门的 9 卡设计大赛。这是众多比赛中比较热门的一个。我想这是因为 9 张卡片刚好可以排版在一张 A4 纸上,只需要双面打印然后切开就完成了 DIY 制作。加上每个桌游玩家都有的少许米宝和骰子,阅读完说明书就可以游戏了。 如果嫌自己 DIY 麻烦或做出来的卡片不好看,在淘宝上有商家专门收集历年比赛中的优秀作品印出来卖,价格也非常实惠。比赛作品中特别优秀的,也会再完善和充实规则,制作大型的商业版本。例如前面介绍的坠空之下就是一例。我觉得,阅读规则书本身也很有意思。不要只看获奖作品,因为评奖只是少量活跃玩家的票选结果,每个玩家口味不同,你会有自己的喜好。而且我作为研究目的,更爱发现不同创作者的有趣灵感。 如果对这个比赛有兴趣,可以以关键词 2025 9-Card Nanogame Print and Play Design Contest 搜索今年的比赛历程。 我花了几周时间玩了大量的 9 卡桌游。喜欢的非常多,无法一一推荐。除了前面提到的坠空之下,让我推荐的话,我会选择 2023 年的 Survival Park (Dinosaurs game) 。倒不是我自己特别偏爱这款,而是我介绍给云豆后,他也很喜欢。 其实,除了 9 卡游戏,还有 18 卡,54 卡等。卡片数量限制提高后,设计者可以设计出更丰富的玩法。例如著名的 Sprawlopolis (无限都市) 一开始就是一款 18 卡桌游,但后来已经出了相当多的扩展。反过来,也有用更少卡片来设计游戏。比如 1 卡设计大赛就限制设计者只使用一张卡片(的正反面)。 在 bgg 上,你可以在 Design Contests 论坛找到每年举办的各种类型设计大赛。除了传统的 各种 PnP 类型外,我很喜欢的还有传统扑克设计比赛。用 2025 Traditional Deck Game Design Contest 就可以搜索到今年的。这个比赛开始的比较晚,2022 年才开始的第一届。 这个比赛限制设计者围绕传统扑克牌来设计游戏玩法。如果你想玩这些游戏,成本比 PnP 游戏更低:你甚至不需要 DIY 卡片,家中找出 1/2 副扑克就可以玩了。我小时候(1980 年代)特别着迷扑克的各种玩法,在书店买到过一本讲解单人扑克玩法的书,把上面介绍的游戏玩了个遍。所以在多年之后见到 Windows 后,对纸牌游戏的玩法相当亲切。 可以说扑克发展了几百年,单人玩法就没太脱离过“接龙”;多人玩法的核心规则也只有吃墩(桥牌)、爬梯(斗地主)、扑克(Poker 一词在英文中特指德州扑克)等少量原型。 但自从有了这种比赛,设计者的灵感相互碰撞,近几年就涌现出大量依托扑克做道具的新玩法。往往是头一年有人想出一个有趣的点子,后一年就被更多设计者发扬光大。电脑上 2024 年颇为好评的小丑牌也是依托德州扑克的核心玩法,不知道是否受过这个系列比赛作品的启发,但小丑牌的确又启发了这两年的诸多作品:例如我玩过的 River Rats 就特别有小丑牌的味道,同时兼备桌游的趣味。 单人谜题类中,我特别喜欢 2024 年的 Cardbury :它颇有挑战,完成游戏的成功率不太高,但单局游戏时间较短,输了后很容易产生再来一盘的冲动。 多人游戏,我向身边朋友推广比较顺利的有 Chowdah 。它结合了拉米和麻将的玩法。我只需要向朋友介绍这是一款使用扑克牌玩的麻将,就能勾起很多不玩桌游的人的兴趣。而玩起来真的有打麻将的感觉,具备一定的策略深度。 我自己曾经想过怎样用传统扑克来模仿一些经典的卡片类桌游,但设计出来总是不尽人意。比如说多年前我很喜欢的 Condottiere 佣兵队长,如果你没玩过它的话,一定也听过或玩过猎魔人 3 中的 Gwent 昆特牌。昆特牌几乎就沿用了佣兵队长的核心规则。而 2024 年的 Commitment 相当成功的还原了佣兵队长的游戏体验。 还有 MOLE 则很好的发展了 Battle Line 。 如果想体验用扑克牌玩出 RPG 的感觉,可以试试 2022 年的Kni54ts :有探索地图、打怪升级捡装备等元素;多人对抗的则有 Pack kingdoms。 有趣的游戏规则还有很多,我自己就记了上千行规则笔记。这里就不再一一列出给出评价,有兴趣的同学可以自己探索。

2025/10/12
articleCard.readMore

深远未来开发总结

桌游 Deep Future(深远未来)开发告一段落,我为它创建了一个 itch.io 的页面 发布第一个试玩版本。接下来的 bugfix 会在 github 继续,等积累一定更新后再发布下一个小版本。 这是一个兴趣驱动的项目。正如上一篇 blog 中写到,驱使我写它的一大动力是在实践中探索游戏开发的难题。写这么一篇总结就是非常必要的了。 开发过程 我在 2025 年 7 月底写下了项目的第一行代码。在前三周并没有在实现游戏方面有太多进展。一开始的工作主要在思考实现这么一个游戏,底层需要怎样的支持。我使用的引擎 soluna 也只是一个雏形,只提供非常基础的功能。我想这样一个卡牌向桌游数字化程序,更好的文本排版功能比图形化支持更为迫切。固然,我可以先做一个 UI 编辑器,但那更适合和美术合作使用。而我现在只有一个开发者,应该用更适合自己的开发工具。应该更多考虑自己开发时的顺手,这样才能让开发过程保持好心情,这样项目才可能做完。所以我选择用结构化文本描述界面:容易在文本编辑器内编写,方便修改,易于跟踪变更和版本维护。 在 8 月的前两周,开发工作更多倾向于 soluna : 维护 yoga 的集成,编写布局模块。 增加文本块的支持,支持简单的文字排版。 增加 icon 的支持,可以和文本混合排版。 增加单色无贴图矩形。这样可以视觉化布局的 box 。 增加嵌套图层,而不是之前的平坦化图元。 期间有两个和游戏无关的(看起来很小的)问题花掉了我很多时间: 设置窗口标题 api 的多线程竞争引起的死锁。 我按照过去的习惯,使用预乘 alpha 的方式处理半透明混合。后将其修改为非预乘模式。 关于 alpha 混合这点。根源在于 20 多年前我使用 CPU 计算 alpha 混合。当时如果将图片像素预先乘上一次 alpha ,可以减少一点运行时的 CPU 开销。这个习惯我一直带到现在 GPU 时代,本以为只是现代图形管线中的一个设置而已。当我独立开发时才发现,现在的图片处理软件默认都不会预乘方式导出图片,这让我自己使用 gimp 编辑带 alpha 通道的图片时,工作流都多了一步。因为 gimp 也是现学的,一下子也没有找到特别方便的方法给图片预乘 alpha ;使用 imagemagick 用命令行处理虽不算麻烦,但增加了工作流的负担。我在上面花掉了十多个小时后(主要花在学习 gimp 和 imagemaick 的用法)才醒悟,配合已有成熟工具简化开发工作流才是最适合我这样独立开发。所以我把引擎中的默认行为改成了非预乘 alpha 。 到 8 月的第三周,已经可以拼出静态的游戏界面:有棋盘、卡片、带文字的桌面布局。虽然从外观上,只是实现一个简陋的静态的带图层排版系统,但视觉上感觉游戏已经有点样子了,而不再仅仅是脑补的画面,这让开发的心情大好。 同时,我实现了基本的本地化模块。其实不仅仅是本地化需求,即使是单一语言,这种重规则的桌游,在描述暂时游戏规则时也非常依赖文本拼接。因为维护了多年 stellaris 的中文 mod ,我受 Paradox 的影响很深。早就想自己设计一套本地化方案了,这次得以如愿。 接下来的四周游戏开发速度很快。在之前三周的引擎补完过程中,我在脑中已经大致计划好后续的游戏开发流程:按游戏规则流程次序,拆分为布局阶段、开始阶段、行动阶段、结算阶段、胜利阶段、文明及奇迹分开实现。每个流程在实现时根据需要再完善引擎以及游戏底层设施。 以游戏玩的流程来依次实现,可以让游戏逐步从静态画面变成可交互的,这种体验能提供一种开发的目标感:让我觉得开发进度在不断推进;而每个步骤其实要解决和补充底层设施的不同方面,解决问题是不一样的,这样可以缓解开发的枯燥感。保持开发的心情最重要,这是我近二十年学到的东西。只是过去我一直偏重于底层开发,一直回避了相对枯燥繁琐重复的游戏功能开发。开发游戏中的不确定性,实现一点点交互功能也要花费大量时间的确是非常打击开发心情的东西。这并不像底层开发有一个确定目标,和 API 打交道(而不是纠缠在低效的人机交互中)也可以直指问题本身。 实现游戏布局设置时,我顺道完善了桌面布局模块,让棋盘、手牌、胜利轨道、中立卡牌区等展示得好看一些。并增加了和鼠标的交互,卡片在区域间的运动等。 待到游戏有了基本的交互,变得可以“玩”了。我发现,一个数字化的桌游最重要的是引导玩家熟悉桌游规则。重要不是做一个详尽的手把手一二三的教学,而是玩家一开始无意识操作中给出有价值的信息反馈。玩家可以学到每个操作对游戏状态造成了怎样的影响。玩家还应该可以随时点击桌面元素去了解这各东西是什么。虽然大段的文字描述对电子游戏玩家来说并不友好,但对桌游玩家来说是必修课。数字版能提供更好的交互手段,让玩家可以悬停或点击一个元素,获得文本解释,已经比阅读桌游说明书友好太多了。 所以我在一开始就花时间在底层设计了这样的提示系统。 打算往下实现更复杂的游戏流程时,我意识到这类流程复杂的游戏,主框架镶嵌一个简单的游戏主循环显然不够用。我需要一个状态机来管理交互状态。一开始并不需要将状态机实现得面面俱到,有个简单的架子即可。Lua 的 coroutine 是实现这样的状态管理非常舒适的工具,几十行代码就够了:gameplay 的状态切换很轻松的就和渲染循环分离开了。 游戏的“开始阶段”本身并无太多特有的 gameplay 需要实现。但是,这套游戏规则中最复杂的 advancement effect 机制在这个阶段就有体现。最难的部分是设计 advancement 的交互。在桌游原版规则中,玩家可以任意指定触发哪些 advancement ,它们的来源也很多样:弃掉手牌、母星区卡片的持久能力、殖民地区卡片的一次性能力等等。每张卡片上可触发的 advancement 数量不一,从 0 到 3 皆有可能,玩家可以选择触发或忽略,最后还可以自由决定对应 effect 的执行次序。 对于桌游来说,这是非常自然的形式:桌游玩家的脑海中一开始就包含了所有游戏规则,大脑会将这些散布在桌面各处的元素聚集起来,筛选出需要的信息,排序,执行,一气呵成。但对于数字版,很容易变成冗长的人机交互过程。每个步骤都需要和玩家确认,因为轻微的差别都有可能影响 effect 结算的效果。这不光实现繁琐、对玩家更是累赘。 所以,电子游戏中更倾向于自动结算的规则,减少玩家的决定权。玩家也不需要了解所有的游戏规则。只有在玩家成长中,从新手到老鸟的过程,玩家可能去关注这些自动结算是怎样进行的,电子规则则提供一些中途干预的手段帮助高级玩家,所谓提高玩法深度。以万智牌和炉石传说相比较,就能体会到内核相似但卡牌效果结算方式的巨大差异。前者是为桌面设计的,后者则天生于电脑上。 不过这次,我不打算对桌游规则做任何调整。专心实现桌游的数字化。有些看似有绝对最佳选择的 advancement ,我也没有让系统自动结算,还是交给玩家决定。一是复原桌游的游戏感觉,二是让玩家参与结算推演的过程,让玩家逐步熟悉游戏规则。 当然,一个 advancement 当下是否可用,这是由严格规则约束的。桌游中需要玩家自己判定(也非常容易玩出村规),而数字版则可以做严格检查,节省玩家记忆规则细节的负担。这个负担依旧存在,转嫁到数字版开发者身上了。为此我在桌游论坛和桌游规则作者探讨了多处细节,以在实现中确定。 advancement 结算这块一开始就决定仔细抽象好,这样可以复用到后续的行动结算部分。不过我还是低估了一次设计好的难度,后来又重构了一次。 另外,从这里开始,我发现这个游戏的规则细节太多以至于我必须提升测试玩法过程的效率。所以设计了一个测试模块。并不是一个自动化测试,而仅仅是为人工测试做好 setup ,不必每次从头游戏。我有两个方案:其一是写一个简单的脚本描述测试用的 setup ;其二是完善存档模块,及作弊模块,玩到一个特定状态就存档,利用存档来促使。 我选择了方案一,在编辑器里编写 setup 脚本。以我的经历,似乎很多游戏项目偏向于方案二,好像有纯设计人员(策划)和测试人员共同参与开发的项目更喜欢那样。他们讨厌写脚本。 行动阶段的开发基本可以按游戏规则中定义的 8 种行动分别实现。其中 EVOKE 涉及文明卡,第一局游戏中不会出现,本着能省则省早日让游戏可玩的想法,我一开始就没打算实现。 而 PLAN 行动是最简单的:只是让玩家创造一张特定卡片,而且不会触发 advancement 。我就从这里开始热身。不过,PLAN 行动和其它行动不同,它不是靠丢弃手牌触发的,而是一个专有行动。这似乎必须引入一种非点击卡片的交互手段。我就分出时间来给界面实现了 button 这个基础特性。同时确定了这个游戏的基本交互手段:当玩家需要做出选择时,使用多张卡片标注上选项,让玩家选择卡片;而不是使用一个文本选择菜单。交互围绕卡片做选择,一是我像偷懒不做选择菜单,二是希望突出游戏以卡牌为主体的玩法。当然,也需要多做一些底层设施上的工作:一开始我打算让每张卡片都在游戏中有唯一确定的实体,但既然卡片本身又可以用来提供玩家决策的选项,就在底层增加了一种叫做卡片副本的对象。 某些行动有独自的额外需求。像 POWER 行动最为简单,只是抽牌而已。但 SETTLE 就涉及和中立区卡牌的交互;GROW 涉及在版图上添加 token ;ADVANCE 涉及科技卡的生成;BATTLE 和 EXPAND 涉及版图区域管理。这些需求一开始在 gameplay 底层都没有实现,只在碰到时添加。 好在这些需求天生就可以分拆。我大致保持一天实现一个行动的节奏,像和银河地图的交互也会单独拿出一天来实现。让每天工作结束时游戏可以玩的部分更多一点,可以自己玩玩,录个短视频上传到 twitter 上展示一下。 部分复杂的部分很快经历了重构。例如星图的管理,从粗糙到完善。一开始只是对付一下,随着更丰富的需求出现很快就无法应对,只能重新实现。中间我花了一天复习六边形棋盘的处理方法 。 交互部分给图形底层也提出了新的需求:我给 soluna 增加了蒙版的支持,用来绘制彩色的卡片。 按我的预想,按部就班的把游戏行动逐步做完,游戏的框架就被勾勒出来了。让游戏内容一步步丰富起来会是我完成这个项目的动力。这个过程耗时大约 2 周,代码产出速度非常快,但也略微枯燥。感觉代码信息密度比较低,往往用打算代码实现一点点功能。这种信息密度低的代码很容易消耗掉开发热情。但它们又很容易出错,因为原本的桌游规则细节就很繁杂,一不小心就会漏掉边界处理。gameplay 的测试也不那么方便,如果依赖人去补充详尽的测试案例,开发周期会成倍的增加,恐怕不等我实现周全,精神上就不想干了。期间主要还是靠脑中预演,只在必要时(感觉一次会做不到位)才补充一个测试案例。 按节奏做到回合结算阶段时,我发现虽然看起来游戏可以玩了,工作其实还有很多:结算的交互和前面的差别很大、还需要补充 upkeep 方块的实现。回合结算事实上是系统行动阶段,虽然玩家参与的交互变少了,但自动演绎的东西增加了。系统结算过程可能导致玩家失败,所以必须再实现一个玩家失败的清点流程才能完整。 到 9 月初的时候,我完成了以上的工作。正好碰上每年一度的 indieplay 评审工作(四天),我在评审前一晚完成了第一个可玩版本(只有失败结算,没有胜利结算),第二天带到评审处,给一个评委试玩。这是第一个除我之外的玩家,表现还不错,居然只碰到 1 个中断游戏的 bug ,还只是发生在游戏最后一回合。来自于专业玩家的评价是:这么复杂的游戏规则想想也知道需要大量的开发工作,一个月就实现出来算是挺快了。缺点是部分游戏流程进行的太快,还没明白是什么就过去了(自动推演的部分);影响玩家选择的支付和结算部分,非常容易误操作选择对玩家不利的选择;至于最后碰到的那个 bug ,可以充分理解。第一次玩家试玩有一两个 bug 是再正常不过了。 我记录了一下玩家反馈,回家调整了对应部分:在底层增加了鼠标长按确认的防呆操作(其中图形底层实现了环形进度条的显示,同时发掘了底层图元装箱的一个小问题:图元拼接在整张贴图上时,需要空出一像素的边界,否则会相互影响),顺便重构了鼠标消息的底层管理 。另外,丰富了不少自动推演的流程的视觉表现,一开始设想尽量快速自动结算方便玩家恐怕不太合适。玩家并不需要过于加快游戏节奏,通过视觉上的推演过程让玩家理解游戏更重要。这些工作做了几个晚上(白天需要做游戏评审工作)。 接下来的两周发生了意外,我的开发工作几乎停滞。 租的房子到期,原计划在 9 月底搬家。给 indieplay 做评委的最后一天,接到母亲电话,在小区门口被顺丰快递员骑的电瓶车撞到,胫骨粉碎性骨折住院。处理医院的事情花了一整个晚上,心情大受影响。 调整心情后,我还需要面对另一个问题:原本计划是和母亲一起收纳搬家的东西,时间上非常充裕,每天只需要规划出小块时间即可。现在虽然父亲可以负责医院住院的事情,但搬家的工作几乎得我一个人来做了。关键是意外让日程安排突然变得紧张起来。把开发从日程重去掉是必然的。 最终如期搬完家,非常疲惫不堪。万幸母亲手术很顺利,只是未来半年行动受限,需要人照顾。 这段时间,我已经把游戏代码仓库开放。由于在 twitter 上的传播,已经有少量程序员玩家了。其实游戏并未完成,网友 Xhacker 率先赢得了(除我本人的)第一场游戏胜利…… 只是代码上并无胜利判定,所以他补完了这部分代码。由于对游戏规则不那么熟悉,所以实现是有 bug 的,后来也被我重构掉了。但接受这种 gameplay 的 PR 让我感受到了玩家共同创作的热情。 Xhacker 同学还依照本地化格式,提供了英文版本的文本。这也是我计划中想做而没精力顾及的部分。帮我节省了大量的时间。后来我只花了两天时间就将后续开发中的新词条双语同步。 网友 Hanchin Hsieh 对多平台支持表现出热情。先后实现了 soluna 的 MacOS 和 Linux 版本 。中间我也花了 1-2 天时间解决多平台的技术问题。还给 soluna 提交了 CI 以及 luamake 的构建脚本。 如果开源项目可以拆分出更独立的子任务(例如跨平台支持、本地化等),多人合作的确能大大缩短开发进程。 搬家结束后,我重拾开发。恢复开发状态用了一两天的时间。后续工作主要是以下几点: 重构胜利结算流程 完善游戏存档 实现文明卡和奇迹 制作主界面,增加多游戏文件支持和语言切换的交互(之前只提供命令行切换) 卡片随机命名 实现输入控件以及玩家自定义卡片名称 将玩家游戏过程组织成文本供回顾游戏历史 这部分花了两周时间,可以说是按部就班。但实际开发工作比字面上的需求多许多。 在重构胜利结算流程中,我顺手把控制游戏流程的状态机模块修改了不少。因为无论是胜利结算还是失败判定,以及持久化支持,都会引入更复杂的状态切换。需要保证这些切换过程中数据和表现一致不能出错。 胜利结算中,为了增加游戏的仪式感,底层支持了镜头控制:可以聚焦放大桌面,将镜头拉近和恢复。 游戏存档被分离到独立服务中,同时承担数据一致性校验。在过去一个月的开发中,我发现存档对最终 bug 非常有效。依赖出错前的存档恢复出错环境比查看 log 要方便得多。但这需要更细致的存档备份,方便玩家从文件系统中提取历史存档。同期还解决了一个底层在 windows 上处理 utf-8 文件名转换的 bug 。 文明卡和奇迹都是游戏后期内容,开发起来并不容易。对于文明卡,规则书上有不少含糊其辞的地方,专门去 bgg 论坛和原作者核对细节。文明卡有一半的每个效果是特殊的,需要单独实现。但这些单独实现的部分和之前的 advancement effect 又有部分共同之处。本着让日后修改更容易的原则,再次重构了部分 advancement 处理的代码,让它们可以共用相同的部分;而奇迹的实现使得星图的管理模块又需要扩展,同样需要扩展的是 EXPAND 行动流程。这部分的开发持续了好几天。 主界面功能涉及到多层界面布局。之前游戏只使用了单层 HUD 结构外加一个说明文字的附加层,没打算实现多层界面(即多窗口)。而按钮模块也是临时凑上去的。待到实现主界面时,其结构的复杂度已经不允许我继续凑合了。 所以我对此进行的重新设计:原则上还是将行为了表现以及交互分离。在同一个代码文件里实现了所有界面按钮对应的功能,用一个简单的 table 描述界面按钮的视觉结构,通过这个视觉结构表来显示界面。这还是一个贴近这个游戏的设计,不太有普适性。可能换个游戏的交互风格就需要再重构一次。不够我觉得现阶段不用太考虑以后再开发新游戏的需求。遇到重写就好了。多做几次才好提取出通用性来。 界面的防呆设计没有继续沿用长按转圈的方法,而使用了两次确认的方式。即危险操作(例如删除存档)的按钮在点击后,再展开一个二级菜单,需要玩家再点击新按钮才生效。我觉得这种方式实现简单,也可以充分防呆。 我原本只想做卡片随机命名,不想做玩家输入自定义卡片名称的。一是做了一个多月有点疲倦了,想早点告一段落;二是考虑到我自己玩了不少策略游戏,几乎不会修改系统随机起好的名字,即使游戏提供了玩家修改名字的功能。很快的,我就从网上搜集了中国和世界大城市名称列表,用来随机给星区和星球卡命名。但当我在做科技卡命名时却犯了难。在原本桌游规则里,依照三条随机组合的 advancement 效果给科技卡起一个恰当的名字,是玩家玩这个游戏的一大乐趣(也是一项对玩家想象力的挑战)。程序化命名无非是在前缀、后缀、核心词的列表中按规则组合,必然失去韵味。我花了一天时间做了一班并不满意。尤其是想同时照顾中文和英文的命名风格太不容易。 Paradox 在群星的最近版本中一只致力于生成更好的随机组合名称。我在汉化时也学到了不少,这或许是很好的一个课题,值得专门研究实现。但在当下,我只想早点发布游戏。所以,我选择实现键盘输入模块。 soluna 原本并未实现键盘输入的相关功能。这主要涉及文本块排版模块的改进。因为一旦需要实现输入,就必须控制输入光标的位置,这个信息只要文本排版模块内部才有。我原计划是在日后增加文本超链接功能时再大改排版模块的,这次增加输入光标支持只能先应付一下了。有了底层支持,增加用户自定义卡片名称倒很容易。 至此,我已经完成了绝大部分预想的游戏功能。除了 7 ,暂时还未实现。 最后,还差一个 credits 列表。之前在做网游,只有在大话西游中我按当时的游戏软件管理加上了制作人员名单。那还是我在客户端压(光)盘前一晚执意加上的。为此我熬了一个通宵。后来的网游我便不再坚持,这似乎开了一个坏头,整个中国的网游产品都不再加入 Credits 了。再后来,我只在杭州开发的一个并不成功的卡牌游戏(卡牌对决)中再加过一次 credits。 正如《程序员修炼之道》第二版所言: 提示 97 :在作品上签名 “保持匿名会滋生粗心、错误、懒惰和糟糕的代码,特别是在大型项目中——很容易把自己看成只是大齿轮上的一个小齿,在无休止的工作汇报中制造蹩脚的借口,而不是写出好的代码……我们想看到你对所有权引以为豪——这是我写的,我与我的作品同在。你的签名应该被认为是质量的标志。人们应该在一段代码上看到你的名字,并对它是可靠的、编写良好的、经过测试的、文档化的充满期许。这是一件非常专业的工作,出自专业人士之手”。 我在 gameplay 的开发中充满着仓促、粗糙的设计,在游戏中展示我的名字会让我心存愧疚,以后或许会完善它或在新作品中做得更好。 数据统计 开发这个项目,我经历了接近两个月,从 2025 年 7 月底到 2025 年 9 月底,除去中间被打断的两周,一共 7 周时间。 游戏项目一共增加了 25152 行,删除了 7912 行文本,合计 17240 行。其中包含了 1000 多行的本地化文本和 3000 行左右的界面布局、测试数据、规则表格等。实际代码在 13000 行左右。 引擎 soluna 因这个游戏增加了 7756 行,删除了 2,084 行代码,合计 5672 行代码。 虽然游戏中美术量不大,但我还是大约花了 3-4 个工作日制作所用到的美术资源。时间花在学习 GIMP 和其它一些美术制作工作使用上为主。图标是在 fontawesome 上进行的二次创作,卡片是自己绘制的。星图则直接复用了桌游的原始资源。 版面设计不算复杂,yoga 提供的 flexbox 方案很好用。算上学习 flexbox 排版的时间,前后大约花了 2 个工作日。 虽然游戏规则很繁杂,但 bug 比我预想的少。debug 时间不算太多,通常随着开发就一起完成了。后来在 github 上玩家提到的 bug 也都可以马上解决。预计后续的游戏测试过程会是一个长尾,持续很长时间,但需要的精力并不多。不过能做到这一点,得益于桌游规则经历了近十年的修订,非常稳定。而我在动手实现数字版前,已经花了一个月的时间充分玩了实体,经历了无数的游戏规则错误。动手写代码时,游戏规则细节已经清晰的刻画在大脑中了。这和写底层代码很像:需求已经被反复提炼,只需要用代码表达出来。开发过程解决的都是程序结构问题,而不是应对多变的需求。 经验积累 经历这么一次,我想我可以部分回答项目开始之初的疑问。 我在开发过程中的情绪波动告诉我,最重要的是保持开发热情。不同情绪状态下的效率、质量差异很很大。这可以部分解释为什么行百里路半九十。并不是最后 10% 真的有一半工作量,而是开发热情下降后,开发效率变低了。伴随着潜在的质量下降,花在重构、debug 上的时间也会增加。 所以明确拆分任务真的很重要。每完成一步就解决了一个小问题。开发精力就能回复一点。但这样也容易陷入到开发细节中。多人协作可以一定程度的避免这一点,分工让人更专心。一人做多个层次不同门类的工作需要承担思维切换的成本,但能减少沟通,利弊还说不好。 对于游戏来说,视觉反馈是激励开发热情的重要途径。所以需要做一点玩一点。让自己觉得游戏又丰富了。但是追求快速的视觉反馈很容易对质量妥协:我先对付一下让游戏跑起来,不惜使用冗长重复的实现方式,硬编码游戏规则…… 事后一定需要额外精力去拆这些脚手架的。所以,会有很大部分的功能需要实现两遍。这或许是预估开发时间时需要将时间乘 2 的根源。 虽然重构很花时间,有时候还很累。但过去的经验告诉我,越早做,越频繁,越省事。这也是独立开发的优势之一:你不必顾及重构对合作者的冲击。所有东西都在一个人的脑子里,只要对自己负责就够了。 对于独立开发,代码量又变成了一个对项目进度很好的衡量标准。因为你知道自己不会故意堆砌低效代码,那么每 100 行代码就真的代表着大致相同的工作进展。整个游戏的核心代码放在 20000 行之内是非常恰当的篇幅,其实这个数字对非游戏项目也适用。因为这意味着你可以在一到两个月完成项目的基础工作。这样的周期不至于让热情消磨殆尽。后续的长期维护则是另一项工作了。 要把代码量控制在这个规模,需要尽可能的把数据分离出去。不然游戏很容易膨胀到几十万行代码。识别出哪些部分的代码可以数据化只能靠经验积累。而经验来源于多做游戏。所以,我今后还需要多写。 同时,分离引擎也是控制游戏代码规模的要点。不用刻意做游戏引擎,只需要做游戏就够了。识别出通用部分,集成到引擎中。给游戏项目也留一个底层模块,把不确定是否应该放在引擎中的代码先放在那里。它们可能跨不同游戏类型通用,但只是还没想到更好的抽象接口而已。 “优化”工作对我很有吸引力。但考虑到游戏开发进度,可以先把优化点记录下来放一放。保持着写好代码的决心,晚一点做优化不迟。这里的优化不仅仅指性能优化,也包括更好的代码结构和更紧凑的实现方式(更短的代码)。老实说,目前这版实现中,还是有大量冗长可以改进的代码,我相信有机会再做一次的话,我只需要一半的代码就能实现相同的功能。当然我不需要再实现一次,开始下一个项目更好。 开源依然有很大的优势。虽然很少有游戏业务代码开源,《大教堂与集市》的 4.10 探讨了“何时开放,何时关闭”,游戏业务本身开源能获得经济收益非常少。我一开始也考虑过闭源开发。这并不是一个经济上的决定,而是我知道,这个项目注定不会有很高的代码质量,低质量代码不具备传播因素,它无法作为学习参考,也没什么复用性,反而有一点点“面子”问题,毕竟写出低质量代码“面子上”不太好看。 但我发现这个项目开源后依然获得了额外收益。 吸引了程序员的参与,多交了几个朋友。在发现 bug 时,有一个更好的交流基础,对着代码看更清晰。即便只是自己读,阅读公开代码比阅读私人代码会更仔细。而且更有动力用文字解释。在写作过程中,思路得以迅速理清。 btw, github 的公开仓库比私有仓库有更多的免费特性。

2025/10/5
articleCard.readMore

有惊无险的一次网站系统升级

好消息是:这个 blog 终于是 UTF-8 编码了。前些年老有人问我能不能把 RSS 输出改成 UTF-8 的,很多 RSS 阅读器不支持 gbk ,这次终于改过来了。 事情源于昨天下午的一次脑抽,我把网站机器的操作系统升级了。上次升级还是十多年前,真的是太老旧了。结果升完级一看,php 被强制升到了 7 ,我自己写的一些 php 程序(主要是留言板)坏掉了。 这些个程序是我在 2004 年重构 2002 年的代码完成的;而 2002 年是从网上随便找来的代码基础上改的。我正儿八经学习 PHP 是在 1997 年,2000 年后就没怎么更新 PHP 的知识了。上次网站升级的时候,PHP 从 4 强制升到 5 ,就乱改了一通,勉强让程序可以运行(开了一些兼容模式)。这次再看代码,简直是惨不忍睹。所以我在本地装了个 PHP8 ,打开 PHP 官网,好好学习了一下手册。然后把代码取下来,重新建了个 git 仓库,正儿八经的改了一下。把留言的部分删了,只留下了浏览旧信息的部分,勉强让它继续跑起来。等什么时候有空了,再用 PHP 或 Lua 重新做一个。 Apache 的配置语法变了,一开始 PHP 跑不起来,折腾了一下配置文件就可以了。 最大的麻烦是 MySQL ,这次强制升到了 8 。之前好像是 4 版或更老的版本。我打开 blog 管理后台一看,全是乱码。心想坏了,编码出问题了。Blog 全是静态页面。只在修改时才从数据库读出内容生成一遍静态页面。所以外面看是正常的。我赶紧关掉了 mysql 服务器,以免(有人留言等修改行为)造成二次伤害。 Blog 是在 2005 年建的,数据采用的是 gbk 编码。其实那一年我已知道未来 UTF-8 一定是主流,但脑子里想的是手机流量费用 3 分钱 1 K 。选用 GBK 而不是 UTF 8 可以为自己和读者省钱。记得那年我和有道的负责人周枫闲聊汉字编码问题,他说 GBK 编码还是有意义的,他们当时爬虫爬来的中文数据储存就是用的 GBK ,这样可以节省 1/3 的储存成本。 其实,当年于我更好的方案应该是储存使用 utf-8 ,只在传输层用 GBK ,以后改起来也方便。可惜当年我自我折腾的能力远比不上现在,用了个别人开发的 blog 系统就懒得折腾了。在古旧得 Mysql 数据库中,是不储存文本编码类型的。基本上是你写什么数据编码就存什么。后来升级后,那些没有标注的编码字段就统一标注成了 latin1/latin1swedishci 。但实际我储存的是 gbk ,读出来自然就乱了。 一开始我觉得,这种问题肯定无数人解决过,google 一下就好。我把通讯编码改成 binary ,select 了几段文本,查看二进制表达,确认是 GBK 编码,数据没有(因为升级或后续操作)损坏。打包了一下数据库仓库目录,想着问题总能解决的吧。 我没有正儿八经的用 mysql 开发过,每次用到 mysql ,都是现学现卖。结果 google 了半天没找到解决方案,有点慌了。估计是像我这样跨越 10 年升级的用户太少了。在 mysql 官网上是这样写的: A special case occurs if you have old tables from before MySQL 4.1 where a nonbinary column contains values that actually are encoded in a character set different from the server's default character set. For example, an application might have stored sjis values in a column, even though MySQL's default character set was different. It is possible to convert the column to use the proper character set but an additional step is required. Suppose that the server's default character set was latin1 and col1 is defined as CHAR(50) but its contents are sjis values. The first step is to convert the column to a binary data type, which removes the existing character set information without performing any character conversion: ... The next step is to convert the column to a nonbinary data type with the proper character set: 简单说就是,先把文本标注成二进制格式,然后再转为你确定的编码。之后就可以正确转换到 UTF-8 了。 但我试了一下还是搞不定,只好在推特上求助。网友中数据库专家肯定比我这种临时抱佛脚翻手册的强多了。感谢热心网友提供了很多方案,甚至私信教我 mysql 。上面的方案我搞不定是因为有些字段做了索引。需要先扔掉索引,转码完了再重建。虽然有人教我,但我对自己能正确操作 mysql 还是没太大信心。就把仓库拖到本地,本地安装了一套 mysql8 做实验。 最后,结合网友的建议以及我自己的判断。我决定先以 binary 传输格式用 mysqldump 导出数据库(大约 500M),然后再用文本转换的方式替换其中的编码,最后再想办法导回。 这里导出命令行一定要加 --default-character-set=binary ,否则内码会被当成 latin 而且转换一次,数据是乱的。 一开始觉得挺简单的,查看了导出数据也很完成,不就是 iconv 转换一下么?实际操作发现 iconv 转换有很多错误。如果忽略掉错误,最后就无法导回数据库。我查了一下 dump 文件,发现数据库的数据中居然混杂着一些 utf8 字符串。iconv 无法正确处理这种混杂的编码。而且 mysql 会将部分字符转义,尤其是引号。如果编码转换中除了问题,就有可能吃掉某些引号等有关的格式文本,就变成了错误格式的文件。 所以全文文本替换是有巨大风险的。思来想去,我自己写了个 Lua 程序,最低限度的解析了 dump 文件的词法,只把 binary 字符串挑出来,并对转义符做好转义。将转换过的文本,用自己的代码判断它是 GBK 还是 UTF8 ,挑选出 GBK 交给 iconv 处理,而 UTF-8 则原封不动。最后再将字符串加回转义符,保证符合 mysql 语法。 最终找到了 680 条 UTF-8 文本。我猜测是当年有几天尝试过把 blog 数据转为 UTF-8 编码,又发现不太对劲所以换回来,中间产生的一些混杂编码。 对于转换好的数据,那些字段编码标准还是 latin ,所以用一个简单的文本替换成 utf-8 即可。 ps. 在本地 windows 上试验用 source 导入数据库时踩了个小坑。用反斜杠做路径会报错,必须用正斜杠绕开 mysql 的转义。 自此大功告成。 查看系统基本复原后,又连续升级了两个 LTS ,一直升级到 2024 LTS 版本。中间只碰到几个自己动过的软件配置文件问题。简单修一下即可。 估计又有十年可以不折腾它了。

2025/9/16
articleCard.readMore

立即模式下的鼠标交互处理

最近在做游戏时,发现在立即模式下鼠标的交互部分实现的比较混乱。 在做引擎时,我简单留出了鼠标相关事件的 callback 接口。一开始写游戏时,也就是对付一下写了几行代码,大致可以工作。做了大半个月后,随着交互界面越来越复杂,那些应付用的代码明显不堪重负。有越来越多的边界情况无法正确处理。等到最近想在交互上加一种长按鼠标确认的操作,发现不能再这样对付下去了,就花了一晚上重构了所有和鼠标交互相关的代码。 之前的问题出在哪里? 如果从系统的鼠标消息出发,我们可以从引擎获得鼠标移动、按下、抬起等事件。或许还可以利用系统发送来的点击、双击等等复合事件,但我选择自己用按下和抬起来判断这些。但是,消息机制本身和立即模式是相悖的。采用立即模式编写游戏业务以及交互,获得当下的状态是最自然的,而“消息”不是状态。它是一个队列:在每个游戏帧中,可能没有消息,也可能有多条消息。如果只是处理鼠标的位置和按键状态,那么保留最后一个状态也可以;但是,像点击这种行为,明显不是瞬间的状态,而是过去一段时间的状态叠加后的事件。 除了“点击”,必须处理的还有“焦点”,或叫“悬停”。一个交互元素获得焦点、失去焦点都不是瞬间状态,它们取决于鼠标过去的位置、鼠标位置下交互元素在屏幕上的位置。即使鼠标不移动,但交互元素在屏幕上动了,或消失了、出现了,都可能引起“焦点”的改变。 所以在立即模式下,最好我们可以将点击和焦点这样的“事件”变成某种“状态”,然后统一用立即模式处理。否则混用立即模式的状态判断和消息队列轮询就会比较混乱。 首先,我们应该把系统传来的鼠标消息在帧间累积起来,然后在每个游戏帧发送出去,而不应该在消息抵达的时候立即处理。这样做可以让游戏代码严格的按帧执行,帧间不会触发任何额外的 callback 。所以,在立即模式下,底层传来的不是鼠标移动消息,而是每帧鼠标的位置。即使没有更新位置,也同样会刷新一次鼠标位置信息。如果两帧之间有多个鼠标移动消息,位置当然只需要记录最后一次,游戏可以忽略中间的轨迹(除非以后要做鼠标手势,那再来改进)。 但鼠标按键则不可只保留多个按压抬起事件的最后一个。比如之前如果鼠标处于按下状态、而在两帧之间鼠标按键抬起又按下,如果只取最后的按键状态,就没有改变(都是按下状态),但操作者实际点击了一次鼠标。这个点击操作就被忽略掉了,这是不行的。 那应该怎么处理?首先,鼠标按键的状态和点击应该分离。如果游戏需要查询鼠标按键是抬起还是按下,那么和鼠标位置一样,每帧逻辑都会被推送这些状态信息。但鼠标的点击行为,应该是另一种独立状态:在鼠标的按键按下时,底层应该记录这个时刻的帧序号,并不立即通知游戏。而当鼠标抬起时,就改变了“鼠标点击”的状态。这个鼠标点击的状态为空时,表示点击并未发生,不为空时,状态值是点击的时长:即按下到抬起的帧数。 对于前面举例的情况,如果在帧间依次发生了抬起和按下,“鼠标点击”状态也会从空转换为这次点击的时长。同时底层会重置按下时刻,等待下一次抬起后再改变状态。在极端情况下,如果两帧之间连续发生了非常多次按下和抬起,我情况于只记录第一次的“鼠标点击”时长。除非以后要支持“双击”,那也是另一种手势,需要额外实现了。“鼠标点击”这个状态只会存在一帧,无论这一帧游戏代码有没有检查使用这个状态,该状态都会重置为空。 其次,我们需要一个焦点管理器。鼠标焦点永远只能在一个对象上。立即模式的交互层可以和立即模式的渲染层一样,每帧遍历所有的对象,渲染层将可渲染对象按层次和次序提交给底层;交互层则是按层次和次序依次判断每个对象是否获得了焦点。交互层和渲染层都和对象的屏幕空间位置有关,所以两者其实可以做到一起;当然也可以分开,因为未必所有的对象都同时需要渲染和鼠标交互。 对于焦点管理器,它可以每帧简单的把当前焦点对象以一个状态量提供。因为查询是哪个对象获得了焦点需要遍历一次所有对象,这在渲染时就会做一遍,所以一般我们可以将上一帧的焦点传给当前帧,交互在视觉上差一帧问题不是很大。 和查询当前鼠标按键状态一样,游戏逻辑可以查询当前的焦点是谁。但它和“鼠标点击”结合起来使用就不太方便。所谓鼠标点击,通常指鼠标按下的那一刻,鼠标焦点在一个对象上,而抬起时鼠标焦点还在同一个对象上,才能视为点击了这个对象。简单用鼠标抬起那一刻鼠标焦点的对象不太符合一般的使用习惯。所以,我们可以把“焦点”这个状态加上当前焦点对象获得焦点持续的帧数。这样,想知道“鼠标点击”发生时,是否真的点击了当前焦点对象,只需要比较两个时长即可:“鼠标点击”的时长不能大于“焦点”的持续时长。 有了以上这个基础,我们在编写游戏时就可以方便的以立即模式处理每帧的业务:获得当前帧鼠标的位置、按键状态、鼠标每个按键点击的状态(为空或一个时长)、当前鼠标焦点的状态(焦点对象及焦点持续时长)…… 在这个基础上,还可以再做一些封装。因为某些模块从效率考虑并不适合每帧都刷新状态。比如交互界面,只有在焦点状态发生改变时,它的属性才会改变:按钮的视觉效果、屏幕提示文字、等等。这些属性改变的成本比较高,不适合每帧都重置。我们可以把每帧的鼠标焦点再记录下来,只有焦点发生改变时,才做额外处理。这个记录焦点状态变化的东西可以放在栈上的临时结构。立即模式比较适合以自然方式书写业务。

2025/9/9
articleCard.readMore

在 Lua 中定义类型的简单方法

我通常用 Lua 定义一个类型只需要这样做: 这样写足够简单,如果写熟了就不用额外再做封装。如果一定要做一点封装,可以这样: 封装的意义在于:你可以通过上面这个 class 模块定义新的类型,且能通过它用类型名找到所有定义的新类型。而上面的第一版通常用于放在独立模块文件中,依赖 lua 的模块机制找到 new_object 这个构建方法。 而封装后可以这样用: 如果觉得 local object = class.object 的写法容易产生歧义,也可以加一点小技巧(同时提供特殊的代码文本模式,方便日后搜索代码): 如果我们要定义的类型是一个容器该怎么做好? 容器的数据结构有两个部分:容纳数据的集合和容器的元数据。之前,我通常把元数据直接放在对象实例中,把集合对象看作元数据中的一个。 比如定义一个集合类型 set 以及两个方法 get 和 set : 真正集合容器在 self.container 里,这里 self.n 是集合的元信息,即集合元素的个数。注意这里集合类型需要有一个构造函数 new ,因为它在构造实例时必须初始化 .n 和 .container 。这里的 set:new 构造函数调用了前面生成的 class.set 这个默认构造行为。 测试一下:注意这里用 class.set:new() 调用了构造函数。它等价于 class.set { container = {}, n = 0 } ,因为 .container 和 .n 属于实现细节,所以不推荐使用。 如果使用者要直接访问容器的内部数据结构,它可以用 obj.container 找到引用。但我们可能希望 set 表现得更像 lua table 一样,所以也可能想这样实现: 这个版本去掉了 .container 而直接把数据放在 self 里。所以不再需要 get 方法。为了让元数据 n 区分开,所以改为了 ._n 。 如果规范了命名规则,用下划线区分元数据未尝不是一个好的方法,但在迭代容器的时候会需要剔除它们比较麻烦。所以有时候我们会把元数据外置,这里就需要用到 lua 5.2 引入的 ephemeron table 来帮助 gc 。 由于 ._n 外部不可见,所以我们用 #obj 来获取它。 如果不想用 ephemeron table 管理元数据,是否有什么简单的方法剔除元数据呢? 最近发现另一个小技巧,那就是使用 false 作为元数据的 key : 这个版本几乎和第二版相同,不同的地方只是在于把 ["_n"] 换成了 [false] 。这里只有一个元数据,如果有多个,可以把 [false] = {} 设为一张表。 这样就不需要额外使用弱表,在迭代时也只需要判断 key 是否为真来剔除它。虽然有这么一点点局限,但贵在足够简单。 当然你也可以给它再定义一个 __pairs 方法滤掉 false : 或者给加一种叫 class.container 的类型创建方法 如果你不需要 class 提供的默认构造函数,同时不喜欢定义一个新的 new 方法,也可以直接覆盖默认构造函数(同时避免别处再给它增加新的方法): local set5 = class.container "set5" function set5:set(key, value) if value == nil then if self[key] ~= nil then self[key] = nil self[false] = self[false] - 1 end else if self[key] == nil then self[false] = self[false] + 1 end self[key] = value end end function set5:__len() return self[false] end function class.set5() return set5 { [false] = 0, } end local obj = class.set5() obj:set("x", 1) obj:set("y", 2) for k,v in pairs(obj) do print(k,v) end

2025/8/26
articleCard.readMore

编写游戏程序的一些启示

这个月我开了个新项目:制作 deep future 的电子版。 之所以做这个事情,是因为我真的很喜欢这个游戏。而过去一年我在构思一个独立游戏的玩法时好像进入了死胡同,我需要一些设计灵感,又需要写点代码保持一下开发状态。思来想去,我确定制作一个成熟桌游的电子版是一个不错的练习。而且这个游戏的单人玩法很接近电子游戏中的 4x 类型,那也是我喜欢的,等还原了原版桌游规则后,我应该可以以此为基础创造一些适合电子游戏特性的东西来。 另一方面,我自以为了解游戏软件从屏幕上每个像素点到最终游戏的技术原理,大部分的过程都亲身实践过。但我总感觉上层的东西,尤其是游戏玩法、交互等部分开发起来没有底层(尤其是引擎部分)顺畅。我也看到很多实际游戏项目的开发周期远大于预期,似乎开发时间被投进了黑洞。 在 GameJam 上两个晚上可以做出的游戏原型,往往又需要花掉 2,3 年时间磨练成成品。我想弄清楚到底遇到了怎样的困难,那些不明不白消耗掉的开发时间到底去了哪里。 这次我选择使用前几个月开发的 soluna 作为引擎。不使用前些年开发的 Ant Engine 的原因 在这个帖子里写得很清楚了。至于为什么不用现成的 unreal/unity/godot 等,原因是: 我明白我要做什么事,该怎么做,并不需要在黑盒引擎的基础上开发。是的,虽然很多流行引擎有源码,但在没有彻底阅读之前,我认为它们对我的大脑还是黑盒。而阅读理解这些引擎代码工程巨大。 我的项目不赶时间,可以慢慢来。我享受开发过程,希望通过开发明白多一些道理,而不是要一个结果。我希望找到答案,可能可以通过使用成熟引擎,了解它们是怎样设计的来获得;但自己做一次会更接近。 自己从更底层开发可以快速迭代:如果一个设计模式不合适,可以修改引擎尝试另一个模式。而不是去追寻某个通用引擎的最佳实践。 我会使用很多成熟的开源模块和方案。但通常都是我已经做过类似的工作,期望可以和那些成熟模块的作者/社区共建。 这个项目几乎没有性能压力。我可以更有弹性的尝试不同的玩法。成熟引擎通常为了提升某些方面的性能,花去大量的资源做优化,并做了许多妥协。这些工作几乎是不可见的。也就是说,如果使用成熟引擎开发,能利用到的部分只是九牛一毛,反而需要花大量精力去学习如何用好它们;而针对具体需求自己开发,花掉的精力反而更有限,执行过程也更为有趣。 这篇 blog 主要想记录一下这大半个月以来,我是怎样迭代引擎和游戏的。我不想讨论下面列举出来的需求的最佳方案,现在已经完成的代码肯定不是,之后大概率也会再迭代掉。我这个月的代码中一直存在这样那样的“临时方案”、“全局状态”、甚至一些复制粘贴。它们可能在下一周就重构掉,也可能到游戏成型也放在那里。 重要的是过程应该被记录下来。 在一开始,我认为以立即模式编写游戏最容易,它最符合人的直觉:即游戏是由一帧帧画面构成的,只需要组帧绘制需要的画面就可以了。立即模式可以减少状态管理的复杂度。这一帧绘制一个精灵,它就出现在屏幕上;不绘制就消失了。 大部分成熟引擎提供的则是保留模式:引擎维护着一组对象集合,使用者创建或删除对象,修改这些对象的视觉属性。这意味着开发者需要做额外的很多状态管理。如果引擎维持的对象集合并非平坦结构,而是树状容器结构,这些状态管理就更复杂了。 之所以引擎喜欢提供保留模式大概是因为这样可以让实现更高效。而且在上层通过恰当的封装,立即模式和保留模式之间也是可以互相转换的。所以开发者并不介意这点:爱用立即模式开发游戏的人做一个浅封装层就可以了。 但我一开始就选择立即模式、又不需要考虑性能的话,一个只对图形 api 做浅封装的引擎直接提供立即模式最为简单。所以一开始,soluna 只提供了把一张图片和一个单独文字显示在屏幕特定位置的 api 。当然,使用现代图形 api ,给绘制指令加上 SRT 变换是举手之劳。(在 30 年前,只有一个 framebuffer 的年代,我还需要用汇编编写大量关于旋转缩放的代码) 在第一天,我从网上找来了几张卡牌的图片,只花了 10 分钟就做好了带动画和非常简单交互的 demo 。看起来还很丝滑,这给我不错的愉悦感,我觉得是个好的开始。 想想小丑牌也是用 Love2D 这种只提供基本 2d 图片渲染 api 的引擎编写出来的,想来这些也够用了。当然,据说小丑牌做了三年。除去游戏设计方面的迭代时间外,想想程序部分怎么也不需要这么长时间,除非里面有某些我察觉不到的困难。 接下来,我考虑搭一些简单的交互界面以及绘制正式的卡牌。 Deep future 的卡牌和一般的卡牌游戏还不一样。它没有什么图形元素,但牌面有很多文字版面设计。固然,我可以在制图设计软件里定下这些版面的位置,然后找个美术帮我填上,如果我的团队有美术的话……这是过去在商业公司的常规做法吧?可是现在我一个人,没有团队。这是一件好事,可以让我重新思考这个任务:我需要减少这件我不擅长的事情的难度。我肯定会大量修改牌面的设计,我得有合适我自己的工作流。 在 Ant 中,我们曾经集成过 RmlUI :它可以用 css 设计界面。css 做排版倒是不错,虽然我也不那么熟悉,但似乎可以完成所有需求。但我不喜欢写 xml ,也不喜欢 css 的语法,以及很多我用不到的东西。所以,我决定保留核心:我需要一个成熟的排版用的结构化描述方案,但不需要它的外表。 所以我集成了 Yoga ,使用 Lua 和我自己设计的 datalist 语言来描述这个版面设计。如果有一天,我想把这个方案推广给其他人用,它的内在结构和 css 是一致的,写一个转换脚本也非常容易。 暂时我并不需要和 Windows 桌面一样复杂的界面功能。大致上有单个固定的界面元素布局作为 HUD (也就是主界面)就够了。当然,用 flexbox 的结构来写,自动适应了不同的分辨率。采用这种类 CSS 的排版方案,实际上又回到了保留模式:在系统中保留一系列的需要排版布局的对象。 当我反思这个问题时,我认为是这样的:如果一个整体大体是不变的,那么把这个整体看作黑盒,其状态管理被封装在内部。使用复杂度并没有提高。这里的整体就是 HUD 。考虑到游戏中分为固定的界面元素和若干可交互的卡片对象,作为卡牌游戏,那些卡牌放在 HUD 中的容器内的。如果还是用同样的方案管理卡片的细节,甚至卡片本身的构图(它也是由更细分的元素构成的)。以保留模式整个管理就又变复杂了。 所以,我在 yoga 的 api 封装层上又做了一层封装。把界面元素分为两类:不变的图片和文字部分,和需要和玩家交互的容器。容器只是由 yoga 排版的一个区域,它用 callback 的形式和开发者互动就可以了。yoga 库做的事情是:按层次结构遍历处理完整个 DOM ,把所有元素平坦成一个序列,每个元素都还原成绝对坐标和尺寸,去掉层次信息,只按序列次序保留绘制的上下层关系。在这个序列中,固定的图片和文字可以直接绘制,而遇到互动区,则调用用户提供的函数。这些函数还是以立即模式使用:每帧都调用图形 API 渲染任意内容。 用下来还是挺舒服的。虽然 callback 的形式我觉得有点芥蒂,但在没找到更好的方式前先这么用着,似乎也没踩到什么坑。 渲染模块中,一开始只提供了文字和图片的渲染。但我留出了扩展材质的余地。文字本身就是一种扩展材质,而图片是默认的基础材质。做到 UI 时,我发现增加一种新的材质“单色矩形”特别有用。 因为我可以在提供给 yoga 的布局数据中对一些 box 标注,让它们呈现出不同颜色。这可以极大的方便我调试布局。尤其是我对 flexbox 布局还不太熟练的阶段,比脑补布局结果好用得多。 另一个有用的材质是对一张图片进行单色渲染,即只保留图片的 alpha 通道,而使用单一颜色。这种 mask 可以用来生成精灵的阴影,也可以对不规则图片做简单遮罩。 在扩展材质的过程中,发现了之前预留的多材质结构有一些考虑不周全的设计,一并做了修改。 到绘制卡牌时,卡牌本身也有一个 DOM ,它本质上和 HUD 的数据结构没什么区别,所以这个数据结构还是嵌套了。一开始,我在 soluna 里只提供了平坦的绘制 api ,并没有层次管理。一开始我做的假设是:这样应该够用。显然需要打破这个假设了。 我给出的解决方案是:在立即模式下,没必要提供场景树管理,但可以给一个分层堆栈。比如将当前的图层做 SRT 变换,随后的绘图指令都会应用这套变换,直到关闭这个图层(弹出堆栈)。这样,我想移动甚至旋转缩放 HUD 中的一个区域,对于这个区域的绘制指令序列来说都是透明的:只需要在开始打开一个新图层,结束时关闭这个图层即可。 另一个需求是图文混排,和文字排版。一开始我假设引擎只提供单一文字渲染的功能就够用,显然是不成立的。Yoga 也只提供 box 的排版,如果把每个单字都作为一个 box 送去 yoga 也不是不行,但直觉告诉我这不但低效,还会增加使用负担。web 上也不是针对每个单字做排版的。用 Lua 在上层做图片和文字排版也可以,但对性能来说太奢侈了。 这是一个非常固定的需求:把一块有不同颜色和尺寸的文字放在一个 box 中排版,中间会插入少许图片。过去我也设计过不少富文本描述方案,再做一次也不难。这次我选择一半在 C 中实现,一半在 Lua 中实现。C 中的数据结构利于程序解析,但书写起来略微繁琐;Lua 部分承担易于人书写的格式到底层富文本结构的转换。Lua 部分并不需要高频运行,可以很方便的 cache 结果(这是 Lua 所擅长的),所以性能不是问题。 至于插入的少许图片,我认为把图片转换为类似表情字体更简单。我顺手在底层增加了对应的支持:用户可以把图片在运行时导入字体模块。这些图片作为单独的字体存在,codepoint 可以和 unicode 重叠。并不需要以 unicode 在文本串中编码这些图片,而将编码方式加入上述富文本的结构。 在绘制文本的环节,我同时想到了本地化模块该如何设计。这并非对需求的未雨绸缪,而是我这些年来一直在维护群星的汉化 mod 。非常青睐 Paradox 的文本方案。这不仅仅是本地化问题,还涉及游戏中的文本如何拼接。尤其是卡牌游戏,关于规则描述的句子并非 RPG 中那样的整句,而是有很多子句根据上下文拼接而来的。 拼句子和本地化其实是同一个问题:不同语言间的语法不同,会导致加入一些上下文的句子结构不同。P 社在这方面下了不少功夫,也经过了多年的迭代。我一直想做一套类似的系统,想必很有意思。这次了了心愿。 我认为代码中不应该直接编码任何会显示出来的文本,而应该统一使用点分割的 ascii 字串。这些字串在本地化模块那里做第一次查表转换。 有很大一部分句子是由子句构成的,因为分成子句和更细分的语素可以大大降低翻译成不同语言的工作量。这和代码中避免复制粘贴的道理是一样的:如果游戏中有一个术语出现在不同语境下,这个术语在本地化文本中只出现在唯一地方肯定最好。所以,对于文本来说,肯定是大量的交叉引用。我使用 $(key.sub.foobar) 的方式来描述这种交叉引用。注:这相当于 P 社语法中的 $key.sub.foobar$ 。我对这种分不清开闭的括号很不感冒。 另一种是对运行环境中输入的文本的引用:例如对象的名字、属性等。我使用了 ${key} 这样的语法,大致相当于 P 社的 [key] 。但我觉得统一使用 $ 前缀更好。至于图标颜色、字体等标注,在 P 社的语法中花样百出,我另可使用一致的语法:用 [] 转义。 这个文本拼接转换的模块迭代了好几次。因为我在使用中总能发现不完善的实现。估计后面还会再改动。好在有前人的经验,应该可以少走不少弯路吧。 和严肃的应用不同,游戏的交互是很活泼的。一开始我并没有打算实现元素的动画表现,因为先实现功能仿佛更重要。但做着做着,如果让画面更活泼一点似乎心情更愉悦一点。 比如发牌。当然可以直接把发好的牌画在屏幕指定区域。但我更希望有一个动态的发牌过程。这不仅仅是视觉感受,更能帮助不熟悉游戏规则的玩家尽快掌控卡牌的流向。对于 Deep Future 来说更是如此:有些牌摸出来是用来产生随机数的、有些看一眼就扔掉了、不同的牌会打在桌面不同的地方。如果缺少运动过程的表现,玩家熟悉玩法的门槛会高出不少。 但在游戏程序实现的逻辑和表现分离,我认为是一个更高原则,应尽可能遵守。这部分需要一点设计才好。为此,我并没有草率给出方案尽快试错,而是想了两天。当然,目前也不是确定方案,依旧在迭代。 css 中提供了一些关于动画的属性,我并没有照搬采用。暂时我只需要的运动轨迹,固然轨迹是对坐标这个属性的抽象,但一开始没必要做高层次的抽象。另外,我还需要保留对对象的直接控制,也就是围绕立即模式设计。所以我并没有太着急实现动画模块,而且结合另一个问题一起考虑。 游戏程序通常是一个状态机。尤其是规则复杂的卡牌游戏更是。在不同阶段,游戏中的对象遵循不同的规则互动。从上层游戏规则来看是一个状态机,从底层的动画表现来看也是,人机交互的界面部分亦然。 从教科书上搬出状态机的数据结构,来看怎么匹配这里的需求,容易走向歧途;所以我觉得应该先从基本需求入手,不去理会状态机的数据结构,先搭建一个可用的模块,再来改进。 Lua 有 first class 的 coroutine ,非常适合干这个:每个游戏状态是一个过程(相对一帧画面),有过程就有过程本身的上下文,天然适合用 coroutine 表示。而底层是基于帧的,显然就适合和游戏的过程分离开。 以发牌为例:在玩家行动阶段,需要从抽牌堆发 5 张牌到手牌中。最直接的做法是在逻辑上从牌堆取出 5 张牌,然后显示在手牌区。 我需要一个发牌的视觉表现,卡牌从抽牌堆移动到手牌区,让玩家明白这些牌是从哪里来的。同时玩家也可以自然注意到在主操作区(手牌区)之外还有一个可供交互的牌堆。 用立即模式驱动这个运动轨迹,对于单张牌来说最为简单。每帧计算牌的坐标,然后绘制它就可以了。但同时发多张牌就没那么直接了。 要么一开始就同时记录五张牌的目的地,每帧计算这五张牌的位置。这样其实是把五张牌视为整体;要么等第一张牌运动到位,然后开始发下一张牌。这样虽然比较符合现实,但作为电子游戏玩,交互又太啰嗦。 通常我们要的行为是:这五张牌连续发出,但又不是同时(同一帧)。牌的运动过程中,并非需要逐帧关注轨迹,而只需要关注开始、中途、抵达目的地三个状态。其轨迹可以一开始就确定。所以,卡牌的运动过程其实处于保留模式中,状态由系统保持(无需上层干涉),而启动的时机则交由开发者精确控制更好。至于中间状态及抵达目的地的时机,在这种对性能没太大要求的场景,以立即模式逐帧轮询应无大碍(必须采用 callback 模式)。 也就是,直观的书写回合开始的发牌流程是这样的: 这段代码作为状态机逻辑的一部分天然适合放在单独的 coroutine 中。它可以和底层的界面交互以及图形渲染和并行处理。 而发牌过程,则应该是由三个步骤构成:1. 把牌设置于出发区域。2. 设定目的地,发起移动请求。3. 轮询牌是否运动到位,到位后将牌设置到目的地区域。 其中步骤 1,2 在 draw_card 函数中完成最为直观,因为它们会在同一帧完成。而步骤 3 的轮询应该放在上述循环的后续代码。采用轮询可以避免回调模式带来的难以管理的状态:同样符合直观感受,玩家需要等牌都发好了(通常在半秒之内)再做后续操作。 我以这样的模式开发了一个基于 coroutine 的简单状态机模块。用了几天觉得还挺舒适。只不过发现还是有一点点过度设计。一开始我预留了一些 api 供使用者临时切出当前状态,进入一个子状态(另一个 coroutine),完成后再返回;还有从一个过程中途跳出,不再返回等等。使用一段时间以后,发现这些功能是多余的。后续又简化掉一半。 至于动画模块,起初我认为一切都围绕卡牌来做就可以了。可以运动的基本元素就是不同的卡片。后来发现其实我还需要一些不同于卡片的对象。运动也不仅仅是位移,还包括旋转和缩放,以及颜色的渐变。 至于对象运动的起点和终点,都是针对的前面所述的“区域”这个概念。一开始“区域”只是一个回调函数;从这里开始它被重构成一个对象,有名字和更多的方法。“区域”也不再属于同一个界面对象,下面会谈到:我一开始的假设,所有界面元素在唯一 DOM 上,感觉是不够用的。我最终还是需要管理不同的 DOM ,但我依旧需要区域这个概念可以平坦化,这样可以简化对象可以在不同的 DOM 间运动的 API。 运动过程本身,藏在较低的层次。它是一个独立模块,本质上是以保留模式管理的。在运动管理模块中,保留的状态仅仅是时间轴。也就是逐帧驱动每个运动对象的时间轴(一个数字)。逐帧处理部分还是立即模式的,传入对象的起点和终点,通过时间进度立即计算出当前的状态,并渲染出来。 从状态管理的角度看,每帧的画面和动画管理其实并不是难题。和输入相关的交互管理更难一些,尤其是鼠标操作。对于键盘或手柄,可以使用比较直观的方式处理:每帧检查当下的输入内容和输入状态,根据它们做出反应即可。而鼠标操作天生就是事件驱动的,直到鼠标移动到特定位置,这个位置关联到一个可交互对象,鼠标的点击等操作才有了特别的含义。 ImGUI 用了一种立即模式的直观写法解决这个问题。从使用者角度看,它每帧轮询了所有可交互对象,在绘制这些对象的同时,也依次检查了这些对象是否有交互事件。我比较青睐这样的用法,但依然需要做一些改变。毕竟 ImGUI 模式不关注界面的外观布局,也不擅长处理运动的元素。 我单独实现了一个焦点管理模块。它内部以保留模式驱动界面模块的焦点响应。和渲染部分一样,处理焦点的 API 也使用了一些 callback 注入。这个模块仅管理哪个区域接收到了鼠标焦点,每个区域通过 callback 函数再以立即模式(轮询的方式)查询焦点落在区域内部的哪个对象上。 在使用层面,开发者依然用立即模式,通过轮询获取当前的鼠标焦点再哪个区域哪个对象上;并可查询当前帧在焦点对象上是否发生了交互事件(通常是点击)。这可以避免用 callback 方式接收交互事件,对于复杂的状态机,事件的 callback 要难管理的多。 一开始我认为,单一 HUD 控制所有界面元素就够了。只需要通过隐藏部分暂时不用的界面元素就可以实现不同游戏状态下不同的功能。在这个约束条件下,代码可以实现的非常简单。但这几天发现不太够用。比如,我希望用鼠标右键点击任何一处界面元素,都会对它的功能做一番解说。这个解说界面明显是可以和主界面分离的。我也有很大意愿把两块隔离开,可以分别独立开发测试。解说界面是帮助玩家理解游戏规则和交互的,和游戏的主流程关系不大。把它和游戏主流程放在一起增加了整体的管理难度。但分离又有悖于我希望尽可能将对象管理平坦化的初衷,我并不希望引入树状的对象层次结构。 最近的设计灵感和前面绘制模块的图层设计类似,我给界面也加入了图层的概念。永远只有一个操作层,但层次之间用栈管理。在每个状态看到的当下,界面的 DOM 都是唯一的。状态切换时则可以将界面压栈和出栈。如果后续不出现像桌面操作系统那样复杂的多窗口结构的话,我想这种栈结构分层的界面模式还可以继续用下去。 另一个变动是关于“区域”。之前我认为需要参与交互的界面元素仅有“区域”,“区域”以立即模式自理,逐帧渲染自身、轮询焦点状态处理焦点事件。最近发现,额外提供一种叫“按钮”的对象会更方便一些。“按钮”固然可以通过“区域”来实现,但实践中,处理“按钮”的不是“按钮”本身,而是容纳“按钮”的容器,通常也是最外层的游戏过程。给“按钮”加上类似 onclick 的 callback 是很不直观的;更直观的做法是在游戏过程中,根据对应的上下文,检查是否有关心的按钮被点击。 所有的按钮的交互管理可以放在一个平坦的集合中,给它们起上名字。查询时用 buttons.click() == "我关心的按钮名字" 做查询条件,比用 button_object.click() 做查询条件要舒服一点。 以上便是最近一个月的部分开发记录。虽然,代码依旧在不断修改,方案也无法确定,下个月可能还会推翻目前的想法。但我感觉找到了让自己舒适的节奏。 不需要太着急去尽快试错。每天动手之前多想想,少做一点,可以节省很多实作耗掉的精力;也不要过于执著于先想清楚再动手,毕竟把代码敲出带来的情绪价值也很大。虽然知道流畅的画面背后有不少草率的实现决定,但离可以玩的游戏更进一步的心理感受还是很愉悦的。 日拱一卒,功不唐捐。

2025/8/23
articleCard.readMore

SetWindowText 引起的死锁

最近发现我在写的小游戏在启动时有很小的概率黑屏。我使用的是 ltask 多线程框架,在黑屏时感觉 ltask 并没有停止工作,似乎只是管理窗口的部分(线程/服务)卡死了。 窗口管理使用的是 sokol_app 做的多平台封装,这只是一个很浅的封装层,但已经够用。我觉得美中不足的是,sokol_app 的 frame 回调函数是放在 WinProc 中,由 Windows 的消息循环被动调度,而不是放在外层的主动 GetMessage 循环中。 即,在 Windows 程序中,线程通常会在最外面写一个这样的 while 循环: 但我们也可以选择在窗口的 WinProc 中,通过响应 WM_TIMER 等消息的方式来做这些工作: 无可厚非,后一种方法显得更正规一点:让 Windows 自身调度所有任务,系统如果做的正确,和系统的窗口系统本身契合的更好一点。这个模式是 Window 的历史设计造成的。把窗口系统的工作流程放在用户线程内,用户的程序其它部分配合它,换取交互的流畅度。 但是,一旦采用多线程设计,就变得有点不同了。窗口只是多线程任务的一部分,需要一个更高阶的框架来调度任务,例如 ltask 干的那些。通过在 WinProc 中处理对应消息,在没有消息进入的时候,线程会堵塞在 GetMessage 函数中。这对 ltask 这样的调度器来说非常的不友好。通常一个任务调度器需要的行为是:每个任务要么完成,要么让出,而不是阻塞。Windows 的 GetMessage/DispatchMessage 也是这样的循环,只不过是单线程的。 ltask 处理这样的模块,也不是完全没有办法。这得益于 ltask 的任务都运行在 lua 虚拟机上,和 C 层有一定的隔离。对于 C 代码来说,stack 是绑定在线程上的,所以无法在一个线程运行一半,然后在另一个线程继续工作(因为 stack 不同);但 Lua 的 stack 在 heap 上,迁移完全没有问题。 我曾经做过类似的尝试 ,但最终又从 ltask 主干上撤销了这个特性。倒不是实现的不对,而是配合它使用的 C 代码如果重入问题解决不好,隐藏的 bug 很难发现。这需要 C 部分最好在设计时就考虑过并行/重入问题。sokol 显然不是这样设计的。 为了让 sokol 可以在 ltask 下工作,我做了不少工作。sokol_gfx 的图形 api 部分倒是简单,我只需要保证在同一个服务中调用就可以了;比较麻烦的是 sokol_app 中处理窗口的部分。直接让 frame 回调函数运行在 ltask 的一个服务中非常困难。原因上面已述:这个回调函数结束后线程会挂起在 Windows 的消息处理循环中,而没有将控制权归还 ltask 。虽然可以通过 ltask 那个实验特性解决这个问题,但 sokol 并没有为多线程设计,很可能隐藏多线程 bug ,一旦出现难以调试。 我试过几个方案后,最终采用了最简单粗暴的方法:利用锁来同步任务。也就是在 frame callback 开始时抛出一个消息,并阻塞在一个锁上。这个消息会开启另一个 ltask 掌握的线程中对应的 render 服务;而在 render 服务渲染完当前帧,解开这个锁,frame callback 就会顺利返回。 在绝大多数场景中,这个方案工作的很好。但我最近偶尔发现在启动程序时,会有很小的概率,锁并没有解开。 一开始我并不为意,觉得或许是一些同步代码没有写好,因为有更想做的特性要开发,这种偶发死锁 bug 出现概率很低,且只出现在启动阶段,想着有空稍微复查一下启动代码就能解决。 这两天感觉的确“有空”了,花了一晚上,终于定位了问题。 问题出在游戏启动阶段改变窗口的标题上。固然,可以在窗口创建时就把标题设置好。但标题需要根据多语言环境设置不同的文本,处理多语言文本的这块逻辑不算简单,我不想放在启动的最初阶段(创建窗口之前),所以窗口创建时使用了一段默认文本,之后才修改它。 sokol_app 的 api 只是间接调用了 SetWindowTextW() 。显然不是 sokol_app 的封装问题。我查阅了 msdn ,发现 SetWindowTextW 只是给 WinProc 发送了一个 WM_SETTEXT 消息。也就是说,等价于调用 SendMessageW() 。 如果在 WinProc 所在线程中调用它当然没有问题,只是引起了 WinProc 重入:调用方在 frame callback 内,而 frame callback 处于 WinProc 的 WM_TIMER 的消息处理环节。这时调用 SetWindowTextW 等于递归再运行一次 WinProc 本身,但消息变成了 WM_SETTEXT ,新的调用返回后窗口的标题栏就被改变了。 可是,我现在在另外一个线程调用 SetWindowTextW 行为有所不同。这时 WM_SETTEXT 被投递到窗口消息处理线程,它需要排队等待 WinProc 再次被处理,也就是外层循环的下一次 DispatchMessage 调用。但是,这个时候当下的 DispatchMessage 还阻塞在 frame callback 的锁上面无法返回。这就是死锁产生的原因: DispatchMessage 调用 WinProc 处理 WM_TIMER 消息,它调用了 sokol 的 frame callback 。我的程序在 frame callback 中发出消息唤醒真正的处理流程,并等待在锁上。 真正的处理流程运行在另外线程,它调用了 SetWindowTextW ,其通过 SendMessageW 投递 WM_SETTEXT 到窗口线程的消息队列,等待返回。 窗口线程需要等当前的 WM_TIMER 处理完毕才 DispatchMessage 才可以结束,后续的 GetMessage 才可以拿到 WM_SETTEXT 消息处理它。 了解了死锁的原因后,最直接的解决方案是在窗口线程调用 SetWindowTextW 。因为这样会直接运行设置文本的逻辑,消息不需要进入消息队列,当然就没有锁的问题。但这个方案不适合现在的 ltask 框架。目前窗口线程不在 ltask 的管辖之下,也就无法在 lua 服务中调用 SetWindowTextW ,也无法直接通过 ltask 内部的消息把这个任务传递过去。 比如容易想到的是:“改变窗口标题”这个行为并不需要等待结果。那么是不是可以改用 PostWindowTextW 发送 WM_SETTEXT 就可以不阻塞调用方了呢? 答案是不行,原因在这里有解释 。因为这条消息发送了一个字符串,这里存在这个字符串生命期管理的问题,为了减少使用错误,Windows 禁止用 PostMessage 发送这样有生命期管理问题的系统消息。只有 SendMessage 可以在结果返回后正确释放消息文本所占用的内存。 所以,我们可以用独立线程通过 SendMessage 投递这个消息,并等待其返回后做完后续(生命期管理)工作。在 C 中创建新线程非常麻烦,但在 ltask 中却非常容易。只需要用一个独立的服务调用 SetWindowTextW 就够了。frame 的处理流程所在的服务/线程向它投递一个 ltask 消息,通知这个独立服务改变窗口标题,就不会阻塞 frame 流程。

2025/8/9
articleCard.readMore

慢跑

我这两年攀岩时总是体力不够用,出去野攀如果需要先爬山接近的话,往往爬到岩壁下就累个半死不想动了。而我那帮 50 多岁的岩友一个个都比我有活力的多。所以我想通过有氧运动改善一下心肺功能。岩友建议我试试慢跑。 去年底痛风发作 后也考虑过减少一些体重,据说有利于降低尿酸。但有点懒就一直没有开始跑。 我的身体状态是这样的: 目前身高 187 ,大学毕业时大约 183 ,后来 20 多年陆续又长了几厘米。大学刚毕业时体重只有 71 kg ,非常瘦。在 2002 年左右开始去健身房撸铁增肌,最高长到过 78kg 。后来去杭州没那么勤快了,又掉下来不少。到 2011 年回到广州时只剩下 74kg 不到。当时身高 185 - 186 之间,后来这 15 年又长了点身高,体重却在孩子出生后暴增,最高到过 90 kg 以上 。 前几年有一段时间,我自己在家做 HIIT 希望可以减重。2020 年时,因为尿路结石看了急症 。之后改做跳绳(希望可以排石),最后体重降到了 84 kg 。 最近一年因为不再上班工作了,除了偶尔(一周两到三次)出门去岩馆攀岩,几乎都在家里。体重在 3 个月前又升到了 91kg 。 大约在两个半月前,我下决心增加一些运动量。除了每周三次的攀岩外,另外四天每天做半个小时以上的慢跑。听取岩友建议,买了双软底的跑步鞋(体重较大,应重点保护膝盖)。选择在家旁边的公园,有质地比较软的跑步道。根据网上信息的测算,根据我的年龄,应该在慢跑时把心率控制在 140 以下。配速不重要,重要的是心率以及每次的时长(不低于 30 分钟),并避免受伤。 两个多月之前,我第一次尝试时,跑到 600 米左右,心率就超过了 150 ,赶紧停下来走路休息。 到现在坚持了两个多月,已经成为习惯。今天刮完台风,特别凉快。跑步时状态很好。第一公里用时 7 分钟,最后心率升到 140 。如果连续再跑下去还会上升,所以我选择走路休息到心率下降到 120 再继续。如此把心率维持在 120~140 之间,半个小时大约可以跑 3.5km 。 跑完再快走 5 分钟左右回家,不太觉得累。相比刚开始跑步时,到家就想躺下休息。这段时间在岩馆更也有动力爬。有岩友称,你终于有点老岩友的样子了。 至于体重,最近三天都在 86kg ,从数字上看已经减少了 5kg 。 控制尿酸方面:过去尿酸在 600 以上(体检报告记录)。现在戒掉了平时爱喝的含糖饮料,只在攀岩时喝一些运动饮料补充体力。日常喝苏打汽水(碱性),虽然以前也没有过多吃海鲜,现在是几乎不碰了。没有吃降尿酸的药。最近尿酸日常在 450 ~ 550 之间(每两天自测一次)。高低感觉和休息状态有关。如果白天过于劳累,晚上又没有好好休息的话,尿酸值也会明显升高。 脚没有再疼过,但总有点隐隐的感觉,可能是心理作用罢了。如果明年还不能降到 400 以下,考虑吃点药。 我知道跑步锻炼是一个漫长的过程,无法立竿见影。等半年以后再追加记录。

2025/7/20
articleCard.readMore

极度未来( Deep Future )给我的启发

最近我在 bgg 上闲逛时了解到了“Make-as-You-Play”这个游戏子类型,感觉非常有趣。它是一种用纸笔 DIY (或叫 PnP Print and Play)的游戏,但又和传统 DIY 游戏不同,并不是一开始把游戏做好然后再玩,而是边做边玩。对于前者,大多数优秀的 PnP 都有专业发行商发行,如果想玩可以买一套精美的制成品;但 Make as You Play 不同,做的过程是无法取代的,做游戏就是玩的一部分。 极度未来 Deep Future 是“做即是玩”类型的代表作。它太经典了,以至于有非常多的玩家变体、换皮重制。我玩的官方 1.6 版规则。btw ,作者在 bgg 上很活跃,我在官方论坛八年前的规则讨论贴上问了个规则细节:战斗阶段是否可以不损耗人口“假打”而只是为了获得额外加成效果。作者立刻就回复了,并表示会在未来的 1.7 规则书上澄清这一点。 读规则书的确需要一点时间,但理解了游戏设计精神后,规则其实都很自然,所以游戏进程会很流畅。不过依然有许多细节分散在规则书各处,只有在玩过之后才会注意到。我(单人)玩了两个整天,大约玩了接近 100 局,酣畅淋漓。整个游戏的过程有如一部太空歌剧般深深的刻印在我的脑海里,出生就灭亡的文明、离胜利只有一步之遥的遗憾、兴起衰落、各种死法颇有 RogueLike 游戏的精神。难怪有玩家会经年玩一场战役,为只属于自己战役的科技和文明设计精美的卡片。 在玩错了很多规则细节后,我的第一场战役膨胀到了初始卡组的两倍,而我也似乎还无法顺利胜利哪怕一局。所以我决定重开一盒游戏。新的战役只用了 5 盘就让银河推进到了第二纪元(胜利一次),并在地图上留下了永久印记,并制作了第一张文明卡片。这些会深刻的影响同场战役的后续游戏进程。 我感觉这就是这类游戏的亮点:每场游戏都是独特的。玩的时间越长,当前游戏宇宙的特点就有越来越深刻的理解:宇宙中有什么特别的星球、科技、地图的每个区域有不同的宜居星球密度,哪里的战斗强度会更大一些…… 虽然我只玩了单人模式,但游戏支持最多三人。多人游戏可以协作也可以对抗。你可以邀请朋友偶尔光临你的宇宙玩上两盘,不同的玩家会为同一个宇宙留下不同的遗产。和很多遗产类游戏不同,这个游戏只要玩几乎一定会留下点什么,留不下遗产的游戏局是及其罕见的。也就是说,只要玩下去哪怕一小盘都会将游戏无法逆转的改变。 下面先去掉细节,概述一下游戏规则: 游戏风格类似太空版文明,以一张六边形作为战场。这是边长为 4 的蜂巢地图(类似扩大一圈的卡坦岛),除去无法放置人口方块的中心黑洞,一共是 36 个六边形区格。玩家在以一个母星系及三人口开局,执行若干轮次在棋盘上行动。可用行动非常类似 4X 游戏:生产、探索、繁殖、发展、进攻、殖民。 每个玩家有 4 个进度条:文化 C、力量 M 、稳定 S 、外星 X。除去文化条外,其余三个条从中间开始,一旦任意一条落到底就会失败;而任意一条推进到顶将可能赢得游戏。文化条是从最底部开始,它推进到顶(达成文化胜利)需要更多步数,但没有文化失败。 另外,控制 12 个区域可获得疆域胜利,繁殖 25 个人口可获得人口胜利。失去所有星球也会导致失败。在多人模式中,先失败的玩家可以选择在下个回合直接在当前游戏局重新开始和未失败的玩家继续游戏(但初始条件有可能比全新局稍弱)。 游戏以纯卡牌驱动,每张卡片既是行动卡,又是系统事件卡,同时卡片还是随机性的来源。抽取卡片用于产生随机性的点数分布随着游戏发展是变化的,每场战役都会向不同的方向发展,这比一般的骰子游戏的稳定随机分布会多一些独有的乐趣。 玩家每轮游戏可作最多两个独立且不同的行动: POWER 抽两张卡 ADVANCE 发展一项科技 GROW 繁殖两个人口 EXPAND 向临接空格移动任意数量人口,但至少在出发地留一个 BATTLE 和临接空格交战,或(当没有任何邻接敌人时)推进任意进度条 SETTLE 在有人口的区域殖民一个星球 EVOKE 打出一张文明卡 PLAN 制造一张新的指定行动卡 在执行这些行动的同时,如果玩家拥有更多的科技,就可能有更多的行动附加效果。这些科技带来的效果几乎是推进胜利进度条的全部方法,否则只有和平状态的 BATTLE 行动才能推进一格进度条。 在行动阶段之后,系统会根据玩家帝国中科技卡的数量产生不同数量的负面事件卡。科技卡越多,面临的挑战越大。但可以用手牌支付科技的维护费来阻止科技带来的额外负面事件,或用手牌兑换成商品寄存在母星和科技卡上供未来消除负面事件使用。 负面事件卡可能降低玩家的胜利进度条,最终导致游戏失败;也可能在地图增加新的野生星球及野怪。后者可能最终导致玩家失去已殖民的星球。但足够丰富的手牌以及前面用手牌制造的商品和更多的殖民星球可以用来取消这些负面事件。 每张星球卡和科技卡上都有三个空的科技栏位,在生成卡片时至少会添加一条随机科技,而另两条科技会随着游戏进程逐步写上去。 游戏达成胜利的必要条件是玩家把母星的三条科技开发完,并拥有至少三张完成的科技卡(三条科技全开发完毕),然后再满足上面提到的 6 种胜利方式条件之一:四个胜利进度条 C T S X 至少一条推进到顶,或拥有 12 区域,亦或拥有 25 人口。 胜利的玩家将给当局游戏的母星所在格命名,还有可能创造 wonder ,这会影响后面游戏的开局设定。同时还会根据这局游戏的胜利模式以及取得的科技情况创造出一张新的文明卡供后续游戏使用。 游戏以 36 张空白卡片开始。一共有 6 种需要打出卡片的行动,(EVOKE 和 PLAN 不需要行动卡),每种行动在6 张空白卡上画上角标 1-6 及行动花色。太阳表示 POWER ,月亮表示 SETTLE ,爱心表示 GROW ,骷髅表示 ADVANCE ,手掌表示 BATTLE ,鞋子表示 EXPAND 。这些花色表示卡片在手牌上的行动功能,也可以用来表示负面事件卡所触发的负面事件类别(规则书上有一张事件查阅表)。 数字主要用来生成随机数:比如在生成科技时可以抽一张卡片决定生成每个类别科技中的 6 种科技中的哪一个(规则书上有一张科技查阅表),生成随机地点时则抽两张组成一个 1-36 的随机数。 我初玩的时候搞错了一些规则细节,或是对一些规则有疑惑,反复查阅规则书才确定。 开局的 12 个初始设定星球是从 36 张初始卡片中随机抽取的卡片随机生成的,而不是额外制作 12 张卡片。 如果是多人游戏,需要保证每个玩家的母星上的初始科技数量相同。以最多科技的母星为准,其余玩家自己补齐科技数量。无论是星球卡还是科技卡,三个科技的花色(即科技类别)一定是随机生成的。这个随机性通过抽一张卡片看角标的花色决定。通常具体科技还需要再抽一张卡,通过角标数字随机选择该类别下的特定科技。 每局游戏的 Setup 阶段,如果多个野生星球生成在同一格,野怪上限堆满 5 个即可,不需要外溢。但在游戏过程中由负面事件刷出来的新星球带来的野怪,放满格子 5 个上限后,额外的都需要执行外溢操作:即再抽一张卡,根据 1-6 的数字决定放在该格邻接的 6 格中的哪一格,从顶上面邻格逆时针数。放到版图外面的可以弃掉,如果新放置的格也慢了,需要以新的那格为基准重复这个操作,直到放完规定数量。放在中心黑洞的野怪暂时放在那里,直到所有负面事件执行外,下一个玩家开始前再弃掉。 开始 START 阶段,玩家是补齐 5 张手牌,如果超过 5 张则不能抽牌但也不需要丢到 5 张。超过 10 张手牌则需要丢弃多余的牌。是随机丢牌,不可自选。 殖民星球的 START 科技也可以在开始阶段触发且不必丢掉殖民星球。但在行动阶段如果要使用殖民星球的科技,则是一次性使用,即触发殖民星球上的科技就需要弃掉该星球。 在 START 阶段触发的 Explorarion 科技可以移动一个 cube 。但它并不是 EXPAND 行为,所以不会触发 EXPAND 相关科技(比如 FTL),也无法获得 Wonder 。和 EXPAND 不同,它可以移动区域中唯一的一个 cube ,但是失去控制的区域中如果有殖民星球,需要从桌面弃掉。 玩家不必执行完两个行动、甚至一个行动都不执行也可以。不做满两个行动在行动规划中非常普遍。两个行动必须不相同。 PLAN 行动会立刻结束行动阶段,即使它是第一个行动。所以不能利用 PLAN 制造出来的卡牌在同一回合再行动。 行动的科技增益是可选发动的。同名的科技也可以叠加。母星和桌面的科技卡上提供的科技增益是无损的,但殖民星球和手上的完整科技卡提供的科技是一次性的,用完就需要弃掉。 完成了三项科技的科技卡被称作完整科技卡,才可以在当前游戏中当手牌使用。不完整科技卡是不能当作手牌提供科技增益的。 SETTLE 行动必须满足全部条件才可以发动。这些条件包括,你必须控制想殖民的区域(至少有一个人口在那个格子);手上需要有这个格子对应的星球卡或该星球作为野生星球卡摆在桌面。手上没有对应格的星球卡时,想殖民必须没有任何其它星球卡才可以。这种情况下,手上有空白卡片必须用来创造一张新的星球卡用于殖民,只有没有空白卡时,才创造一张全新的星球卡。多人游戏时,创造新的星球卡的同时必须展示所有手牌以证明自己没有违反规则。如果殖民的星球卡是从手牌打出,记得在打出星球卡后立刻抽一张牌。新抽的牌如果是完整科技卡也可以立刻使用。如果星球卡是新创造的,或是版图上的,则不抽卡。 SETTLE 版图上的野生星球的会获得一个免费的 POWER 行动和一个免费的 ADVANCE 行动。所谓免费指不需要打出行动手牌,也不占用该回合的行动次数。这视为攻打野生星球的收益,该收益非常有价值,但它是可选的,你也可以选择不执行 SETTLE 的 Society 科技增益可以让玩家无视规则限制殖民一个星球。即不再受“手牌中没有其它可殖民星球”这条限制,所以玩家不必因此展示手牌。使用 Society 科技额外殖民的星球总是可以选择使用手上的空白卡或创造一张新卡。这个科技不可堆叠,每个行动永远只能且必须殖民一个星球。 SETTLE 的 Goverment 科技增益可以叠加,叠加时可以向一科技星球(星球卡创建时至少有一科技)添加两个科技,此时玩家先添加两个随机花色,然后可以圈出其中一个选择指定科技,而不需要随机选择。 GROW 的 Biology 科技增益必须向不同的格子加人口,叠加时也需要每个人口都放在不同格。如果所控区域太少,可能浪费掉这些增益。 如果因为人口上限而一个人口也无法增加,GROW 行动无法发动。所以不能打出 GROW 卡不增加人口只为了获得相关科技增益。 未完成的科技卡在手牌中没有额外功能。它只会在 ADVANCE 行动中被翻出并添加科技直到完成。如果 ADVANCE 时没有翻出空白卡或未完成的科技卡,则创造一张新科技卡。新创建的科技卡会立刻随机生成三个随机花色。玩家可以选择其中一个花色再随机出具体科技。在向未完成的科技卡上添加新科技时,如果卡上没有圈,玩家可以选择圈出一个花色自主选择科技,而不必随机。一张卡上如果圈过,则不可以再自主选择。 ADVANCE 的 Chemistry 科技增益可以重选一次随机抽卡,可以针对花色选择也可以针对数字选择。但一个 Chemistry 只能重选一次,这个科技可以叠加。 ADVANCE 的 Physics 科技增益只针对科技卡,不能针对星球卡。所以,无论 Physics 叠加与否,都最多向科技卡添加两条科技(因为科技卡一定会至少先生成一条)。当 Physics 叠加两次时(三次叠加没有意义),科技卡上的三条科技都可以由玩家自主选择(每一科技卡原本就可以有一条自由选择权,叠加 Physics 增加了一次选择权)。注意,花色一定是随机生成的。这个增益增加的是玩家对科技的选择权。 只有在所有邻接格都没有敌人(野怪和其他玩家)时,才可以发动 BATTLE 行动的推进任意胜利条的功能。战斗默认是移除自己的人口,再移除敌人相同数量的人口。但可以选择移除自己 0 人口来仅仅发动对应增益。所以 BATTLE 行动永远都是可选的。 BATTLE 的 Military 科技增益新增的战场可以重叠,即可以从同一己方格攻打不同敌人格,也可以从多个己方格攻打同一敌人格。和 Defence 科技增益同时生效时,可以一并结算。 EXPAND 行动必须移动到空格或己方控制格,但目的地不可以超过 5 人口上限。永远不会在同一格中出现多个颜色的人口。移动必须在出发地保留至少一个人口。当永远 FTL 科技增益时,可以移动多格,途经的格不必是空格,也可以是中心黑洞。 EXPAND 行动移动到有 Wonder (过去游戏留下来的遗产)的格子,且该格为空时,可以通过弃掉对应花色的手牌发动 Wonder 能力,其威力为弃牌的角标数字。Wonder 只能通过 EXPAND 触发,不会因为开局母星坐在 Wonder 格触发。 BATTLE 的 spaceship 科技增益需要选择不同的目的地,多个叠加也需要保证每个目的地都不相同。 PLAN 行动制造新卡时,只有花色是自选的,数字还是随机的。PLAN 会结束所有行动。 行动阶段后的 Payment 阶段可以用来消除之后 Challenge 阶段的负面事件数量。方法是打出和母星及科技卡上科技增益的花色。针对母星以及每张科技卡分别打出一张。如果卡片上有多个科技增益花色,任选其中一个即可。科技卡上未填上的增益对应的花色则不算。每抵消一张就可以减少一张事件卡,但事件卡最后至少会加一张。每次抵消一次事件,都可以所在卡片(母星或科技卡)上添加一个 upkeep 方块。每张卡上的方块上限为 3 ,不用掉就不再增加。但到达上限后,玩家依旧可以用手牌抵消事件,只不过不再增加方块。 挑战阶段,一张张事件卡翻开。玩家可以用对应花色的手牌取消事件,也可以使用桌面方块取消,只需要方块所在卡片上有同样花色。还可以使用殖民星球取消,需要该星球上有对应花色的科技(不是星球卡的角标花色)。但使用殖民星球需要弃掉该星球卡。不可使用母星抵消事件卡。 事件生效时,如果需要向版图添加野怪。这通常是增加随机方块事件,和增加野外星球事件(带有 5 方块)。增加的方块如果在目标格溢出,需要按规则随机加在四周。 如果增加的方块所在格有玩家的方块,需要先一对一消除,即每个增加的野怪先抵消掉一个玩家方块。如果玩家因此失去一个区域,该区域对应的桌面星球也需要扔掉,同时扔掉牌上面的方块。如果母星因此移除,玩家可以把任意殖民星球作为新的母星。移除的母星会变成新的野外星球。如果玩家因此失去所有星球就会失败。在多人游戏中,失败的玩家所有人口都会弃掉,同时在哪些有人口的格放上一个野怪。 游戏胜利条件在行动阶段达成时就立刻胜利,而不需要执行后续的挑战行动。在单人游戏中,除了满足常规的胜利条件外,还需要根据版图上的 Wonder 数量拥有对应数量的殖民星球(但最多 4 个)。这些殖民星球需要在不同的区格,且不在母星系。玩家胜利后应给当前母星所在格标注上名字,这个格子会在后续游戏中刷多一个野怪。玩家可以创建一张文明卡,文明卡的增益效果和胜利条件以及所拥有的科技相关,不是完全自由选择。 不是每局胜利都会创造 Wonder 。需要玩家拥有至少 5 个同花色科技,才能以此花色创造 Wonder 。每个 Wonder 还需要和胜利模式组合。Wonder 以胜利玩家的母星位置标注在版图上,胜利模式和科技花色的组合以及 Wonder 地点不能在版图中重复。 这个游戏给我的启发很大。它有很多卡牌游戏和电子游戏的影子,但又非常独特。 不断制作卡牌的过程非常有趣,有十足的创造感。读规则书时我觉得我可能不会在玩的过程中给那些星球科技文明起名字,反正不影响游戏过程,留空也无所谓。但实际玩的时候,我的确会给三个半随机组合起来的完整科技卡起一个贴切的名称。因为创造一张完整的科技卡并不容易,我在玩的过程中就不断脑补这是一项怎样的科技,到可以起名的时候已经水到渠成了。 更别说胜利后创建文明卡。毕竟游戏的胜利来得颇为艰难。在失败多次后,脑海中已经呈现出一部太空歌剧,胜利的文明真的是踏着前人的遗产(那些创建出来的独有卡片)上成功。用心绘制一张文明卡真的是乐趣之一。我在 bgg 上看到有玩家精心绘制的带彩色头像的文明卡,心有戚戚。 游戏的平衡设计的非常好,有点难,但找到策略后系统也不是不可战胜的。关键是胜利策略会随着不断进行的游戏而动态变化:卡牌角标会因新卡的出现而改变概率分布,新的科技卡数量增加足以影响游戏策略,卡组里的星球科技会进化,星球在版图上的密度及分布也会变化…… 开局第一代策略和多个纪元的迭代后的策略可能完全不同,这让同一个战役(多局游戏的延展)的重玩价值很高。 用卡牌驱动随机性是一个亮点:以开始每种行动都是 6 张,均匀分布。但会因为星球卡打在桌面(从卡堆移除)而变化;更会因为创造新卡而变化。尤其是玩家可以通过 PLAN 主动创建特定花色卡片,这个创造过程也不是纯随机的,可以人为引导。负面事件的分布也会因此而收到影响。 用科技数量驱动负面事件数量是一个巧妙的设计。玩家获得胜利至少需要保有 6 个科技,即使在游戏后期纪元,也至少需要创造一个新科技,这会让游戏一定处于不断演变中。强力的桌面卡虽然一定程度的降低了游戏难度,但科技越多,每个回合潜在的负面事件也越多。以 3 科技开局的母星未必比单科技开局更容易,只是游戏策略不同而已。 每局游戏的科技必须创造出来(而不是打出过去游戏创造的科技牌)保证了游戏演变,也一定程度的平衡了游戏。即使过去的游戏创造出一张特别强力的科技,也不可以直接打在本局游戏的桌面。而只能做一次性消耗品使用。 一开始,负面事件的惩罚远高于单回合能获得的收益。在不太会玩的时候,往往三五回合就突然死亡了。看起来是脸黑导致的,但游戏建议玩家记录每局游戏的过程,一是形成一张波澜壮阔的银河历史,二是当玩家看到自己总是死于同一事件时有所反思,调整后续的游戏策略。 而战役的开局几乎都是白卡和低科技星球,一定程度的保护了新手玩家,平缓了游戏的学习曲线。边玩边做的模式让战役开局 setup 时间也不会太长,玩家也不会轻易放弃正常战役。 单局失败是很容易接受的,这是因为:单局时间很短,我单刷时最快 3 分钟一局,长局也很少超过 10 分钟。每局 setup 非常快。而游戏演化机制导致了玩家几乎不可能 undo 最近玩的一局,因为卡组已经永久的改变了。不光是新卡(因为只增加新卡的话,把新制造的卡片扔掉就可以 undeo ),还会在已有的卡牌上添加新的条目。 虽然我只玩了单人模式(并用新战役带朋友开了几局多人模式),但可以相像一个战役其实可以邀请其他玩家中途加入玩多人模式。多人模式采用协作还是对抗都可以,也可以混杂。协作和对抗会有不同的乐趣,同时都会进化战役本身。这在遗产类桌游中非常少见:大多数遗产类游戏都有一个预设的剧本和终局条件,大多推荐固定队伍来玩。但这个游戏没有终局胜利,只有不断创造的历史和不断演化的环境,玩家需要调整自己的策略玩下一局。

2025/7/13
articleCard.readMore

育儿的一些日常

以下从我最近两个月发的推文中整理。 可可 晚上可可读着书在床上睡着了。我没叫醒她,给她盖了被子就睡了。早上醒来时她跟我说,完蛋了,昨天晚上我没有洗澡。我说没关系,别被妈妈发现就好了。然后她蹑手蹑脚的偷偷起来换了身衣服,然后又躺回来睡觉。 可可的同学喊她联机 minecraft ,我在隔壁看书,听她们在微信上聊了半天硬是鸡对鸭讲。我过去跟她说,你把电脑屏幕拍个照片给她看不就好了。结果对面喊了句:你怎么玩国际版啊,我玩的是网易中国版,然后安慰可可说,你自己玩也是可以的。我想:到底谁是正版受害者? 可可最近在读的一本小说突然就找不到了,她怎么都想不起来在哪里。我花了许多时间引导她回忆,终于想起是周三的课外班落在隔壁班的教室里了。如果缺乏引导,她的记忆是绝对不可能打开的。周五家长会,我特地提前了 5 分钟到学校,和隔壁班主任解释了一番,在教室仔细搜寻,果然找到了。可可很开心。 可可最近读书挺认真的,问了好多问题。前几天问了好几个成语的意思,又比问了什么时候用——(破折号),还讨论了为什么小说里要写那么多她觉得并不精彩的情节。 可可二年级,我最近发现她数学是真的不行 :( 今天检查作业错了一道题,引导了半天才发现她对 100 以上的数字概念都没建立起来。比如知道 10 个 100 是 1000 ,但她觉得 20 个 100 是一万,而且讲了一个小时才纠正过来。果然,人类天生的感知就是对数的么?本福特定理诚不我欺。 我觉得文字阅读能力对人的一生非常重要,而现在的小孩娃很难自发练习了 :( 试过很多方法培养兴趣,还是很难。最近一个月试着强制每天半小时文字阅读。两个娃都还听话,虽然觉得是个负担,但也认了这个任务。但经过一段事件,感觉阅读能力真的有提高(从阅读速度判断)。 可可看了几部关于老鼠的小说后,已经开始跟同学说地球上最聪明的动物是老鼠,地球就是老鼠造的计算机了。 可可迷上和我一起玩 rimworld 。假期跟妈妈出去旅行,回到家第一件事就是让我打开电脑继续抓一只豚鼠当宠物。知道游戏可以通过存档回退时间后,她让我试了一下在婚礼上把除新娘之外的人全部杀掉。等她长大,我一定推荐她看一遍杀死比尔。 可可说看到短视频中说 switch 的卡带是苦的。我说你要不要试试,她挑了一张舔了一下说好苦啊。云豆说我也试试。过了一会,可可又换了一张再舔了一下,这下她相信每张 switch 卡带都非常苦了。 可可说,我们玩个游戏,我问你问题,你必须马上回答。我说好。可可问:你最喜欢哥哥还是我?看我没说话,她说,算了,这个问题不好,下一个问题…… 应朋友邀请去扬州玩。在扬泰机场跟可可讲李白的诗,我说古时候送别朋友远行,可能就一辈子不会再见了。可可问,不能打电话吗? 云豆 云豆说,什么时候买 switch 2 啊。我说你又不喜欢马车,买它作甚。但还是下了单。第一天试了 switch 秘密展和马车,玩得很开心。周末他的一帮同学闻讯都来了我们家。但是摸了一下 switch 2 以后,又围在 pc 上玩《小飞船大冒险》去了。 云豆家长会上,班主任展示了一张同学自制的贺卡。粉色的封面上画着一颗爱心,写着“我喜欢你”。打开后,内面用透明胶贴满了一整面秘密麻麻的蚊子。看来广州的夏天蚊虫真多,难为孩子能攒这么多。 云豆很兴奋的告诉我,他在科学课上学到埃菲尔铁塔是古斯塔夫造的。他前段玩了 33 号远征队,古斯塔夫是他最喜欢的角色。我告诉他我对埃菲尔铁塔那一带的路很熟,因为我玩了鬼武者。 给云豆买了本《猫和少年魔笛手》,我自己先读了一遍,非常喜欢。不过我怀疑他可能不太看得懂。云豆最近主动看书了,《哈利波特》已经快把《凤凰社》读完了。前几年我给他读过前四本,这次是他自己主动从第一本开始读的。 云豆问我,100 以内哪个数的因数最多,它有多少个因数?我想到一个问题:取一个足够大的整 n ,比 n 小的整数中因数最多的数大约有多少个因数?云豆说他找到 100 以内因数最多的是 96 ,有 12 个因数。我说 72 也是 12 个,我问,你能不能证明没有更多的了?1000 以内最多因数的是 900 ,有 27 个(其实 840 的有 32 个因数更多)。我给他讲了应该怎么找到这个数,以及应该怎样快速计算因数的个数。他发现分解质因数有实际的用途,还是挺开心的。 云豆学校最近查视力,一边 5.0 一边 4.4 ;去年都是 5.0 。前同事介绍了个医生,我们就去看眼科了。配了 OK 镜,前两天佩戴颇费事,第三天开始就很顺手了。 买了一本《在数学的雨伞下》。我先读完觉得内容不错,然后在睡前给云豆读了三次共三个小时左右。出乎意料,接受度还不错。不过每次不能太长时间,小孩得慢慢来,时间长一点他就犯困。 云豆看了 switch 2 预告的直面会后非常开心,因为樱井政博又回来做卡比了。 和云豆把双影奇景通关了,然后在隐藏关死了几百次才打到第三小关。云豆强迫症犯了,一定要我陪他练习直到把隐藏关通关。 云豆同学来家里玩,我说你们打游戏水平都不错,不如一起玩双影奇境。玩了两关后,同学说没意思,我们还是玩蛋仔派对吧。 晚上给云豆讲了一晚上勾股定理,用的总统证法。娃还没开窍,累死他也累死我了。最后他终于自己想通了等量加等量还是等量;我一开始以为是公理所以没办法教,这个必须自己想明白。“三角形的内角和是 180 度” 这个可以有疑惑的定理却很快接受了,只因为老师在课堂上讲过。去年花了 8 个周末给云豆讲质数,质因数,公约数等等。虽然花了比我预想得多的时间,但我确定他最后是懂了。今年课堂上开始教了,他说很轻松。我看课堂速度比我去年教的快多了,如果靠老师教,估计要学个一知半解。 云豆拿了语文测验卷子回来,错了好多。我给他讲卷子发现他阅读能力真的是很差。三国演义的半白话自然是完全不懂的;而一篇白话的百草园,也是一半没看懂。很多书面语的词完全不明白意思。 云豆的好朋友过生日,我帮他选了个礼物 RG28XX 。 云豆一大早起来背 100 以内的质数表,课本上还有口诀,说是今天数学老师要抽查。我说不需要这么背的。你心里顺着数数,把个位是 1379 的挑出来,去掉乘法口诀里出现的数字比如 49 ,再检查一下是不是 3 的倍数。最后记住 9 字头的只有 97 就好了。他试了一次就开心的上学去了。

2025/6/15
articleCard.readMore

电梯的交互和调度

今天在网上和人闲扯,说到电梯的交互设计或许是有问题的。一般在楼宇的电梯区,会设置上下两个按钮,让乘客表达自己是要上行还是下行。如果在电梯区显示电梯当前所在楼层的话,就会有人理解为:上是指让电梯轿厢向上运行,下是指让其向下。一旦这样理解,就会输入错误的指令。 几乎每个有过在高层办公室上班经历的程序员都参与过电梯调度算法的讨论。看来,在饭点挤电梯是程序员们的共同记忆。(另一个永恒话题是怎样提高厕所的使用效率)我也不例外,20 多年里,我曾经反反复复和人讨论过这个问题。现在再也不用挤电梯了,似乎可以把过去考虑过的方案记录一下。 先说说现实存在过的方案: 大多数方案都是为了提高电梯的运营效率。要么为了节能,要么为了更快的满足乘客需求,要么为了提高高峰时的吞吐量。 大部分高层建筑都把多部电梯按楼层分区。有些电梯只服务低层,有些服务高层。如果楼层更多时可能还会分出更多区间。对于超高层建筑,也有把顶楼超高区单独分割出来,需要转电梯的。 这个设计显然是因为对于高层建筑,电梯的需求按楼层分布是金字塔型的。乘客永远都需要从地面进入,越往上,乘客越少,而路程越长。乘客的目的地却是接近均匀分布的,如果让乘客随机进入任意轿厢,最终电梯会在更多楼层停留开门,将乘客预先分组就显得很有必要。 另外,为了解决繁忙时段的吞吐量问题,电梯也可能按单双层分组。这样可以把一部分运力转嫁到楼梯上,减少每部电梯的停留时间。类似的方案还有针对乘客类型设置专用电梯,比如让饭点运输食物的乘客走专用梯,而减少乘客使用电梯的需求量;让领导们使用专门电梯,提高他们的幸福指数以获得重要工作上的效能增益,等等。 也有一些办公楼会让乘客预先输入自己的目的地,而不是简单的选择上行还是下行。这样,系统理论上可以统筹安排。我也使用过这样的系统,效果嘛,一言难尽。只能说理想很丰满,现实很骨感。电梯公司想乘着软件系统升级多赚点钱无可厚非,但复杂系统就是这样:很难把它实现得正确。 回到文章开头的话题,我的观点是,与其做一个交互更复杂的系统妄想提高效率,还不如进一步简化它。 其实,电梯的外部控制按钮或许并不需要上下两个?只要一个召唤按钮就够了。 首先,这样的交互设计是没有歧义的:我需要使用电梯,就召唤它过来。 其次,用上下行来对乘客预分类过于粗糙,实际中对效率的提升非常有限。 如果建筑只有一部电梯,看起来对乘客分类的意义最少:反正乘客都必须乘坐这唯一一部电梯去目的地的,即使电梯目前运行方向相反,提前进轿厢的区别也仅仅是在里面等待还是在外面等待。 有同学说,不对啊,假设电梯目前从 1 楼向上运行到 10 楼顶楼,5 楼的人想下去,按了召唤按钮,电梯就可能在上行过程中做无谓的停留。如果电梯按钮分开上下,需求就明确了,电梯只会上去后下行时才会停下来。 我的观点是,其实电梯在上行时停下来,乘客就可以进去了。这样电梯之后下来时就不用再次在 5 楼停下来。无论是电梯运行时间,还是乘客抵达 1 楼的时间,差别都微乎其微。 而且就我的实际经历:在饭点想乘电梯下楼的话,往往是只要电梯开门了就进去,哪管它上行还是下行。你不进去等下就进不去了。稍低楼层的人更多的是反向坐电梯,不然就可能要等到餐厅快打烊了才吃得上饭:因为你不反向乘电梯的话,电梯下行的第一站永远是最高层,比你楼层高的乘客会优先使用。电梯的设计运力难以满足高峰期的需求。 在这种使用场景下,略低楼层的乘客往往上下两个按钮都会按下,在电梯上行时就先进入轿厢,而当电梯折返下行路过同一楼层时,电梯再次开门,外面却已经没有乘客了。效率反而降低了。如果电梯只设一个召唤按钮,这个问题就可以回避掉。 ps. 真要在高峰期保证公平的话,电梯需要设置成:单趟只停一个楼层,然后循环这个目的地。例如,一部高层电梯可以依次循环停 30, 29, 28, .... ,每一趟只在目的地停一次。这个运行模式可以在电梯不满载时自动取消,或是按高峰时间段固定开启。可惜我工作过的办公楼还没有见过电梯系统能设置成这种公平模式的。 这种单按钮召唤的设计,只要算法合理也并不比上下两按钮的低效。上下两按钮只是预先把乘客分开上行组和下行组,避免只有一组乘客时电梯反向停留(例如在上行阶段为下行乘客开门)。单按钮系统可以在载荷超过阈值时拒绝响应外部召唤请求,在完全已进入轿厢的乘客都送达目的地后,再根据外部召唤情况跑下一趟。这样就可以做到:延迟处理外部请求队列,以延长乘客外部等待时间为代价,增加单趟满足的乘客数量,从而提高整体的运行效率。 那么,如果电梯系统有多部电梯时怎样处理呢? 我觉得也可以不用上下行按钮预分类乘客。而是将电梯本身分为上行开门和下行开门。和高低层分类一样,乘客应该自行去上行区和下行区召唤电梯。鉴于除了地面的乘客趋向于上行外,其实绝大多数楼中乘客使用电梯都是下行的。多部电梯的系统只要保留一部梯为上行开门就够了。而且,即使你需要下行,其实也可以进入这部梯,它或许并不慢。因为一旦反向抵达有乘客召唤的最上一层,之后它下到一楼是直达的(下行不开门)。

2025/6/9
articleCard.readMore

一个简单的 A star 寻路算法实现

我需要一个接口简单的寻路模块,所以今天写了一个 。其实之前也写过很多版本,在我上传代码时就发现我自己的 github 账号下早有同名仓库。不过,之前的版本的接口设计不太满意,直接删掉了,用这次的新版本复用老的仓库名字。 我希望达到的目标是,C 接口简单易用,且和地图本身的数据结构无关,只提供寻路功能。这样容易拓展到不同应用场景。 数据结构简单,内存开销固定,在算法执行过程中不额外分配内存。这可以方便的在多线程环境运行。 我不需要处理特别复杂和规模巨大的地图,那种场景应该额外做一些预处理。但在起点和终点的路线结果不长时(即使在大规模地图上),应该有较好的性能。 原始的 A star 算法实现最为简单,在大多数情况下有不错的表现,所以我选择了它。我知道算法可以有很多改进方法,但我觉得代码简单最为重要。 通常 A star 算法依赖一个优先队列,但我没有选择使用诸如平衡二叉树等复杂结构来实现它,而使用了最简单的单向链表。因为这样可以轻松的把全部数据全部塞在一块平坦内存中。 基础数据结构是一个用数组实现的闭散列 hash 表,使用者来决定使用多大的数组,通常使用预期路径长度的平方大小会比较合适。为了减少每次寻路的初始化成本,使用了一个 version 值表示每个 slot 的初始状态,每次调用寻路,都会把 version 递增( O(1) 操作),这样就可以让整个 hash 表的所有 slot 复位。 寻路过程中每个尝试的节点都会加入 hash 表中,在 hash 表使用率超过一半就会中止算法,防止性能恶化。但接口在这种情况下依然会返回已经找到的离目标最近的中途点。 在不复杂的大规模地图上,通常可以通过多次调用找到完整路径。但依然建议针对大地图做更高层次的预处理。在 Youtube 上有一个 Rimworld 作者讲解 Rimworld 中区域分割系统的视频值得一看,搜索 "RimWorld Technology - Region System" 可以找到。 A star 工作中的待展开节点集是用单向链表的形式串起了 hash 表中的 slot ,而没有使用额外的优先队列结构。虽然单向链表的插入操作是 O(n) 的,但我猜想在大部分场景中,这个 n 并不算大。尤其是估价函数理想工作状态下(朝着目标直线移动),新插入的节点都是在链表一端附近的。这个猜想需要足够多的测试数据验证。 为了调试算法工作中的内部状态,模块提供了一个函数可以输出整个 hash 表的当前状态图(仅限于每个 slot 的 gscore ,即离起点的路程)。合理使用这张图,可以把算法的内部状态可视化表现。test 中使用 ascii 字符展示,但用灰度图输出图像效果会更好。 代码刚写好,尚未充分测试。但我觉得接口设计还算通用,应该会有人愿意使用。期待有更多人使用而让代码的质量提升。

2025/5/14
articleCard.readMore

卡牌构筑类桌游核心规则之七

纯单人游戏在桌面游戏中不太多见,但我很喜欢这种。毕竟,找人一起玩桌游太不容易,虽然多人协作桌游总可以一个人操控多方进行 solo ,但终究不是为单人游戏设计的。今天介绍的两款单人卡牌游戏,我没买到实体版,都只是在桌游模拟器上玩过几盘。 第一款是 Legacy of Yu (2023) 大禹治水。老实说,这不是一款卡牌“构筑”游戏。虽然在游戏过程中玩家还是需要从市场列“购买”新卡片,但游戏过程并不是围绕构筑进行的。这些卡牌更像是消耗品。 游戏中的工人卡有三种用法: 打出后获得卡片上标注的资源,然后进入弃牌堆。 销毁一张工人卡,获得卡片上额外标注的一次性资源,卡片将移出游戏。这样获得的资源一定比前一种方法获得的多。 把卡牌(常驻)押在版图中已经盖好的房子上,此后的回合每回合获得持续资源奖励。 和一般的卡牌构筑游戏不同,卡堆不是越少越好。一般的卡牌构筑游戏,精简卡堆总是好的,因为这样可以加快卡堆循环,能更快抽到自己需要的强力卡。而这个游戏中,当抽牌堆耗尽,游戏进程就会向前推进。一旦准备不足,推进游戏会加快失败进程。虽然,游戏过程中,除非迫不得已,都不要销毁工人卡获得额外资源。 游戏中有砖头、木头、粮食、货币(贝壳)四种资源,以及白色劳工、红色战士、黄色弓箭手、黑色骑士、蓝色枪兵五种工人。 资源可以用来做建设:砖头+木头+劳工=农场(三个待建),砖头+3x木头+劳工=前哨(四个待建),3x砖头+木头+劳工=房屋(四个待建),运河。 农场效果是固定的,为后面的轮次每回合增加固定产能。三个农场分别对应粮食、劳工、其它任意工人;前哨可以让四种特殊工人和白色劳工相互替代;房屋的触发效果是随机的,标注在房屋卡片背面,大多数是触发说明书上的事件。建成房屋还可以为工人提供工作地(将工人换成对应资源)以及常驻资源产地(减少卡组中的工人卡换取持续产能)。 游戏需要玩家以不断增加的成本修建六段运河。成本会逐步递增,一二段需要两个劳工及两个贝壳;三四段需要三个劳工及两个贝壳;五六段需要两个劳工两个指定颜色工人及三个贝壳。每段运河修建成功后,可获得一次性奖励并摧毁部分抽牌堆中的工人卡,以及触发事件。并可以为之后的游戏回合带来一些贸易选项: 贸易选项是固定的: 两个贝壳换一个粮食 一张弃牌换两个贝壳 劳工及粮食转换为任意工人 四个贝壳换一个劳工 两个粮食及两个贝壳增加一张工人卡 砖头或木头换一个贝壳 玩家需要在修完六段运河后存活到回合结束才能赢得游戏。 在游戏版图上方由预备工人卡和蛮族卡共享市场列。蛮族卡越多,可选择的工人卡就越少。一旦市场列全部挤满蛮族卡,游戏就会失败。 市场列的最左端位置上的工人卡总是免费的。玩家可以选择拿取放在弃牌堆,也可以直接销毁获得一次性资源。而蛮族卡会随着修建运河的进程逐步进入市场列。未消灭的蛮族,在每个回合结束会收取贡品,通常贡品可以用销毁一张工人卡抵消,但如果工人卡被销毁光也会导致游戏失败。击败蛮族需要支付卡片上标注的指定种类的工人,击败蛮族后会获得卡片上标注的一次性奖励。 这个游戏有传承机制,熟悉基础规则后,可以根据说明书逐步解锁新的玩法:游戏难度会随着游戏进程慢慢加强,并引入一些新的游戏机制。因为根据单局游戏失败或成功,导向不同的游戏进程,难度也是动态调节的。 这个游戏不是很热门,可能是因为它只能单人游玩,在国内很难买到实体版。但这个游戏我非常喜欢,桌游模拟器上有汉化过的电子版。 Kingdom Legacy: Feudal Kingdom (2024) 是一个较新的游戏。它和很多传承类游戏一样,几乎只能玩一次。因为游戏过程中会涂改卡牌,这个过程是不可逆的。而且卡堆一开始在包装内的次序是设计过的,一旦打乱还原比较麻烦。后期的一些卡片一旦被巨头,也会失去一些探索未知的乐趣。 可能是因为每开一局都需要新买一盒游戏的远古,这个游戏各处都缺货,不太好买到。好在其官网有所有卡片的电子版本,可以方便做研究。 游戏规则简单有趣,整个游戏过程是升级卡牌。大部分卡片有四个状态:两面每面上下两端。卡牌升级指支付一些资源,让卡片旋转到另一端或翻面(根据卡片上的指示),同时结束当前回合;卡片上也可能有一些标注的效果让卡片状态变化。资源不使用额外指示物,而是弃掉当前的卡片获得(同样标注在卡面),资源必须立刻使用,无法保留到下一回合。 这个游戏的“构筑”过程颇有新意。它没有主动挑选购买新卡的环节,但一旦抽牌堆为空,就会结束一大轮,会从卡堆中新补充两张新卡(以设计过的次序,没有随机元素)。而玩家的主动构筑在于对已有卡片的变化(升级)。 每一个回合,抽四张手牌,用其中三张的资源换取一张卡的升级。在玩的过程中,如果当前回合资源不足以升级卡片,可以选择增加两张新卡继续当前回合;也可以选择 pass ,放弃当前所有手牌,重新补四张。游戏不会失败,不管怎么玩,游戏都在抽到第 70 号卡后结束,并结算得分。玩家可以以得分多少评价自己玩的成绩。游戏包装内不只 70 张卡片,超过编号 70 的卡片会在游戏进程中根据卡片上描述的事件选择性加入游戏。 游戏中有六种资源:金币、木材、石头、金属、剑、货物。它们对应了不同卡片的升级需求。通过卡牌升级,把牌组改造为更有效的得分引擎是这个游戏的核心玩点。部分卡片是永久卡,可以在游戏过程中生效永久驻留在桌面提供对应功能。有些卡片会被永久销毁,如前所述,一盒游戏只能玩一次,所以一旦一张卡片被销毁就再也用不到了。按游戏规则的官方说法,你可以把已销毁的卡片擦屁股或是点火。 为了方便初次游戏熟悉规则,在翻开第 23 号卡片之前,可以反复重玩,玩家可以不断的刷开局;直到 23 号卡片之后,游戏才变得不可逆。而在游戏后期,玩家牌堆会越来越大(因为每个大轮次,即抽完牌堆后后会加入两张新卡),这时就引入了支线任务 ,在游戏术语中叫做扩展(expansions)。触发支线时,需要清洗(销毁)一张桌面的永久卡,并执行一次 purge 12 动作。即洗掉牌堆,抽出 12 张卡,选一张保留,并销毁另外 11 张卡。但 purge 的这 11 张卡上的分数可以保留下来,记录在支线得分中。支线会让牌堆维持在一个较小的规模。 每个支线都会持续 4 轮(对应卡片的四个状态),每轮旋转或反转支线卡推进任务。支线的每个状态都会有一个当轮生效的效果。游戏的基础包中有三个内置支线卡,额外的扩展包增加了许多任务(以及额外的卡片)。一局游戏可以最多触发 10 个支线。 8 月 11 日补充: Kingdom Legacy: Feudal Kingdom 的卡片翻转机制我是第一次玩到,感觉挺有趣。但我最近又玩了一款老一点的游戏 Palm Island (2018) 也是同样的机制,玩起来也颇为有趣。 不过棕榈岛没有遗产机制,只有一些有限的成就卡(勉强也能算遗产)。它的资源储存和消耗方法比较独特,最有趣的一点是:虽然是一款桌面游戏,它被设计成没有桌面也能玩,只需要把握在手中即可,并不需要打在桌面上。

2025/5/8
articleCard.readMore

对数和自然对数的底

最近读了一本书:《数学的雨伞下》。阅读体验非常好,这本书用浅显的语言,科普了许多深刻的道理。这本书所介绍的知识结构比较类似我挺喜欢的另一本《从一到无穷大》,但讲解更为细致一些,以至于如果事先明白这些知识,甚至会觉得有些冗长。但细细品味,会觉得理解能更深一层。 我在通读完一遍之后,这几天带着儿子精读。重读第一章中“对数之桥”一节时,我思考了一个问题:当年纳皮尔 Napier 到底出于什么动机制作一张高精度对数表,他制表的计算思路是怎样的。书中并没有答案,所以我又在互联网上翻看了当年 Napier 原著 Mirifici Logarithmorum Canonis Descriptio 的介绍,感觉收获颇丰。 制作对数表的直接原因当然是为了简化大数乘除法的计算。对数概念的提出在幂概念建立之前,而现在的数学教学中,一般却是从幂自然推导到对数的。似乎后者才是自然而然的。这应该是因为,古人研究数学,最初是为了解决现实中的问题。所以,乘法必须有对应的几何意义。比如,计算正方形面积需要把计算边长的平方;立方体的体积需要计算边长的立方。更高次的幂却难有对应的几何意义,有理数幂则更为抽象。 现实中,也很难碰到极大的数字,超乎寻常的精度需求也很小,除了天文学。 人无法以上帝视角在宇宙空间中做测量,只能以地球为基点。所以,天文尺度的计算都依赖三角学。把天文(以及地理这种地球尺度的)数字问题化为三角函数,然后再加以计算。比如,测量地球到太阳的距离、地球到月球的距离、地球的直径都是这样。因为这些尺度都非常大,如果计算精度不够,就容易失之毫厘,差之千里。 为了测算太阳系内天体的距离,可以在地球表面找两个尽可能远的点(最多相距地球的直径),观察天体,记录下天体在视野中的角度。这样,地球表面的两个端点和被观察的天体,就构成了一个三角形。三角形的底边就是两地的距离,而顶角则可以对比两地观测的结果得到。这就是三角视差法。可想而知,对于太阳系内的天体,这个视察角度非常小,需要极高的观测精度和计算精度才能计算出距离(远大于地球直径)。 甚至,这个方法可以运用到测量附近恒星到地球的距离。这几乎是人类利用三角法能测算的最大尺度。在地球表面找两个点已经不够了,因为那最长不超过地球的直径。更长的标尺只有地球绕太阳的轨道:在一年中隔半年做一次观察,这两个观测点在宇宙空间中就隔了地球和太阳距离的两倍长,这总该够长了吧?其实不然。在这个尺度上,古人依然观察不到星星的位置相隔半年的星图中有所不同。这也是为什么日心说提出后,不光是神学家不接受,连天文学家(比如第谷)也不接受。 如果地球围着太阳转,而地球距离太阳如此之远,那么就算是恒星离得再远,地球位于太阳两侧时,总能观测到某些明亮(离我们相对较近)的星星位置有些许偏差吧?人类难以相像太阳系外的宇宙如此空旷。事实是,太阳以外的恒星离我们真的太远了,即使以地日这种天文距离为底边,和附近的恒星形成的等腰三角形的顶角也不到一秒。过去的测量工具的精度是完全不够用的。直到 19 世纪中叶(哥白尼死后 200 多年)人类才真正观测到天鹅座61/贝塞尔星 有 0.3 个秒视差,从而估算出离地球大约 10 光年左右。 测量精度是一方面,计算精度也很重要。在三角公式里算几个乘法,若是通过对数方法转换为加减法计算,而精度不够的话,恐怕结果会差上一个数量级。 纳皮尔在没有幂概念的基础上就发展出了对数概念,靠的还是寻求其几何意义。他的灵感来源并不是幂运算,而是三角公式。三角和差公式中,角度相加被转换为三角函数的乘法运算,这提示着,乘法和加法之间可以相互转换。纳皮尔的对数表也并不是现在意义的列一系列数字,逐个列出它们的对数。而是给出角度的三角函数值的对数。它可以看成是当时已存在的三角函数表的拓展。这也是为什么,纳皮尔的表只有 90 * 60 = 5400 项(对应四分之一圆周在分精度下的所有角度值),但数字精度却有小数点后 7 位。因为当时最精确的三角函数表是 7 位精度。 在没有计算机的年代,计算对数必须查对数表。那么最初的对数表怎么得到的呢?如果是按幂函数的逆去计算,那就涉及高次开方,人肉计算显然是不可能的。而且当时,还并没有发现对数和幂的互逆关系(那要等到 100 年后的欧拉),甚至连幂的概念都没有。 《数学的雨伞下》这本书为了让读者更容易理解对数表,举例子使用的是以 2 为底的对数。对数列是一个自然(等差)数列:1,2,3,4,5... ;真数列是 2, 4, 8, 16, 32 .... 这样一个等比数列。但实际这样制作对数表会难以实用,因为真数数列膨胀的太快了。如果要实用,最好真数数列的间隔不要太大。如果间隔太大,在利用它做乘法运算的时候,很多数字会偏差很大。 把对数用于快速计算乘法,选用怎样的底并不重要。当等差数列的差距为 0.00000001 时(因为当时的三角函数表有 7 位精度),等比数列的差值选为 1.0000001 或 0.9999999 最方便计算。因为这样,列出等比数列时,就不需要连续计算乘法,而只需要移位相加即可。一个十进制数乘以 1.0000001 只需要把这个移动 7 位的小数点,再加上原数即可。如果等比数列的公比为 1.0000001 ,其实是给对数表选择了一个以 (1+1/n)^n (n = 10^7) 的底。当然,这是现代数学的看法,在纳皮尔的时代,还没有发展出底这个概念。 纳皮尔研究的是三角对数,真数范围在 0 到 1 之间。当时的人并没有完整的小数和数级的概念。过去研究圆,使用的是一个超大的(10^7)的半径而不是今天流行的 1 。因为这样,三角函数才能近似为整数(对于 7 位精度,使用10^7 的圆半径,相当于比今天的三角函数放大了一千万倍)。btw, 纳皮尔在制作对数表的过程中,发明了小数点,用来保留计算过程中的精度。 他先构造了一个等比数列,再通过几何定义去计算其对数对应的等差数列。从现代观念看,纳皮尔选择的底约为 0.9999999^1000000 ,非常接近 1/e 。 在今天来看,如果我们想制作一张好用的对数表,真数列自然是越密越好。如果我们把 n 取无穷大,让 1/n 足够小,(1+1/n)^n 的极限即为欧拉数 e 。我想,这也是为什么欧拉数 e 被称为自然对数的底。纳皮尔的时代,无法通过“视对数函数为幂函数的逆函数”来建立这种直观的认识,人类深刻认识 e,要到百年后的欧拉。 关于纳皮尔如何制作对数表的,他自己写过构造方法一书。300 年后的 1914 年 EW Hobson 写了 John Napier and the invention of logarithms, 1614 纪念纳皮尔,详细讨论了纳皮尔原著中的方法。这篇文章在网上可以找到中文翻译。另可以参考这一篇文章 。 纳皮尔在计算过程中,充分考虑了计算的误差区间,严格保证他计算的对数表满足 7 位精度。他首先计算了 0.9999999 的 0 到 100 次方,然后计算 0.99999999^100 = 0.99999 的 0 到 50 次方。虽然计算这个等比数列只需要把前一个数字在十进制上移位并计算减法,这个计算工作并不难(并不需要算乘法),但纳皮尔在这一步把最后一项算错了:本应该是 0.999500122480 ,而他计算成了 0.9995001222927 。这个 bug 导致了使用最终的对数表会产生微小的误差(影响最后一位数字),纳皮尔自己觉得这个误差是三角函数表不精确导致的,并建议用 8 位精度重制三角函数表。

2025/4/10
articleCard.readMore

卡牌构筑类桌游核心规则之六

这次介绍两款在国内人气不高的卡牌构筑类桌游。游戏都还不错,可能是因为没有中文版,所以身边没见什么朋友玩。 首先是 XenoShyft 。它的最初版全名为 XenoShyft: Onslaught (2015) ,后来又出了一个可以独立玩的扩展 XenoShyft: Dreadmire (2017) 。 故事背景有点像星河舰队:由人类军士抵抗虫子大军。简单说,这是一个塔防游戏:游戏分为三个波次,每个波次三轮,一共要面对九轮虫群的冲锋。 游戏中有四类卡片:部队、敌人、物品、矿物,另有一组表示玩家所属部门的能力卡,每局游戏每个玩家可以分到一张,按卡片上所述获得能力 矿物就是游戏中的货币,用来在市场购买部队卡和物品卡。敌人卡分为三组,对应到三次波次,洗乱后形成系统堆。玩家需要在每轮击败一定数量的敌人,撑过三个波次就可以取得游戏胜利。 玩家基础起始牌组 10 张,4 张最低级的士兵和 6 张一费的矿物。根据玩家的部门,还会得到最多 2 张部门所属的特殊卡。 市场由部队卡和物品卡构成,其中部队卡是固定的,分三个波次逐步开放购买。物品卡一共 24 种(基础版),但同时只会有 9 种出现在市场上。玩家部门可能强制某种物品一定出现在市场上,其它位置则是每局游戏随机的。在游戏过程中,当一种物品全部买空后,会在市场中随机补充一堆新的物品卡。普通敌人卡按波次分为三组洗乱,然后根据波次再从 6 张 boss 随机分配到三个波次中。 每个轮次,玩家先抽牌将手牌补齐到 6 张,然后打出所有的矿物卡,并根据波次额外获得 1-3 费,然后用这些费用从市场购买新卡片,花不完的费用不保留。新购得的卡片直接进入手牌(而不是弃牌堆)。这是一个合作游戏,所以玩家可以商量后再决定各自的购买决策。 然后,玩家把手牌部署到战区。每个玩家把部队卡排成一行(最多四个位置),物品中的装备可以叠在部队卡上增强单位的能力。玩家可以给队友的部队卡加装备(但不可以把自己的部队卡部署在队友战区)。部署环节玩家之间可以商量,同时进行。 之后进入战斗环节。这个环节是一个玩家一个玩家逐个结算。翻开敌人队列上的敌人卡(在部署环节是不可见的)、在敌人卡片翻开时可能有一次性能力,发动该能力、然后(所有)玩家都有一次机会打出手牌中的物品卡或使用部署在战场上的卡片能力。之后,双方队列顶部的两张卡片结算战斗结果。卡片只有攻击和 HP 两个数值,分别将自己的 HP 减去对手的攻击点。一旦有一方(或双方)的 HP 减到 0 ,战斗结束,把战斗队列卡片前移,重复这个过程。直到一方队列为空。 如果己方部队全灭,每场战斗的反应阶段(每个玩家都可以打出一张手牌或使用战斗卡片能力)依然有效,但改由基地承受虫子的攻击。基地的 HP 为所有玩家共享,总数为玩家人数乘 15 。可以认为基地的攻击无限大,在承受攻击后,一定可以消灭敌人。一旦基地 HP 降为 0 ,所有玩家同时输掉游戏。 游戏中的死亡效果有两种,毁掉(burning)和弃掉(discarding)。毁掉一张卡指把这张卡片退回市场(如果市场上还有同类卡)或移出游戏(市场上没有对应位置),而弃掉一张卡指放去玩家的弃牌堆。 通常,敌人卡片效果一次只会结算一张(即当前战斗的卡片)。但有些卡片效果会对场上敌人队列中尚未翻开的卡片造成伤害。这种情况需要先将所涉及的敌方卡片都翻过来,并全部结算卡片出场能力。对于需要同时结算多张敌人卡片出场能力时,玩家可以讨论执行次序。 如果对这款游戏有兴趣,又找不到人玩的话,可以试试它的电子版,在 steam 上就有。不过看评论,据说电子版 bug 有点多。 另一个游戏是 G.I. JOE Deck-Building Game (2021) 。G.I. JOE 特种部队是孩之宝(也就是变形金刚品牌的拥有者)旗下的一个品牌,除了玩具,有衍生的漫画、电影和动画片。这个桌游也是这个玩具品牌的衍生品。我认为这个 DBG 里的某些设定(不同的游戏剧本、同一剧本中不断推进的故事任务、队员的多种技能)也影响了星际孤儿那个电子游戏。 游戏有很多剧本、以及若干扩展。不同的剧本在规则细节上有所不同(这一点和星际孤儿很相像),这里只减少核心共通的规则。 这是个多人协作游戏。当然,只要是协作游戏,就一定可以单人玩,只需要你轮流扮演不同角色的玩家即可。每个玩家一开始有一张特殊的领袖卡,然后配上 9 张固定的初始牌组成了起始卡组。每个回合摸 5 张卡,用不完的卡会弃掉,不能保留到下一回合使用。每张领袖卡都对应了一个升级版本,可以在游戏进程中购买替换。 市场由一组卡片洗乱,随机抽出 6 张构成。每当玩家购买一张卡,就会补充一张新卡。但如果卡堆耗尽尚未结束游戏,游戏失败。在游戏过程中,可能有敌对卡片出现,会盖掉市场中的卡。玩家需要解决掉敌人,否则盖掉的卡片无法购买。如果 6 张市场卡片都被盖掉也会导致游戏失败。 当每个玩家执行完一轮行动,即为一大轮游戏。在每大轮开始,都会推进一个全局的威胁指示条。一旦威胁指数上升到某一程度,就会发生一些固定事件。维护指数走到头会导致游戏失败。 游戏故事由三幕构成,每幕随机选取两张对应的故事任务卡和一张固定的终局局故事卡,一共 9 张故事任务卡构成了整局游戏。永远有一个故事任务呈现在场景中,它有可能触发一个回合效果,需要在每个玩家回合开始时结算。 每一幕开始都会洗混所有的系统事件卡堆(包括之前解决完弃掉的事件卡),故事卡和威胁进度条会触发这些事件。这些事件会给玩家增加一些负面效果,或是在场上增加一些任务让玩家解决。 游戏任务分两种:团队任务和支线任务。故事卡一定是团队任务,事件产生的 boss 卡也是团队任务。团队任务可以在当前玩家决定去进行任务时,其他玩家提供协作;而支线任务只能由当前玩家独立完成。任务有地形、难度、技能需求、持续效果等元素构成。 地形指玩家开启任务需要使用怎样的载具,分陆海空三类。技能要求则限制了玩家可以派出的队员。难度数字决定了玩家最终需要在此技能上获得多少点才能完成任务。持续效果则会在该任务完成前,对玩家造成的负面效果。 开启一个任务需要玩家从机库派出一个对应地形的载具以及至少一个队员(从手牌打出)。该载具是在玩家回合开始时从手牌打在机库中的,VAMP 作为默认载具总可以保证一个回合使用一次。高级载具可以从市场购买。对于团队任务,所有玩家都可以协商派出队员,但队员总数不能超过载具的容量。 任务上标注了所需技能,派出的队员卡如果有符合的技能,则可以把技能点加到任务中。如果技能不匹配,也可以视为一个通用技能。任务卡最多要求两种技能,如果是 & 标记,则表示可以只要符合两种技能中的任意一种都可以生效;如果是 or 标记,则需要当前玩家选择其中一种技能,所有队员都需要匹配这种技能。 最终参与任务的技能总数决定了最终可以用几个六面骰。每个六面骰有三个零点,两个一点,一个两点;扔出对应数量的骰子,把最终点数相加,如果大于等于任务的难度值,则任务成功并或许成功奖励,否则任务失败。对于故事任务,失败需承受任务卡上的失败惩罚,并结束任务;对于其它任务,失败会让任务继续保留在场上。 有一类叫做 Precision Strikes 的任务,在翻出时需玩家讨论后决定放在谁的面前,变成它代做的支线任务。每个玩家最多只能放两张 Precision Strikes 在面前,到他的行动回合,必须先处理掉 Precision Strikes 任务。 在玩家做完所有想做的任务后,剩余的手牌可以作为够买新卡的费用。每张卡都标有一个自身的价格,以及一个在购买阶段可以当成几点费用使用。没有用完的费用不会积累到下个回合。购买的载具卡会在购买后直接进入机库,供后续回合所有玩家使用。其它卡片则放在抽牌堆顶。 整个回合结束后,弃掉所有手牌,以及回合中使用过的卡牌以及载具,重新抽五张。 玩家可以共建一个基地。这个基地由五部分构成,在游戏过程中逐步升级,升级也时通过购买完成的。在游戏过程中,以升级的部分也可能被摧毁或重建。这五个部件如下: Repair Bay 会让任务中使用的载具都放在该处而不是弃牌堆。在回合结束(或被摧毁),Repair Bay 中的载具都会回到机库。这样,载具的利用率会大大提升。 Stockade 建成后,击败的 boss 卡会进入这里而不会重复进入游戏。 Battlestation 可以在团队任务中重掷一个骰子。 Laser Cannon 可以在支线任务中增加一个骰子。 Command Room 把手牌增加到 6 张。

2025/4/8
articleCard.readMore