开发者日志【白隙生花节目组】ep4：程序制作

昨天 16:047 次播放综合

铛铛铛！欢迎回到，白隙生花大舞台！✨✨✨大家好！这里是正在和代码一起成长的程序！👋今天主要由我，负责玩法部分程序的狗哥，作为本期节目的主持人来说说我们俩虚弱程序第一次做游戏的感受ORZ

第一次参与游戏开发，我们对程序制作的理解很简单：让角色动起来，再把设计好的玩法做出来，应该就差不多了吧？真正开始之后才发现，“角色能动”和“角色好好地动”，中间还有好多事情要考虑。

比如，我们曾经认真研究过：角色为什么掉不进坑里。

听起来有些奇怪，别人家的程序可能在努力防止玩家掉下去，我们却在想办法让角色顺利落到该去的地方。当时，画面里明明留着一个空隙，角色却像踩在空气上一样悬在那里。检查之后才发现，角色身上负责物理碰撞的那个“看不见的盒子”比坑口还宽，边缘搭住了旁边的平台。找到原因之后，把碰撞范围调窄，角色终于能掉下去了。事情到这里就结束了吗？并没有！新的问题是：身体虽然被墙挡住了，头发和衣服却可能伸出画框。这次调整让我第一次很具体地意识到，角色在画面里长什么样、物理上占多大空间、能活动到哪里，是几件需要配合好的事情。一个数字变了，影响可能会沿着整个玩法传下去。以前玩游戏时，我很少留意角色为什么恰好能通过某条通道。现在才知道，这个“恰好”，背后可能藏着好几轮调整。

还有一次，我们花了不少功夫，只为了让角色翻页后，好好站在门口。

最初的想法很直接：翻到另一面，把角色放在对应的位置就好了。但实际玩起来，玩家发起翻页的位置各不相同，按普通的镜像规则处理，结尾就不一定落在门口。后来改成了根据门的位置安排落点，又发现程序认为的“门口中心”，和美术画面里真正的门框中心，并不完全一致。甚至，刚放过去时看着对齐了，等角色受重力影响落稳，脚底又可能偏离门槛。于是，这件事从“改一下坐标”，变成了逐项确认：门框在哪里？脚底在哪里？落地后有没有支撑？从不同位置翻过去，结果是不是都合适？玩家看到的，只是角色翻过一页，站到门前。程序这边，却要把这一瞬间前后的事情都照顾到。

这也让我慢慢改变了判断“做完了”的标准。以前看到功能成功运行一次，就会忍不住松口气；现在会继续试试：换一个起点呢？多等一会儿呢？如果玩家接着移动，会发生什么？

写程序时觉得合理的顺序，到了玩家手里，也需要重新检查。

比如操作提示。起初很容易觉得：既然已经发出了显示提示的指令，那就可以开放对应操作了。但提示还需要一点时间才能滑进画面。程序知道接下来该按什么，第一次游玩的玩家却还没来得及看到。所以我们后来把相关操作的解锁时机，放到了提示真正显示之后。

这是一个很小的调整，却让我开始学着区分两种视角：我已经熟悉了整套流程，但玩家正在第一次认识这个世界。我不能默认他们知道下一步，更不能因为自己操作熟练，就觉得引导已经足够清楚。

制作《白隙生花》的过程里，这样的小问题还有很多。它们通常没有什么惊天动地的技术名词，却会实实在在地影响游玩感受。

于是，开发日常逐渐变成了：

“这次应该可以了！”
“等等，换个位置试试。”
“……好像还有一种情况。”

有时也会着急：怎么一个看起来这么简单的效果，做起来要考虑这么多事情？

但回头看学习笔记，会发现这些反复并没有白费。我们逐渐学会先把问题复现出来，弄清楚它为什么发生，再检查修改有没有影响别的地方。也开始明白，“之前测试通过”只能说明之前的版本，改完之后，还是要重新确认。

团队协作也是一样。玩法、场景和演出分别做好之后，还需要认真对齐：谁来通知任务完成？什么时候暂停操作？音乐应该在动画开始前停，还是开始后停？这些事情如果没有说清楚，各自运行正常的内容，接在一起也可能出问题。

第一次做游戏，我学到的因此不只是怎样写出一个功能，还有怎样把一个问题讲清楚，怎样让自己的代码接得住队友的工作。

当然，最开心的时刻依然很简单：角色终于顺畅地走过了之前卡住的地方；一次翻页终于准确落在门前；原本只能在讨论中描述的玩法，终于能亲手操作了。