下载 App

开发日志 04:把一堆规则,变成一个游戏

修改于前天 15:037 浏览综合
一、上一篇日志之后
上一篇日志里,我聊了“涌现式开发”——一个无限增殖的 bug 教会我的事。
写完那篇之后,我做了一个决定:不再增加新系统,开始把现有的东西“做成游戏”。
具体来说,是从“技术原型”变成“可以玩的东西”。这中间有三件事,我想展开聊聊。
二、60关:难度曲线不是算出来的
我做了一个 60 关的闯关模式。每一关有目标词、可用元素、步数限制。
设计的时候,我以为难度就是“融合深度”:一阶词简单,二阶词中等,三阶词难。
但玩家不是这么感受的。
一个跨阶融合——比如“火烧云 = 火焰 + 云”——它的融合深度是 2(火焰 1 次,云 2 次),但玩家需要投放 5 次才能凑出来。
“深度”是理论最小值,“步数”才是玩家的实际成本。
我们写了一个工具(scan_level_costs.lua)来算每个关卡的最少投放次数。第一次跑完,发现8 关的步数预算算错了——最严重的一关,理论最少要 4 步,我只给了 5 步。几乎不可能通关。
工具比直觉可靠。
三、图标:玩家看不懂形状,但看得懂图
最初,游戏里的元素是用 NanoVG 画的几何图形:火是三角,水是圆,土是方块。
我想让玩家“一眼认出元素”,所以给每个词分配了不同的形状和颜色。
但很快发现:形状推理只是理想状态。 大多数玩家根本不会去记“什么形状对应什么元素”。他们看到的是“一团橙色的三角形”——然后问:“这是什么?”
于是我们做了一件事:给每个元素生成独立的卡通图标。
火是燃烧的火焰,水是圆润的水滴,土是带裂纹的土块。60 个关卡目标,全部有专属图标。
这件事的收益远超预期:
关卡卡片上直接放目标图标,玩家一眼就知道要做什么
故事页里,目标元素以图标形式出现,不再需要文字解释
词库按钮、世界内的词、拖拽预览,全部统一用图标
代价是:60 张图,5 批生成,反复调整。 有两张重做了三次——比如“溪”和“河”太像,“绿洲”和“岛”太像,“双虹”和“雨虹”太像。
但值得。因为图标不是装饰,它是玩家理解游戏的语言。
四、小坠:一个吉祥物如何让游戏有了主角
游戏里有一个吉祥物,叫“小坠”。
它是一团圆滚滚的、灰白色的、还没“融合成型”的元素。它有一双大眼睛,头顶上有一个小光点。
它的设定是:它想吃遍所有元素,变成一个完整的生命。
它出现在主画面中央——坐在一个金色魔法阵里,等着玩家开始游戏。
它出现在每关的故事页里——站在画面里,等着玩家帮它合成目标。
它在游戏里也一直存在——右下角的小角落,头顶的光点会显示当前关卡的目标形状。
它让游戏有了一个“主角”。
之前的《词坠》是一个抽象的规则引擎:你投元素,它们融合,你凑出目标。
现在它是一个关于“小坠”的故事:小坠想要蒸汽、火焰、湖、云,你需要帮它合成。
五、故事图:给每关一个理由
我们给前 10 关做了独立的故事图。
每一关都有一个场景:第 1 关是厨房,小坠想泡个热水澡;第 2 关是夜晚森林,小坠想生火取暖;第 3 关是沙滩,小坠抱着冲浪板,但海面平静得像镜子。
每张图都在说一句话:小坠需要这个元素,但它没有。
这不是“关卡目标”,这是“故事”。
六、踩过的坑,都是 AI 协作的坑
这一阶段有大量“AI 生成”的内容:图标、背景图、故事图。
但 AI 只能生成素材,不能保证“接上线”。
我在这上面栽了好几次:
坑一:UI.Avatar 是个半成品。
我用 UI.Avatar 组件显示关卡卡片的图标,结果它根本不加载图片——源码里写着“Actual image loading would be handled by engine integration”,而那个集成不存在。所有卡片都显示灰色小人。
坑二:Render.Bind 漏了一行。
故事页的渲染层和 UI 层是两套依赖注入。我把故事数据接进了 UI 层,忘了接进渲染层。于是故事图和小坠根本不画——因为渲染层拿不到数据,直接 return 了。
坑三:背景图只铺了舞台。
游戏舞台是 9:16 居中的,两侧有黑边。背景图只画在舞台内,黑边就露出来了。看起来就像“没铺满”。
每一个坑,都不是“代码写错了”,而是“接错了线”。
而 AI 不会主动告诉你“这个组件不能用”或“这个字段没接上”。它只会按照你写的代码执行。所以我学会了:每个模块接入后,先做一个最小验证。
七、现在的状态
《词坠》现在有:
60 个关卡,从一阶到四阶,逐步引入 5 个基础元素
66 个元素图标,覆盖所有关卡目标
11 个融合产物图标,覆盖所有中间产物
10 张故事图(前 10 关),每张一个场景
主画面 + 关卡选择页 + 游戏内,三态状态机
吉祥物“小坠”,4 种表情,出现在主画面、故事页、游戏内
它已经是一个“游戏”了。
——虽然还有很多优化空间:后 50 关的故事图还没做,音效还没加,真机还没全面测试。
但它终于像一个有温度的东西,而不是一个规则引擎。
开发日志3:能跑的游戏,和正确的游戏截图
开发日志3:能跑的游戏,和正确的游戏
一、第二篇日志之后 写完上一篇日志,我以为接下来就是"填内容"——把 30 关关卡数据录进去,把元素分好阶,跑通流程,上线。 事实是,我花了大量时间在"排查看不见的 bug"上。 这一类 bug 的共同点是:代码不报错、画面正常、游戏能跑,但玩法是错的。 它们不像崩溃那样刺眼,甚至不会让你立刻发现,只会让你在某个时刻觉得"为什么手感不太对"。 这篇日志讲三个这样的 bug,和我为此搭的工具链。 二
1 赞
开发日志05:一个小坠,从代码里长出来截图
开发日志05:一个小坠,从代码里长出来
一、回到最开始 第一个版本里,火是一个红色三角形,水是一个蓝色圆。它们相撞,变成一个白圆,名字叫“蒸汽”。 那时我盯着屏幕看了很久,觉得这东西有生命。它不是我画的,不是我摆的,它是自己撞出来的。 后来我才知道,这叫 涌现。 再后来,我花了很长时间,试着把这个“生命感”做成一个游戏。 二、把规则变成玩法 涌现本身不是玩法,它只是机制。要让玩家觉得好玩,得有目标、有反馈、有成长。 于是我把“随机挑战”
开发日志2:差点把《词坠》做成词库增殖机器截图
开发日志2:差点把《词坠》做成词库增殖机器
## 一、上一篇日志之后 上一篇日志里,我介绍了《词坠》的核心构想:玩家投放元素,元素互相融合,长出一套你完全没设计过的法则。 写完那篇日志后,我做了一件事——**把我之前设计的 49 个词全部推翻了**。 起因是一个很朴素的问题:**太阳为什么是二阶?** 在旧设计里,"火 + 大 = 太阳"是一次融合。但太阳这么宏大的东西,怎么可能和蒸汽、冰放在同一阶?**融合次数 ≠ 语义复杂度。** 这个
开发日志 01:从一个我理解错的词开始截图
开发日志 01:从一个我理解错的词开始
我一直以为涌现就是小概率事件,直到我把它想明白了 --- 一、这个主题把我卡了整整一天 拿到“涌现”这个题目的时候,我脑子里第一反应是:抛硬币,十个正面拿大奖。*l 然后我把它发给 AI 助手问了一句:“这算涌现吗?” 它说不算。我当时不服。概率这么低、结果这么稀有、玩家这么上头,怎么就不算? 后来它解释了一句话,我记到现在: > 概率是“我抽到了”,涌现是“我没想到会这样,但它发生了”。 小概率
00:09
荒古传说:潜水偷看玩家群,结果被大佬的“毕业猎人”秀了一脸…截图
荒古传说:潜水偷看玩家群,结果被大佬的“毕业猎人”秀了一脸…
各位好,我是《荒古传说》的开发者。平时我都在群里潜水看大家反馈 bug、提建议。 结果今天有玩家甩给我一段视频,我直接看傻了。 大家看视频吧……这满屏的暴击、2.0+的攻速,加上这身神话套。说实话,我们在写数值的时候,都没想过有玩家能在这个阶段把弓手拉扯得这么完美。 很多兄弟平时吐槽说洗练看脸、挂机肝,但看到这位大佬的视频,我突然觉得——这游戏没白做(甚至有点小骄傲)。 视频我放这了,大家
看图提问破案,这款推理游戏细节控狂喜截图
看图提问破案,这款推理游戏细节控狂喜
喜欢看图推理、细节反转、纯逻辑解谜的玩家看过来! 《细思极恐推理社》是一款竖屏单手可玩的看图推理游戏,没有血腥jump scare,没有超自然鬼怪,所有真相都藏在画面的细节里,越琢磨越有细思极恐的味道。 ▶ 怎么玩?像侦探一样提问破案 你面对的不是传统的“找物品”,而是一整个案发现场。 你可以随时向AI主持人提问,只会得到「是」「否」「与案情无关」三种回答——就像真实的案件问询,一步步排除干扰、锁