《Balatro》销量破百万之后：一个单人开发者的意外
LocalThunk 在 Balatro 发布一年后接受采访说，他在发布前一个月还以为这款游戏「可能会卖几千份」。现在它在 Steam 上有超过 9.4 万条评价，绝大多数好评。 为什么这款游戏起效了？不是因为扑克牌主题（这个主题没什么特别），而是因为一个设计选择：**把所有信息都放在桌面上，但数字关系的复杂性远超视觉的简洁**。玩家永远知道规则，但永远不知道最优解。 这是一种罕见的设计：完全透明的信息 + 无限的策略深度。大多数卡牌游戏用「隐藏信息」来制造不确定性，Balatro 用「显示信息但让组合爆炸」。这个区别很细微，但它决定了玩家是「在猜测」还是「在探索」。探索比猜测更上瘾。
Claude 生成 Godot 4 动画状态机代码：15 分钟流程完整记录
这段 12 分钟的屏幕录制记录了完整的过程：从描述角色需要的动画状态（待机/行走/跑步/跳跃/受击/死亡），到 Claude 生成 GDScript 代码，到在 Godot 编辑器里调试，到最终可运行的状态机。中间有三次 AI 输出的代码需要修正（两次是信号名称错误，一次是状态转换逻辑遗漏了边界条件）。总时间：23 分钟。没有 AI：按照经验估算，同样功能手写大约需要 2-3 小时。
我用 AI 为游戏生成了配乐，玩家以为是真人作曲
实验：给我正在开发的解谜游戏的三个章节分别生成配乐——Suno AI，使用不同的 style prompt。然后在早期测试时，把这件事藏起来，不告诉测试者这是 AI 做的。 反馈：11 个测试者里，9 个提到了配乐。其中 5 个用了「氛围很对」「和游戏融合得很好」之类的表达。有 2 个猜到了「不太像真人作曲」，理由是「太稳了，没有人类作曲师的那种不规则感」。 告诉他们真相后，有 3 个人说这让他们不舒服，尽管他们之前觉得好听。 这个实验让我想了很久：音乐的价值有多少在于「听起来」，有多少在于「知道是谁做的」。我没有答案，但我决定在发行版里标注「AI 辅助配乐，创作者：[我的名字] × Suno AI」。不是因为法律要求，是因为我不想让测试者第二次有那种不舒服的感觉。
FMOD 与 Godot 4 的动态战斗音乐集成实录
这支视频记录了一次真实的集成踩坑过程——不是教程，是「为什么我们用了三周才让 FMOD Adaptive Music 在 Godot 4.3 上正确响应战斗状态变化」的诚实记录。核心问题出在 Godot 的 `AudioServer` 与 FMOD 的 `Studio System` 在帧时序上的冲突：FMOD 的 beat callback 会在音频线程触发，而 Godot 的信号系统默认在主线程处理，两者之间 8-16ms 的延迟在快节奏战斗中会产生可感知的音乐漂移。解决方案和一些代码片段都在视频里。
FMOD 与 Godot 4 的动态战斗音乐集成实录
这支视频记录了一次真实的集成踩坑过程——不是教程，是「为什么我们用了三周才让 FMOD Adaptive Music 在 Godot 4.3 上正确响应战斗状态变化」的诚实记录。核心问题出在 Godot 的 `AudioServer` 与 FMOD 的 `Studio System` 在帧时序上的冲突：FMOD 的 beat callback 会在音频线程触发，而 Godot 的信号系统默认在主线程处理，两者之间 8-16ms 的延迟在快节奏战斗中会产生可感知的音乐漂移。解决方案和一些代码片段都在视频里。
一位诗人做了一款游戏，因为她觉得诗歌已经不够用了
Zhao Mingzhu 在出版了两本诗集之后，开始做游戏。不是因为她不写诗了，而是因为她发现有一些东西她想表达，但诗歌的形式无法承载——那些需要「玩家做一个选择，然后承担那个选择的后果」的时刻。 她做的第一款游戏叫《碎字》，玩法是：玩家用文字碎片组合成句子，但每次组合会消耗材料，某些碎片组合后就消失了，无法再用。游戏里没有「对」和「错」的句子，只有「你还有多少碎片」。 这款游戏在文学社群里比在游戏社群里更受关注。有几位文学评论者写了对它的分析，用的是诗歌批评的语言，而不是游戏评测的语言。 媒介的边界是被使用者定义的，不是被定义者使用的。
Aseprite 2.1 的新动画帧标签系统——卡牌翻转动效的正确做法
Aseprite 2.1 引入了「帧标签继承」：子标签可以从父标签继承播放速率，这对卡牌游戏的动画制作是一个静悄悄的革命。 卡牌翻转动画通常需要 3 段：翻转前半程（8帧）、牌面切换（1帧）、翻转后半程（8帧）。旧版本里你必须手动同步三段的帧速率；新版本里用标签继承，只需调整父标签的速率，三段自动跟随。配合 Godot 4 的 AnimationPlayer，卡牌翻转动画的制作时间从 45 分钟压缩到约 12 分钟。 本文附有一个 Aseprite 模板文件，包含预设的卡牌翻转、发牌入场、弃牌消散三套动画标签结构。
用 LLM 生成 NPC 对话的工程现实：三个没人告诉你的问题
把 LLM 接入游戏运行时生成 NPC 对话，在 Demo 里效果惊艳，在正式游戏里会遇到三个工程问题： **第一个：延迟。** GPT-4o API 的 P95 延迟在 1.2-2.8 秒之间，玩家等待超过 0.8 秒就会觉得「卡」。解决方案是预生成缓冲区——让 NPC 在玩家走近时就开始生成下一轮对话，但这需要精确的触发时机设计，和游戏系统深度绑定。 **第二个：一致性崩塌。** 在同一对话中发给不同请求的 context window 如果处理不当，NPC 会「忘记」五句话前说的承诺。角色记忆的持久化和压缩是独立于 LLM 能力之外的工程问题，需要单独设计。 **第三个：费用。** 一个中等规模的 RPG，如果每次 NPC 交互都调用 GPT-4o，月费用很快会超过游戏本身的收入。Claude Haiku 在部分场景下是更实际的选择，但你需要做质量-成本 tradeoff 的精细测试。 这三个问题都有解决方案，但每一个都需要时间，不是「接个 API」能搞定的事。
