《AAA下水道清理大王》开发日志3

修改于10/1710 浏览综合

我们的游戏是个增量游戏，有点蒸汽朋克或者西方幻想的风格，所以我把它的局外内容包装成一块城镇的地图。

与此同时，作为一个增量游戏，它是有知识树的设计，所以这两天就一直在做这方面的内容。

这两天改了知识树的背景，重做了好几轮地图，也重新讨论了一遍弹球机制和数值计算方式。

时间确实花了不少在界面、美术和表现上。原因也很直接：之前一眼看过去，感觉快瞎了，实在没什么卖相。我觉得这些东西反正都要打磨，先让自己看得下去，也没什么不行。

不过，画面终于顺眼一些，不代表游戏已经做好了。它从开局到后面的成长流程，还有很多地方没成立。这个问题先记在这里，后面再说。

这次有一个小改动，效果比我预想的好，也让我得到了一条以后可以复用的经验。

昨天我本来想把城镇地图直接作为知识树的背景，再加一点随鼠标移动的视差。设想的时候觉得挺合适，实际做出来却不对：地图已经很复杂，上面再铺一层知识节点和说明，整个画面就很乱。

最初的知识树。地图、节点、说明都在争抢注意力。

看过效果之后，我就把自己前面的想法推翻了，决定换成 UV 流动背景。说白了，就是让一组重复的小图案在背景里缓慢移动。

接下来要想的是，流动的图案到底用什么。后来我提出，不如直接用主角的头，或者把主角的头简化成一个 icon。实际做完一看，这个效果非常对，没什么毛病。兜帽、暗脸和两只眼睛，本来就是我们这个角色最容易被记住的部分，拿来做底纹也很合适。

从原头像里保留兜帽、暗脸和眼睛，简化成单色图标，再放进流动背景。这里截取的是头像预览网页；下面则是接入 Unity 后的知识树。

改成低对比的主角头像纹样后，背景安静了很多，也和游戏本身有了联系。截图展示的是当天的头像版，节点和数值说明还会继续调整。

我觉得这甚至可以变成一套公式化打法：从游戏的主要角色，或者最有代表性的视觉印象里，提取一个容易辨认的 icon；这个 icon 可以用于界面，也可以低对比地平铺成 UV 流动背景。

以后做别的游戏，可以先拿这套方法试一遍。它用到的东西不多，但很容易让界面带上自己游戏的特征。随后我们也把类似的处理扩展到其他面板，让每页有自己的图标和颜色，再统一进入、返回时的过渡效果。

地图就没这么顺利了。它经历的返工，要比知识树背景多得多。

一开始，地图是一整张 AI 生成的背景。图里有建筑、有街道、有装饰，东西很齐，但放进游戏以后，感觉丑爆了

最早的城镇版本，整张生成图承担了大部分场景内容。

后来我们先把它拆开，尝试用独立的 2D 地面、建筑和装饰来组织地图，再逐渐转向 3D 模型。这样房子、树和井口就能单独摆放、调整，也方便处理交互。

中间的二维分层版本。地面和物件已经分开，但造型与整体效果还需要继续改。

做房屋的时候，我提出一个流程：先根据对标风格生成样式图，我选觉得合适的版本，再让 AI 建模，最后放到 Unity 里做三渲二

然后我们选择的风格是类饥荒的建筑物/设施风格，看起来是比较契合我们游戏的风格的

三渲二最初用的是自写 Shader 做试验。为了得到更好、更稳定，也更方便调整的效果，后来接入了Unity的 RealToon 插件，再围绕材质、描边和模型比例做我们自己的风格化处理。

但 3D 模型第一次放回地图，还是不太对。单看新房子似乎好了一些，和旁边的地板、建筑放在一起，就不像同一个游戏里的东西。

左侧的新事务所已经换成 3D 模型，但它和原来的地板、其他房屋明显不统一。

我自己的审美能力有限，很多时候能感觉到难看，却说不清楚具体难看在哪里。那就继续找参考，看看别人怎么处理。

我们前后看了几款游戏，手绘和墨线的方向保留了《饥荒》的影响，地图的组织方式后来重点参考了《王权陨落》。我比较喜欢它，也觉得它和我们已有的美术、制作方式比较适配，实现起来没那么难。

当时参考的《王权陨落》截图。分区地块、简化的建筑和树木，以及深色外围背景，是我们拿来研究的部分。图片来自官方 2.11 更新公告，红圈和 NEW 标记为原图内容。

不过，找到参考也不代表第一遍就能做对。最开始做出来的是几个分离的小岛，线条和形状显得生硬，背景颜色也不太合适。看起来更像一组摆出来的模型，没什么完整地图的感觉。

第一次尝试分块地图。每块地都很完整，放在一起却像几个独立展台。

这一轮我又去问了 Opus 5.5，拿到一些指导意见，再带回来继续调整。我们把分散的小岛改成连在一起的街区，突出中间的事务所，收拢地面颜色，调整外围背景。之后又继续改分割线的粗细和规整程度，增加装饰，同时约束物体别跑到所属地块外面。

地图上的内容也跟着玩法一起改。既然新版已经不要装备系统，就把旧装备设施（工房）去掉；要进入清理关卡的地方，统一做成井，再让不同的井有各自的样子。

这一轮调整后的地图。图中展示了各区域解锁后的配色，一座事务所和六口井组成了主要交互点。

经过这么多轮，终于到了我觉得能看得过去、不会太难看的程度。还谈不上多惊艳，但至少不像前面那样，自己看着都难受了。

游戏设计和数值这边，我也去问了 Opus 5.5 的建议。

原来的设计是三个槽位轮换发射。这个机制在规则上能跑起来，但我总觉得实际效果不好，也未必有必要让玩家围着几个槽位做选择。中间讨论过主动技能，后来想想，也没什么必要，全部被动就行。

现在改成了更直接的逻辑：基础攻击先发普通球，特殊球作为升级内容解锁。每进行 N 次普通攻击，就额外发出对应的特殊球。不同特殊球各自计数，解锁以后都能生效。

这样，买到新的特殊球，就会在原有攻击上继续增加东西。成长主要体现在先买什么、先强化什么，以及后面能叠出什么效果。

我自己试下来，目前感觉还可以，比原来那版好很多。至少这个方向更接近我想要的增量成长了。

新机制接入时的实机截图。右侧显示各特殊球的独立计数；这张图记录的是当时的战斗界面，局内美术之后也在继续调整。

同时我们还改了球、怪物和水之间的关系。之前水涨得太快，怪物没能形成高低错落的目标，原本想要的连续弹射就很难出现。现在让前期水涨慢一些，怪物隔一段时间出现；后期水再加速，把怪群推到水面附近。普通球也能反弹，后续伤害逐次减半，之后还可以通过升级让球入水、减慢水下怪物上浮。

我希望成长能逐步改变这些东西之间的作用。买了升级以后，除了数字增加，还应该出现之前做不到的玩法。

至于数值怎么计算，这里要说清楚：“数值计算加物理模拟”这个具体方案，是 Codex 选择的。我的要求是把数值算清楚，并且在过程中提出修改意见。

最早先用 .NET 和 C# 跑规则、流程模拟。后来我提出，希望弄清楚哪些内容能够直接计算，也希望这个项目结束以后，工具和设计经验还能带到下一个项目里。经过讨论，就逐渐变成了现在的复合方式：用 Python 做公式计算，再用 .NET／C# 的二维物理模拟检查实际表现。

公式计算先回答一些容易比较的问题：伤害是多少，升级要花多少钱，同样的预算先买什么，特殊球的触发频率会带来多少理论收益。

但球在井里到底能撞到几个目标，怪物会不会提前死亡，有多少伤害被浪费，一轮结束到底能拿到多少收入，这些就需要把运动、碰撞和结算过程跑起来看。

这段视频录的是“第二井：先解锁新球”的二维坐标回放，按 1 倍速完整播放。圆形表示碰撞体，细条表示剩余生命，彩色小点是球，底部蓝色区域是水位。它展示的是 10 月 15 日当时的模拟记录，不是 Unity 实机，也不代表后来修改规则后的最终数值。

两部分结合起来，至少能让我们更清楚地知道，哪些数字是算术结果，哪些依赖假设，哪些已经在模拟里发生过。当然，规则一改，相关计算也得跟着更新。现在普通球增加了衰减反弹，旧的伤害结果就不能原封不动地继续用。

我对这件事的期待，是这次做完以后，除了留下一个游戏，还能留下以后用得上的计算方法，以及一些关于成长和数值的经验。

接下来还有几块工作要继续推进：

补上主菜单，继续优化地图和进入游戏的流程。
优化存档系统，让新游戏、继续游戏和进度管理更完整。
制作更多音乐，尝试技术音频，包括音乐循环、场景切换和声音随游戏状态变化的处理。

音乐和技术音频都是我有兴趣，但以前一直没什么余力尝试的东西。现在有 AI 帮忙，可以真的动手做一做了。这也是这次开发里，我自己比较期待的部分。

然后就到了这个游戏最主要、也最需要认真处理的部分：它本身到底怎么玩。

目前整个游玩流程其实还不算成立。从开局第一轮怎么进行，到玩家拿到收入后买什么，再到后面怎样继续成长，里面有很多地方都没有打磨好。核心 gameplay 还要继续试，全局成长流程也需要重新梳理。

这两天确实一直在打磨外部内容，但我不觉得这有什么问题。它们本来就是要做的，而之前那个卖相，实在很难让我忽略。先处理到看得下去，我也更愿意继续打开它、玩它、找问题。

我仍然觉得这个核心方向能跑通。接下来要把它从一个能操作、能结算的原型，往一段真正成立的游玩过程推进：第一局给玩家什么体验，第一笔钱买什么才有感觉，每一次升级怎样改变下一局，以及玩家为什么愿意再进一次井。

数值流程要重新优化设计，展示数值和成长的 UI 也要再做一轮。现在地图总算没那么难看了，接下来就得在这些地方多花时间。

最后补一段 10 月 16 日录制的试玩交互视频。从开始游戏，到地图和知识树操作，再到入井后的战斗，可以看看目前这些内容连起来是什么效果。

猜你想搜

聚光灯游戏创作挑战增量游戏玩法

9.1

9.6