CodingNow | 云风的 RSS 预览

编写游戏程序的一些启示

2025-08-23 01:14:10

这个月我开了个新项目：制作 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 模式）。

也就是，直观的书写回合开始的发牌流程是这样的：

for i = 1, 5 do
  draw_card() -- 发一张牌
  sleep(0.1)  -- 等待 0,1 秒
end

这段代码作为状态机逻辑的一部分天然适合放在单独的 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() 做查询条件要舒服一点。

以上便是最近一个月的部分开发记录。虽然，代码依旧在不断修改，方案也无法确定，下个月可能还会推翻目前的想法。但我感觉找到了让自己舒适的节奏。

不需要太着急去尽快试错。每天动手之前多想想，少做一点，可以节省很多实作耗掉的精力；也不要过于执著于先想清楚再动手，毕竟把代码敲出带来的情绪价值也很大。虽然知道流畅的画面背后有不少草率的实现决定，但离可以玩的游戏更进一步的心理感受还是很愉悦的。

日拱一卒，功不唐捐。

SetWindowText 引起的死锁

2025-08-09 10:51:37

最近发现我在写的小游戏在启动时有很小的概率黑屏。我使用的是 ltask 多线程框架，在黑屏时感觉 ltask 并没有停止工作，似乎只是管理窗口的部分（线程/服务）卡死了。

窗口管理使用的是 sokol_app 做的多平台封装，这只是一个很浅的封装层，但已经够用。我觉得美中不足的是，sokol_app 的 frame 回调函数是放在 WinProc 中，由 Windows 的消息循环被动调度，而不是放在外层的主动 GetMessage 循环中。

即，在 Windows 程序中，线程通常会在最外面写一个这样的 while 循环：

for (;;) {
    while (PeekMessageW(&msg, NULL, 0, 0, PM_REMOVE)) {
        if (msg.message == WM_QUIT)
            return;
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    // 在这里，我们可以做一些额外的工作，比如渲染游戏画面、处理游戏逻辑。
}

但我们也可以选择在窗口的 WinProc 中，通过响应 WM_TIMER 等消息的方式来做这些工作：

LRESULT CALLBACK wndproc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) {
    switch (uMsg) {
        case WM_TIMER :
            // 在这里，可以定时做一些工作。
        break;
    }
    return DefWindowProcW(hWnd, uMsg, wParam, lParam);
}

// 外面的消息处理循环则可以使用 GetMessage 而不是 PeekMessage

while(GetMessage(&msg, NULL, 0, 0) {
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

无可厚非，后一种方法显得更正规一点：让 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-07-20 12:21:00

我这两年攀岩时总是体力不够用，出去野攀如果需要先爬山接近的话，往往爬到岩壁下就累个半死不想动了。而我那帮 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 以下，考虑吃点药。

我知道跑步锻炼是一个漫长的过程，无法立竿见影。等半年以后再追加记录。

极度未来（ Deep Future ）给我的启发

2025-07-13 12:50:02

最近我在 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-06-15 18:52:47

以下从我最近两个月发的推文中整理。

可可

晚上可可读着书在床上睡着了。我没叫醒她，给她盖了被子就睡了。早上醒来时她跟我说，完蛋了，昨天晚上我没有洗澡。我说没关系，别被妈妈发现就好了。然后她蹑手蹑脚的偷偷起来换了身衣服，然后又躺回来睡觉。
可可的同学喊她联机 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-06-09 14:02:45

今天在网上和人闲扯，说到电梯的交互设计或许是有问题的。一般在楼宇的电梯区，会设置上下两个按钮，让乘客表达自己是要上行还是下行。如果在电梯区显示电梯当前所在楼层的话，就会有人理解为：上是指让电梯轿厢向上运行，下是指让其向下。一旦这样理解，就会输入错误的指令。

几乎每个有过在高层办公室上班经历的程序员都参与过电梯调度算法的讨论。看来，在饭点挤电梯是程序员们的共同记忆。（另一个永恒话题是怎样提高厕所的使用效率）我也不例外，20 多年里，我曾经反反复复和人讨论过这个问题。现在再也不用挤电梯了，似乎可以把过去考虑过的方案记录一下。

先说说现实存在过的方案：

大多数方案都是为了提高电梯的运营效率。要么为了节能，要么为了更快的满足乘客需求，要么为了提高高峰时的吞吐量。

大部分高层建筑都把多部电梯按楼层分区。有些电梯只服务低层，有些服务高层。如果楼层更多时可能还会分出更多区间。对于超高层建筑，也有把顶楼超高区单独分割出来，需要转电梯的。

这个设计显然是因为对于高层建筑，电梯的需求按楼层分布是金字塔型的。乘客永远都需要从地面进入，越往上，乘客越少，而路程越长。乘客的目的地却是接近均匀分布的，如果让乘客随机进入任意轿厢，最终电梯会在更多楼层停留开门，将乘客预先分组就显得很有必要。

另外，为了解决繁忙时段的吞吐量问题，电梯也可能按单双层分组。这样可以把一部分运力转嫁到楼梯上，减少每部电梯的停留时间。类似的方案还有针对乘客类型设置专用电梯，比如让饭点运输食物的乘客走专用梯，而减少乘客使用电梯的需求量；让领导们使用专门电梯，提高他们的幸福指数以获得重要工作上的效能增益，等等。

也有一些办公楼会让乘客预先输入自己的目的地，而不是简单的选择上行还是下行。这样，系统理论上可以统筹安排。我也使用过这样的系统，效果嘛，一言难尽。只能说理想很丰满，现实很骨感。电梯公司想乘着软件系统升级多赚点钱无可厚非，但复杂系统就是这样：很难把它实现得正确。

回到文章开头的话题，我的观点是，与其做一个交互更复杂的系统妄想提高效率，还不如进一步简化它。

其实，电梯的外部控制按钮或许并不需要上下两个？只要一个召唤按钮就够了。

首先，这样的交互设计是没有歧义的:我需要使用电梯，就召唤它过来。

其次，用上下行来对乘客预分类过于粗糙，实际中对效率的提升非常有限。

如果建筑只有一部电梯，看起来对乘客分类的意义最少：反正乘客都必须乘坐这唯一一部电梯去目的地的，即使电梯目前运行方向相反，提前进轿厢的区别也仅仅是在里面等待还是在外面等待。

有同学说，不对啊，假设电梯目前从 1 楼向上运行到 10 楼顶楼，5 楼的人想下去，按了召唤按钮，电梯就可能在上行过程中做无谓的停留。如果电梯按钮分开上下，需求就明确了，电梯只会上去后下行时才会停下来。

我的观点是，其实电梯在上行时停下来，乘客就可以进去了。这样电梯之后下来时就不用再次在 5 楼停下来。无论是电梯运行时间，还是乘客抵达 1 楼的时间，差别都微乎其微。

而且就我的实际经历：在饭点想乘电梯下楼的话，往往是只要电梯开门了就进去，哪管它上行还是下行。你不进去等下就进不去了。稍低楼层的人更多的是反向坐电梯，不然就可能要等到餐厅快打烊了才吃得上饭：因为你不反向乘电梯的话，电梯下行的第一站永远是最高层，比你楼层高的乘客会优先使用。电梯的设计运力难以满足高峰期的需求。

在这种使用场景下，略低楼层的乘客往往上下两个按钮都会按下，在电梯上行时就先进入轿厢，而当电梯折返下行路过同一楼层时，电梯再次开门，外面却已经没有乘客了。效率反而降低了。如果电梯只设一个召唤按钮，这个问题就可以回避掉。

ps. 真要在高峰期保证公平的话，电梯需要设置成：单趟只停一个楼层，然后循环这个目的地。例如，一部高层电梯可以依次循环停 30, 29, 28, .... ，每一趟只在目的地停一次。这个运行模式可以在电梯不满载时自动取消，或是按高峰时间段固定开启。可惜我工作过的办公楼还没有见过电梯系统能设置成这种公平模式的。

这种单按钮召唤的设计，只要算法合理也并不比上下两按钮的低效。上下两按钮只是预先把乘客分开上行组和下行组，避免只有一组乘客时电梯反向停留（例如在上行阶段为下行乘客开门）。单按钮系统可以在载荷超过阈值时拒绝响应外部召唤请求，在完全已进入轿厢的乘客都送达目的地后，再根据外部召唤情况跑下一趟。这样就可以做到：延迟处理外部请求队列，以延长乘客外部等待时间为代价，增加单趟满足的乘客数量，从而提高整体的运行效率。

那么，如果电梯系统有多部电梯时怎样处理呢？

我觉得也可以不用上下行按钮预分类乘客。而是将电梯本身分为上行开门和下行开门。和高低层分类一样，乘客应该自行去上行区和下行区召唤电梯。鉴于除了地面的乘客趋向于上行外，其实绝大多数楼中乘客使用电梯都是下行的。多部电梯的系统只要保留一部梯为上行开门就够了。而且，即使你需要下行，其实也可以进入这部梯，它或许并不慢。因为一旦反向抵达有乘客召唤的最上一层，之后它下到一楼是直达的（下行不开门）。

CodingNow | 云风修改

CodingNow | 云风的 RSS 预览

可可

云豆

该作者的社会化媒体