《呢喃灶间》开发总结

       大家好，我们是《呢喃灶间》的制作组，这次来分享一下在《呢喃灶间》的开发过程中，团队内部使用AI生成内容的经验。

       对于我本人而言，我相信生成式AI对于游戏行业的意义，并不仅在于可以用廉价的方式获取文档、资产和脚本，也不在于替代人类完成工作；而在于能作为一种新的维度，用以往的技术无法实现的方式为游戏带来前所未有的变化。

       在我过往的经验中，也尝试过使用生成式AI实时介入游戏的进程，以达到智能化角色的目的，例如：

       · 2025GGJ——《备忘夹》

       · 2025BOOOM——《末位淘汰的七日默示录》

       不过很遗憾，这些游戏因为太过复杂，最终无法在开发周期结束前成功面世。

       于是，在本次聚光灯中，我尝试了用更简单的切片——菜品描述——以简化生成任务的复杂度。

       受到厨王争霸的启发，我们选择了双人对抗的卡牌烹饪游戏，将食材作为卡牌，投入到锅中合成新的卡牌（即菜品），并邀请了AI作为评委，为双方的菜品评分。

      虽然结果不如人意，但我们成功在48小时的挑战中完成了食材合成的功能。并在后续的更新中完成了评分功能。

       很显然，生成功能还需要再优化。

       在开始前，我希望感谢TapTap聚光灯活动，没有聚光灯Game Jam（和免费提供的Cursor账号），我就不会有机会写这篇帖子。

       那么，透露一个事实：本游戏的所有GDS脚本都是通过AI生成的，我本人并不会GDS。这是我第一次有机会尝试使用GDS参与制作。因而分享一些创作经验。

       尽管一个人开发的时候，注释狗都不写，但一旦让AI写代码，就必须要详尽地为每一部分都提供注释，否则……

       如果您仍然看不懂注释，那么……

       对于AI写的代码，最好在全生命周期都记录日志，详细地监控异常状况，并且要求AI不准提供错误应对方案，允许直接报错（因为它们通常都会为异常提供备用方案）。

       这么做的意义在于：

      感谢您耐心看到这里，那么，我们提供一个——

       我们在尝试开发一个新的恐怖探索游戏，同样会使用生成式AI，预计于9月底放出新进展（如果没有就不要挖土了，多半是咕了）

       如果能成功发布进展，我们也许会向各位分享一个可能可以参考的设计经验？那么到时候再见咯。