UE5零赘余开发：开放世界格斗游戏如何做减法

1. 从“零赘余”说起为什么一个开放世界格斗游戏敢做减法第一次看到《Samson》的实机演示我脑子里蹦出来的不是“画面真炸”而是“这游戏怎么这么干净”。主角在废弃工业区里跑动、攀爬、出拳画面里没有满屏的UI图标没有密密麻麻的收集品标记甚至连常见的技能冷却条都找不到。后来看到Liquid Swords团队在采访里反复提到一个词——“零赘余”我才意识到这不是美术风格的选择而是一整套开发哲学在驱动。“零赘余”这个词听起来很虚但落到游戏开发里它其实是一道非常具体的算术题你团队有多少人、多少时间、多少预算然后你决定把这些资源砸在哪些系统上同时砍掉哪些看起来“别人都有”的东西。Liquid Swords的答案很明确——他们要做的是一个以近战格斗为核心驱动力的开放世界游戏所有不直接服务于“打斗手感”和“城市探索沉浸感”的系统要么不做要么做到最简。这个选择在当下的3A语境里其实挺冒险的。你去翻翻近几年的开放世界大作哪个不是塞了潜行、射击、驾驶、建造、解谜、卡牌小游戏玩家已经被训练成“内容越多越好”的思维模式媒体评测也习惯用“内容量”来衡量一款游戏是否值回票价。但Liquid Swords反其道而行他们公开说“我们不想让玩家在菜单里花时间不想让玩家为了升级去刷无关的支线不想让战斗被数值系统稀释。”那他们靠什么撑起一个开放世界答案是UE5。更准确地说是UE5提供的那套“高保真底层能力”让他们可以用更少的中间层代码和美术妥协去实现一个“看起来很大、玩起来很密”的城市空间。这里的关键逻辑是当引擎帮你把渲染、物理、动画、音频的底层管线都做得很扎实时你就不需要为了“让画面能跑起来”而额外堆叠优化层、LOD策略、材质简化方案。省下来的精力全部投到格斗系统的帧数据调优和城市关卡的密度设计上。我之所以对这个案例感兴趣是因为它回答了一个很多独立团队和中型团队都在纠结的问题UE5到底适不适合做“小而精”的项目很多人觉得UE5是给3A大厂准备的资源消耗大、学习曲线陡、蓝图一多就卡。但Liquid Swords的实践给出了另一个视角——如果你把UE5当成一个“高完成度的底层工具箱”而不是一个“什么都要帮你做完的万能框架”它反而能帮你省掉大量重复造轮子的时间。接下来的内容我会从几个层面拆解这个案例先讲“零赘余”在技术选型上的具体含义再深入UE5的哪些特性真正支撑了这种减法策略然后聊格斗系统的帧数据与动画蓝图怎么配合接着谈开放世界城市在UE5里的关卡流送与性能取舍最后分享一些从社区和实操中总结的避坑经验。如果你正在用UE5做项目或者正在犹豫要不要转UE5这些内容应该能帮你少走一些弯路。2. “零赘余”不是口号它在技术选型上到底意味着什么2.1 减法策略的第一刀砍掉“通用系统”只留“核心循环”很多团队在做项目规划时习惯先列一张“功能清单”开放世界要有天气系统、要有昼夜循环、要有NPC日程、要有阵营声望、要有装备词条、要有技能树……这张清单越列越长最后发现光是实现这些“标配功能”就已经把工期吃掉了大半而真正决定游戏好不好玩的核心战斗反而只分到了很少的调优时间。Liquid Swords的做法是反过来的。他们先定义《Samson》的核心循环玩家在城市里移动→发现可交互的敌人或环境→进入近战格斗→通过战斗获得资源或推进剧情→继续移动。这个循环里最关键的三个节点是“移动手感”“战斗手感”“城市空间的信息密度”。其他所有系统如果不在这个循环里就砍掉或者极度简化。比如天气系统他们不是不做而是只做“对战斗有影响”的部分——雨天路面湿滑会影响脚步抓地力大风会影响投掷物的轨迹但不会去做一套完整的“云层模拟季节变化生态反应”的复杂系统。再比如NPC日程他们只给关键NPC做了简单的时段位移普通路人就是固定路点循环因为玩家在格斗游戏里根本不会去观察路人几点回家。这种减法在UE5里有一个很实际的收益你不需要为了支撑那些“通用系统”去写大量的蓝图通信、数据表管理和状态同步逻辑。UE5的蓝图系统虽然强大但每多一个系统就多一层事件分发和依赖关系项目后期调试时一个简单的“开门”动作可能要穿过五六个蓝图接口才能找到源头。砍掉非核心系统等于砍掉了这些潜在的调试噩梦。2.2 为什么是UE5而不是自研引擎或Unity这个问题Liquid Swords在多个场合被问过。他们的回答可以归纳为三点动画管线、材质系统、以及“不用自己写渲染器”。先说动画。近战格斗游戏对动画的要求极其苛刻——每一拳的起手帧、命中帧、收招帧都要精确到毫秒级而且不同招式之间的衔接要能无缝混合。UE5的动画蓝图和状态机虽然学习成本不低但它提供的“动画层混合”“骨骼控制节点”“动画通知”这套机制是目前商业引擎里最成熟的。你可以在动画蓝图里直接调用游戏逻辑的变量比如“当前是否处于硬直”“连招计数是多少”然后根据这些变量实时切换动画片段。这种“动画驱动逻辑、逻辑反馈动画”的双向绑定在自研引擎里往往要写大量底层代码才能实现。再说材质。UE5的材质编辑器是节点式的但它的节点库非常深从简单的PBR到复杂的次表面散射、视差遮蔽、世界位置偏移都有现成的节点可以用。对于《Samson》这种需要大量工业废墟、金属锈蚀、潮湿沥青的场景材质的表现力直接决定了沉浸感。Liquid Swords的美术团队在采访里提到他们用UE5的材质层系统Material Layers快速搭建了一套“基础材质磨损层污渍层”的模块化方案同一个基础金属材质通过叠加不同的层就能生成几十种变体而不需要每个都从头做。最后是渲染器。自研渲染器听起来很酷但现实是你花两年写出来的渲染器可能还不如UE5默认的Lumen和Nanite效果好。Liquid Swords明确说他们不想把时间花在“让阴影不闪烁”“让反射不破碎”这种底层问题上他们要用UE5现成的全局光照和几何体流送方案把精力留给格斗系统的帧数据调优。2.3 “零赘余”在项目管理上的体现小团队如何避免被工具反噬UE5有一个被很多人吐槽的点蓝图一多项目就卡资产一多打开就慢。这其实是“工具反噬”的典型症状——你用了强大的工具但你没有建立对应的管理规范结果工具的强大变成了负担。Liquid Swords的做法是建立了一套“资产准入规则”任何进入主分支的资产必须满足三个条件——命名规范、引用层级不超过三层、以及有明确的Owner。命名规范不用多说关键是“引用层级不超过三层”。比如一个角色蓝图它可以直接引用动画蓝图和材质但动画蓝图不能再引用另一个蓝图去获取数据数据必须通过接口或数据资产传递。这样做的目的是防止“蓝图蜘蛛网”——你改一个变量整个项目几十个蓝图都报错。另一个经验是“蓝图与C的边界”。UE5允许你用C写底层逻辑用蓝图做上层拼接。Liquid Swords的策略是所有涉及性能敏感的计算比如格斗的伤害判定、帧数据插值全部用C写蓝图只负责“调用”和“表现”。这样既保证了运行效率又保留了蓝图快速迭代的优势。很多团队反过来做用蓝图写核心逻辑结果后期优化时发现根本无从下手。提示如果你正在用UE5做项目建议在项目初期就定好“什么用C、什么用蓝图”的规则。一个简单的判断标准是如果这段逻辑每帧都要跑或者涉及大量数学计算就用C如果只是事件响应和UI更新就用蓝图。3. UE5的哪些底层能力真正支撑了“零赘余”开发3.1 Nanite与Lumen让美术不用为性能做“预减法”传统游戏开发里美术和程序之间有一场永恒的拉锯战。美术想做高模程序说面数超标美术想做复杂光照程序说烘焙时间不够。结果往往是美术被迫做“预减法”——把模型减面、把光照烘焙成贴图、把反射做成假CubeMap。这些“预减法”在最终画面里会留下痕迹模型边缘有锯齿、光照过渡不自然、反射和实际场景对不上。UE5的Nanite和Lumen改变的就是这个流程。Nanite允许你直接导入影视级高模引擎会自动做几何体流送和LOD你不需要手动减面。Lumen允许你使用动态全局光照不需要烘焙光照贴图光源移动时阴影和反射会实时更新。对于《Samson》这种需要大量工业废墟场景的游戏这意味着美术可以专注于“这个场景看起来对不对”而不是“这个场景能不能跑起来”。Liquid Swords在采访里提到一个细节他们有一个场景是一栋半坍塌的工厂内部有大量裸露的钢筋和破碎的混凝土。如果用传统流程这个场景的光照烘焙至少需要几个小时而且每次调整钢筋位置都要重新烘焙。用Lumen之后他们可以直接在编辑器里拖动钢筋光照实时更新调整效率提升了不止一个量级。当然Nanite和Lumen不是没有代价。Nanite对显存和IO的要求很高Lumen在低端硬件上帧率波动明显。Liquid Swords的应对策略是在PC端提供“Nanite质量”和“Lumen质量”的选项让玩家根据自己的硬件调整在主机端则锁定一套经过验证的配置保证帧率稳定。这种“把选择权交给玩家但保证默认体验”的做法比强行统一画质要务实得多。3.2 世界分区与关卡流送开放世界不一定要“无缝”很多人一提到开放世界就想到“无缝大地图”。但无缝意味着所有内容都要常驻内存对硬件压力极大。UE5的世界分区World Partition系统提供了一种折中方案你可以把地图切成网格每个网格是一个独立的关卡单元引擎根据玩家位置动态加载和卸载。《Samson》的城市不是那种“从山顶跑到海边”的连续自然景观而是一个被划分为多个区域的工业城市。Liquid Swords利用世界分区把城市分成十几个区块每个区块有自己的加载边界。玩家在区块之间移动时引擎会在后台预加载下一个区块同时卸载已经离开的区块。这样既保证了探索的连续性又控制了内存占用。这里有一个实操细节值得注意世界分区的网格大小需要根据游戏玩法来定。如果网格太小加载卸载太频繁会导致帧率波动如果网格太大内存占用又下不来。Liquid Swords的做法是让网格大小略大于玩家“一次战斗可能移动的范围”这样在战斗过程中不会触发加载战斗结束后再自然过渡到下一个区块。3.3 动画通知与运动扭曲格斗游戏的帧数据怎么落地格斗游戏的核心是“帧数据”。每一招的起手、命中、收招都有固定的帧数玩家通过输入时机来决定是否连招、是否取消。这些帧数据在UE5里怎么实现Liquid Swords用的是“动画通知运动扭曲”的组合。动画通知AnimNotify是UE5动画系统里的一个机制你可以在动画片段的特定时间点插入一个通知当动画播放到那个时间点时引擎会触发一个事件。比如在“出拳”动画的第12帧插入一个“命中判定”通知当动画播到第12帧时引擎就会调用你指定的函数去检测是否击中了敌人。运动扭曲MotionWarping则是用来解决“动画和实际位移不匹配”的问题。比如你做了一个“冲刺拳”的动画动画里角色向前冲了3米但实际游戏中敌人可能在2.5米外。运动扭曲可以在动画播放时动态调整角色的根骨骼位移让动画的视觉表现和实际碰撞判定对齐。这对于格斗游戏至关重要因为玩家对“打没打中”的感知非常敏感如果动画显示打中了但判定没中玩家会觉得“手感飘”。Liquid Swords在采访里提到他们花了大量时间在“动画通知的时序调优”上。一个简单的直拳从起手到命中他们调整了十几版帧数据才找到“看起来快、打起来准、连起来顺”的平衡点。这种调优没有捷径只能靠反复测试和玩家反馈。4. 格斗系统与城市探索的耦合UE5里怎么让“打”和“跑”不割裂4.1 移动即战斗把跑酷动作融入战斗状态机很多开放世界游戏的毛病是“移动”和“战斗”是两套系统。你跑动的时候是一个状态机进入战斗后切换到另一个状态机切换的瞬间会有明显的“卡顿感”或“模式感”。《Samson》想做的是一种“移动即战斗”的体验——你翻越栏杆的动作可以直接接一记飞踢你在墙上蹬踏的瞬间可以触发空中连击。这在UE5里实现起来核心是“状态机共享”。Liquid Swords没有把移动和战斗分成两个独立的动画蓝图而是用一个统一的“角色状态机”里面定义了“地面移动”“空中移动”“战斗姿态”“受击姿态”等状态状态之间的转换条件由游戏逻辑动态判断。比如当玩家在跑动中按下攻击键状态机不会先切换到“战斗姿态”再播放攻击动画而是直接从“跑动”状态混合到“冲刺攻击”动画同时保留跑动的速度向量。这种做法的技术难点在于“动画混合的权重控制”。UE5的动画蓝图提供了“混合节点”Blend Node你可以根据速度、方向、输入状态等变量动态调整两个动画片段的混合权重。Liquid Swords的做法是在跑动和攻击之间设置一个0.2秒的混合窗口前0.1秒跑动动画权重从1降到0.3攻击动画权重从0升到0.7后0.1秒跑动权重降到0攻击权重升到1。这样过渡看起来既不会太突兀也不会太拖沓。4.2 城市空间作为战斗舞台关卡设计如何服务于格斗《Samson》的城市不是背景板而是战斗的一部分。Liquid Swords的关卡设计师在采访里说他们设计每个区域时会先问三个问题这个区域有多少种进入方式有多少个可以利用的环境物体有多少个可以迫使敌人改变位置的地形比如一个废弃的停车场设计师会放置几辆报废汽车作为掩体但汽车可以被重击打飞改变战场格局会设计一个二层平台玩家可以从上面跳下发动偷袭但敌人也可以把玩家扔下去会留一条狭窄的通道迫使敌人只能一个一个上来但玩家也可以选择把敌人引到开阔区域一打多。这些设计在UE5里通过“关卡蓝图”和“物理约束”来实现汽车的重击飞散用的是Chaos物理系统的破坏效果平台的边缘检测用的是碰撞盒和射线检测。这里有一个经验格斗游戏的关卡设计最怕的是“平地一片”。没有高低差、没有掩体、没有可交互物体战斗就会变成纯粹的数值对拼。Liquid Swords的做法是在每个战斗区域至少放置三种“战术元素”一个高低差、一个可破坏物体、一个可绕行路径。这三种元素不需要很复杂但必须存在让玩家有“选择怎么打”的空间。4.3 敌人AI的“零赘余”不做全知全能只做“合理反应”很多游戏的敌人AI被玩家吐槽“太蠢”或“太假”。太蠢是因为AI反应迟钝太假是因为AI全知全能——你躲在墙后它也知道你在哪你换个弹它立刻冲过来。《Samson》的AI设计走的是“有限感知”路线敌人有视野锥、有听觉范围、有记忆时间。你躲在墙后它不会立刻知道你在哪但如果你发出声音比如打碎玻璃它会朝声音方向搜索。在UE5里实现这套AI用的是“行为树感知系统”。行为树定义敌人的行为逻辑巡逻、搜索、攻击、撤退感知系统负责收集环境信息视觉、听觉、伤害来源。Liquid Swords的调优重点是“感知的衰减曲线”——敌人看到你之后记忆会保留多久如果它跟丢了你会搜索多大范围这些参数直接决定了AI是“聪明”还是“作弊”。他们的经验是感知衰减时间不要设得太短否则敌人会显得“金鱼记忆”也不要设得太长否则玩家会觉得“甩不掉”。他们最终用的参数是视觉记忆8秒听觉记忆5秒搜索范围15米。这个参数组合在测试中得到了比较好的反馈——敌人会追你但不会追到天涯海角你躲起来它会在附近找一会儿然后放弃。5. 实操中的坑与经验从UE5项目里总结的避坑清单5.1 蓝图性能陷阱什么时候该把逻辑挪到CUE5的蓝图系统很方便但它的性能开销比C大得多。一个每帧执行的蓝图函数如果里面有复杂的数学计算或循环很快就会成为性能瓶颈。Liquid Swords的经验是任何在Tick事件里执行的逻辑只要超过10个节点就应该考虑用C重写。具体来说以下几类逻辑建议用C实现格斗的伤害计算和帧数据插值敌人AI的感知检测和路径计算大量物体的物理模拟和碰撞检测网络同步相关的状态复制而以下几类逻辑可以放心用蓝图UI事件响应和界面更新简单的触发器逻辑比如开门、拾取动画通知的接收和转发调试用的可视化工具注意蓝图和C的边界不是绝对的。你可以先用蓝图快速验证玩法等玩法确定后再把性能敏感的部分迁移到C。但迁移的时机要早不要等到项目后期才做否则会牵一发而动全身。5.2 资产命名与引用管理防止“蓝图蜘蛛网”UE5项目做大了之后最头疼的问题之一是“找不到东西”。一个材质叫“M_Metal_01”另一个叫“M_Metal_New”还有一个叫“M_Metal_Final”你根本不知道哪个是当前在用的。Liquid Swords的解决方案是强制命名规范所有资产必须按照“类型_用途_变体_版本”的格式命名比如“M_Env_Metal_Rusty_v2”。更重要的是引用管理。UE5的“引用查看器”Reference Viewer可以让你看到一个资产被哪些其他资产引用。Liquid Swords的规则是任何资产如果被超过20个其他资产引用就必须做一次“引用审查”确认这些引用都是必要的。如果发现某个资产被大量引用但实际很少用到就把它拆分成更小的模块或者用数据资产Data Asset来替代硬引用。5.3 世界分区的加载卡顿怎么让流送更平滑世界分区虽然好用但如果配置不当玩家在区块边界移动时会出现明显的卡顿。Liquid Swords踩过的坑是一开始把网格设得太小50米结果玩家跑几步就触发一次加载帧率波动很大。后来他们把网格调到150米同时在区块边界设置了“预加载区域”——当玩家距离边界还有30米时引擎就开始加载下一个区块这样等玩家真正跨过边界时内容已经加载好了。另一个经验是“异步加载的优先级”。UE5允许你给不同的资产设置加载优先级Liquid Swords把“地形”和“建筑”设为高优先级“装饰物”和“粒子效果”设为低优先级。这样在加载时玩家先看到地形和建筑装饰物稍后出现视觉上不会觉得“世界没加载出来”。5.4 动画蓝图的调试怎么快速定位“动画不播放”的问题动画蓝图是UE5里最容易出问题的部分之一。你明明设置了状态转换条件但动画就是不播放或者动画播放了但混合权重不对角色看起来像“滑步”。Liquid Swords的调试方法是“三层排查”第一层检查状态机。在动画蓝图里打开“调试过滤器”只看当前角色的状态机。确认状态转换的条件是否满足比如“速度300”这个条件实际速度是多少如果速度是299那当然不会转换。第二层检查动画序列。确认动画序列本身有没有问题比如帧率设置、循环设置、根骨骼位移。有时候动画不播放是因为序列的“播放速率”被设成了0或者“循环”选项没勾。第三层检查混合节点。如果状态机切换了动画也播放了但看起来不对那就是混合权重的问题。在混合节点上打开“调试显示”可以看到当前两个动画的权重分别是多少。如果权重是0.5和0.5但你想让攻击动画占主导那就需要调整混合参数。这套排查方法看起来简单但在实际项目中能省下大量“瞎猜”的时间。Liquid Swords的动画师说他们团队新人入职第一周就是学这套排查流程。6. 从《Samson》反推你的UE5项目该怎么定“赘余”的边界6.1 先定“不做什么”再定“做什么”很多团队的项目文档里写满了“我们要做XX系统”“我们要实现XX功能”但很少写“我们不做XX”。Liquid Swords的做法是在项目启动阶段就列一张“不做清单”不做多人模式、不做载具驾驶、不做建造系统、不做分支剧情。这张清单不是拍脑袋定的而是根据团队规模、工期、核心玩法推导出来的。对于中小团队我建议在“不做清单”里至少包含以下几项不做需要大量网络同步的多人玩法、不做需要长期运营的赛季系统、不做需要大量文案的分支叙事。这些系统要么技术复杂度高要么内容消耗大很容易把团队拖垮。6.2 用“垂直切片”验证核心循环而不是铺量UE5项目最容易犯的错误是“铺量”——先做一张大地图再往里填内容。结果地图做完了发现核心玩法不好玩但已经没时间改了。Liquid Swords的做法是先做一个“垂直切片”一个小区域、一个完整的战斗循环、一套完整的动画和UI。这个切片可能只有10分钟的内容但它包含了游戏的所有核心系统。垂直切片的好处是你可以在早期就验证“这个游戏好不好玩”。如果不好玩改起来成本低如果好玩再把这个切片的模式复制到其他区域。Liquid Swords在采访里说他们的垂直切片做了整整六个月期间反复调整格斗手感和城市密度直到团队内部都觉得“打起来很爽”才进入量产阶段。6.3 性能预算要按“最坏情况”来定而不是“平均情况”UE5的Nanite和Lumen很强大但它们对硬件的要求也很高。Liquid Swords的性能预算策略是按“最坏情况”来定而不是“平均情况”。比如一个战斗场景平均可能有5个敌人但最坏情况可能有15个敌人同时出现。如果你的性能预算只考虑了5个敌人的情况那15个敌人时帧率就会崩。他们的做法是在关卡设计阶段就标记出“高密度战斗区域”然后在这些区域里做压力测试。测试方法是用调试命令生成大量敌人观察帧率变化找到帧率开始下降的临界点然后把这个临界点的敌人数量的80%作为设计上限。这样留出20%的余量应对玩家引怪或意外情况。6.4 社区反馈要“早听、多听、但选择性听”Liquid Swords在开发过程中定期发布开发日志收集社区反馈。他们的经验是反馈要早听因为早期改起来容易要多听因为不同玩家的视角不同但要选择性听因为玩家说的“我想要XX”往往不是他们真正需要的。比如有玩家说“希望加入装备系统”但如果你真的加了装备系统可能会稀释格斗的核心体验。Liquid Swords的做法是把玩家的“需求”翻译成“问题”玩家想要装备系统背后的需求可能是“希望有更多成长感”。那他们就用“技能解锁”和“招式升级”来满足这个需求而不是做一套完整的装备掉落和词条系统。这个思路其实和“零赘余”是一脉相承的——不是玩家要什么就给什么而是理解玩家真正想要什么然后用最精简的方式去满足它。7. 一些零散但实用的UE5操作技巧7.1 用“数据资产”管理全局参数而不是散落在蓝图里格斗游戏有大量可调参数每一招的伤害、硬直时间、击退距离、连招窗口。如果这些参数散落在各个蓝图里调优时会非常痛苦。Liquid Swords的做法是创建一个“数据资产”Data Asset把所有格斗参数集中在一个表格里。调优时只需要改表格所有引用这个数据资产的蓝图会自动更新。在UE5里创建数据资产的步骤是右键→杂项→数据资产→选择你的数据类。数据类可以用C定义也可以用蓝图定义。定义好字段后在编辑器里创建一个实例填入参数值。然后在蓝图里通过“获取数据资产”节点来读取参数。7.2 用“动画蒙太奇”处理一次性动作而不是塞进状态机状态机适合处理循环性的状态跑动、待机、战斗姿态但一次性动作比如处决、翻越、拾取如果也塞进状态机会让状态机变得非常臃肿。UE5的“动画蒙太奇”AnimMontage就是为这种场景设计的你可以把一段动画做成蒙太奇然后在蓝图里用“播放蒙太奇”节点来触发播放完毕后自动回到之前的状态。Liquid Swords的用法是所有长度超过1秒、不需要循环的一次性动作都用蒙太奇。蒙太奇还可以设置“播放速率”和“起始位置”方便做变速和倒放效果。7.3 用“控制台命令”快速测试性能而不是每次都打包UE5提供了一系列控制台命令可以在编辑器里直接测试性能。常用的有stat fps显示帧率stat unit显示游戏线程、渲染线程、GPU的耗时stat game显示游戏逻辑的耗时r.ScreenPercentage 50降低渲染分辨率测试GPU瓶颈t.MaxFPS 30锁定帧率测试稳定性Liquid Swords的团队在调优时会先用这些命令定位瓶颈在CPU还是GPU然后再针对性地优化。比如stat unit显示游戏线程耗时很高那就去检查蓝图逻辑和AI计算如果GPU耗时高那就去检查材质复杂度和光照质量。7.4 用“关卡实例”复用场景模块而不是复制粘贴UE5的“关卡实例”Level Instance允许你把一个关卡当作一个资产在另一个关卡里多次引用。这对于《Samson》这种需要大量重复工业场景的游戏非常有用。比如你做了一个“废弃仓库”的关卡实例可以在城市的不同位置放置多个实例每个实例可以单独调整位置和旋转但内部的资产是共享的。这样做的好处是修改仓库的设计时所有实例都会自动更新不需要一个个去改。而且关卡实例支持“流送”不会一次性加载所有实例对性能也友好。8. 最后聊几句个人体会我跟踪Liquid Swords的《Samson》开发日志有一段时间了最让我印象深刻的不是他们用了多少UE5的高级特性而是他们对自己“不做什么”的清晰认知。在游戏行业里做加法很容易做减法很难。加法让你觉得“我在进步”减法让你觉得“我在放弃”。但《Samson》的案例说明有时候放弃一些东西才能把真正重要的东西做到极致。如果你正在用UE5做项目我的建议是先别急着研究Nanite和Lumen怎么调参数先想清楚你的核心循环是什么然后围绕这个循环去决定哪些系统必须做、哪些系统可以砍。UE5是一个很强大的工具但工具越强大越需要你有清晰的判断力。否则你很容易被工具带着走最后做出一堆“技术上很厉害但玩起来很无聊”的东西。另外关于UE5的学习路径我个人的经验是先学蓝图再学C但不要停留在蓝图。蓝图能帮你快速理解引擎的逻辑但真正要做性能敏感的系统还是得回到C。Liquid Swords的团队配置里C程序员和蓝图设计师的比例大概是1:2这个比例可以参考。至于《Samson》最终能不能成功现在下结论还太早。但至少从开发思路来看他们走了一条很清醒的路。在这个“内容越多越好”的时代敢做减法的团队值得多看一眼。