这是因为，如果独立编译 Lua 的 C 扩展库，通常需要链接 Lua 的 C API 。标准的方法是动态链接 lua 实现，如果静态链接 liblua.a ，会导致进程中有多份 lua 的实现。在 Lua 的历史版本中，这将导致运行期错误。

这是因为，Lua 的实现中有一个静态的“空”对象，所有的 nil 都指向这个对象。如果进程空间中有多份 Lua 实现，就会出现多个空对象。运行时的数据结构中会引用这个空对象，而不同副本的实现将“空”和自身保留的“空”对象引用做比较时，就会出现错误的判断。

在更早期的版本，出现这种链接出现的项目，bug 会隐藏得很深。所以后来 Lua 增加了 luaL_checkversion() ，倡议在外部库初始化时调用，除了检查版本号，还会检查当前执行的 lua 实现是否和虚拟机创建时用的实现是同一个副本。

但我还是认为，在同一进程中置入多份 Lua 实现是不好的。

注：这也是 Windows 动态库的一个独有问题。因为 Windows 的 DLL 不允许有未完成的符号，必须在编译链接时指定所有符号（Lua C API）的来源；如果是 Linux ，可以不链接 Lua C API 的库，在运行时加载动态库，加载器就能把进程内的对应符号装载起来。

回到题头的问题：soluna 静态链接了 Lua ，并未导出 C API ，要用 C 写额外的库怎么办？

曾经在 Ant Engine 中，我采用了一个方法：提供一个假的代理动态库，提供所有 Lua C API 的符号。外部库可以动态链接它，而它将所有 Lua C API 调用转发到 engine 内部链接的 Lua 实现中。

这样做的好处是，即使是预编译好的 Lua C 库，只要它正确的以动态链接形式链接了 Lua ，就能直接被 Ant Engine 加载。如果不需要外部库，这个代理库也可以不发布。

今天，我想给 soluna 加上类似的特性，但尝试了新的方案：外部库在构建时额外实现一个简单的入口函数，它不依赖真的 Lua 实现，而是链接 soluna 项目中的 extlua/extlua.c 这个 Lua API 代理实现。再由 soluna 的定制加载器来加载这个外部库。

比如，我有一个叫做 foobar 的外部库，原本的实现是这样的：

static int
lhello(lua_State *L) {
    lua_pushstring(L, "Hello World");
    return 1;
}

extern int
luaopen_foobar(lua_State *L) {
    luaL_Reg l[] = {
        { "hello", lhello },
        { NULL, NULL },
    };
    luaL_newlib(L, l);
    return 1;
}

当我们编译成动态库时，导出的 luaopen_foobar() 是库的入口。lua 的 require 可以正确的导入它。但这个实现依赖若干 lua C APIs ，例如 lua_pushstring() 等。

如何在 soluna 里正确加载它呢？我们需要在调用 luaopen_foobar() 这个入口函数前，将进程中的 Lua C APIs 注入这个动态库。

在这个方案中，只需要链接 soluna 项目中的 extlua/extlua.c 单个文件，然后导出一个额外的库入口函数：

extern int
extlua_init(lua_State *L) {
    luaapi_init(L);
    luaL_Reg l[] = {
        { "ext.foobar", luaopen_foobar },
        { NULL, NULL },
    };
    luaL_newlib(L, l);
    return 1;
}

这个函数的第一行需要调用 luaapi_init(L) ，它的实现在 extlua.c 中。然后用 luaL_newlib() 注入原有的模块入口函数即可。

luaapi_init(L) 并不依赖任何 Lua 的内部实现，只依赖 Lua 的一个官方宏 lua_getextraspace() 完成了注入 Lua C APIs 的魔法。

这是个有趣的技巧：

lua_getextraspace(L) 的官方定义是这样的：

#define lua_getextraspace(L)    ((void *)((char *)(L) - LUA_EXTRASPACE))

每个 Lua_State 结构前都保留有一个指针的空间，可以用来传递数据。soluna.external.load 会构建一个空的 Lua 虚拟机，并把所有 Lua C APIs 的引用放在它的 extraspace 。因为上面的 extlua_init() 是一个标准的 lua_CFunction ，所以可以用标准函数 package.loadlib 读出。传入这个带 C APIs 的空 Lua 虚拟机，luaapi_init() 就能正确的导入所有 API 了。随后的 luaL_newlib() 会把所有真正的入口函数放在这个空虚拟机中。当然，只是一些字符串（入口名）和 C 函数指针。

接下来，soluna.external.load 再从这个虚拟机中把整个入口函数表复制到当前虚拟机，并销毁掉这个临时虚拟机，就完成了整个外部模块的动态加载。

soluna.extlib(name) 的实现是这样的：

function soluna.extlib(name)
    local extlua = require "soluna.extlua"
    local filename = assert(package.searchpath(name, package.cpath))
    settings = settings and soluna.settings()
    local entry = assert(package.loadlib(filename, settings.extlua_entry))
    return extlua.load(entry)
end

要使用上面例子中的放在 sample.dll 中的库 ext.foobar 只需要这样：

local libs = soluna.extlib "sample"
local foobar = require "ext.foobar"
assert(libs["ext.foobar"] == foobar)

即使要静态链接 sample 模块（iOS 不支持动态库，可能必须静态链接），只需要采用以下编译方案即可正确工作：

1. 静态链接 sample 模块
2. 不要链接 extlua/extlua.c
3. 将 luaapi_init() 定义为一个空函数
4. 把 extlua_init() 这个入口函数导入
5. 用 soluna.extlua.load(入口函数) 加载

这个游戏的规则还是挺复杂的，在 BGG 上的 weight 评级达到了 4.06 。注：游戏的重度（weight）是由玩家评分综合而来，最高为 5 。它指的是规则的繁杂程度，而并非游戏的策略深度（通常有相关性）。例如围棋虽然策略深度几乎达到了桌游的天花板，但它的 weight 就不到 4 。而 bgg 上 weight 超过 4 的游戏并不多见，大部分超过 3 的桌游，一般就被归为重度游戏了。我大概花了 10 多个小时试玩，看了几个小时的教学视频，才感觉学会了游戏的基本规则。不过一旦理解了游戏的设计逻辑，玩起来还颇为流畅，规则书以及规则助记版都非常符合直觉，简单好认。重度游戏大多不太讨人喜欢，但设计良好的重度游戏也能带来更多乐趣。

ST:CC 以及它的前身 Imperium 提供了非常丰富的卡组瘦身机制：

1. 可以把卡堆里的牌 LOG 起来：和早期卡牌构筑游戏不同，得分卡并不是专门的卡，而是每张卡本身就带有 VP 。这更像银河竞逐这样的引擎构建游戏。收集的卡越多得分越高。LOG 可以把当局游戏不再用的卡从当前卡堆里移除，但得分依旧保留。

2. 可以把卡片 deploy 到桌面：放在桌面的卡可以提供持久的被动能力，也可以有限的提供主动能力或响应能力。同时，活动卡组也得到的瘦身。根据卡片属性不同，提供有差异的回收规则。船员卡可以常驻一张，新的船员卡晋升后 dismiss 旧的；飞船卡则在占领星球后自动 dismiss ；事件卡则每张有不同的回收前置行动（不回收会在游戏结束结算时计为负分）。

3. 卡片可以 beam 到飞船或星球上：这可以对卡组作更灵活的临时瘦身。几乎所有的飞船都有主动能力可以 beam 手牌，但反向回到手牌的 recall 操作却比较稀少。不过，beam 在飞船上的卡也可以随飞船 dismiss 而一同回到弃牌堆。

永久（不可逆）和临时（可收回）的卡牌瘦身操作，可以让玩家在游戏过程中动态的调整卡组，让游戏的确定性更高，而不会在抽牌堆太大时，过于依赖抽卡的手气。就我这几天玩的数盘游戏体验，通常我的活动牌组（抽牌堆加上弃牌堆和手牌）在整局游戏里也很少超过 20 张。

ST:CC 在游戏过程中的卡组升级也有新意。

首先，和大多数卡牌构筑游戏一样，初始卡组是 10 张左右，每轮抽 5 张。这样可以保证前两轮可以作一个轮回，让随机性限制在 10 张卡的不同组合上。但和之前的很多游戏不同，它的 10 张卡是完全不同的，每张都特别设计过。甚至游戏带了 6 套风格迥异的初始牌组。而传统上的设计更偏好在初始卡组中放上雷同的初始能力卡，加上很少量的特殊卡。如果没玩过桌游的话，可以对比杀戮尖塔这样受桌游启发的电子游戏：一开始的初始卡组中只有一张特殊能力卡加上普通的打击和防御。

而和一般的卡牌构筑游戏的升级流程不同，它会为每个初始牌组设计 5 张左右的固定补充卡堆和 8 张左右的高级补充卡，以固定节奏补充进来：每次抽牌堆抽空都会自动触发这个补充操作，加入一张额外的补充卡。基本的补充卡的随机性在于每局游戏的进入次序是打乱的，而高级卡则需要用不同资源购买，但可以让玩家指定（没有抽卡的随机环节）。这样熟练牌组的玩家可以预先学习好每个角色牌组的策略，再实际玩的时候又不至于形成太固定的套路。

因为补充卡是通过卡组循环进入抽卡堆的，添加新的补充卡可以带来更多的组合，相当于卡组升级。所以调节抽卡堆的消耗速度就相当于控制玩家卡组升级速度。ST:CC 在主动控制牌堆轮转这一点上设计得比大多数卡牌构筑前辈出色。

1.抽牌能力。这是一个常规设计，不仅用来补充当前回合的行动选择，同时加快了抽牌堆的轮转。

1. 弃掉抽牌堆顶的牌。这在《Dominion》中多以攻击效果出现，说明早期这种设计更多强调的是其负面影响：让玩家暂时失去潜在的行动能力。但由于卡组瘦身很容易，它也出现了有益的一面：加快牌堆轮转。

2. 在回合结束时，玩家可以任意保留手牌。这给玩家了选择：确保下一回合能做的行动，但减缓了牌堆轮转速度。

3. 从市场获取新牌后，可以自由选择放入弃牌堆还是放入抽牌堆。前者加快了牌堆轮转，后者提供了确定性：可用抽牌能力立刻获取，或确保下一轮可以抽到。

由于有大量从弃牌堆抽牌的能力。这极大的丰富了获取行动卡的途径。抽牌堆抽卡是随机的，弃牌堆抽卡是确定的（挑选），牌堆轮转加快固然是好事，但弃牌堆清空也是需要考虑的问题。

除了固定补充卡升级，游戏还提供公共市场和供双方争夺的中立地点卡。但很多传统的市场机制是用资源从市场买卡，而 SC:CC 并不通过积累资源购买市场卡，而是改为用特定行动卡片直接获取。市场被分为了四类：船员、货物、飞船、盟友，分别对应不同的行动卡去获取。根据选择的初始牌组不同，获取这些市场卡的行动卡使用方式也不一样。由于行动力有限，规划行动的分配获取市场卡就变成了卡片 combo 重要的一环。玩家很难积累获取市场卡的能力，抢夺地点卡更是这样：规则限制了每个回合最多只能获得一个中立地点。整局游戏中不会获得太多的额外卡片，且每张公共卡都是单独设计的，这让引入每张卡到自己的卡组都需要仔细规划。

ST:CC 的卡片被设计成一卡多用。卡片处于不同位置：从手牌打出或桌面上激活会有不同的能力。而即使是同一种方式使用它，一般也有多种能力供选择，只能选其一使用。虽然每种使用方式大多有前置条件或副作用，但本身的多种选择让每张卡片在不同场景下都有用。

因为卡片的位置非常丰富：除了传统的抽牌堆、弃牌堆、手牌外，还有桌面区、市场区、当前市场、市场库存、中立地、废牌堆、附着在其它卡片上、LOG 区、升级区、事件区等等。就我主要玩的 PICARD 牌阵来说，大量的行动就是将卡在这些这些区域之间调度。所以在玩的时候，有一点工人分配游戏的感觉。不仅提供了丰富的卡牌策略，还非常好的契合了星际迷航那种驾驶飞船探索宇宙的主题。

为了让游戏不限于千篇一律的构建得分引擎循环，游戏给每个牌组都设计了不同主题的任务。任务不同于很多引擎构建游戏的终局任务卡，那个在 ST:CC 里也有，被设计为 Encouter 卡片，通常可以提供大笔的 VP 。任务就是固定在每个初始卡组上的，像是堆每组不同风格的牌作一个游戏引导，引导在游戏过程中侧重某种玩法。例如，PICARD 的基本任务就是获得三张同盟卡，并把他们都 beam 到同一艘飞船上，且获得至少 4 点科技点和 4 点影响力，就可以完成。

这个设计不会让玩家（熟悉后）玩游戏时不会走一步看一步，每步寻找当下行动的利益最大化。玩家必须作一个长远规划：因为任务必不可少的需要分成很多步骤，同步相当多的行动在好几个回合才可能达成。以我玩的经验来看，基本任务一般在游戏中后期才可以达成，而以开始不作计划的话，常常忙到快结束时还差上一点点。

由于只靠固定牌组很难有效的完成任务，随机出现的公共牌加入卡组都能带来意想不到的高效组合，所以每局游戏的过程都会差异很大。我用 PICARD 玩了 3,4 局游戏，都选的 KOLOTH 这个 bot ，但每局游戏体验完全不同。更别说换掉对手会有完全不同的局面。游戏为每个舰长的 bot 定制了不同的自动化策略来模拟人类玩家选择不同舰长会出现的不一样的打牌倾向。

这是一个两人对战游戏，但也可以用设计好的自动化规则来模拟一个对手。但在 BGG 上，大多数玩家认为这个单人对抗 bot 的玩法更好玩。游戏的教学作的不错，提供了一个更存粹没有对手的单人模式，通常用于熟悉牌组。这个教学模式就是无干扰的刷分，刷够足够的分就胜利了。通过玩这个模式，可以体验不同舰长牌风格迥异的 combo 策略。通常建议把 6 个舰长都刷够分，这样在对战时既能知道自己应该怎么玩，还能熟知对手的策略。

正式的单人模式是对抗固定规则的对手。采用的是不对称规则：玩家和 bot 的行动法则是不一样的。我没有玩过对战模式，但据 BGG 论坛玩家的反馈，预设规则把和真人玩家的对抗时会产生的交互：争夺市场卡片、抢占中立地点等模拟的很好。一开始玩的时候，操作 bot 很容易出错，但玩过一盘之后就非常顺畅了，bot 每个回合一两分钟就能操作完，反之自己这边的行动每个回合会花很长时间。可想而之，和人对战应该会有极大的 downtime ，怪不得大多数人都选择了单人 solo 。

但我觉得，如果有个人类对手和自己一样玩过很多盘 solo 的话，再在一起对战应该也是非常有趣的。

官方还为单人模式设计了一个长线的五年计划规则。让玩家可以连着玩 5~10 盘游戏，在每盘游戏间加入了牌组升级：每次胜利都可以加入当局游戏终局时的某张市场卡进入初始牌组，或是 boost 一些初始能力。由于游戏设计了 6 组不同的牌，这相当于需要击败 5 个不同的对手（自动化 bot ），想来不会有太多重复感。我打算熟悉玩所有卡组后就尝试一下这个长线任务，应该会很有趣。

很想买一套实体版，但在淘宝上找不到代购，甚至目前美国那边也缺货等着重印。我这几天都是在桌面模拟器上玩的（有玩家制作的 mod ）。我的感觉是，由于电子版缺少触感，细节更容易玩错。即使很熟悉后，游戏效率还是比不上实体。这点和版图游戏颇为不同，这个几乎全部用卡牌作道具，假若是实体牌的话，电子版只在洗牌时会便利一点，打牌及查看牌面要麻烦很多。而很多版图游戏，电子模拟器在 setup 以及游戏过程中的摆放都会更方便。

作为 solo 游戏，实体版最方便的地方在于易于反悔。只要没有信息揭示环节（例如抽牌后查看），大多数行动你都可以方便的在牌桌上 undo ，尝试各种不同的组合。电子模拟器上的 undo 操作一不小心就把桌面状态弄乱了。毕竟桌游除了桌面，人脑里还有一整套游戏状态，缺少实体会让大脑负荷要重得多。

谈点体外话。由于这款游戏规则相对繁杂，我尝试用 AI 辅助学习游戏规则，使用的 Gemini 。可惜这个游戏还太新，网上资料太少。导致 Gemini 对游戏规则细节知之甚少。但它又表现得很懂，对话中自信满满。我问了很多规则细节结果都是错的，即使我让它指出细节出至规则书上具体哪里，也全是幻觉。甚至引用论坛网友的讨论也能理解错误。最后，我还是得自己推敲规则书，或是用传统的搜索方法找到 bgg 论坛规则讨论版面的帖子，研读作者写的 FAQ 等等。和 AI 的问答阅读起来固然舒服，针对性很强（不像规则书读起来那么累），但我实在没有能力鉴别 AI 的错误。毕竟我原本就是因为不懂规则才去问的呀。

有些错误还是能看出来。毕竟我玩的游戏很多，可以从作者的游戏设计思路角度去考虑。玩的过程中有疑问去问 AI 。对反直觉（感觉游戏不应该这样设计）的答案有所警惕，可继续追问。但有些真看不出来。

比如我在和 bot 对战时，触发了一条 bot 需要 log 一艘飞船，我不知道该如何处理。（特地用英文术语）问了下 AI 。AI 告诉我应该把最近 bot 部署的 ship 卡 log 起来，并将同一地区的所有外派部队收回。但后一条是 AI 自己编的规则，我在规则书中怎么都找不到对应的文字。反复询问，AI 都表现的信誓旦旦。让我去查规则书某个章节（其实不存在）。它还引用了 BGG 论坛的帖子。而我仔细研读了大篇的帖子后，确定是 AI 混淆了 log 和 dismiss 的处理方法。

再有一例：游戏的舰长面板分 A/B 两面，供玩家选择。A 面只有一个任务，B 面有三个任务，其中一个和 A 面任务完全相同。完成 B 面的任务还有额外的 VP 奖励。我一开始非常不解，初看起来，A 面没有任何优势，因为 B 面不仅提供了 A 面的选择，有额外 VP ，还可以有更多选项。我在规则书上也没有找到选择 B 面的惩罚。带着这个问题我询问了 gemini ，它在搜索了 bgg 论坛后，又胡扯了一堆什么 A 面让玩家更专注，完成难度和行动奖励不同（实际完全一致的）。但实际上，核心差别其实是：B 面的科技/军事/影响力等导轨设计不同（我一开始没注意到，规则书里也没提这个差异），而 BGG 论坛里针对这点讨论的帖子中，下面好几条回复都强调了这一点，gemini 恁是在查看帖子后，把这条最重要的信息忽略掉了没告诉我。

结果，我和 AI 的这些对话并没有帮我节省理解规则的时间。不仅自己重新反复研究规则书，还花了更多时间去论坛看帖（当然这不是坏事）。我想，如果我让一个人类游戏玩家教我，若是自己没怎么玩这个游戏的话，都不会表现的如此自信吧。如何辨别 LLM 提供的信息中哪些确有价值会变得更加重要。LLM 的语言表达能力越来越强，也会变得越来越有欺骗性。

读小说真的需要时间和心境，因为进入心流状态更慢。如果长时间无法进入状态，很容易就读不下去；但一旦读进去了，比玩游戏（互动形式）或看影视剧（多媒体形式）更让人沉浸和回味。你可以对精彩处反复斟酌体会其中的情感，也更容易停下来脑补作者在情节上的留白。阅读节奏完全由自己控制，可快可慢。鉴于制作成本，小说的多样性远超其它媒介，提供的选择就更为宽泛。

我最近尝试使用 AI 来提升我的阅读体验。首先发现的是 AI 非常适合荐书。我使用的主要是 Gemini ，免费的版本就足够了。我可以先列举一些我很喜欢的书，让它帮我推荐更多。在初选的名单中，再通过对话了解书的特色。为了避免自己总是阅读类似的书，也会让 AI 推荐一些我之前没有尝试过的类型。当然，小说本身还是人创作的，通过推荐作者比推荐书本身更有效率。

这两个月我想读点太空歌剧类的小说，但老一点的名著基本都看过了，所以转向近十年的新作。另一方面的原因是大多数科幻小说本身就有时效性，这些年人类现实中的科技发展很快，文学家的幻想很容易随着时间和现实脱节。

但我很快就发现，想读新一点科幻小说最大的问题是中文版的翻译速度完全跟不上。AI 推荐的书 90% 都没有中译版。即使把时间放宽一点，十年前的长篇，往往也只翻译了开头。这很好理解：如果出版了第一本销量不如意，可想而知后续会更不理想。这在经济上是绝对理性的行为，可对粉丝来说颇有点难受。

题外话，桌游领域也有点类似。桌面游戏通常也是由单个人设计，受者也非大众。即使设计者想好了出一个系列，若前作卖得不够好，扩展包也就难以发行。我最喜欢的桌游设计师 Thomas Lehmann 解释过 Res Arcana 的第三个扩展 Res Arcana Duo 为什么作为一个（看似简化过的）独立游戏发行而不延续扩展包的形式：必须想点办法扩大这个系列的玩家群，否则扩展包的销量只会越来越少。作为中文用户，我对 Res Arcana Duo 至今没能出中文版还是有点伤心的。希望今年的新作 Dark Pact (2026) 黑暗契约可以出中文版。看完介绍，我对这个纯粹的卡牌构筑游戏颇感兴趣。

我是 Old Man's War 系列的忠实粉丝，很喜欢 John Scalzi 。他的书读起来一点也不累，那种书中遍处可见的程式员式的冷幽默颇对我胃口。我前段时间在京东上买了一本互惠帝国系列的第一本《崩塌的帝国》。收到书时是一个暖日的下午五点，晚上十点就合上了书页，中间除了正常吃了个晚饭，别的时间都在读书。读这本书的另一个动机是我想多看看关于太空旅行的不同设定（以给设计我那个关于太空航行的游戏提供灵感）。读完了这本书后，除了很满意书里的科幻设定外，还很期待后续的故事发展。

可惜这套三部曲的后两本一直都没有翻译成中文版。

我觉得我近些年的英文阅读水平提升了不少，要不尝试一下直接读英文吧。试了一下，离享受读书还是颇有距离。阅读小说需要一个流畅的体验过程，无法顺势进入心流，阅读就变成了一个苦差事。文学类作品和技术类文章差异很大，能顺利阅读技术类英文，不等于读小说也没问题。我想还需要更多的阅读练习，而学习必然辛苦，这不是我目前想要的。

隔了两天，我尝试了另一个方法，这是我发现 AI 能提供给我的另一项重要帮助：翻译阅读。

我觉得，技术类文章和文学类创作最大的不同是：前者追求用精炼准确表达知识，后者需要在描述作者构思的情节之外传达情感。理解一本小说，需要基于对小说中人物和故事的理解；正如翻译一本技术书，你得理解其中的技术原理。这也是为何机器的逐句翻译无法做到准确的原因。大语言模型应该能改善翻译，但我一开始尝试的还是直接的 google translate 和装在本地 ollama 中的 translategemma 本地模型，对小说直译。

用不同方法，经过几个章节的体验，我发现最适合我的是让机器完全对译，不做任何针对中文语境的加工，并以中英对照的形式一段段话展示供我阅读。我主要还是针对中文阅读，虽然语言感觉有点蹩脚，但因为我知道信息原本是英文的，而我又有相当的英文语法知识，所以大脑很快就能适应，在阅读过程中自动转换为合适的中文理解。由于是机械直译，反而不会缺失信息。当觉得句子难以理解时，迅速跳转到英文原文处，通常就明了了。读到精彩的对话，往往回味一下英文原句更有感触。

有些句子颇难理解。这时可以打开一个 Gemini 对话，提供它足够多的上下文，然后贴上原文，Gemini 可以解释得非常清楚。毕竟这是 10 年前的小说了，我估计小说的原文本身（甚至第一卷的中译本）就是大模型的训练材料。比如这次我就学到一个知识：在英文语境中，皇帝会自称 We/Our 而不是 I/My ，用来指代个人和背后皇权的双重身份，这和中文背景下，皇帝自称“朕”颇有共通之处。第一次读英文直译时，我会对翻译器输出的“我们”有所疑惑，但随即和 AI 讨论就学到了这个。第一卷的中译本中，译者恰如其分的选择了“朕”来翻译 We ，google translate 这种直译显然是做不到的，但 Gemini 有了上下文就能选择这种译法。我很怀疑它受了训练语料的影响（被中译版的文本训练过）。

我用这个方法读完了第二本《the consuming fire》，大约花了 2-3 倍第一本的时间，阅读速度的下降是很明显的，但可以接受。我觉得稍加训练就可以改善到完全不影响阅读心流的状态。然后我读了第三本《The Last Emperox》，居然和读第一本一样的时长。但我觉得倒不是我快速适应了这些新的阅读方法，而是这个系列三本书的故事结构其实是类似的，读到了后面，跟上书的节奏越来越容易了。阅读长篇小说的过程有点像是在在脑子里逐步搭建作者构建的世界，然后一点点填上细节，最艰难的部分在最前面，后面就是顺理成章的活。

即使情节上有点雷同，我还是很喜欢这套三部曲。

这两天在补《The Expanse》小说的最后三卷，不需要等美剧了 :)

最近坚持的还不错，每周可以保证至少 3 次跑步。现在的心肺能力明显好了很多。去年刚跑步时，每跑 5-10 分钟就需要步行几分钟缓缓，不然心率很容易超过 140 （我给自己定的心率上限）。现在差不多可以保持心率在 140 以下连续跑完 4 km 了。大约花费 30 分钟。这差不多是 8km/h 的平均速度，前半程会更快一点，后半程为了保持心率需要降一点速度。

我觉得另一方面的原因是在冬季，跑起来不那么热。现在会挑选中午有太阳的时候跑，晒晒太阳更舒适。跑完后也没特别累的感觉，只是在最后 10 分钟有一点点难受，希望快点结束。但每次还是坚持跑满 30 分钟。

我家附近 500 米处开了家抱石馆。在两个月前，我带可可去了一次，她莫名其妙的喜欢上了抱石。去了两次后就让我给她办张月卡。我说，次卡每次 95 ，月卡 750 ，一个月要去 8 次以上才划算。她说没问题，几乎天天晚上让我带她去。虽然有一半的动力是去岩馆撸那只胖猫，但看得出来是真的喜欢。我之前也带云豆出去攀岩，从小到大爬过上百次，谈不上讨厌，但始终爱不起来，我也没逼他。后来可可长大了一点，去过两次明显没有兴趣，我干脆就不带她去了。这次莫名其妙的爱上抱石，我是没想到的。

一开始，她只能爬 v0/v1 的线路。但进步非常快，她有从小练起的舞蹈基本功打底，身体的柔韧性特别好，尤其在爬平衡线上特别有优势。在岩馆中超过很多大人（新手）也颇为得意。在第二张月卡时，几乎可以完成所有的 V2 线路，并勉强可以挑战 V3 了。毕竟身高臂展上有劣势，一些成人可以顺利完成的 V2 线路，她需要多做几个动作，无形中提高了难度。

我跟着她也办了月卡，但不会每天爬，有时就是看着教一下，但也比过去勤快了许多。水平也跟着上升。现在可以爬一些 V4-V5 的线路了，而上次在这个水平还是小孩没出生前，体重在 75kg 以下的时候。

现在体重保持在 83kg-84kg 之间，已经很久没有降低了。比半年前再减了大约 2 kg ，比开始跑步前最重 93kg 时几乎减了 10 kg 。考虑到力量（肌肉？）也有所增长，还算满意。身边很多人都说我前两年日益见长的肚子又消失了。希望未来一年可以把体重降到 80kg 以下。

体能的上升对爬高墙的帮助特别明显。去年时，我去岩馆爬高墙，差不多 3-4 条线后就需要躺下休息。现在可以爬满两个小时。最近开始恢复爬先锋（比顶绳更消耗体力，我已经有 10 年没爬过了），发现自己又可以比较轻松的完成 5.10c/d 左右的先锋线路了。去年野外去了多次英西，一次阳朔，一次六盘水。野外先锋还没怎么爬，明年应该可以逐步恢复。

另，痛风未再来过。但尿酸水平并未降低，也没有更高。

还有一个身体的小问题值得注意：有次在去阳朔的车上和同车的岩友聊天。我说我的指关节常年疼痛，是不是大部分攀岩者都是这样。他们的水平都比我高一大截，说并不是这样，这种现象只在部分超高水平的岩友中听过，并建议我保护好指关节，减少抱石中那些指力线路。

我回头和 gemini 讨论了一下，建议是差不多的。另外可以做一些反向的力量训练，我买了一根套在指头上外撑的橡皮筋每日练习。也正是这个原因，我现在没有跟着可可一起每天抱石，并在刻意减少了需要做 Crimps 的线路。目前恢复的还不错，至少日常不爬的时候关节不疼了。

可可还拉了一个同班的小女孩一起抱石，我意外的发现她爸爸的爱好是跑马拉松。我请教了他许多长跑的问题，他说下次带我跑一次 8km 再加到 10km 。据说他从高中开始长跑，一直停留在每次 5km 的量，直到有人带着跑才越过这个坎。虽然他真的很爱长跑，但说每次跑马拉松，跑到最后也是非常难受的，全靠意志力坚持下来。

虽然云豆对和我攀岩兴趣不大，却意外的愿意和我一起跑步。部分原因是他意识到自己体重有点超标了。目前是六年级的寒假，身高 1.74m ，体重最重时有 77kg 。我说你还是跟我跑步吧，我能减下来，你也可以。

寒假第一次跟我跑了 4 km 累得不行，后来我便随着他减到 3km 一次。毕竟是小孩，慢慢的就适应了。和他一起跑步，也帮我把速度提了起来。他嫌我跑得太慢（一开始我跑 4km 需要 35 分钟），父子俩跑了几次后便在半小时之内了。这跑步的兴趣也来得莫名其妙，最近一周就跑了 5 次。（体重还真减了一些，75kg）

今天跑完我告诫他，切忌一时热情，锻炼身体是个长期的过程，贵在坚持。每次跑到最后，总会有点难受的，需要一些意志力说服自己坚持下来。有个伴当然最好，可以相互督促。养成习惯后，日后住校，也能有自驱力。

ps. 教育子女真的是个长期的活。我琢磨着儿子愿意跟我跑步还有一部分原因是最近两个月每晚带着妹妹攀岩有点懈怠了他，或许是有点吃醋：过去我总是陪他比妹妹多一点的。而妹妹似乎不愿意跑步…… 结果，我也被动的增加了颇多的运动量，何尝不是件好事。

我感觉体验比较接近的有 Voidfall (2023) 和 Spirit Island (2017) 。因为灵魂岛（spirit island ）更早一些，而且 steam 上有官方的电子版，bgg 上总体排名也更高，所以我在上面花的时间最多。

这两个游戏的特点都是确定性战斗机制，即在战斗时完全没有投骰这类随机元素介入。在开战之前，玩家就能完全确定战斗结果。战斗只是规划的一环，考虑的是该支付多少成本或许多大的收益。而且灵魂岛作为一款卡牌驱动的游戏，完全排除了抽牌的随机性，只在从市场上加入新牌（新能力）时有一点随机性。一旦进入玩家牌组，什么时候什么卡牌可以使用，完全是在玩家规划之内的。这非常接近 dotAge 中规划应对危机时的体验。

灵魂岛的背景像极了电影 Avatar ：岛的灵魂通过原住民发挥神力赶走了外来殖民者。每个回合，把神力的成长、发威（玩家行动）和殖民者（系统危机）的入侵、成长和破坏以固定次序循环。其中，殖民者的入侵在版图上的地点有轻微的随机性，但随后的两个回合就在固定规则下，在同一地点地成长和破坏（玩家需要处理的危机）。扮演岛之灵魂的玩家可以选择到破坏之刻去那个地块消除危机，在此之前玩家有两个回合可以准备；也可以提前在殖民者成长之前将其消灭在萌芽之中，但这给玩家的准备时间更少，却往往意味着更小的消耗；还可以暂时承受损失，集中力量于它处或更快的发展神力。游戏提供给玩家的策略选择着实丰富。

在 dotAge 中，版图是需要规划的，玩家需要取舍每个格子上到底放什么建筑以达到连锁功效最大化。而在灵魂岛中，每张法术会提供一些元素，同一回合激活的元素组合可以给法术本身效果加成。我觉得这两个设定有异曲同工之秒。我在思考游戏设计时，受 dotAge 和 Dawnmaker 的影响，总觉得需要在版图的位置上做文章才好体现出建筑的组合，玩过灵魂岛才发现，其实单靠卡牌不考虑版图布局其实也能实现类似的体验：几张特定的法术卡组合在同一回合打出会对单一法术有额外加成，而这种组合可以非常丰富。去掉随机抽卡机制，让玩家可以 100% 控制自己牌库中的组合选择；而且总牌量很少，每个回合出牌数及其有限（受单回合出牌数及法力点双重限制），让发牌组合必须有所取舍。这像极了我在 dotAge 的狭小地图空间中布局建筑的体验，这个格子放了这个，那个建筑就得不到加成。

但受限于桌游，灵魂岛的游戏体验和 dotAge 差别还是很大的。我玩了（并击败了）多级难度的灵魂岛，难度越高差异越明显。桌游必须要求短回合快节奏，这让游戏规划的容错性大大降低。dotAge 一局游戏可以玩一整天，即使是超高难度，也允许玩家犯点小错误。由于电子游戏可以把元素做得更多，让机器负责运转规则，单点的数值关系就可以更简单直白。而灵魂岛这种需要在很少的行动中体现复杂计划的多样性，那些法术的真正功效就显得过于晦涩：虽然法术字面上的解释并不负责，但理解每个法术背后的设计逻辑，在游戏中做出准确的决策要难得多。

我在标准难度下，玩了十几盘才真正胜利过一次灵魂岛。之后每增加一点难度，感觉挑战就大了不少；反观 dotAge 我在第二盘就领会了游戏得玩法而通关，困难难度也并未带来太大的挫折感。但现在往上加难度玩灵魂岛，我还是心有余悸，不太把握得住。而且直到现在我都没敢尝试 2 个神灵以上的组合玩法，那真是太烧脑了。难怪实体版桌游都是多人合作，而不是 1 控 2 去玩。

Voidfall 从游戏结构上更接近 dotAge 一点。它完全没有战斗，就是纯跑分。只要你跑分速度超过了系统规则，就胜利了。dotAge 几乎就是这个框架：玩家需要在疾病、恐惧、温度和自然四个领域积累积分抵抗系统产生的四类危机。在每次危机来领前做好准备，也就是积累产生对应领域积分的能力。

但无论是 spirit island 还是 voidfall 都没有 dotAge 中最重要的工人分配机制。从游戏机制角度看，dotAge 更像是电子化的 Agricola (2007) 农场主。因为农场主在桌游玩家中太经典，几乎所有桌游玩家都玩过，这里就不多作介绍了。虚空陨落（voidfall）则是一个比较新的游戏，值得简单讲一下。它没有官方电子版，但在 Tabletop Simulator 中有 mod 可以玩。

和 dotAge 的四个领域有点类似，voidfall 中玩家有军事、经济、科技、政治四个方向的议程可以选择。获得对应的议程卡后，就可以大致确定一个得分路线。不同的路线同时影响着玩家当局游戏的游戏过程。

桌游的流程不会设计的太长，在 voidfall 中只设计了三个阶段，每个阶段有一张事件卡，引导玩家的得分手段。这些事件的效果是可预测的，这和 dotAge 的预言很像。三个阶段也和 dotAge 的季节交替末日来临类似：用规则控制游戏节奏，明确的区分游戏不同阶段要作的事情。一开始生产建设、然后扩张战斗、最后将得分最大化。

我没有特别仔细的玩这个游戏，但从粗浅的游戏体验看，还是颇为喜欢的。过几天会多试试。

我对“确定性战斗机制”这点其实没有特别的偏爱。基于骰子的风险管理机制也很喜欢。

前两年就特别关注过 ISS Vanguard (2022) 这个游戏。最近又（在 Tabletop Simulator 上）玩了一下 Robinson Crusoe: Adventures on the Cursed Island (2012) 和 Civolution (2024) 。这几个游戏都特别重，几句话比较难说清楚，而且我游戏时长也不多，这里就不展开了。

顺便说一句，同样是鲁宾逊的荒岛求生题材的单人桌游 Friday (2011) 是一个非常不错的轻量游戏。如果不想花太多时间在重度游戏上，它非常值得一玩。这是一款及其特别的卡牌构筑类游戏，整个游戏机制不多见的把重点放在卡组瘦身上：即玩家更多考虑的是如何有效的把初始卡组中效率低效的卡精简掉。

游戏上手容易，大约花 5 分钟就能读完规则；设置成本极低，只使用一组卡片；但却颇有难度，我差不多在玩了 20 盘之后才找到胜利的诀窍。淘宝上就可以买到中文版（中文名：星期五），推荐一试。

去年也和朋友聊过很多，但对理清楚自己的想法帮助有限。因为和人聊容易陷入不断的细节解释当中，一些天马行空的想法更容易被质疑，一旦陷入辩论就不太容易跳出来。而且每个人的时间并不固定，很容易造成时间和精力的浪费。和 AI 聊要轻松得多，AI 毕竟见多识广，随便提到的点都能接得上话。不想聊下去尽可以中断，不用担心浪费时间。即使怀疑 AI 出现幻觉，也可以随时暂停下来通过搜索核实。

不过，我觉得和 AI 讨论也有另一方面的问题。那就是太容易顺着你的思路夸大其词。它更像是一个貌似领域知识渊博但只是想讨好你的同好，不断的放出一些华丽的辞藻却在逻辑上经不起推敲。分析起游戏来头头是道，直到谈到我真的玩过上百小时的游戏时，对游戏的细节错误百出。如果我没有这些游戏的真实体验，几乎不可能分辨真伪。一开始我还会想和真人讨论时一样指出它的错误，让它修正后重新发表观点。后来就渐渐放弃了从 AI 那里直接获得真知。把它当成一个比搜索引擎更方便的信息获取入口就够了。

但我依然偶尔被 AI 的总结惊艳到。比如说有一场主题为模拟类型游戏的话题，聊到最后 AI 总结：

成功的模拟游戏本质上是“熵增模拟器”。设计师的任务是制造一个不断趋向于“热寂”和“混乱”的世界（交通拥堵、热量堆积、资源耗尽、情感崩溃），而玩家的乐趣在于投入自己的脑力作为“负熵”，去建立一个脆弱但精密的秩序。

所以，在设计时，不要害怕设计“笨拙”的规则（如巡逻员、有体积的货车、会变质的食物）。这些“物理摩擦力”正是通往成就感的阶梯。如果没有这些混乱，游戏就只是一张算好了答案的报表。

要让玩家感到“战胜了混乱”而不是“被垃圾规则恶心”，需要遵循以下原则：确定性的混乱：混乱的原因必须是可回溯的。 提供“高级工具”来解决“基础问题”：游戏初期给玩家简单的工具去面对混乱，中后期给玩家更高级的逻辑工具。从“点”到“面”的连锁反应：混乱不应是孤立的错误，而应该是系统性的连锁反应。

我觉得在这种形而上的话题上，它讲得还是蛮有道理的。但我依然不觉得这些总结真的可以成为游戏设计的指导工具。

当然，让 AI 说什么依然极度依赖你对它说了什么。大多数时候 AI 会信誓旦旦的帮忙做一些具体设计（当我想设计卡牌驱动的游戏时），可我真的实体化这些卡片试玩后，完全玩不下去。我实在没信心再和它讨论这些卡片设计上的具体细节：真的不如我自己从零设计高效。但有时候，AI 也会对设计游戏这件事情有所畏缩，一旦强调我应该先用卡纸或在桌面模拟器中自己尝试做个原型试试。总之，让我感觉本质上它还是在跟着我的情绪走。完全没有独立思考的痕迹。

意识到这点，我现在更想把今天的 AI 当成一种更高级的知识搜索引擎。从这个角度看，这段时间 AI 的确给我推荐了不少不错的游戏。虽然我仔细玩过之后，这些游戏给我的体验并非完全符合 AI 的描述，我还是感谢 AI 让我挖掘出了它们。

尤其值得一提的是 AI 极力向我推荐的 dotAGE 这个游戏。我一口气玩了接近 160 小时。

其实它刚上 steam 的时候我就玩过 demo ，当时只是觉得还不错，但没有深入。前几天 AI 反复督促我要仔细玩一下，我才沉浸了进去。这是款回合制没有战斗的城市建设游戏。随机元素很少，几乎所有要面对的灾难，都在游戏规则下提前预示给玩家。玩家要做的就是提前规划每个回合的行动，通过精算赢得游戏。值得一提的是，游戏推荐的难度和最高难度给我的几乎是截然不同的游戏体验。在默认难度下，即使对游戏规则不甚了解，不需要精确规划，也能通过运气赢得游戏胜利。那种“Push Your Luck”机制驱动带来的胜利是一种相当刺激的游戏体验；但在最高难度下，游戏变得无法通过运气获胜，转而必须精密规划。而这种精算带来的又是另一种成就感。

在玩游戏之余，我又阅读了作者在游戏发售前夕于 reddit 上写的两篇文章，方才了解到这个游戏几乎是作者一人在攻读完游戏设计专业的博士学位后，独自花了 9 年时间制作出来的，颇为震撼。怪不得我在玩的时候感觉这个游戏要深度有深度要广度有广度，完全不像是能短期做出来的。只能说，设计出好的游戏真的很难。

skynet 维护了一份修改版的 Lua ，允许在多个虚拟机之间共享函数原型。这可以节省初始化 Lua 服务的时间，减少内存占用。

跨虚拟机共享函数原型最困难的部分是函数原型会引用常量字符串，而 Lua 在处理短字符串时，需要在虚拟机内部做 interning 。所以 skynet 的这个 patch 主要解决的是正确处理被 interning 的短字符串和从外部导入的函数原型中包含的字符串共存的问题。具体方法记录在这篇 blog 中。

这次 Lua 5.5 的更新引入了 external strings 这个特性，已经大幅度提升了 Lua 加载字节码的速度。我比较倾向于在未来不再依赖额外的 patch 减少维护成本。所以建议新项目避免再使用共享常量表，减少对 patch 过的 Lua 版本的依赖。

Lua 5.5 基本上兼容 Lua 5.4 ，我认为绝大多数 skynet 项目都不需要特别改动。但在升级后，还是建议充分测试。注意：更新仓库后，需要用 make cleanall 清除 lua 的编译中间文件，强制 Lua 重新编译。直接 make clean 并不清理它们。

Lua 5.5 有几处更新我认为值得升级：

1. 增加了 global 关键字。对减少拼写错误引起的 bug 很有帮助。skynet 自身代码暂时还没有使用，但后续会逐步添加。

2. 分代 GC 的主流程改为步进式进行。过去版本如果采用分代模式，对于内存占用较大的服务，容易造成停顿。所以这类服务往往需要切换为步进模式。升级到 Lua 5.5 后，应该就不需要了。

3. 新的不定长参数语法 ...args 可以用 table 形式访问不定长参数列表。以后可以简化一部分 skynet 中 Lua 代码的实现。

这段时间我每天晚上给她讲一点点数学，都是课本上的内容，然后我再稍稍发挥一下。几次之后，我发现最大的问题是她觉得数学很无聊。

她似乎比较抗拒学新的知识，更喜欢用熟悉的方法。去年我发现她计算能力有问题，每天给她做加减法练习，总算不再用更早年我教她的 +1 法算加法了：即计算 7+8 的时候，算 8 次 +1 ，也就是数数。二年级学了乘法，乘法表也背了，但现在做应用题，本该用乘法的场合，她还是习惯连续算加法，一旦乘数太大就会出错。要用除法的时候就更混乱了，并不是用减法，而是靠猜测来试。大脑里完全没有建立乘除的概念。乘法表更像是独立的有背诵任务的诗词，还没古诗那么有趣。

我说：数学其实是这个世界上最有趣的东西。

她说：为什么呢？

我说：这个世界上有趣的东西很多，但数学是性价比最高的。一本数学书很便宜，但可以让你读很久。从中发现有那么多有趣的事实。原来解决不了的问题，知道方法突然就明白了。如果是自己找到的方法，就更让人兴奋了。

她说：我还是觉得数学没意思。

我说：慢慢来，不着急。首先不要排斥它。学数学其实不需要硬背那么多东西，我小时候最不喜欢背书了，所以才喜欢数学的。因为数学是最不需要背的，只要你从原理出发，一步步理解，最后什么问题都能解决，只是速度慢一点。多练习就快了。那些需要记住的知识，用的多就自动记住了，不需要专门背。

还好她不排斥我给她讲数学。前段还给我说，为什么只有你给我讲数学我才懂呢？

就这么，我每天（半个小时左右）给她讲一点点。我觉得其实也讲不了什么，聊胜于无。有一点我觉得还不错，她有数学作业不会做，会主动来问，不需要等我检查作业。一点拨就懂了，但第二天又会有新问题，依旧靠自己解决不了。不过，知道自己不懂算是个好的开始吧？

昨天晚上，她说今天学的直线、射线和线段。这个好简单，之前的都好难。

我说，我出道题目吧。在纸上画五个点，你看看一共可以连出多少条线段。

她说，我去拿张纸来。

画了半天，数错了。可可说，我脑子好乱啊。

我说，我来教你方法。我们先把你画的点标上数字编号，从 1 标到 5 。然后你每次连一条线段，就把两端的数字记在图案下方，顺着写整齐。最后，数下面的记号。

这次她算对了。但是，好麻烦啊，为什么要用这么麻烦的方法。我想偷懒就会搞错。

我说，其实，你不需要画图，只用写数字就可以了。但是不要随便连线。1 号点先和 2 号点连，再和 3 号点连…… 顺着数字从小到大，这样就不会搞错。不需要真的把连线图画在纸上，在脑子里相像就可以了，只需要在纸上写下 1 号点能和几个点连成线段就可以了。这里，你写个 4 。然后再看 2 号点。

她画了一点时间，终于发现了规律，列出了算式 4 + 3 + 2 + 1 = 10 。

我说看吧，其实这不是一道绘图题，用数学方法，它转化为一道计算题了。

可可好像有点兴趣了，说我现在可厉害了，我能算 10 个点的问题。我说你试试。可可的悟性没我相像的那么高，并没有直接写出 9 到 1 的等差数列，每个数字都想了一会，直到 4 以后才有点把握后面应该是 3 2 1 。但是，面对长达 10 个数字的加法算式，可可说，我知道方法了，这个算起来太麻烦了，我不算了。

我说，你不是学了乘法吗？其实，这个问题不一定要用加法做，我告诉你怎么用乘法解决这个问题，就不用算这么麻烦的算式了。你看，刚才你连线的时候，把 1 号和 2 号连起来之后，从 2 号做起点就不连 1 号了。因为 1 到 2 和 2 到 1 是同一条线段。两个点之间只可以连一次。但是，如果我们每两个点都连两次，那么这 10 个点，每个都可以连出去 9 条（射线）。

最后，总共画了 10 组，每组 9 条射线，一共是 10 * 9 = 90 条。因为我们每条线段都计算了 2 次，所以答案就是 90 / 2 = 45 条线段。

有了这个方法，100 个点的问题你也能算出来了吧。

可可问，家里有没有有趣一点的数学书，我要看。我翻出了前年带着云豆读过的《我的第一本数学书》。可可翻了一下说，怎么这么多字啊。我说，周末我带着你读。

早上起床的时候，可可问，今天我能不能把昨天那本书带到学校去？

希望她能发现一点点数学的乐趣。

首先是 Decktamer（训牌师）。我玩了十几个小时，把初级难度通关了。

它的新设计是用卡牌构筑的形式重新做了一个宝可梦。和杀戮尖塔开创的战斗结束后抽卡，用战斗胜利的奖励钱买卡、洗卡、升级的模式不同。它的战斗卡是不需要洗的，战斗中死亡就直接消失；新卡片是在战斗中捕获对手获得。加强战斗卡的方式主要是用道具卡杂交战斗卡：从一张战斗卡上抽取需要的技能，加到另一张战斗卡上。

战斗过程更像是万智牌那种更传统的卡牌战斗模式：摆放战斗卡都场上，再由上场的卡片发动能力。这种传统战斗模式不同，发动战斗技能没有额外的资源消耗，而修改成每回合必然从卡片上所有技能中选择一个。这可以避免给同一张卡片合成太多能力造成的不平衡。更多能力往往只是增加了容错性，可以应付更多场景。

玩家卡牌被分成了两个牌堆：战斗卡堆和道具卡堆。这种双卡堆的模式最近的卡牌构筑游戏中比较常见，下面还会再提到。不过这里道具卡堆并不是抽牌堆，更像是一个道具背包，可以随时使用。

我在简单难度通关的感受是：只有最终 boss 有挑战。而这种挑战更像是一个谜题。所以第一次面对最终 boss 我没有一次通过。而是熟悉了它的技能，第二次刻意针对这些技能来升级牌组，这样才通关。整个游戏给我的感觉是，解密成分更重一些，也就是该如何养卡才能解决对手。所以游戏里（简单模式下）有无限次的 undo 。我相信选择更高难度后会有不同的感受。不过暂时没有玩下去。

第二个游戏是 Rogue Hex 。大约玩了 7 个小时，四个设计角色中，前三个获得了胜利。

这个游戏用卡牌构筑的形式重新实现了一个简化版的文明。这是我之前就特别想做，但是没想到合适方案的点子。所以，我在初玩时感觉相当有趣。能把卡牌构筑的乐趣融合到 4x 游戏中相当不错。不过，玩到游戏后期，数值还是有点崩，往往中盘就几乎碾压对手了，但为了胜利，依旧需要机械性的玩很多回合。

当然，我觉得它的核心机制设计的还是挺好的。这是个新游戏，平衡还有很大的改善空间。

在这个游戏中，基本资源分别是：劳动力用于抽牌打牌、食物用来发展发展城市、计划用来移动地图单位、信仰用来重置、金钱用来替换前面的基本资源。这些资源有仓储上限，回合结束的时候超过上限的部分会浪费掉。我认为“仓储限制”是让玩家有更多选择的核心设计点之一。

无仓储限制的成长涉及两个点数，科技用于增加正面 buf （类似杀戮尖塔中的神器）以及生产用于增强牌组。我认为设计两个的原因也是给玩家提供选择。大多数情况下，发展科技就会降低生产的增速，反之亦然。

像文明那样，玩家可以在版图上探索采集一次性资源转换为一次性消耗的卡片；扩展城市获得永久资源再用卡牌转换为永久建筑或用版图上的工人单位采集转换为卡片。这部分对文明原本的系统还原的挺不错的（至少在每局游戏的前半段很好）。

游戏循环基本上是用抽牌的手牌积累科技点、生产点和上述的基本资源。用这些点数兑换成发展。和文明一样，指挥地图单位探索和攻击对手也是发展重要的一环。把文明游戏机制中的各种操作翻译为打牌，最大的区别在于：原本玩家可以自由分配每个回合的行动，而在卡牌模式下，需要根据抽到的手牌做决定。这有两个方面的变化：其一、原始机制下提供给玩家的选择非常多，容易产生选择困难；手牌是有限的，玩家可以聚焦在有限行动选择中。其二、可选行动有了随机性，玩家需要根据牌组、抽牌堆、抽牌能力去管理随机性。这也是卡牌构筑类型游戏的核心玩法。

但嫁接卡牌构筑类型和 4x 类型系统有一个需要设计的地方： 4x 游戏中每个回合给玩家的选择都是有意义的，如果把太多东西做成卡牌供玩家选择，而每个回合选择受限，很可能极大的降低游戏的容错性，变得太看脸。所以，在这个游戏中，劳动力即用于支付打牌成本，又可以用来抽牌。这等于提供给玩家一个主动增加选择的能力，而不是像杀戮尖塔中那样，抽牌本身也是特定卡片的技能。

我发现很多类似游戏（下面会再次提到）都有这个设计：允许玩家主动花一个特定资源点，就可以抽牌。

但是，这类游戏成长点太多。不像杀戮尖塔那样只是提高和优化卡组，每局游戏后期很难不崩掉。要么前期开荒死掉，要么后期碾压变得选择没有太大意义。我觉得这个游戏还可以改进，我也很期待会使用怎样的解决方法。

最后一个游戏是 Dawnmaker ，也是最近我最喜欢的一个。我玩了 30 个小时，所有难度都通关了。

这个游戏回答了我很多之前没想到设计解法的问题。它对卡牌构筑类型做了更多的保留，没有卡牌战斗部分，更接近一个生存类型的基地建造游戏。玩这个游戏时让我想到了 retromine 和 Stellar Orphans （星际孤儿）。但很多设计处理的更好。

这个游戏就是打出卡牌在六边形棋盘上建造建筑让基地活下去。没有敌人，无需战斗，需要对抗的只是逐步增加的粮食需求。

单局游戏内只有五种资源：粮食、科技点、工程点、行动点、胜利点。赢得单局游戏可以获得金钱，金钱用来升级卡组，在后续的游戏局种获得优势，以对抗难度逐步上升的挑战。

游戏设定了两个卡堆：手牌堆和市场建筑堆。这两个卡堆分开抽牌。手牌在当前回合打出的工程点可用来在市场堆购买建筑，并在版图上建造。建筑放在版图上就有了持久能力，通常用于配合手牌更有效的获取资源。和 Rogue Hex 不同（它没有双卡堆），购买的建筑卡必须立刻摆在版图上，而不是置入抽牌/弃牌堆。从我游戏的感受看，这是个没有巧妙的改良设计。

星际孤儿也有市场设定，但受传统卡牌构筑规则的影响，还是设计成从市场购买，投入弃牌堆，抽到手牌使用的循环。控制前期卡和后期卡的方式也只是简单的通过市场掉率决定。但在 Dawnmaker 中，通过市场卡分级严格区分了前期卡和后期卡。如果城镇中心没升级到特定等级，对应的卡片也不会在市场上出现。刷市场只需要消耗科技点，这点和 Rogue Hex 用劳动力抽卡异曲同工。但双卡堆设计避免了直接抽行动牌。因为这类游戏中，行动牌和建筑牌本质上是有区别的。Rogue Hex 用一次性消耗卡表达建筑，我觉得是因为没能跳出传统卡牌构筑规则。

在版图上摆建筑是这个游戏的核心玩法。在非卡牌构筑游戏中非常常见，我也见过很多企图和卡牌构筑类型结合的游戏，只有这个我认为结合的最流畅。在星际孤儿中也有四个 slot 用于安装卡片获得永久能力，但只是点缀，而且安装位置并不改变游戏。

Dawnmaker 的建筑摆放相当重要。甚至比构筑行动卡堆更重要。其变化也非常多，留给玩家很大的选择空间。这种在六边形弃牌上填格子的玩法在桌游中很常见，技巧深度和乐趣很有保障。最近几年也有很多电子游戏基于这类玩法，但我觉得更像桌游电子化，而我玩 Dawnmaker 的感觉则更接近电子游戏的体验。

Dawnmaker 在 steam 上有 demo ，有兴趣的同学可以试试。但 demo 只能玩第一个角色，我在正式版本中尝试了另外两个角色，让我惊讶的是，其实三个角色共享同一套完整的卡池。仅仅只是初始卡组不同，但游戏风格差别非常巨大。而且，游戏中并不设常规卡和稀有卡，抽到的概率是一致的。也就是说无论你用那个初始卡组开局，都可能抽到所有卡片，概率是一致的。但玩游戏的感受却并没有那种：我抽到了特定卡以后，游戏就变容易了的感觉。在熟悉了游戏之后，几乎任何卡片搭配都可以玩出花来。

三个初始卡组（角色）标注的是 regular ，complex ，extreme 。我一开始以为是三档难度，通过调整数值减少容错性，需要逐级更熟悉游戏规则才能玩下去。

通关后的感受是：的确越后面的角色需要对游戏更熟悉。但并没有在数值上减少容错性，而是更复杂的角色代表的需要更复杂的卡片 combo 。三个角色玩的体验也很不一样。

虽然在玩第一个角色时，我能感受到不同的流派：用大块农田组合堆砌粮食产能、用主动激活的方式生产粮食、用科技转换粮食等等。胜利点的来源也可以来源于建筑、科技等。但直到我玩第二个角色才发现，靠版图主动技能的组合也可以另成一番景象。而第一个角色更多的思考如何在版图上摆放建筑的位置。第三个角色更是要求不断的拆建建筑，让版图的布局变成动态的。学会这些玩法后，回头在不同角色中也可以实现（因为共享一个大卡池）。

Dawnmaker 的数值调的非常好。每局游戏的生死总是在一线间。尤其是后面的角色更偏重于主动触发版图技能，相比调配行动手牌多了一层选择。有时候看似死局，仔细思考后居然是有解的。同时又需要一点点运气，概率管理原本就是卡牌构筑游戏的核心，在小丑牌中体现得淋漓尽致，Dawnmaker 也有类似的体验。

在游戏规则上，给我的一点启发：

如何把卡牌构筑结合到基地建设类别游戏上？加入版图元素，把建筑卡堆和行动卡堆分离是个不错的设计。

游戏资源种类不需要太多，不需要完全用卡牌表达。传统的卡牌构筑基本规则中，资源点都是靠当前回合的行动手牌生成，不留到下个回合。但建设类游戏的建造资源完全可以跨回合保留积累，但需要强调仓储上限。这样就可以提供给玩家足够的行动选择和组牌的多样性。

非战斗类游戏，可以用不断上升的需求来制造压力。而需求的上升速度可以和玩家的发展规模挂钩。这样玩家就必须在长期发展和短期生存困境上做出抉择。从自己组建的卡堆中抽卡是卡牌构筑类游戏的核心乐趣来源：提供给玩家更丰富的风险管理手段。

ps. 其实只要把游戏暂停下来立刻就不卡了。虽然我直到这个游戏需要的计算量非常大，但是卡交互操作肯定是实现的不对。因为这并不是因为渲染负荷造成的卡顿，可以让游戏时间流逝更慢一些，也不应该让鼠标点击后的界面弹出时间变长。

在暂置游戏前，我先把一些关于游戏设计上的理解先记录下来。也是对上一篇的补充。

在最初几十小时的游戏时间里，我一直想确认游戏经济系统的基础逻辑。和很多类似策略游戏不同，欧陆风云5 在游戏一开始，展现给玩家的是一个发展过（或者说是设定出来）的经济系统版图。玩家更需要了解的是他选择扮演的国家在当下到底面临什么问题，该怎样解决。这不只是经济，也包括政治、文化和军事。而很多游戏则是设定好规则，让玩家从零开始建设，找到合适的发展路径。

大多数情况下，EU5 玩家一开始考虑的并不是从头发展，所以在游戏新手期也没有强烈的理解游戏底层设计细节的动机。不过游戏也有开荒玩法，在游戏中后期势必会在远方殖民、开拓新大陆；甚至游戏还设计了让玩家直接转换视角以新殖民地为核心来继续游戏。但即使的重新殖民，在四周鸟无人烟的地方开荒，和在已有部分发展的区域附近拓展也完全不同。

我十分好奇这样一个复杂的经济系统是怎样启动起来的，所以仔细做了一点归纳笔记。不一定全对，但很多信息在游戏内的说明和目前的官方 wiki 都不完整，只能自己探索。

游戏中的一切来源于“原产”，官方称为 ROG ，比较类似异星工厂里的矿石。上层的一切都是从原产直接或间接获得。版图上的任何一个最小单位的地块，只要上面有人口，就会不断生产出唯一品种的原材料进入这个世界。它和国家控制力、市场接入度都无关系。比原材料更高级的产品都是由原产直接或间接转换而来。

货币本身在世界中不以资源形式存在，货币本身也没有价值。货币的存在在于推动包括原产在内的原材料和产品等在世界中的流动。所以，世界中即使不存在经济活动、没有货币，亦或是货币急剧膨胀，这些因为国家破产而债务消失等让货币总值急剧变化的行为也不会直接影响这个世界中的物资变化。即没有很多游戏中直接用钱凭空兑换成物资的途径。

换句话说，如果整个世界缺铁，那么只能通过生产手段慢慢的产出，再多的钱也无法变出铁来。但分配更多的人力去生产、更高的科技水平可以获得铁产量的提升、使用更高效的配方、各种提升生产率的增益等等都可以加快铁的产出速度。

从一个世界的局部看（这是一般玩家的视野），获得原材料的方式有三种：

1. 养活更多的劳工或奴隶开发对应原产。
2. 在合适的地理位置上用劳动或奴隶生产。
3. 从附近的市场进口。

第一种方式，玩家拥有对应原产地，然后在地皮上增加人口。但新增人口是农民，还需要从农民升级成劳工。国家 buf 中，默认只有原住民满意度对产量有轻微的增益。

第二种方式，玩家有更大的自主性。以铁为例，只要是湿地地形或者地皮邻接湖泊，就可以主动产铁。这种生产除同样需要劳工外，还有原料开销：把炭转换为铁。这种生产方式直接被市场接入率打折，即离市场越远的地方单位人口的生产效率越低，但同时有更多增加生产率的增益途径：最基本的就有当地劳工识字率和市民满意度。和虽然和第一种方式一样需要劳工，但游戏似乎会先满足原产需求的劳工，多出部分才进行建筑生产。所以在劳工不足时，若需进行建筑生产，需要主动减少原产等级。因为生产建筑可以由玩家主动关闭，但原产似乎不行。

第三种方式，通常需要在本地市场拥有一定的市场容量。在不考虑成本时，甚至可以亏本进货。对开荒来说，进口原料比进口成品的优势就在于占用更少的贸易容量。

为什么上面以铁举例，因为铁是开荒时最重要的资源。虽然木头和石头也很重要，但游戏把木材、粘土、沙、石头设定为一般物资，所有地块都有一个很低的默认产能，从市场角度看，根据市场规模，每个市场总有一定量的供给。但铁不属于这种物资。

建造建筑需要的基本材料是砖头，砖头可以通过基础建筑，从粘土或石头转换。

开发原产需要的基本材料是木头或工具。大多数基础建筑的生产配方里都需要工具。而工具在非城市生产建筑中，只有乡村市场可以把铁转换为工具。所以、如果开荒时的市场中缺铁，就只能通过进口。进口制造工具的铁比进口工具更能利用上贸易容量（铁和工具的单位贸易容量相同，但铁到工具以 4:5 转换）。

铁矿在版图上相对其它资源更少，所以一般开荒需更关注市场覆盖下有无湿地地形或有无湖泊，同时需要用充足的木材供应，可以把木材转换为炭再转换为铁。

一旦单一地块上的人口超过 5000 ，就可以升级为城镇，这种生产就有更多选择。以工具制造来说，城镇里就多出了用石头或铜转换为工具的配方。尤其是石制工具的途径，虽然效率很低，通常利润也很低，但贵在石头有保底产出。城镇的升级需要砖头和玻璃，玻璃可通过沙子转换，而沙子有保底产出或通过工具加木材转换。

开荒期间，解决了木头、砖头、玻璃、工具这四种基本货物（前三种是各种基础建筑建设需求，最后是大部分生产转换配方的必须）后，就要考虑提高产能的问题，这里的核心之一是纸。因为劳工识字率影响着生产率。纸是印书的原料、书是图书馆的维持品，而图书馆以及更多提高识字率相关的建筑都需要书。

造纸术需要纤维作物或皮革或布匹。纤维作物的基本生产方法是在对应农场通过牲畜木材工具制造；而牲畜则在耕种村落通过工具加粘土转换；皮革则可以在森林村落通过沙加焦油和野味转换，其中焦油在一般木材产区都可以通过木材转换得到。

另一个重要的资源是人口。它在游戏中和钱一样重要、甚至更重要。因为一切的生产行为都需要人。对开荒而言，升级到城市对效率影响最大，这里的硬性要求就是 5000 基础人口。除了主动殖民，就是本地土著转换、周边迁移（集中）以及自然生长率。这些都可以通过内阁行为略微加速，同样关键是修定居点（同时加移民吸引度和自然生长率）。定居点除了 250 农民外的维持成本是石头、木头、羊毛、野味。前两个一定有保底产出，后两个不是必须，缺少只会让效率打折，但供应充足可以发挥全部性能。定居点和乡村市场都占用农民，在最初阶段，我感觉乡村市场更重要一些，毕竟可以制造工具，还能提供宝贵的贸易容量。

不同阶层人口除了产生固定需求（吃掉本地市场的部分产出）外，更基本的需求是食物。EU5 中的食物系统设计，我觉得也是很巧妙的。

食物并不是货物的一种，而是和钱一样，表示为一个单一值。最主要的食物来源是生产带食物属性的货物（被称为食物原料）的副产品。属于食物原料的货物，被设定了不同的食物倍率，这就让有些食物原料产生食物的效率更高。不工作的劳工默认会以一个较低的产能生产食物，所以不必担心多出来的劳动力被浪费。另外，农民在森林村落里，虽然产品皮革并非食物原料，但生产行为本身被设定了食物产能。另外，农村相对城市有额外的食物产能的乘数增益。

食物的仓储按省份为单位计算，省份归属的若干地块共享一个食物仓库。在每个省份会优先填满仓亏，多出的部分卖给了所属市场，这里是不计市场接入度的。而一旦仓库有空间，就会从所属市场购买。战争是影响它的一个变数。因为军队也会从这个仓库中获取食物，围攻会阻止市场上的食物交易。

食物在本地市场上的交易行为会影响到本地食物价格，购买食物的开销和销售食物的收入是分开计算的，全部通过国库完成。市场间并不能单独交易食物，但通过对有食物原料属性的商品的交易，会产生附带的食物流通（但并不会产生额外的货币流动）。我觉得理论上会出现市场仓库中的食物储量为 0 ，但依然出口食物原料的情况，但实际玩的时候并没有发现，所以不清楚游戏怎样处理。但我猜测，食物流通是在单独层面计算的。既然超出市场食物容量的食物似乎就消失了，那么也可以接受万一食物储量为 0 却继续出口的情况，把储量设为 0 即可。

最后，写写我对税收的看法。

简单说，游戏里的经济活动产生了税基。税基中按王室影响力直接把钱进入国库，另外的钱按阶层影响力分到了各阶层。但玩家可以对阶层分得的钱征税，让这些钱进入国库。

看起来，在不造成阶层不满的前提下，税率越高，国库收入就越高。但实际我玩的感觉是，其实税基才是整个国家的收入，国库仅仅是玩家可以主动调配的部分。阶层保留更多的收入，也会投入到国家发展中去，只不过有时不是玩家想要的方向，甚至是负方向。例如当玩家想削弱某个阶层的影响力时，阶层把钱投入都修建扩大本阶层影响力的建筑上。但总的来说，如果国库钱够用，更低的税收更好。因为税基相同时，税收影响的是分配。低税收必定增加阶层满意度，带来的正面增益是额外的。正所谓藏富于民。

而影响税基最重要的是地区控制度。当然地区控制度不仅仅影响税基，还影响了更多建筑的效率。从这个意义上来说，地方分权比中央集权更有利于经济发展。分封属国，尤其是朝贡国，比大一统国家会获得更好的经济局面。

但权力分配在游戏中也相当重要，因为它直接影响调配价值观的能力。价值观在一盘游戏进程中必须配合时代发展而演变才能更好的发展经济。而集权以及王室影响力是权利分配能力的来源。

所以说，最终玩整个游戏的体验还是在和面，只是多出了一份历史感。有了真实历史这种后验知识，才更为有趣。

我没有玩过这个系列的前作，但有 800 小时《群星》的经验，还有维多利亚 2/3 以及十字军之王 2/3 的近百小时游戏时间，对 P 社的大战略游戏的套路还是比较了解的。这一作中有很多似曾相识的机制，但玩进去又颇为新鲜，未曾在其它游戏中体验过。

我特别喜欢 P 社这种在微观上使用简洁公式，宏观展现出深度的游戏设计。我试着对游戏的一小部分设计作一些分析，记录一下它的经济系统是如何构建的。

我在玩了几十小时后，也只模糊勾勒出经济系统的大轮廓。下面是我自己的理解，可能还存在不少错误。

EU5 的经济系统由人口/货币/商品构成，市场为其中介。

游戏世界由无数地区构成。地区在一起可以构成国家，也能构成市场。一个国家可以对应一个市场，也可以由多个市场构成，也可以和其它国家共享市场。

每个市场都会以一个地区为市场中心，这反应了这个地区的经济影响力，它不同于国家以首都为中心的政治版图。市场自身会产生影响力，而市场中心地区的所属国家则因其政治影响力而产生市场保护力，两相作用决定了市场向外辐射的范围。每个地区在每个时刻都会根据受周围不同市场的影响强弱，最终归属到一个唯一市场。

每个地区有单一的原产物资（商品）。原产在版图上不会改变，可以被人口开发，计入所属市场供给。

地区上可以修建生产建筑，生产建筑通过人口把若干种商品转换为一种商品。转换效率受地区的市场接入率影响。市场中心地区的接入率为 100% ，远离市场的地区接入率下降，在边远地区甚至为 0 （这降低了同样人口的工作效率）。注：原产不受市场接入率的影响。

市场每种商品有供给和需求。每种商品有一个额定价格。需求和供给的多寡决定了目标价格和额定价格的差距，目标价格在 10% 到 500% 间变化。实际价格每个月会向目标价格变动，变动速度受物价波动率影响。

注：商品在每个市场有库存。库存和需求是独立的，库存多少不影响价格（供需状态影响它）。当需求超过供给时会消耗库存，反之则增加库存。库存有上限，一旦达到上限就无法进口。当贸易的交易对手需求大于供给时可以对其出口而无法进口，供给大于需求时可以从其进口，而无法出口；而自己只要有库存就可以出口（即使需求大于供给）。

商品的价格减去原料成本（原产物资没有原料成本）为其利润，利润以货币形式归属生产人口，并产生税基。

负利润的生产建筑会逐渐减员，削减产量，除非政府提供补贴。缺少原料的生产建筑会减产。

人口会对商品产生需求。食物类型的商品是最基本的需求。 不能满足食物需求的人口会饿死，不能满足其它需求的人口会产生不满。

对于单一市场：

1. 人口在市场上产生商品需求。
2. 生产建筑通过人口生产出商品供给市场。
3. 市场上的供给和需求影响了商品价格。
4. 人口通过生产获取货币形式的利润，并产生税基。

税基中的一部分货币留给人口，一部分以税收形式收归国库。

货币用来投资新增生产建筑，或对其升级。建筑升级需要商品，这部分商品以需求形式出现在市场。人口会用自己的钱自动投资建筑，玩家可以动用国库升级建筑。

多个市场间以贸易形式交换商品：

每个市场有一个贸易容量，贸易容量由市场中地区中的建筑获得。贸易容量用来向其它市场进出口商品。

市场所属国家拥有贸易竞争力，贸易竞争力决定了向市场交易的优先级。高优先级贸易竞争力的市场先消耗贸易容量达成交易。

商品在不同市场中的价差构成了贸易利润，其中需要扣除贸易成本（通常由两个市场中心间的距离决定）。贸易利润的一部分（由王权力度决定）进入国库，其它部分变为税基。

在国家主动进行贸易外，人口也有单独的贸易容量，自动在市场间贸易平衡供需。

我觉得颇为有趣的部分是这个经济系统中货币和商品的关系。

游戏中的生态其实是用商品构成的：人口提供了商品的基本需求，同时人口也用来生产它们。在生产过程中，转换关系又产生了对原料的需求。为了提高生产力，需要建造和升级建筑，这些建筑本身又是由商品转换而来。所以这么看来，是这些商品构成了这个世界，从这个角度完全不涉及货币。

但货币是什么呢？货币是商品扭转的中介。因为原产是固定在世界的各个角落的，必须通过市场和贸易通达各处。

建立一个超大的单一市场可以避免贸易，它们都直接计入市场中心。但远离市场中心生产出来的商品（非原产）受市场接入度的影响而削弱生产效率，所以这个世界只能本分割成若干市场。不同市场由于供需关系不同而造成了物价波动。价差形成贸易的利润，让商品流动。这很好的体现了货币的本质：商品流动的中介。

政府通过税收和其主导的国家贸易行为获得货币，同时也可以通过铸币获取额外收益（并制造通货膨胀）。再用这些货币去投资引导世界的发展：建造和升级生产建筑光有钱是不行的，必须市场上有足够的商品；没有钱也是不行的，得负担得起市场上对应商品的价格。

注：铸币可以看作是用黄金或白银直接变成货币的生产行为。它的基础产能似乎和人口无关，也不需要分配人口去工作，也没有特定的生产地点 。只需要在国家结余菜单中勾选即可。选择更大的产能会导致货币贬值，本质上是单位黄金/白银兑换的价值变少，但游戏中是以通胀变现的。即，生产出来的货币并没有变少，但国家的通胀增加了。铸币行为表现为在市场中自动消耗一定量的贵金属。如果整个市场中都没有贵金属，也就无法铸币。

11 月 7 日补充：

玩游戏的时候，一直没弄懂游戏中市场间的交易是怎么撮合的。官方 wiki 现在没有详细解释，游戏内的说明也不够完整。昨天和玩友讨论后，又仔细在游戏中研究了一下，发现其实游戏中说明还是很丰富的，只是细节散布在不同界面中。我是这样理解的：

由于同一市场中可能有不同国家的贸易建筑，所以导致了在一个市场中，不同国家分别拥有一定的贸易影响力和贸易容量。注：在友好的外国，可以修建贸易站，这种建筑占用当地的人口，为当地产生税基，但可以为本国带来贸易影响力和贸易容量。这些数值可以在市场界面上看到。

贸易影响力在出口紧俏商品时起作用，即商品的当月节余不能满足当月出口需求时，高影响力的贸易订单先被满足。在订单详情界面中可以看到相关商品的供给和需求细节。我不确定进口商品过多时是否也按影响力排序，游戏内的说明中说贸易影响力不影响进口，但我认为受商品仓库上限的影响，如果当月进口数量太多会超过库存上限，同样需要对进口订单排序。只不过在库存过高时，通常交易是负利润，很难出现这种情况罢了。

即使在一个外国市场内没有贸易容量，也可以发起贸易，只要该市场在你拥有贸易容量市场的贸易范围内。计算贸易距离似乎看的是市场边界的最短距离（而不是市场中心的距离），在贸易订单界面可以看到商品的出口地点和进口地点，很多时候并不是贸易中心地。贸易范围看起来是一个国家相关值。所以，在周边国家建贸易站可以扩展可以交易的市场。但如果在交易对手的市场内没有贸易容量，那么贸易影响力一定为零，对紧俏商品的采购很可能失败。

在两个市场间对某种商品进行贸易，会产生订单，同一商品只会有一张。订单上会指定商品数量，数量越多，消耗的贸易容量越大。每种商品有一个基础消耗比例，根据贸易距离乘一个系数。所以距离越远的贸易，消耗的贸易容量越大。在下订单时，并不能立刻确定是否能成交。如果商品库存不够，需要根据贸易影响力排序。低影响力国家发起的订单可能不能完全满足，甚至为 0 。这种情况下，订单所属的贸易容量就被浪费掉了。

每个订单可以看作是一支商队，贸易容量就是商队的规模。长途贸易需要支付额外的费用，可以理解为商队的工资以及海峡过路费等。这个费用以贸易容量为比例支付，而不是实际成就额。所以，即使订单数量为 0 ，这些额外费用也是要支付的。所以订单有亏本的风险。所以大容量订单（未能成交的）风险更大。如果是采购战略物资，采用多个小订单分散去不同市场采购获得足够成交数量更安全。

订单可以被人工固定，每月固定执行，但有更大的可能无法成交。大部分情况下，采用系统自动生成的订单。系统看起来会按利润多寡分配贸易容量。但似乎也不会产生过大的订单，具体规则没有写。总之，系统自动生成的订单浪费贸易容量的机率更小。

人口自身也有一定的贸易容量（独立于国家可以控制的贸易容量）自发进行贸易。对应的订单在游戏界面中无法查到。但在商品界面详情中可以看到一个合计数值，显示该商品由人口自发贸易行为产生的输入或输出总量。人口如何产生这些贸易的规则不清楚，从文字说明看，和人口自身的需求相关。我怀疑也和贸易利润相关。

今年夏天，我迷上了 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 卡游戏，还有 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。

有趣的游戏规则还有很多，我自己就记了上千行规则笔记。这里就不再一一列出给出评价，有兴趣的同学可以自己探索。

这是一个兴趣驱动的项目。正如上一篇 blog 中写到，驱使我写它的一大动力是在实践中探索游戏开发的难题。写这么一篇总结就是非常必要的了。

开发过程

我在 2025 年 7 月底写下了项目的第一行代码。在前三周并没有在实现游戏方面有太多进展。一开始的工作主要在思考实现这么一个游戏，底层需要怎样的支持。我使用的引擎 soluna 也只是一个雏形，只提供非常基础的功能。我想这样一个卡牌向桌游数字化程序，更好的文本排版功能比图形化支持更为迫切。固然，我可以先做一个 UI 编辑器，但那更适合和美术合作使用。而我现在只有一个开发者，应该用更适合自己的开发工具。应该更多考虑自己开发时的顺手，这样才能让开发过程保持好心情，这样项目才可能做完。所以我选择用结构化文本描述界面：容易在文本编辑器内编写，方便修改，易于跟踪变更和版本维护。

在 8 月的前两周，开发工作更多倾向于 soluna ：

1. 维护 yoga 的集成，编写布局模块。
2. 增加文本块的支持，支持简单的文字排版。
3. 增加 icon 的支持，可以和文本混合排版。
4. 增加单色无贴图矩形。这样可以视觉化布局的 box 。
5. 增加嵌套图层，而不是之前的平坦化图元。

1. 设置窗口标题 api 的多线程竞争引起的死锁。
2. 我按照过去的习惯，使用预乘 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 的构建脚本。

如果开源项目可以拆分出更独立的子任务（例如跨平台支持、本地化等），多人合作的确能大大缩短开发进程。

搬家结束后，我重拾开发。恢复开发状态用了一两天的时间。后续工作主要是以下几点：

1. 重构胜利结算流程
2. 完善游戏存档
3. 实现文明卡和奇迹
4. 制作主界面，增加多游戏文件支持和语言切换的交互（之前只提供命令行切换）
5. 卡片随机命名
6. 实现输入控件以及玩家自定义卡片名称
7. 将玩家游戏过程组织成文本供回顾游戏历史

这部分花了两周时间，可以说是按部就班。但实际开发工作比字面上的需求多许多。

在重构胜利结算流程中，我顺手把控制游戏流程的状态机模块修改了不少。因为无论是胜利结算还是失败判定，以及持久化支持，都会引入更复杂的状态切换。需要保证这些切换过程中数据和表现一致不能出错。

胜利结算中，为了增加游戏的仪式感，底层支持了镜头控制：可以聚焦放大桌面，将镜头拉近和恢复。

游戏存档被分离到独立服务中，同时承担数据一致性校验。在过去一个月的开发中，我发现存档对最终 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 的公开仓库比私有仓库有更多的免费特性。

事情源于昨天下午的一次脑抽，我把网站机器的操作系统升级了。上次升级还是十多年前，真的是太老旧了。结果升完级一看，php 被强制升到了 7 ，我自己写的一些 php 程序（主要是留言板）坏掉了。

这些个程序是我在 2004 年重构 2002 年的代码完成的；而 2002 年是从网上随便找来的代码基础上改的。我正儿八经学习 PHP 是在 1997 年，2000 年后就没怎么更新 PHP 的知识了。上次网站升级的时候，PHP 从 4 强制升到 5 ，就乱改了一通，勉强让程序可以运行（开了一些兼容模式）。这次再看代码，简直是惨不忍睹。所以我在本地装了个 PHP8 ，打开 PHP 官网，好好学习了一下手册。然后把代码取下来，重新建了个 git 仓库，正儿八经的改了一下。把留言的部分删了，只留下了浏览旧信息的部分，勉强让它继续跑起来。等什么时候有空了，再用 PHP 或 Lua 重新做一个。

最大的麻烦是 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），然后再用文本转换的方式替换其中的编码，最后再想办法导回。

mysqldump -u root -p --default-character-set=binary

这里导出命令行一定要加 --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 即可。

sed -i 's/CHARSET=latin1/CHARSET=utf8mb4/g' backup_utf8.sql
sed -i 's/COLLATE latin1_swedish_ci/COLLATE utf8mb4_unicode_ci/g' backup_utf8.sql

ps. 在本地 windows 上试验用 source 导入数据库时踩了个小坑。用反斜杠做路径会报错，必须用正斜杠绕开 mysql 的转义。

自此大功告成。

查看系统基本复原后，又连续升级了两个 LTS ，一直升级到 2024 LTS 版本。中间只碰到几个自己动过的软件配置文件问题。简单修一下即可。

估计又有十年可以不折腾它了。