AI时代下的游戏人,上岸or上桌?
AI时代游戏人如何转型?揭秘CodeBuddy+Unity开发实战,掌握AI编程与GaaS立项策略。从工具链搭建到特种作战思维,助你在AI浪潮中抢占先机!

「缸脑博物」第12期
如今,AI成为了亿万年前的氧气——旧生命在致命的氧气中窒息,而新生命则在其中绚丽燃烧。
我们已经无法想象一个没有AI的世界,也无法抛开AI讨论有关于游戏行业的话题。
尽管它才出生不久,但人类历史中所发生的一切——理性、科学、爱情、死亡、艺术、战争......都是它的养料。它从人类的虚构羊水中汲取营养,而在下一个瞬间,长大成神......
1. 游戏已是特种作战时代
尽管AI是一个横跨了应用数学到代码编程的庞大学科,但就AI的实际应用来说,我们尽可以放下心中的顾虑,仅是将AI视作一个经验丰富的万能员工来与之协作。
对于非技术出身的游戏人来说,AI使得我们几乎在瞬间拥有了驾驭引擎的能力。
正如我在文章《无他,AI编程就是干中学!纯小白用CodeBuddy暴力手搓微信小程序
》中说的那样,我们可以靠着AI在短时间里上手编程——我大概花费了10个小时的时间,使用了公司的CodeBuddy为个人的公众号制作了一个主页小程序。

图:使用CodeBuddy制作的小程序
这种Vibe Coding(氛围编程)的实际体感更像是产品和程序大佬之间对需求,通过画示意图、列需求、来回拉扯,逐渐让AI实现我们的诉求。
而这位程序大佬又有两个特点:一是很多系统的权限它没有,得靠你来帮忙开个门;二是它比较被动,有些事情你不问或者不提,它就当不知道。
而使用CodeBuddy+unity制作游戏的体验则更加令人感到兴奋与惊奇。限于篇幅,我这里仅作概要性的介绍。

图:使用CodeBuddy制作unity游戏
应该说,利用codeBuddy来制作unity游戏的门槛是非常低的——所有代码部分都可以由CodeBuddy来实现,仅剩下一些引擎的配置工作(尤其UI)需要手动完成。而配置方面的操作,你也可以要求CodeBuddy一步步地,傻瓜式地给予引导。

图:CodeBuddy制作的后室搜打撤Demo
我最常使用的工作流大概如下:
● 用概述性的话语向CodeBuddy描述我的需求,例如:我希望角色有一个属性是饥饿值,饥饿值会随着时间自动降低;
● 之后,先让CodeBuddy基于理解出一个方案。当然,有时它的方案会很详细,加一些我们还不想处理的功能,例如提前预留了吃东西加饥饿的功能。这有时会带来困扰,最佳的方式是一次只做一小步功能;
● 正如前面说的,我们对方案进行审核,去掉那些多余的、激进的内容。对于没有程序背景的我们来说,在这一步可以多问一些实现后会有怎样效果的问题,以明确CodeBuddy提出的方案在实现后,将有我们预期的效果;
● 然后就是实际制作了,这一步最轻松,全部由CodeBuddy来,我们可以去泡个咖啡,回来就应该差不多好了;
在使用AI辅助操作引擎的过程中,你会发现有两件事是非常关键的:
1.1. 工具链的搭建
对于小白来说,我们可以让AI先在untiy中制作出一些只需要通过拖拽、填写等基础操作就能进行交互的「配置工具」,然后利用这些界面更友好的工具来实现复杂功能。
这里,我举一个具体的例子——制作一个吸血鬼幸存者Like的游戏中的生成式随机地图,这里其实有几个更细分的功能:
● 需要一个工具,能够让我们自由地把瓦片组装成地块,即地图的最基础单元。这里,我们可以粗暴理解瓦片就是一张张做好的PNG素材;
● 需要一套地块生成的管理系统,使得角色接近地图边缘时,系统能从地块库中,按一定规则找一块出来拼到地图边缘。从而让世界看起来是无限的;

图:随机地图的生成逻辑
这里,第一个细分功能显然不完全是代码层面的问题,我们需要一个中介工具来将瓦片组装成地块。
大致的提示词示意如下:
● 游戏的地图是有限大的随机生成的地图
● 地图的基础组成单元是【地块】,整个地图由9×9的地块构成(暂定)
● 每个地块由6×6(暂定)的地格组成
● 你需要为我做一个【地块生成工具】的工具,这个工具的主要作用是【生成/更新地块预制体】和配置每种地块预制体的生成概率。我能够在这个工具中设置每种地块由哪些瓦片组成并且可以预览,我也能动态调整地块由多少乘以多少的地格组成以及整个大世界由多少地块组成;
之后,就像前面的工作流中说的那样,和CodeBuddy讨论出一个双方都认可的方案,然后实际制作。如下图所示,CodeBuddy可以制作一个相当给力的配置工具。

图:做好的地块编辑器
1.2. 文档体系的搭建
让AI经常记录、复盘项目的制作过程总是有益的。
事情是这样的:通常,AI在实现某个功能或者定位某个问题时,需要通过阅读相关的脚本来了解情况。而越要全面了解问题,就需要阅读更多的脚本,这带来了效率上的问题;同时,AI毕竟不会每次都阅读全部的脚本(也不经济),方案有时会陷入局部最优解的陷阱中。而让AI了解情况时,辅助阅读文档,将给到AI更加宏观的视角,快速而全局地处理问题,实现功能。
一个更具体的例子是:有时一个问题我们反复尝试了不同的解决方式才解决,我们可以让文档记录下这个艰难的解决过程,为什么有些方案是不行的;或者让AI反思为什么一开始没有使用正确的方案,而是迭代了很多轮才使用。这样的信息很有助于后续类似问题的处理。
通常而言,我会先让AI梳理一个文档更新规范,这有点像程序法,包含了AI更新文档时需要注意的事项。

图:文档更新规范
接下来当时是记录项目实际开发内容的文档。这些文档都由AI自己书写,并且在完成每一个小功能后都可以即时更新。

图:项目文档
这里,我将自己最高频使用的一些AI话术贴在下方,以供参考:
● 请你复述对我需求的理解,并描述功能实现后的效果(确保需求正确传达)
● 为实现功能,概述你要做的和我要做的工作(明白该需求的代码和配置的工作量占比,也是进一步确认需求传递正确)
● 你的实现方案是否是全局最优,有足够的鲁棒性,功能之间是否足够模块化,是否有潜在风险。你可以参考项目文档和更多脚本后来回答(讨论方案的质量和效能,保证项目整体结构的优雅)
● 表格化列出几种方案的优劣势、风险,并给出你的推荐和原因(如果AI给了几种方案,可进一步对比)
● 现在,方案完成了(给AI看成功的截图),请把我们做的内容更新到文档,注意参考更新规范,记录项目的实际映射、技术方案等(确保文档能实际加速后续需求的方案优化)
2. 特种作战下的Gaas立项逻辑
至此,我们应该已经对驾驭AI来制作一个独立向的游戏有了一个比较具体和感性的认识。可以看到,AI是一种可怕的平权武器——那些也许能惊艳行业,却限于技术能力不足、缺少美术支持而无法落地的点子,现在有了被付诸实践的可能;一些需要堆量的、高成本的游戏类型,小团队也有了实践的能力。
因为有了AI,每个个体都成为了潜在的“游戏开发恐怖分子”,能够对那些看似强大的开发团队展开特种作战......
可以预见,我们即将经历一场海量拷贝游戏的浪潮,将快速裹挟和分化用户,让他们变得更加挑剔、短择、没有耐心。当外部有大量短频快的、廉价却高质量的游戏内容时,Gaas游戏或许需要重新省视自己的核心价值与护城河,提供那些除新奇感之外的内容来对抗这种变化。
要理解Gaas所面临的挑战,我们需要认识到,AI对于Gaas和非Gaas的游戏有着不同的价值。
2.1. 不同的商业范式从AI处的获益不同
如果我们非常粗暴地对游戏的商业范式进行划分,那么可以概括为拷贝类的游戏和Gaas类的游戏。
从玩家的角度来说,尽管都是玩游戏,但对两种范式的游戏的要求是不同的——拷贝制游戏更像是偶尔来一次的“搓一顿”,更多吃的是新奇的体验;而Gaas游戏则是高频吃的食堂,口味之外的营养配比、食材新鲜度、乃至热闹的用餐氛围、经典而熟悉的用餐环境也会被纳入考量。
听起来,也很像恋爱关系中,短择与长择对伴侣有着相当不同的要求。
回到AI,其所创造的内容,无论是图片、音乐、文字亦或是模型,主要的特点就是不稳定、不顶级。对于内容品质、稳定性要求不要的场景,那是量大管饱。
显而易见的,拷贝制游戏,尤其其中的独立游戏,AI的增益是最大的——我们还是举一个例子,《吸血鬼幸存者》。从制作的角度来说,无论是美术还是程序,都是易于实现的。

图:AI生成的像素风格素材
所以,就在现在,制作一个爆款独立游戏的唯一卡点,就只有创意,或者说是策划能力本身了。
对Gaas游戏来说,问题则要复杂一些。尤其是像《燕云》这种走高品质内容迭代路线的游戏,AI更多是做加速和成本优化(替代低端人力)。至少在文章写下的时刻,AI的能力尚有这样的局限性。

图:AI对高质量内容的提效有限
2.2. 立项启示:什么是对Gaas游戏真正重要的
在回答什么是对Gaas真正重要的东西前,我们应该追问一句,究竟什么是Gaas游戏?它除了提供一般拷贝游戏那样的新奇体验之外,还提供了什么独特的东西?
在我的理解中,Gaas本质上提供了一种价值确认,一种来自官方和其它玩家的价值承诺——官方不断更新游戏,一方面是提供新的可游玩内容,另一方面也是在不断向玩家许诺游戏的长期存在,玩家所投入的时间和感情,受到了官方的认可。
而游戏所存在的交易、对战之类的,有关玩家间交互的玩法设计,则是让其它玩家来认可游戏行为的价值。
这种价值确认的力量,往往随着游戏运营事件的增长、玩家间社交联结的加深而愈发强大,从而让Gaas游戏和拷贝制游戏的商业逻辑存在根本的不同。
一个价值预期崩坏的反面案例就是《星球重启》——在23年字节突然宣布大规模收缩游戏业务后,玩家对游戏是否还能长线运营产生了怀疑。运营数据也是不可逆地一路下跌,造成了游戏寿命的快速削减。

图:《星球重启》可惜了
在这个视角下,与Gaas游戏对应的概念可能不再是拷贝制游戏,而是一个价值平台。某种程度上,制作Gaas就是制作某种具有独特框架的、能够与官方内容或其它玩家交互的平台,其长线服务这一面的设计(包括经济稳定、道具保值、品牌口碑等)的重要性将远高于某些具体玩法的独创性,甚至也高于题材的独特性。
如果有两款产品,一款玩法相当新颖,但在长线迭代逻辑上存在风险,而另一款则在框架上没有特别创新的地方,但在长线迭代逻辑上更顺畅,那么我会认为后者的成功概率更大。换句话说,对Gaas游戏来说,新瓶装旧酒(基于已验证的Gaas范式)也许要比新瓶装新酒来的更靠谱。
例如,《七日世界》就非常大胆地采用了赛季制来做SOC,却没有得到太好的数据——赛季制带来的诸如对SOC底层囤积心理的挑战、更短数值线带来的商业化空间压缩,都限制了产品的上限,且这些问题很难在短期的测试中得到预警与修正。这种范式创新带来的问题往往无法靠游戏自己迭代解决,而是靠后来者踩着前人的尸体前进,因此第一个吃螃蟹的最后往往沦为被解剖的麻雀。

3. 真正重要的事:提出有品位的问题
那么对于个体的游戏人而言,什么是重要的呢?
我们可以更感性地审视与AI的协作——它其实是一个巨大的概率模型,像是尚未坍缩的概率云,一大块未经雕琢的大理石。而我们人类存在的意义,便是帮助这只无限打字的猴子,在尽可能少的尝试次数内,打出我们想要的《莎士比亚全集》。
没错,我们的全部价值,就是向AI问出正确的问题!如果这个问题恰好具备相当的全局视角、混合着漫长人生的独特记忆、包含着人类复杂的激素波动和感官幻觉,那么也许就会是一个颇有“品位”的问题。
正如在与Codebuddy的协作中,我们需要不断提出对便捷工具、优雅代码、模块化架构的相关问题,并且将抽象的“游戏性”拆解为一个个具体的功能需求——AI负责解决问题,而我们负责创造问题。

