普通视图

发现新文章,点击刷新页面。
今天 — 2026年1月15日云风的 BLOG

和 AI 聊游戏设计

作者 云风
2026年1月15日 16:05

最近一段时间和 AI 聊游戏设计比较多。我主要用的是 google 首页上的 AI 模式,也试过 twitter 上的 grok 。

去年也和朋友聊过很多,但对理清楚自己的想法帮助有限。因为和人聊容易陷入不断的细节解释当中,一些天马行空的想法更容易被质疑,一旦陷入辩论就不太容易跳出来。而且每个人的时间并不固定,很容易造成时间和精力的浪费。和 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 年时间制作出来的,颇为震撼。怪不得我在玩的时候感觉这个游戏要深度有深度要广度有广度,完全不像是能短期做出来的。只能说,设计出好的游戏真的很难。

昨天以前云风的 BLOG

Skynet 升级到 Lua 5.5.0

作者 云风
2025年12月23日 10:19

Lua 5.5.0 已经正式发布。所以,skynet 的 Lua 版本也随之升级。

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

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

这个 patch 的副产品是允许在多个 Lua VM 间共享常量表。打了这个 patch 后,就可以使用 skynet.sharetable 这个库共享只读常量表了。

这次 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 代码的实现。

❌
❌