AI 原生游戏开发实践 · 玩法体系全景

在上一篇 《AI原生游戏开发 —— 从管线重构到动态体验》 里,我提出过一个判断:AI Native 真正改变的不是 AI 生成资产,而是游戏工业第一次从”资产生产能力的竞争”,转向”体验验证速度的竞争”——最有竞争力的团队,不一定是拥有最多美术资产的团队,而是能最快验证”什么好玩”的团队。

那篇讲的是为什么。这一篇,讲怎么做

如果验证速度是新的竞争焦点,那么紧接着的问题就是:当你想让玩家有某种体验时,AI 到底怎么帮你把”想要的体验”,变成”可玩并且验证过的原型”? 上一篇把战斗、敌人、关卡这些管线分别谈了一遍;这一篇,我要把它们收进一套统一的框架里——让”从体验到验证”这件事,在每个系统上都走同一条路。

所以这篇是一张地图。每个系统怎么从体验目标出发、怎么用 AI 协作落地、怎么验证迭代,我都会展开讲清楚——包括为什么这么做,以及边界在哪。后面我还会用具体实例去扩展每个系统,这篇先把完整的体系立起来。


一条贯穿全篇的主线

不管是战斗、敌人还是关卡,做法其实是同一条线:

体验目标 → 功能 + 数值(配置驱动)→ AI 协作落地 → 验证迭代

这四步看起来朴素,但每一步的顺序和分工都有讲究。

第一步,体验目标。 先想清楚你要让玩家有什么感受——手感、情绪、节奏、成长。这是一切的起点,也是 AI 无法替你做的判断。很多团队跳过这一步直接做功能,做到一半发现”不好玩”,却说不清到底哪里不好玩——因为从来没定义过”好玩”是什么样。体验目标不是一句空话,它必须能被翻译成可验证的东西,否则后面三步都没有靶子。

第二步,功能 + 数值。 代码定骨架,数值定表现。这里的关键纪律是:迭代尽量靠改数值,而不是反复改代码。 频繁改代码,每次都有引入 bug 的风险、要重新测试、要重新评审;改数值则是热重载,不动逻辑,风险几乎为零。所以最好的可靠性,其实是少写代码、少改代码——把所有”可能变的东西”在写代码时就暴露成配置。

第三步,AI 协作落地。 AI 找参照、做翻译、批量生成。注意分工——人做决策,AI 落地操作。 AI 不替你判断”这个数值好不好”,它帮你把判断快速变成现实。

第四步,验证迭代。 机器跑 + 真人测,对照体验目标看达没达成。不达标就回去改,形成闭环。

这条线上最关键的一句话是:先验证好玩,再投入资产。 传统开发最大的浪费,是美术做了三周才发现玩法方向错了,这时候推翻成本极高,于是只能硬着头皮”赌方向”。而当玩法能用占位资产 + 数值快速验证时,你在第一时间就能发现方向不对,改个参数就行,没有人受伤——拒绝坏方向的成本几乎为零。这才是 AI 给玩法开发带来的根本改变:不是让你做得更快,而是让你更早地拒绝错误。

下面三个系统,都是这条主线的具体展开。区别只在于:每个系统锚定的”体验”不一样。


战斗系统:锚点是战斗体验

战斗系统的体验锚点是战斗体验——而手感,是达成这个体验的手段。手感本身太虚,做起来要拆成两层:功能(命中、伤害、技能、Buff 这些机制)和数值(TTK、暴击、后坐力、冷却这些参数),再加上 3C(角色、镜头、操作)。每一层都是”功能 + 数值”的组合——功能撑起骨架,数值决定手感,而手感最终是为了那个让人想一直打下去的战斗体验。

这里有个反直觉、但极其重要的顺序:功能要在数值之前。

举个具体例子。同一个”ADS 灵敏度 1.2″,在不同的功能实现下意义完全不同:镜头 FOV 是用线性过渡还是缓动?灵敏度是否随 FOV 同比缩放(也就是有没有启用 ADS multiplier)?切换瞄准的过程中能不能开火、被打断了怎么处理?这些全是功能层面的设计。如果功能没定下来,你调的那个”1.2″根本没有锚点——它在某种实现下是稳的,换种实现就飘了。所以正确的顺序是:先把功能想清楚、实现出来、把参数接口暴露好,数值才有意义。

AI 在战斗系统的角色,我把它概括成一句话:AI 找参照,人做决策。

具体是这样跑的。策划用品类语言描述意图——比如”对标 CoD 的射击手感,但移动更灵活一点”。注意,策划说的是意图,不是具体数字。然后 AI 去做两件事:先理解功能机制(把”CoD 的 ADS 做了什么”翻译成”我们要实现什么”——FOV 切换曲线、multiplier、切换中能否开火),再协助实现(生成可跑的代码骨架,把所有可调参数暴露出来,写好热重载和单元测试)。功能落地了,AI 再去拆数值:从对标游戏抽出参数,按”移动更灵活”这个需求做差异化偏置(移动 +15%、转向阻尼 −20%),每一项都带引用来源,可追溯。

然后是这套流程里我认为最关键、也最容易被忽略的一步——人和 AI 一起共创测试用例。

传统的”评审”是单向的:人对着 AI 的产出找毛病,给意见。但共创测试用例是双向的:人提出体验意图(“近距离遭遇战,玩家应该 0.5 秒内能决定打还是跑”),AI 把这种模糊的意图翻译成可执行的测试场景(“玩家 5 米距离、弹夹剩 8 发、敌人正面,检查 TTK 是否 ≤ 0.5 秒”)。这一步的真正价值,是逼着人把”我觉得好玩”这种直觉,显式化成”在什么场景下应该怎样”的具体标准。这些用例会成为团队的共识,后面机器跑、真人测,大家都对着同一组用例,不会出现”我说好玩你说不好玩”的扯皮。而且用例可以复用、可以持续沉淀——这是小团队第一次有机会建立 AAA 级的测试基线。

最后是双轨验证

一条轨道是机器跑:让程序里的虚拟玩家按用例条件跑上千场自动化战斗,统计每条用例的实际 TTK、命中率、胜率,验”数值对不对”。它的强项是快(秒级)、客观、量大,但测不出手感。另一条轨道是真人 playtest:真人拿手柄实打,用例库当 checklist 一条条勾,验”手感爽不爽”。它能测出数值对了但打起来”肉、没反馈”这种问题,但慢、样本少。

关键在于这两条轨道是分工,不是替代:机器筛数值,真人调手感。真人的起点已经是机器筛过的好版本,所以只需要微调最后那 5%。

跟传统的”凭经验给个数值 → 进游戏盲调 → 改 → 再调”循环相比,这套方式的差别不是”AI 帮你写得快”,而是:起点从一个随机的点,变成了一个被市场验证过的基线。 传统方式可能要循环 20 到 50 轮才能找到一个”还行”的点,而且没有客观参照,容易陷进”我觉得还差点意思”的死循环;新方式有对标、有用例库,客观可辩论、可回归,一两轮就收敛。周期从两到四周压缩到一到三天。


敌人系统:锚点是战斗体验带来的情绪价值

如果说战斗系统锚的是”打起来是什么战斗体验”,敌人系统锚的就是这个战斗体验所带来的情绪价值——玩家打完这一场,带走了什么。情绪价值不是凭空产生的,它是战斗体验之上长出来的结果:先有好的战斗体验,敌人才能在这个体验里制造出值得记住的情绪峰值。

这是敌人系统最容易被做错的地方。很多团队把心思花在”这只怪有多强、行为树多复杂”上,却忘了问一个更根本的问题:这个设计有没有给玩家制造一个”高光时刻”? 一场战斗的体验不是均匀的,它是一条有起伏的曲线,而真正让玩家记住的,是曲线的峰值——那些”危机 → 转折”的瞬间。

我用三个变量来锚定它:TTK × OODA × 情绪价值。

  • TTK(Time To Kill)是一次交战的时长容器,它决定了玩家能跑几轮 OODA。
  • OODA(观察 Observe → 定向 Orient → 决策 Decide → 行动 Act)是玩家在这段时间里的认知循环。简单理解:OODA 就是玩家从”发现问题”到”解决问题”的一轮完整思考过程。
  • 情绪峰值就产生在 OODA 循环里那个”危机 → 转折”的临界瞬间。

把它讲具体:玩家被一只敌人锁定(危机),用一个滑铲躲掉、反手爆头(转折)——爽。弹夹只剩 2 发面对满血敌人(危机),头铁命中(转折)——爽。队友倒下(危机),一打三杀光(转折)——这是高光。这些都不是”敌人设计得难”或”设计得弱”的问题,而是敌人有没有制造出 OODA 循环里的临界点

而 TTK 决定了这些临界点有没有机会发生。TTK 太短(比如 0.1 秒),玩家来不及观察、判断、行动,就被秒了,只剩挫败和迷茫;TTK 太长(10 秒以上),OODA 跑太多轮,就疲劳、无聊、拖沓。恰到好处的 TTK + 一次完整的危机到转折的 OODA = 高光体验。

所以敌人系统的每一项功能和数值,都要回到这个问题上来:它是否在 TTK 内,让玩家跑完 OODA 并产出了情绪峰值?这把整个评估标准重写了。行为树不只是”让 AI 会动”,它要制造威胁信号让玩家进入观察;招式不只是”造成伤害”,它要有可读的前摇留出反应时间;反应延迟要留白,让玩家的行动有空间。AI 鬼畜瞬反是反面教材——因为玩家根本来不及 OODA;AI 站桩挨打也是反面教材——因为玩家不需要 OODA。HP 和伤害这些数值也一样:HP 决定这只敌人的 TTK,伤害决定玩家被秒前的 TTK,两者都必须容得下至少一到两轮 OODA。

单只敌人的 OODA 是微观的。当多个敌人组合在一起,会产生宏观的 OODA——”我先打谁?”这种优先级判断。所以整体编排(波次、Squad、AI 导演)要在情绪曲线的低谷时介入:玩家太顺就加压,玩家太苦就给喘息。

那么”情绪”这种主观的东西,到底怎么验证?

我把验证分成三步,层层收敛——量在前,质在后。

第一步,机器跑硬指标。 虚拟玩家打上千场,统计 TTK、玩家反应时间、OODA 次数/分钟、死亡率、敌人击杀分布。这些是客观数据,每个指标都有期望区间(这些区间也是 AI 拆对标游戏拆出来的,不是凭空猜)。不达标的用例先标红筛掉一大批。这一步能从上千个用例收敛到上百个。

第二步,从玩家行为反推情绪。 这一步是敌人系统验证特有的,也是最巧妙的。AI 不会”感受”情绪,但它能识别情绪发生时的客观特征。原理是:情绪峰值会引起玩家的特定行为,反过来就能从行为反推情绪。具体分三个动作:你告诉 AI”残血反杀算高光”,AI 把这句话翻译成精确判定(击杀时 HP < 20% 且该敌人此前攻击过玩家);AI 写脚本从百万行日志里自动扫描,标出每场战斗在第几秒触发了哪些信号;再把这些离散信号拼成一条情绪曲线,跟设计目标对照,圈出”该高光但没出现”的区段。整个过程不需要 AI 有任何”感情”,它做的只是规则定义 + 数据扫描 + 对比——全是 AI 的强项。

第三步,LLM 看回放。 前两步有个死穴:它们只能识别你预先定义过的信号,而且行为是间接推断(“玩家闪避了”不等于”玩家觉得爽”)。LLM 看回放就是来补这两个洞的。把游戏录像和操作日志丢给多模态大模型,让它像一个”看过上万小时游戏视频的资深玩家”那样,在时间轴上打点:0:15-0:22 紧张、0:22-0:25 高光(残血翻盘)、0:40 挫败(卡关)。它能 work,是因为它训练时见过海量游戏视频和解说,认识”高光时刻看起来什么样”——它不感受情绪,但能识别情绪发生时的画面特征。要说实话:这一步还在早期,准确率在快速提升但没到完全可信,适合当辅助筛选,不替代真人终判。

这三步配合的意义在于:只跑数据,数值对了但可能还是不好玩;只靠真人,成本又爆炸。 三步分工,才能既快又准地验证情绪。而且每个”未对齐”的点,都是一条明确的改动指引——回到对应的功能或数值象限去改。


关卡系统:锚点是节奏与探索

关卡系统的体验锚点是节奏与探索。但跟前两个系统不同,关卡这一层有个特殊性:它是组装层。

关卡设计师真正交付的,是四样东西的协同布置:POI(兴趣点)、路网、怪物、资源。 这里要划清边界——怪物的设计归敌人系统(这只怪多强、行为树怎么写),资源的数值归经济系统(一个医疗包回多少血),但”在这张图的这个位置摆什么、刷几只、放哪些补给”——这是关卡系统的事。关卡系统拿敌人系统提供的怪、经济系统定义的资源、场景系统的地形,按体验目标布置到具体位置

而这四样东西的核心难点是:它们必须协同,指向同一个体验目标,不能互相抵消。

举几个反例就明白了。如果怪物摆得很密(想制造紧张),但资源给得很足(让人放松),两者就互相抵消,玩家根本不紧张。如果 POI 想引导玩家往东(鼓励探索),但路网只有往西的路,设计意图就落空了。如果稀有资源堆在某个 POI,但那个 POI 在死胡同、路网根本不经过,玩家就拿不到,白摆。所以关卡设计的真正手艺,是把”这段要紧张”翻译成一套配方:战斗 POI 靠拢 + 路网收窄成单线 + 怪物高密度 + 资源断供——四样一起服务”紧张”。每个配方,就是一个”体验目标 → 四样布置”的打包规则。

这里 AI 的定位必须说清楚:AI 自己不懂关卡设计。 这一点我不回避。AI 做的是承接专业策划的经验——把”什么体验用什么配方”这种零散、隐性的经验,结构化地沉淀成一个配方库,在制作时调用、在验证后回填。第一次用可能很空(没经验),但用得越多、回填越多,这个库越值钱,最后变成团队的资产。这跟战斗系统的”测试用例库持续演进”是同一个道理——都是把人的隐性经验,沉淀成团队的显性资产。

配方有了,怎么落地?这里只说方法论上的一点,具体的 UE 实现留给关卡系统的实战篇。

核心思路一句话:配置表驱动。 四样配方全部落进配置表,由程序化的方式读表生成——策划改表定意图,工具读表自动落地,改表就能重新生成,不动代码。这正是前面那条主线”配置驱动”在关卡系统里的体现:程序把能力做好暴露成配置,策划靠改表迭代,谁都不用频繁改代码。

把它讲清楚一点:每一样设计产出(POI、路网、怪物、资源),都有对应的落地手段,而中间把”设计意图”和”工程实现”连起来的,是配置表这个交接界面。设计师在表这一侧表达”要什么”,工程在表那一侧负责”怎么生成”。两边解耦,迭代就快。

最后,关卡做出来怎么验证?同样是回采数据看是否达成体验目标——玩家轨迹、停留、死亡点埋点,生成热力图,对照配方意图看:紧张段真紧张了吗(四样没抵消?)、该去的 POI 去了吗、走的路对吗。哪个配方实跑有效就强化入库,哪个翻车就修正参数——配方库越用越准。


后续方向:同一套框架还能装什么

战斗、敌人、关卡讲完,这套框架其实还能套到更多系统上。

成长养成、掉落经济、任务叙事,是跟战斗/敌人/关卡平级的游戏系统,都能复用同一套主线:体验目标 → 功能与数值 → AI 协作 → 验证迭代。运行时 AI 导演和 PCG × AI 则是两种横向能力,贯穿所有系统——前者让游戏对每个玩家”活起来”,后者让内容”长出来”。运行时导演的架构上一篇已经详细谈过(波次编排、事件注入、内容变异那套),这里不重复;只重申那条边界——上一篇的说法是”LLM 做’想什么’,行为树做’怎么做'”,放到这套框架里,意思就是 LLM 只做局间编排,不下场做每帧的 Tick 决策

这些先点到为止,后续会逐个展开。


技术底座:让这一切真正可靠、可普及

前面讲的全是”做什么”。但这一切能不能落地,取决于两个技术底座。

第一个底座:AI 写代码怎么才可靠。

我的答案是——可靠性不靠”AI 更聪明”,而靠一条固定的开发流程(SOP):确定框架/Skill → 制定 Plan → Skill 下执行 → 功能验收 → 配置化 → 数值验收。

这里只点出几个最核心的判断,完整的流程会另起一篇《AI Coding SOP》专门展开。其一,把 AI 框在已有的客户端框架内——它是填空,不是从零盖楼。其二,先出设计 Plan 让人审,绝不允许跳过 Plan 直接写代码。其三,也是跟玩法体系最相关的一点——两道验收:功能验收管”代码对不对”,数值验收管”数值对不对”。功能验收不过,回去改代码,成本重;数值验收不过,只改配置表,不碰代码,成本极轻。这正是整篇反复强调的”迭代靠数值不靠改代码”在工程上的落地——代码是骨架,尽量一次过;数值是调整层,可以反复改、反复验。

第二个底座:让所有人都能用,不只是程序。

前一个底座降的是程序的成本。这一个底座降的是所有人的成本——而且聚焦在玩法设计和原型搭建阶段。

AI 在这里当的是人与编辑器之间的翻译层。传统流程里,美术、策划要落地一个想法,得先学会编辑器一堆复杂操作、菜单、参数含义,然后手动在编辑器里搞。而有了翻译层,他们直接用人话表达玩法意图(“给我把近距离 TTK 0.4 秒的霰弹枪””这段要紧张那段给喘息”),AI 翻译成编辑器里的实际操作和配置,快速落地成可玩原型。

它降的是三种成本:学习成本(不用学编辑器的操作、菜单、参数含义)、使用成本(不用手动一个个点,AI 批量执行)、配置成本(不用记字段名、不怕填错,AI 按意图生成并校验)。

而且这一层直接接上前面四个系统的原型搭建。策划说”对标 CoD 手感、移动更灵活”,AI 翻成 3C 参数配置,直接进游戏调;策划说”会包抄的近战怪,三只一组刷”,AI 翻成占位怪 + 行为配置 + 刷怪表;策划说”这段紧张那段喘息”,AI 翻成 POI/路网/资源配置由 PCG 生成。每一个都是”策划说意图 → AI 翻译 → 可玩原型,立刻验证”。

但边界必须划得很清楚:这一节只搭”玩法原型”,不碰美术表现。 这个阶段的美术,正是上一篇说的四阶段里的第一阶段——验证期:给玩法提供够用的占位(方块人、灰模、商城资产、临时特效),服务玩法体验,而不是做好看的成品。目标是”够用 + 快”,因为这阶段是验证玩法。后面的采购、调优、替换,以及美术表现、渲染、光影材质,不在这一节,留待后续章节。

这层的意义在于一个视角的转变:AI 降的从来不是”程序的成本”,而是所有人的成本——让每个岗位都从”折腾工具”里解放出来,把精力放回”判断玩法好不好玩”上。而 AI 降的也只是”操作成本”,不是”判断”——玩法好不好玩,永远是人的判断。AI 落地,人决策。


写在最后

把这张地图收成一句话:

AI 不替人做判断,而是让”从体验到可玩原型”这条路快 10 倍。

人定体验目标、做判断;AI 找参照、落地、跑验证。三个玩法系统各有自己的体验锚点——战斗锚战斗体验、敌人锚战斗体验带来的情绪价值、关卡锚节奏与探索——而锚点决定了”验证什么”,验证又驱动迭代。没有体验锚点,就不知道该验证什么,AI 也无从协作。锚点,是一切的起点。

这篇是地图。接下来,我会把:

  • 战斗系统
  • 敌人系统
  • 关卡系统
  • AI Director
  • AI Coding

逐个拆开。

这篇是地图。后面的文章,会是一次真实开发过程的持续记录。

不是讨论 AI 能做什么。

而是讨论——当 AI 真正进入游戏开发之后,一个团队是如何理解系统、验证体验、重构玩法,并最终把想法变成游戏的。

地图已经画好。接下来,是走进每一条街道。

AI原生游戏开发实践 —— TPS相机重构

一、为什么写这篇

上一篇我们讨论了AI Native游戏开发的方法论,核心观点是”体验验证前置”——在正式资产到位之前,游戏已经可以被完整游玩和验证。

方法论说起来很美,但落到真实项目里到底什么样?

这篇用一个真实案例来回答:我们手里有一个FPS工程,想把它改造成TPS。不是从零做一个TPS,而是在已有FPS系统的基础上,让它变得”像一个TPS”。

这不是一篇TPS相机技术文。这是一篇关于AI如何参与真实开发现场的纪录——从理解一个陌生的系统开始,到产出完整的改造方案和开发计划。


FPS vs TPS

二、起点:一个FPS工程想变成TPS

我们面对的是一个已经运营了一段时间的FPS射击工程,基于UE开发,代码量不小,多个团队经手过。工程里确实有TPP模式——有一个CameraMode组件支持FPP/TPP切换,切过去相机确实到了角色身后。

Wrong vs Right TPS

但切到TPP之后你会立刻感觉到”这不是TPS”。相机距离固定在216cm,肩部偏移只有24cm,跟随没有任何Lag,感觉像把一个摄像头刚性焊在角色背上。瞄准的时候相机直接切回FPP,TPS视角下根本没法正常ADS。开枪几乎没有相机反馈——后坐力、开火震动这些系统存在,但只在FPP下生效。贴墙时相机直接怼进墙里。整体更像是一个”从背后看FPS”,而不是真正的第三人称射击体验。

传统做法大家都清楚:策划凭经验写一份相机需求文档,列一堆”要加的功能”,程序排期开发,做完联调,发现不对,改,再联调,再改。几个月下去,可能还在调基础手感。而且因为不清楚现有系统的全貌,很可能重复造轮子——某个功能其实已经有了,但没人知道。

一开始我们也是这么想的。

后来换了个思路:与其凭经验猜”要做什么”,不如先让AI把整个相机系统翻一遍,搞清楚”已经有什么”。


三、AI不是在”生成功能”,而是在”理解系统”

这是整个过程中最出乎意料的部分。

AI读完整个相机系统的源码后,我们发现了一个令人意外的事实:这个工程的相机框架能力其实很强。

SpringArm组件支持15种以上的移动状态——站立、蹲下、趴下、翻越、跳伞、游泳、被背负、NPC对话……每种状态都有独立的相机距离、偏移、高度配置,通过一个叫BasicLayerConfig的TMap在蓝图里配置,完全数据驱动。CameraModifier体系更是一字排开:武器后坐力Modifier、枪械摇摆Modifier、受击相机Modifier、开火震动Modifier、趴姿冲击Modifier、车载相机Modifier……十几个Modifier各司其职。瞄具系统有一张完整的CSV配置表,50多种瞄具各自的缩放倍率、FOV、景深参数全部可配。FPP/TPP切换有完整的优先级机制,支持多个系统同时请求相机模式切换并按优先级仲裁。

框架能力远比我们预想的强。

Camera Modifier Stack

但AI同时也发现了另一面。让AI翻一个运营多年的工程代码,很像在考古——你不断挖出一些东西,有的还在用,有的被埋了,有的做了一半就停了。

AI Code Archaeology

Sprint相机层——完整的加速/稳定/减速相机变化逻辑,大约60行代码,但整段被 #if 0 包裹。这不是”没做”,而是做过,被遗弃了。

后坐力系统——非常精细,支持按姿态分别配后坐力模式,有弹簧阻尼恢复。但检测到非FPP直接return。一个工程”像不像TPS”,有时候只差一行代码。

ADS瞄准——触发瞄准时直接强制切FPP,没有任何配置开关。TPS体验断裂,往往不是缺系统,而是系统之间没有真正协作。

代码里还有大段标注”废弃逻辑”的注释块——左右肩射Camera层、喷气背包Camera层,全部写了配置属性声明但被注释掉。之前有团队规划过一套完整的TPS肩射相机系统,但在某个时间点被整体搁置了。这些废墟和活代码混在一起,一个运营多年的工程往往不像”一个系统”,更像多个时代叠加起来的遗迹。不是AI标出来,很难分辨哪些是活的哪些是死的。

AI还顺着调用链一路往下翻,挖出了几个更意外的东西。

FPP/TPP切换的过渡时间不对称——切进FPP是0.1秒snap,切回TPP是0.6秒平滑过渡,两个方向各有独立easing曲线。这不是随便写的数字:快速zoom out看起来突兀,所以进FPP要快,回TPP要慢。一个嵌在代码里的体验设计决策,没有任何文档记录过为什么。AI读到这组数字的时候,我们才意识到前人在这里做过非常细致的考量。

相机模式有7级优先级。有意思的是玩家手动切换FPP/TPP的优先级排在第5——高于载具。代码注释写了:”玩家的主动切换优先级很高,如果业务逻辑需要覆盖,需要先单独调用清理接口”。一个UX哲学嵌在代码里:玩家的选择权高于大部分系统行为。

最意外的发现:AI顺着Retarget逻辑往下翻,发现即使玩家在TPP模式,只要武器开镜,动画会悄悄切到FPP模式。TPP下开镜瞄准时,角色的手臂动画其实在用FPP的。不读完整条链路根本发现不了。

一个工程看起来”不像TPS”,不是因为它缺少做TPS的能力,而是因为这些能力散落在各处,有的被禁用了,有的只给FPP用,有的逻辑写了但没配参数,有的做了一半被搁置了,有的藏在你不会注意到的条件分支里。

一开始以为”要做很多新功能”。后来发现”大部分功能已经有了,只是没用好”。

这个发现改变了整个项目的走向。如果按传统思路,我们会排一个”开发新TPS相机系统”的计划,可能要几个月。但实际上需要做的是”启用已有功能+调参数+修几个硬编码”,工作量小一个数量级。

更有意思的是,AI梳理出了一个完整的配置层级:底层是BasicLayerConfig控制各姿态的基础相机参数,中间层是IndoorLayerConfig在室内自动叠加偏移(每0.5秒向上做一次射线检测判断是否在室内),上层是瞄具表控制ADS时的FOV和景深。也就是说,很多”相机不对”的问题,可能根本不需要改代码,调表就行。但在AI分析之前,没人知道这套三层配置体系的全貌,更没人把它们之间的数据流画清楚过。

这让我们重新思考了一个问题:传统项目里,团队花在”开发新功能”上的时间可能没有想象中那么多。大量时间其实花在了”搞清楚现有系统到底是什么状态”上面。一个中大型工程里,某个功能被谁写了、被谁禁用了、当时为什么禁用、现在还能不能用、参数配在哪张表里——这些问题靠人肉翻代码可能要几天到几周。AI把这个过程压缩到了几个小时。

而且AI的”理解”不是简单的代码搜索。它能把分散在十几个文件里的逻辑串成一条完整的链路:玩家按下瞄准键→FSM Action触发→CameraMode组件按优先级仲裁→SpringArm状态切换→BasicLayerConfig查找对应参数→插值过渡到目标位置→CameraModifier逐个叠加后坐力/摇摆/受击效果→最终输出相机变换。这条链路横跨了GameplayFramework、Camera、Weapon、Animation四个模块,没有人能一次性在脑子里串起来。AI可以。


四、从Feature List到设计原则——每条原则背后都是一个坑

搞清楚系统现状后,第一版方案很自然地变成了一个Feature List:ADS要保持TPP、要加Sprint相机、要启用探头、要补全TPP射击反馈、要优化碰撞……

列了一大堆。

然后我们发现一个问题:功能列了这么多,但不知道什么该先做什么该后做,不知道什么该克制什么该加强,不知道两个功能冲突时听谁的。

Feature List缺的不是”做什么”,而是”为什么做”和”什么不做”。

于是我们开始建立设计原则。不是一开始就坐下来写一套完整的Camera Philosophy——那种东西写出来也没人看。而是每次踩到一个坑,就把教训沉淀成一条原则。五条原则,每一条都来自一个真实的问题。

Camera Philosophy:可读性 > 手感 > 演出 > 炫技

一开始想做很多动态运镜来增加”高级感”。相机跟随加大幅度的惯性,Sprint加强烈的FOV推进,受击加大幅度的画面偏移。看起来确实更”动态”了。

然后我们发现玩家打不到人了。

TPS视角下玩家需要同时关注角色位置、敌人位置、环境掩体,相机的动态效果每增加一分,玩家能分配给”瞄准敌人”的注意力就少一分。于是确立了这条原则:相机的所有变化都必须服务于Gameplay信息传递,可读性永远排在第一位。

Comfort & Stability:长时间不疲劳,ADS必须稳定

尝试了更强的Camera Lag和Sprint Shake。第一个问题不是”不够爽”,而是玩家开始晕了。

短时间体验”哇这个相机好有电影感”。30分钟后”我需要休息一下”。TPS是长时间游玩的品类,相机舒适度比短时爽感重要得多。于是这条原则把短期舒适(别晕)和长期疲劳(玩2小时别累)都涵盖了进去。

Camera Rhythm

Transition & Rhythm:状态切换有节奏

每个Camera功能单独跑都没问题。但同时跑起来的时候,Sprint拉远还没恢复完就进了ADS,ADS还在过渡就触发了后坐力,后坐力还没回弹就吃了一个爆炸冲击。

问题不在于某个功能错了,而在于相机失去了节奏。

Consistency:同一行为永远同一反馈

ADS状态下的射击反馈和腰射的反馈不一致。有时Sprint出来拉远幅度不一样。有时ADS过渡快有时慢。

结果是:玩家永远无法形成稳定的肌肉记忆。每次操作都要”看一下相机在干什么”才能做下一步判断。TPS依赖肌肉记忆的程度比很多人以为的要高——你需要知道Sprint之后ADS拉回来要多久,才能在正确的时机开枪。

Safety Rules:Camera绝对不能坏

狭窄空间Camera疯狂抖动。ADS被爆炸效果强制拉开。贴墙时相机突然穿进角色。这些不是”体验不好”的问题,是”体验彻底崩溃”的问题。

Camera坏一次,玩家对整个操控系统的信任就会动摇。于是这条原则定义的不是”该怎么做”,而是”绝对不能发生什么”。


AI vs Human

五、功能和数值分离——AI穷举可能性,人判断什么是对的

方案做到一半,我们发现了一个更本质的问题:很多Camera体验的好坏,不取决于”功能有没有”,而取决于”参数对不对”。

同样一个Sprint Camera功能,FOV多推2度和少推2度,相机拉远30cm和拉远50cm,感觉完全不同。功能做对了只是起点,参数调对了才是终点。

但功能开发和参数调优需要的能力完全不同。功能开发需要理解代码架构、改逻辑、处理边界情况;参数调优需要反复进游戏体验、凭感觉判断、做取舍。前者AI做得又快又稳,后者只有人能做。

于是我们把工作流拆成了两条线:

AI负责把功能做通——分析代码、启用被禁用的功能、补全缺失的逻辑路径、生成参数表模板带默认建议值。

策划负责把体验调对——拿着AI生成的参数表,进游戏反复体验,逐项调整,直到手感对。

更准确地说:AI更适合”穷举可能性”,人更适合”判断什么是对的”。 AI可以告诉你”这个工程有15种相机状态、8类Camera Modifier、50多种瞄具配置”,但只有人能判断”站立时相机离角色多远感觉最舒服”。

这不是AI的局限,是合理的分工。

举个具体例子。AI分析完射击反馈系统后,告诉我们”工程里十几个CameraModifier,其中后坐力、开火震动、FPP骨骼动画这三个只在FPP下生效,枪械摇摆和通用抖动在FPP和TPP下都生效,受击相机在TPP下生效但效果很弱”。基于这个分析,AI帮我们生成了一份按武器类型分类的TPP后坐力参数表模板。但”步枪的后坐力缩放到FPP的0.5感觉对不对””SMG的高频抖动会不会让玩家觉得烦”——这些判断只有人拿着手柄打几局才能回答。

AI不断输出”系统能做什么”和”参数可以怎么调”,策划不断在游戏里回答”这样对不对”。两条线并行,比传统的串行反馈模式快很多。


Development Order

六、开发计划:先”像不像TPS”,再”瞄得准”,最后”打得爽”

有了方案和原则后,下一个问题是:先做什么?

TPS相机最大的问题往往不是”功能缺失”,而是”基础节奏没立住”。如果基础视角就不对,后面加再多高级功能也是在歪的地基上盖楼。

我们把P0拆成了7步,按严格顺序推进:

第一步是基础TPP视角和肩部位置。做完这一步只回答一个问题:”像不像一个TPS?”如果肩部偏移不对、相机距离别扭,后面所有东西都会跟着歪。

第二步是ADS。建立稳定的瞄准体验。这是最高风险的一步——会影响输入、FOV、后坐力、瞄准稳定性,牵一发动全身。所以放在第二步,尽早暴露问题。

第三步是碰撞处理。解决贴墙和室内的穿模问题。第四步是射击反馈,让TPP下开枪有感觉。第五步是Sprint相机,第六步是探头,第七步是受击反馈。

每完成一步立刻验证。不是写完所有功能再一起测,而是每一步都确认”对了”再进下一步。

为什么这个顺序很重要?因为TPS相机的依赖链是有方向的。基础视角不对,ADS拉近的目标位置就会偏;ADS不稳定,射击反馈就无从调起;碰撞没处理好,室内的所有功能都会出问题。后面的每一步都依赖前面的步骤是对的。如果跳着做,最终很可能要回头全部返工。

我们还给每一步标了风险等级。ADS改造是高风险——它牵涉输入、FOV、后坐力、瞄准稳定性,改一个地方可能影响五个地方。所以放在第二步,尽早暴露问题。Sprint Camera和探头是低风险——已有逻辑取消注释就能跑。低风险的可以快速推进,高风险的要留足调试时间。

整个过程有一条核心原则:除非影响核心体验,否则优先复用现有能力,避免大规模重构。 工程已经有的东西尽量用,能调参数解决的不改代码,能启用已有功能的不写新功能。

P0完成后锁定基础体验。后续的P1(高级感)和P2(高级战斗表现)不得破坏P0建立的基础——ADS稳定性、基础视角、碰撞行为、基础射击反馈,这些一旦锁定就不能再动。


AI System Understanding

七、AI真正的价值——压缩”搞清楚现状”的成本

回头看整个过程,AI没有自动做出一个TPS相机。

AI做的是把”摸清现状→发现问题→出方案→拆计划”这个过程从几周压缩到了几天。

传统流程里,一个新接手的程序要理解现有相机系统可能需要一到两周——翻代码、看注释、问原作者、跑测试。一个策划要写出靠谱的TPS相机需求可能也需要一到两周——查参考、写文档、和程序对齐理解。然后再花几周排期和开发。

AI改变的不是”开发效率”——真正改代码、调参数的时间没有本质变化。AI改变的是”理解效率”。

在这个项目里,AI第一次开始像团队里的一个高级程序员——不是因为它会写代码,而是因为它能快速理解整个系统。

AI在几个小时内读完了整个相机系统的源码,告诉我们:这里有什么、这里缺什么、这里被谁禁用了、这里的配置表长什么样、这里的数据流是怎么走的。然后基于这些事实(不是猜测),产出方案和计划。

传统流程是”先猜后验”——先凭经验猜需要做什么,开发完了再验证猜得对不对。AI Native流程是”先看后做”——先让AI把系统翻一遍,基于事实出方案,然后有针对性地开发。

这回扣了上一篇的核心观点,但维度有所不同。上一篇说的”体验验证前置”主要是指用占位资源验证玩法方向。这篇的实践让我们意识到:验证前置不只是验证玩法,也包括验证”现有系统的真实能力”。 在动手改之前先搞清楚手里到底有什么牌,这本身就是一种验证前置。

还有一个意外收获。AI产出的不只是一份方案,而是一份团队都能看懂的”系统地图”。以前只有写这段代码的人知道相机系统长什么样,现在AI把整个系统的架构、数据流、配置表、已有功能、被禁用的功能整理成了文档。新加入的程序和策划看完这份文档就能快速进入状态,不需要再花两周自己翻代码。

这可能是AI参与大型工程开发中一个被低估的价值:不只是帮你做事,更是帮你把隐性知识变成显性知识。很多工程里最大的资产不是代码本身,而是”为什么这么写”和”这里能做什么”的上下文信息。这些信息过去只存在于少数人的脑子里,AI让它变成了每个人都能查阅的文档。


八、这只是开始

相机只是TPS改造的第一步。

后面还会继续把移动系统、TPS瞄准、动画分层、武器挂载这些模块逐步拆开。不只是讲”最终方案”,而是真实记录AI如何参与一个大型游戏工程的持续重构。

目前很多问题其实还远没解决。AI能帮助团队更快理解系统、更快验证方向、更快搭出原型。但”什么是好的体验”依然需要人反复试、反复踩坑。相机的手感、射击的节奏、移动的重量感——这些东西没有任何AI能替你判断,只有人拿着手柄在游戏里跑几十个小时才能慢慢逼近答案。

到目前为止,AI最大的价值依然不是”自动生成游戏”,而是让团队第一次能够更快理解系统、更快验证方向、更快知道什么不好玩。

AI穷举可能性,人判断什么是对的。AI理解系统,人理解体验。

这是一个持续展开的AI Native开发纪录,不是一篇孤立的案例分享。如果你也有一个”明明有能力但跑起来不像那回事”的工程,试试先让AI把它翻一遍。你可能会和我们一样发现:答案可能就在代码里,只是从来没人完整地看过。

AI原生游戏开发 —— 从管线重构到动态体验

AI Native游戏真正改变的,不是AI生成资产。而是游戏工业第一次开始从”资产生产能力竞争”转向”体验验证速度竞争”。


一、行业判断:游戏工业真正昂贵的是什么

过去二十年,游戏工业的核心瓶颈始终是内容生产。

传统3A工业依赖大规模美术团队、长周期资产生产、重资产迭代流程。一个3A项目动辄几百人的美术团队,两到三年的资产制作周期,数以亿计的开发预算。表面上看,这些成本花在了”做内容”上。但如果仔细拆解,你会发现真正昂贵的并不是”写代码”或”建模型”本身——真正昂贵的是”验证一个玩法方向”。

一个关卡设计师有了想法,需要等场景美术搭完环境才能验证动线;一个战斗策划想调整射击手感,需要等武器模型和特效到位才能感受反馈;一个系统策划想测试新的刷怪节奏,需要等敌人模型和动画就位才能跑playtest。每一次验证都被美术资产的进度卡住。发现方向错误的时间越晚,浪费的美术产能越多。

我们都见过这些经典灾难:武器特效精心制作三周,上了才发现TTK根本不对;Boss动画做了两个月,进游戏才发现机制不好玩;场景美术搭了三个月,playtest发现地图尺度有问题、战斗空间太空旷。

真正昂贵的从来不是”做资产”,而是”做错资产”。

很多团队都经历过:一群人花了几个月做资源,最后才发现”这东西根本不好玩”。那种会议室里的沉默,每个做过游戏的人都懂。

这就是传统游戏工业最大的结构性浪费:设计验证和资产生产紧耦合。

AI带来的最大变化,并不是”自动生成游戏”——至少今天还远不是。AI带来的真正变化是:

游戏团队第一次可以在正式资产完成之前,提前完成玩法验证。

这意味着三件事:

  1. 策划验证前置——在占位资源上就能跑通完整的体验循环,确认设计方向
  2. 美术从”生产驱动”变成”体验收敛”——不再是美术做完什么策划就验证什么,而是策划验证完什么美术就朝什么方向收敛
  3. 程序重新成为开发节奏的核心——AI大幅加速了程序侧的产出,使得”出一个可验证的版本”的速度从以月计变成以天计

这就是AI Native游戏与传统游戏工业最大的区别。不是”用AI替代了谁”,而是整个开发管线的节奏控制权变了

行业内很多团队还在讨论”AI什么时候能替代美术”。但这个问题本身就问错了。如果一个团队今天还在等待”AI自动生成3A资产成熟”,那它大概率已经错过了AI Native游戏真正的窗口期。 因为窗口不在资产生成,而在管线重构。


二、为什么是搜打撤,为什么是现在

过去两年,AI在游戏行业的讨论几乎全部集中在两个极端:一边是”AI生成3D资产即将颠覆美术产能”,一边是”AI只能聊天,对游戏开发没有实质帮助”。两个判断都有问题——前者高估了3D生成的成熟度,后者低估了AI在程序和策划环节已经具备的规模化能力。

真正有价值的问题不是”AI什么时候能替代美术”,而是:在3D生成尚未成熟的今天,如果我们换一种资产策略,AI到底能把一款游戏的开发推进到什么程度?

我们选择类ARC Raiders的PvEvP协作搜打撤作为分析对象,不是因为这个品类最热门,而是因为它在两个层面上都天然适合AI介入。

技术层面,这个品类的结构特征让AI的介入空间最大化:

  • 单局制意味着不需要跨局记忆和长期叙事一致性——这恰好避开了LLM最弱的环节
  • PvE核心意味着没有PvP公平性约束——AI可以自由调度内容而不破坏竞技平衡
  • 搜打撤三段式结构清晰,天然适合模块化拆解——每个阶段的策划/程序/美术工作都可以独立评估
  • 小队规模数据量极低——即使引入运行时AI调度,算力成本也在可控范围

体验结构层面,搜打撤的核心乐趣本身就来自不确定性——动态遭遇、风险变化、资源压力、临场决策。玩家期待的不是每局一样的固定流程,而是每次进入战场都不知道会遇到什么。这恰好是AI Director最擅长的事:动态重组体验。从Left 4 Dead的AI Director到Roguelike的程序化生成,这类”每局不同”的游戏结构天然适合AI介入。搜打撤只是这个方向上最匹配当前技术成熟度的品类。

这不是一个关于”未来AI游戏会怎样”的畅想文章。这是一个关于今天就能落地的工程方案,以及为什么有些环节还不行的诚实评估。

我们将游戏开发拆解为8条管线,分属两层:

  • 核心玩法层:战斗、敌人、任务/关卡、角色/装备
  • 场景与表现层:场景、表现(打击感/视觉反馈)、音频、UI

美术侧不追求AI生成量产级3D资产,而是走”AI占位验证 + 商城/项目资产复用 + AI批量调优”的路线——这不是妥协,而是基于上面行业判断的主动选择:让体验验证和资产生产解耦


AI原生游戏生产管线

三、核心玩法层:程序和策划已经可以全面AI化

1. 战斗管线——数值驱动的环节,AI天然适配

战斗管线是最能体现AI落地价值的管线之一,但原因并不是”AI能写出完美的战斗代码”,而是战斗系统的核心工作本质上是参数驱动的。

武器DPS、TTK、技能冷却、Buff叠加规则——这些不是创意工作,是数学工作。传统流程中,策划花大量时间手动填Excel、反复微调数值、跑模拟验证平衡性。这恰好是AI最擅长的:给定约束条件,穷举参数空间,输出符合设计意图的数值方案。一个有经验的策划配合AI,一天可以完成过去一周的数值迭代量。

程序侧更直接。武器状态机、伤害计算模块、技能框架、Buff系统——这些都是模式高度确定的工程工作。AI代码生成在这类场景下的产出质量已经相当稳定,不是”能用”的水平,而是”直接进工程”的水平。配置表批量生成和校验更是AI的强项,基本消灭了手动填表的出错风险。

战斗管线的瓶颈从来不在美术资源——一把枪的模型不影响射击手感的调优。瓶颈在数值迭代速度。AI恰好把这个瓶颈打开了。一个占位简模挂上AI生成的参数表和代码,策划今天就能进游戏调TTK。

2. 敌人管线——结构化设计 + 行为系统,AI的强项

敌人管线有一个被低估的特点:它的设计工作高度结构化。

一个搜打撤游戏的敌种体系,本质上是一个分类问题——按体型(轻/中/重)、按行为模式(巡逻/伏击/追击/AOE)、按难度梯度(普通/精英/Boss)构建矩阵,然后填充属性参数和克制关系。这种”先定框架、再填参数”的工作模式,AI做得又快又稳。积分桶参数、巡逻路线方案、波次配置表、难度曲线——这些过去需要策划反复playtest调整的数值,AI可以基于设计意图批量生成初版,策划在这个基础上做精调,效率提升不是百分之几十,是数量级的。

程序侧,行为树/状态机代码、感知系统、SpawnManager——这些同样是模式确定的工程工作,AI生成质量稳定。

验证刷怪节奏需要的是什么?一个能跑的SpawnManager加几个胶囊体简模,不是精雕细琢的怪物模型。”出一个可测的敌人系统”从几周变成几天。AI消灭的不是工作量,而是等待。

3. 任务/关卡管线——流程设计的模块化价值

搜打撤玩法的任务设计有一个天然优势:三段式结构本身就是模块化的

搜索阶段的POI配置、战斗阶段的遭遇设计、撤离阶段的压力曲线——每个阶段都可以独立定义参数和规则。AI可以生成任务类型库(摧毁、护送、采集、防守、侦察),也可以根据地图拓扑生成POI功能分配和动线建议。这里策划的核心价值不是”想出这些任务类型”(AI可以覆盖),而是”判断哪些组合在体验上是好的”——这是需要游戏感觉的判断工作,暂时无法被AI替代。

程序侧,任务状态机、触发器系统、事件调度器都是标准的AI落地场景。动态事件系统(巢穴警报、友军求救、物资空投)的框架代码也是成熟的生成目标。

这条管线的程序工作量大、模式清晰,AI介入的ROI非常高。传统流程中验证一张关卡的搜打撤节奏需要等场景美术搭完环境——几个月。有了AI白盒+任务系统代码,发现方向错误的成本从三个月变成了两天。

4. 角色/装备管线——配置表密集型,AI的效率碾压点

装备体系设计和经济模型数值模拟是策划侧AI的典型场景。但这条管线AI介入价值最大的环节其实是配置表生成

一个中等规模的搜打撤游戏可能有几十把武器、多套护甲、大量战略配备。每一个都需要完整的DataTable配置:基础属性、品质加成、升级曲线、兼容性规则。传统流程中这是纯体力活,耗时巨大且极易出错。AI批量生成+自动校验,不仅提速5-10倍,而且几乎消灭了人工填表的数据一致性问题。

游戏开发中被低估的成本不是”想一个好设计”,而是”把一个设计变成几百行没有错误的配置数据”。AI最先改变的,不是资产生产,而是配置生产。

这里值得多说一句:AI特别适合参数空间探索、数值平衡、Build组合推演、波次设计、Encounter矩阵、掉落配置、配置校验——而这些恰好是大量中层策划每天最耗时间的部分。AI不会替代”会设计的人”,但会迅速淘汰”只会填表的人”。 策划的核心价值正在从”执行配置”回到”做体验判断”。


四、场景与表现层:程序依然强势,但美术和体验调优需要人

5. 场景管线——AI做规划,人做感觉

场景管线最能体现AI的能力边界。

AI可以做的事情很具体:地图功能分区方案、POI分布密度建议、程序化植被和道具摆放规则、地形生成和寻路网格代码。这些都是有明确输入输出、可以用规则和数据驱动的工作。

AI做不好的事情也很明确:空间感。一张好的搜打撤地图,它的紧张感来自视线管理、来自”转角遇到敌人”的空间叙事、来自高低差和掩体分布带来的战术深度。这些需要关卡设计师的直觉和大量playtest,AI目前无法替代。

最务实的做法是:AI负责”基础设施”(地形生成、加载系统、环境交互代码),人负责”体验层”(空间布局、氛围营造、战术路径设计)。两者配合而不是互相替代。

但即使在场景管线,验证节点前移依然成立。AI生成的白盒地形虽然粗糙,但足以让关卡设计师验证空间尺度、视线关系和战术路径。先确认”好不好玩”,再投入资源让它”好看”。 这个顺序省下的不只是时间——它把”花三个月搭完场景才发现尺度不对”这种经典灾难直接消灭了。

6-8. 表现/音频/UI

表现管线:程序侧(屏幕震动、顿帧、镜头抖动、破坏系统代码)AI可以直接生成,但打击感的最终调优是主观判断工作,需要人反复体验和微调。特效资产走商城复用+AI参数微调路线。

音频管线:AI生成的临时音效和音乐可以在原型阶段使用——这比”没有音效”好太多,因为没有音效的战斗根本无法评估打击感。但最终品质的音效仍然需要专业制作。

UI管线:这是美术侧AI成熟度最高的管线。2D UI元素的AI生成质量已经可以直接进入产品,配合商城UI Kit基本可以实现AI全覆盖。这不是未来的事,是今天就在发生的事。


五、开发节奏回归:谁来定义游戏生产的时间线

过去十年,游戏工业的节奏控制权实际上长期掌握在美术生产管线上。

因为玩法验证依赖资产、场景验证依赖环境、战斗验证依赖特效、动线验证依赖关卡美术。程序虽然决定”系统能不能跑”,但真正决定”什么时候能验证体验”的,是资产生产速度。策划等美术、美术等外包、外包等反馈——整条链路的节奏由最慢的环节决定。

AI改变了这件事。当AI能批量生成代码、能自动生成配置、能快速搭建白盒、能生成可玩的占位资源——游戏开发第一次重新回到”程序+策划驱动”。

这个变化的意义远比”效率提升百分之多少”更大。它意味着:

  • 迭代周期压缩——过去一个迭代周期以月计(等资产→测试→反馈→修改),现在以天计(AI生成→测试→反馈→再生成)
  • 试错成本骤降——想试三种不同的关卡布局?过去意味着三倍的场景制作时间。现在意味着三个AI白盒,一周内全部验完
  • 小团队获得大团队的迭代速度——不是因为人更少更好,而是因为AI消除了”等待”这个最大的时间黑洞

这也改变了团队内部的角色关系。传统流程中,策划出完文档就进入漫长的等待——等美术出资产、等程序搭系统、等联调能跑起来。现在策划出完文档的当天,AI就能生成一个可玩的版本。策划从”提需求然后等”变成了”提需求然后立刻验证”。 美术的角色也变了:不再是”先做出来让策划验证”,而是”策划验证完了告诉美术该朝哪个方向做”。

关键判断: AI Native时代最有竞争力的团队,不一定是拥有最多美术资产的团队,而是能最快验证”什么好玩”的团队。程序+AI驱动的迭代速度,正在成为新的核心竞争力。


六、每条管线怎么验证:在资产到位之前把游戏跑通

第五章讲了宏观的节奏变化。这一章讲具体的:每条管线里,策划和美术分别怎么在占位阶段完成验证。

战斗管线:AI生成数值+代码后挂上占位武器和临时特效,策划立刻可以进游戏验证射击手感和TTK。不需要等武器模型做完。美术在这个验证版本上观察特效时序和节奏是否对,确认方向后再去商城选型——而不是先买了资产再发现不合适。

敌人管线:胶囊体简模加颜色区分兵种就够策划测试刷怪节奏和难度曲线了。美术在这个基础上确认”不同兵种需要多大的体型差异”和”需要什么轮廓特征来保证辨识度”,然后带着明确需求去找匹配的商城资产。

任务/关卡管线:AI白盒关卡让策划直接跑搜打撤全流程——动线是否流畅、POI密度是否合理、撤离阶段紧张感够不够。在白盒上就把体验跑通,正式场景进来只是换皮,不是赌方向。

场景管线:在白盒上确认空间尺度和视线关系。美术据此规划正式场景的布局方向,避免了”花三个月搭场景,然后发现地图太大/太小/动线有问题”的经典灾难。

音频管线:AI生成临时射击/爆炸/环境音效,策划体验完整的音频反馈链路。用占位音效确认各音效的层次和优先级关系,再制作或采购正式音频资产。

UI管线:AI生成Debug用HUD,策划在游戏中实时看到血量/弹药/状态数据,验证信息呈现是否清晰、交互流程是否顺畅。

体验验证闭环

每条管线都遵循同一个模式(见体验验证闭环图)。

传统流程:”美术先行,设计跟着资产走”
新流程:”设计先行,资产跟着体验走”
传统工业最昂贵的不是生产,而是方向试错。 新流程把方向试错的成本降了一个数量级。


七、美术资产策略:不是等AI能生成3D,而是根本不需要

行业里有一种思维惯性:讨论AI在游戏开发中的价值时,总是卡在”3D资产生成什么时候成熟”这个问题上。仿佛只要3D生成不成熟,AI就对游戏开发没有帮助。

这个思路错了。

3D资产生成确实不成熟,短期内也看不到达到量产标准的可能。但这不意味着美术侧就只能等。我们的策略是一套四阶段工作流,完全绕过了”AI生成3D”的瓶颈。

美术资产四阶段工作流

阶段一:验证期——24小时可测

策划出设计文档后,AI立即生成白盒关卡、简模角色/敌人/武器、临时特效、测试音效和批量测试配置数据。关键不是这些占位资源的品质(它们确实粗糙),而是它们让玩法验证不再被美术进度卡住。任何玩法想法都能在24小时内进入可测试状态。

阶段二:采购期——不造轮子

玩法方向确认后,从UE Marketplace / Fab等商城选型采购,同时从其他项目复用已有资产。中小团队不应该把资源花在已经被商城解决的问题上。 问题不在于”找不到资产”,而在于”不同来源的资产放在一起像拼盘”。

阶段三:调优期——把拼盘变成一盘菜

这是整套策略最关键的环节。AI调优管线把”逐个手调”的脏活变成了批处理:

成熟度高、可直接批量落地:

  • 贴图精度对齐——AI超分辨率放大,法线/AO/粗糙度通道联动补充细节
  • 涂装/变体批量生成——色调变体、磨损变体、迷彩变体一键产出
  • 命名/目录规范化——AI脚本批量重命名、自动分类到标准目录
AI资产调优分组

成熟度中等、需要人工辅助:

  • 风格统一——AI批量重绘贴图统一色温/磨损/污渍风格
  • 材质标准化——AI校准PBR参数到统一标准
  • LOD自动生成、动画重定向、比例校准、碰撞体适配

阶段四:替换期

正式资产替换测试占位,美术精调后上线。

为什么这个策略比”等3D生成成熟”更好

第一,它今天就能用。 不需要等任何技术突破。

第二,它改变了开发节奏。 整条管线从”等资产→做游戏”变成”做游戏→换资产”。

第三,它降低了方向试错成本。 错误的设计方向在占位阶段就能发现,不再需要用三个月的美术产能去”赌方向”。

四阶段工作流不是一个”美术资产管理方案”——它让”等资产”这件事从开发关键路径上消失了。


八、运行时体验:AI导演的可能性与局限

除了开发管线的AI化,搜打撤游戏在运行时也有AI介入的潜力。但需要先说清楚:这部分目前仍处于早期探索阶段,和前面讨论的已落地能力不同,这里更多是方向性的思考。

为什么这个品类最适合尝试AI导演

PvE搜打撤的几个特征让它成为AI导演系统的理想试验田:纯PvE没有公平性约束、小队数据量极低、单局制不需要跨局记忆、搜打撤三段式结构天然适合分阶段调度。

为什么不能让LLM直接控制敌人

这是理解AI导演架构的关键问题。

LLM天然不适合的运行时场景:

  • Combat Tick——伤害计算、碰撞检测、状态更新每帧执行,LLM推理延迟(几百毫秒到几秒)完全无法满足
  • NavMesh实时控制——寻路、避障、队形保持需要毫秒级响应
  • 高频决策——”这一帧该开枪还是换弹夹”对LLM来说太高频了
  • 确定性要求——同样的输入,行为树永远输出同样的结果;LLM不保证,这在多人同步场景中是致命的

四个硬约束决定了LLM必须在帧级逻辑之上运行:latency、token cost、determinism、debuggability。

LLM真正擅长的运行时场景:

  • 波次编排(Wave Orchestration)——”接下来30秒该刷什么怪、从哪个方向来”
  • 遭遇节奏调控(Encounter Pacing)——”该加压还是给喘息空间”
  • 导演编排(Director Orchestration)——”触发伏击”还是”投放友军求救信号”
  • 内容变异(Content Mutation)——每局生成不同的任务/POI/敌人配置
  • 事件注入(Event Injection)——在合适的时机触发动态事件

关键判断: LLM不适合Combat Tick,但非常适合Encounter Orchestration。LLM做”想什么”,行为树做”怎么做”。

AI导演架构

运行时AI导演架构

诚实地说,还有哪些没解决

  • 输出稳定性:LLM可能生成不合理的配置组合,需要大量约束规则和输出校验
  • 体验质量控制:”数值平衡”和”好玩”是两件事
  • 调试困难:AI导演的糟糕决策比规则系统更难回溯和修复
  • 成本:每局LLM推理的服务端成本需要认真核算

当前更现实的做法是:先让LLM负责局前配置生成(一次性推理,成本可控),局中调度仍用传统规则系统+加权随机。验证了质量和稳定性之后,再逐步扩大LLM的决策范围。不要一上来就赌全盘AI导演。


九、总结:AI改变的是什么,没改变的是什么

AI改变了什么

程序全线可以AI化。 8条管线的程序侧都已经可以规模化落地。直接减少60-70%的基础代码工作量——不是替代程序员,而是让程序员从重复性工程工作中释放出来,集中精力在架构设计和核心系统上。

策划的数值和配置工作被大幅加速。 效率提升5-10倍。策划的核心价值从”填表”回到了”做判断”。

美术不再卡住开发节奏。 通过”AI占位→商城复用→AI调优”的三段式策略,开发团队可以在完全没有美术资源的情况下验证完所有玩法。

验证成本降了一个数量级。 过去是”赌方向、做资产、验证、发现不对、返工”;现在是”验证、确认方向、做资产、上线”。

AI没改变什么

3D美术资产仍然依赖人工。 这个短期内不会变。但正如前面分析的,这并不妨碍AI发挥巨大价值——关键是策略选对。

需要”感觉”和”判断”的工作仍然是人的。 关卡的空间感、打击感的调优、音效的层次设计、美术的风格把控——AI可以辅助但无法替代。

游戏设计本身的创意能力没有变。 AI擅长”给定框架后填充内容”,而非”发明一个让人上瘾的核心循环”。搜打撤好不好玩,不取决于配置表生成有多快,取决于核心循环设计的质量。

AI成熟度矩阵

最大的提效杠杆

  1. 程序侧全面AI化 → 最大、最确定、今天就能落地的杠杆
  2. 策划数值/配置自动化 → 释放策划的创意带宽
  3. 美术资产复用+AI调优 → 绕过3D生成瓶颈,改变开发节奏
  4. MCP工具化 → 为运行时AI导演建立技术基础

过去二十年,游戏工业越来越像”内容制造业”。团队越来越大,管线越来越重,验证越来越慢。一个玩法想法从提出到被验证,可能需要等待几个月的资产生产。

AI Native游戏,可能是第一次让游戏开发重新回到“小团队快速实验”的时代。

AI Native游戏真正改变的,从来不是”谁被替代”。而是游戏工业第一次开始从“资产生产能力竞争”转向“体验验证速度竞争”

未来最有竞争力的团队,不一定是拥有最多资产的团队。而是能最快验证”什么好玩”的团队。

AI Native最大的意义,可能不是让游戏”自动生成”,而是让团队尽可能更早发现”什么不好玩”。

AI没有让做游戏变得”容易”,但它让一个小团队做出过去需要大团队才能做出的东西变成了可能。这才是AI Native游戏开发的真正含义。