项目规模暴涨10倍，这个100人团队却扛住了：花小钱办大事

文 / 游戏那点事 零、西泽步

做一款“大游戏”，通常意味着更大的团队、更长的工期和更高的预算。但如果项目规模成倍增长，团队人数和预算却不可能同步翻倍，开发者还能从哪里挤出效率？

在gamescom dev 2026的一场分享中，KING Art Games联合创始人、创意总监、《战锤40K：战争黎明4》（Warhammer 40,000: Dawn of War IV）游戏总监Jan Theysen，拆解了这家德国独立工作室过去两个项目连续跨越体量台阶的过程。

（Jan Theysen在 gamescom dev 2026现场分享《战争黎明4》的开发方法）

KING Art Games已成立26年，推出过约50款覆盖不同平台的作品。开发《钢铁收割》期间，团队从约45人增长到100多人；《钢铁收割》的体量约为此前最大项目的4倍，而《战争黎明4》又是《钢铁收割》的两倍以上。

换言之，仅用两代作品，工作室所面对的项目规模就扩大到了过去的约10倍。

（Jan Theysen，KING Art Games联合创始人、创意总监、《战争黎明4》游戏总监）

《战争黎明4》计划于2026年12月3日登陆PC。根据Jan在现场展示的数据，游戏包含4个阵营、超过110种单位与建筑、超过500种武器、能力与升级，以及4条共约70个任务的战役线，还包括4段CGI、20多段过场动画和多种游戏模式。

（《战争黎明4》在阵营、单位、能力、战役和模式上的内容规模）

但在约五年的开发周期里，项目的核心团队规模大约只有100人。Jan认为，面对这种差距，关键并不是要求每名开发者把同一份工作做快一倍，而是回答两个更现实的问题：哪些工作可以不做？必须做的工作，能不能换一种更聪明的方式完成？

真正的效率，不是让同样的工作凭空快一倍，而是少做玩家不在意的事，把时间留给真正影响体验的部分。

围绕这一点，他将《战争黎明4》的开发经验归纳为六个方面：清晰愿景与强支柱、高影响捷径、团队与所有权、利益相关方沟通、预告片驱动开发，以及工具与自动化。

（本次分享围绕六个方面展开）

以下为游戏那点事整理的分享实录，为优化阅读体验有所调整：

01

清晰愿景与强支柱

让所有人朝同一方向发力

我想先讲清晰的愿景和足够有力的项目支柱。这个概念并不新鲜：你要定义自己的游戏是什么，也要定义它不是什么。但真正重要的是，这些支柱最好在预制作阶段由团队共同形成，而不是管理层写完以后再自上而下地交给大家。

如果更多人参与了支柱的建立，他们就更容易认同这款游戏，也更愿意在几年开发周期里持续保护它。支柱确定后，我们还必须与团队、发行商和IP方达成共识，让所有人都知道我们要做什么、又明确不做什么。

（先建立同时服务玩家体验与生产需要的清晰支柱）

这件事不能只在项目开始时说一次。开发持续几年后，每个人都会在自己的工作里慢慢走向不同方向，所以我们必须一遍又一遍地重申愿景，让团队不断重新对齐。

《战争黎明4》有五个核心支柱：以初代《战争黎明》为指路星；让游戏值得玩家投入时间与金钱；还原《战锤40K》的感觉；提供足够的多样性；让战术决策的重要性高于操作执行。

（《战争黎明4》的五项项目支柱）

“以初代《战争黎明》为指路星”替我们省下了大量讨论时间。初代和二代都是好游戏，但两者差异很大。如果没有明确方向，每出现一个功能，大家都会重新争论应该更像一代、二代，还是把两者混在一起。

现在我们只需要先问：初代是怎么做的？今天有没有足够好的理由改掉它？如果没有，讨论就可以结束，把省下来的时间用于真正需要创新的部分。

当然，“还原《战锤40K》的感觉”仍然太抽象。下一步要由美术、动画、音频等不同部门把支柱拆成各自能够执行的目标、规则与工作流程。此后，所有进入游戏的内容都应该至少支持其中一个目标。

一个点子可能很好，但如果它不能让项目更接近已经达成共识的目标，它就不属于这款游戏。

这也是解决冲突的办法。创意往往像提出者自己的孩子；一个人连续几次提案都没被采用，很容易把讨论理解成对个人的否定。把问题重新表述为“这个方案是否支持项目目标”，争论就会从“谁的点子更好”变成“什么更适合这款游戏”。

（用项目目标讨论方案，让争论回到目标而非个人偏好）

同样的标准也能帮助团队摆脱沉没成本。有些功能已经投入了很多时间，却始终无法正常工作，大家会因为舍不得前期投入而继续追加资源。

此时只要再问一次：它究竟在支持哪个目标？如果答案对所有人都不明显，就应该停下来。清晰的支柱看似抽象，实际上能替项目省下非常具体的时间。

02

高影响捷径

把时间花在玩家真正能感受到的地方

第二点是“高影响捷径”。它包含两个问题：有没有成本很高、但玩家并不总是在意的功能？如果某项工作确实不能少，我们又能不能换一种生产方式？

我很喜欢用《指环王》举例。电影开头需要用强制透视、绿幕等手段，反复建立“霍比特人很矮”这件事。但观众接受设定后，后面的某些镜头即使只让演员跪下来拍，甚至不再严格处理人物比例，也几乎没有人介意。制作团队先在最需要说服观众的地方投入，随后在不影响感受的位置使用了更便宜的办法。

游戏也一样。一款RPG的前几个任务也许必须充分展示分支选择，让玩家确信世界会回应自己；但玩到30小时以后，每个支线都拥有同样数量的分支，未必还能带来同等回报。《战争黎明4》里，我们会问：每个单位真的都需要同样数量的待机动画吗？玩家高频使用的核心单位和偶尔出现的后期单位，是否应该得到完全相同的投入？

（“高影响捷径”：把资源集中到真正影响玩家体验的位置）

不要一开始就在表格里规定每个单位必须有10个待机动画。可以先做两个或五个，交给玩家测试；如果有人明确感觉重复，再继续增加。如果没人注意，就没有必要把预算花在一个无法形成体验差异的位置。

另一种办法，是向各个部门提出一个看似不可能的问题：假设必须把产量提高到原来的10倍，你会怎么做？大家都知道“增加10倍人手和10倍时间”不是可选答案，于是只能重新审视流程，寻找能够复用、自动化或省略的部分。

（以“十倍产量”倒逼团队寻找生产方法上的突破）

与《钢铁收割》相比，《战争黎明4》的关卡美术和关卡设计人员各增加了约50%，但任务产量提高了约300%。其中一个关键，是我们不再为每个任务从空白地图开始，而是先搭建更大的“战场”：在同一套生态和美术主题下制作一个大型沙盒，再把多个任务放进其中。

同一片区域在一个任务里可以是出生点和基地，在另一个任务里可以出现在流程中段，也可以只成为可玩区域之外的背景。我们会在战场本身上投入更多，但随后制作每个任务的成本会显著下降。玩家得到的是更多任务和更丰富的变化，并不会因为底层复用了同一块战场而损失体验。

捷径不是把质量普遍做低，而是先识别哪里值得“贵”，再让其余部分为这些重点让路。

03

团队与所有权

找到能带着其他人往前走的人

任何团队里都会有少数特别能推动事情的人。他们不只具备能力，也在团队中积累了信任：当他们朝一个方向走，其他人愿意跟上。我们必须主动找到这些人，为他们提供支持，也给他们足够的权限。

（培养能主动承担责任、推动结果的人）

《战争黎明4》的动画总监Thomas就是这样的例子。初代《战争黎明》对他意义很深，当他知道我们要开发第四代时，第一反应是“绝不能把它搞砸”。他既有经验，又对项目抱有强烈责任感，因此我们让他负责单位任务组——从概念到模型、动画、特效、变体和数值，把单位真正送进游戏。

他并不是因为职位描述天然覆盖所有环节才得到这项责任，而是因为我们相信他能完成，也知道其他人愿意跟随他。长期稳定的团队在这里非常有价值：你会知道谁能承受压力，谁能在问题出现时真正推动事情向前。

与此同时，项目要避免瓶颈和单点故障。不能只有一个人懂灯光，也不能只有一个人知道后端如何运转；一旦这个人生病或离开，整个环节都会停住。

我们的组织里仍然有美术、程序、设计等部门。部门适合知识共享、导师制和专业评审，例如由资深程序员帮助新人做代码审查。但真正解决跨学科问题、快速推进工作的，是任务组。

（小型任务组围绕清晰目标自主解决问题）

一个任务组通常不超过5个人，有一个明确的负责人；成员原本的职级和部门层级并不重要。管理者需要给出清晰目标并检查结果，但要给任务组很大的方法自由。它就像公司内部的一家小公司：接到具体订单后，自主决定怎样交付。

任务组可以持续几年，例如贯穿项目的单位任务组；也可以只存在几周，专门解决一个没人天然负责的跨部门问题。小团队采用短迭代，定期展示方案，通常比把问题来回转交给各部门更有效，也更能激发成员的主人翁意识。

（用每日同步、每周决策会和跨部门交流保持信息畅通）

为了让这些小组彼此同步，我们有部门和任务组的每日站会，也有处理重大问题的每周决策会。凡是无法由一两个人解决、需要多方信息的议题，都集中到决策会上，让相关方同时在场，而不是让问题逐级传话。我们还尝试过让不同负责人定期一起吃饭，在非正式环境里讨论生产问题。

真正的所有权不是把任务扔给一个人，而是给出清晰结果、足够自由、持续沟通，以及兑现责任所需的权限和支持。

04

利益相关方沟通

别让信息差制造额外工作

开发团队、发行商、外包伙伴和IP方都不想做坏游戏，也不想浪费钱，但每一方的优先级并不完全一样。最重要的是建立开放关系，理解对方为什么关心某些事，并尽量减少坏消息突然出现的情况。

（与发行商、合作伙伴和IP方建立开放、透明的关系）

沟通必须透明。要分享进展、庆祝成果，也要在问题出现时正面说明：问题是什么，我们准备怎样解决，预计需要多久。如果团队暗中处理了几周，下一次里程碑交付时，发行商只会看到“这段时间似乎什么都没发生”；如果对方从一开始就知道问题和解决计划，修复本身就会成为可见的进展。

对发行商最好保留一个清晰的对接窗口，避免双方很多人彼此交叉沟通，最后在组织里形成多个版本的故事。

我们还会每年举行三到四次内部Show&Tell，让所有部门和任务组展示阶段成果。大项目里，一名UI程序员可能完全不知道过场动画已经做到什么程度；当大家看到其他团队真正做出了什么，会重新获得动力，也会再次理解项目接下来要走的方向。

（团队每年举行三至四次内部Show&Tell）

如果这场分享只能带走一个具体做法，我会推荐重新设计里程碑汇报。过去的汇报往往是一张合同式表格：哪些内容已交付、哪些有条件通过，再附上一个构建版本。它能完成手续，却很难让人真正理解或喜欢这个项目。

《钢铁收割》做过众筹，我们当时会制作面向支持者的更新视频：展示新美术、新动画、程序成果和仍处于灰盒阶段的功能。后来我们把类似方法用于合作方汇报，用十来页内容和几段短视频说明新进展、挑战与机会，并让展示足够短、足够有趣。

（用短视频向合作方同步里程碑、新进展与挑战）

结果是，发行商公司里的更多人愿意观看，也真正知道游戏发生了什么。他们会对某个功能产生期待，项目在组织内部也更容易获得关注。很多返工并不是能力不足，而是双方曾经假设了不同的东西；正确沟通本身就能消除这部分额外成本。

与其等到里程碑时证明“我们交付了”，不如持续让合作方看见“项目正在怎样变好”。

05

预告片驱动开发

先找到能让人“感受到游戏”的核心

所谓“预告片驱动开发”，不是让营销决定设计，而是尽早想清楚：什么东西真正能把这款游戏卖给团队、合作伙伴和玩家？你不可能同时完成所有内容，但可以先把优先级排对。

（“预告片驱动开发”：尽早找到真正能让人感受到游戏价值的内容）

我们开发《钢铁收割》时，知道它是架空历史背景、拥有第一次世界大战风格的机甲，也希望玩法接近《英雄连》。这些内容写在设计文档里，但直到众筹预告片做出来，团队才真正“感觉”到游戏是什么。

预制作阶段，我们规划的是整款游戏，真正执行的内容却只围绕预告片中的几个镜头：一台机甲怎样走过场景、怎样摧毁物体、重量感和破坏效果怎样成立。所有人都集中在少数必须做对的事情上。当镜头被剪进预告片，大家不需要再读120页设计文档，也能从情绪上理解这款游戏。

这就是情感钩子的价值。核心体验成立以后，每一个新功能和新资产都可以接受同一个问题：它会让这个核心变得更好吗？我们并不需要单纯“更多”，也不需要为了显得不同而做横向变化，只需要真正让游戏更好的内容。

（基础确定后，避免只做横向变化；尽早并持续试玩）

这能抑制功能蔓延和不必要的绕路。与此同时，要尽早并持续试玩自己的游戏。做了26年游戏以后，我仍然会在看见一个人实际操作时发现，自己原以为玩家会理解、会喜欢的东西，完全不是那么回事。哪怕只有一个人试玩，坐在他身后观察，也可能让你重新判断什么才真正重要。

当玩家能够先“感觉到”游戏，团队才有一个足够具体的核心，用来判断此后的每一次增加和改变。

06

工具与自动化

让系统替团队承担重复验证

最后是工具与自动化。我们使用工具、自动化流程和自动测试，扩大产能并管理大项目不断增长的复杂度。

（《战争黎明IV》没有使用生成式AI，但大量依靠工具、自动化和自动测试扩展产能）

一条约30小时、包含约70个任务的战役，不可能全部依靠人工反复跑完。我们会教机器人按任务目标行动：占领三个点、摧毁基地，或者按照不同顺序完成多条路径。它不能判断任务是否有趣、节奏是否正确，但只要最终走到了胜利界面，就能证明这一条逻辑路径至少没有被改坏。

平衡测试也是如此。单位、武器、附件和阵营组合有数以万计的排列，人工无法覆盖。让AI对战AI连续进行大量比赛，就能发现特定模式下某个阵营对另一个阵营是否出现明显异常。每天构建完成后，系统自动运行测试，并把失败报告交给相关负责人。

复盘这个项目，我们认为下一次应该更早做自动化。与其功能和任务都完成后，再艰难地为它们补测试，不如在开发功能的同时建立验证。此时设计者最清楚哪些分支可能出错，也最适合告诉机器人应该怎样运行。

另一个需要增加的投入是评审和带教。负责人和资深成员必须有时间训练新人。如果新人独自做几个月，资深成员随后又用几个月返工，节省下来的带教时间只是被推迟成了更昂贵的修复成本。

（复盘后的改进方向：更早自动化，并增加评审与带教）

归根结底，我们总结出的六个方法都在回答同一个问题：怎样减少不会改善游戏的工作，把有限的人力和预算放到玩家真正能看见、能感受到的地方。

（六项方法的总结）

如果一项内容不能让游戏变得更好，也不能支持已经达成共识的目标，那么无论它本身多么出色，都不应该留在项目里。

07

现场问答

问：你提到“教机器人玩任务”。自动化测试具体能验证什么，又不能验证什么？

Jan：它不能告诉我们任务是否有趣、节奏是否正确。它能验证的是逻辑有没有正常工作。任务本身已经有明确目标，例如占领三个据点后摧毁基地，我们只需要让AI尽可能完成这些目标。

当AI最终看见胜利界面，我们就知道它走过的这条路径是成立的。如果一个任务允许以不同顺序摧毁多个基地，我们会让它覆盖不同排列，确认每条分支都能正常结束。这种机器人并不“聪明”，但已经足以持续发现逻辑回归。

问：你所说的“支柱”和“目标”有什么区别？

Jan：支柱是项目整体想达到的状态，例如“让游戏看起来、玩起来都像《战锤40K》”。问题在于，这句话涉及美术、动画、音频等许多部门，仍然无法直接执行。

因此，每个部门都要继续回答：我们能做什么来支持这根支柱？美术部门会定义应该采用怎样的画面语言、哪些技术适合或不适合；动画和音频也会形成自己的规则。我们把这些更具体、能落实到工作里的内容称为目标。它不是排期或产量指标，而是各部门实现项目支柱的方式。

问：一个对IP极其投入、又很能推动事情的人，会不会反而把质量标准推得过高，带来失控的范围？

Jan：这种情况当然会发生，但某种程度上，我们也希望它发生。你仍然要把他带回预算、里程碑和可实现性的现实，不能让一个人自由奔跑半年后再看结果；关键是持续沟通，同时保留他提出更好方案的空间。

我们最初只计划继承初代的“同步处决”（Sync Kills）：单位死亡时播放一段更完整的处决动画。Thomas 后来提出，能不能把它扩展成“同步战斗”（Sync Combat），不只处理死亡瞬间，而是让整段交战产生更丰富的互动，例如欧克跳上无畏机甲。

这个想法不在原计划里，也没有预先编入预算，但它足够出色，于是团队一起寻找在现有约束下实现它的方法。

如果他没有获得信任和支持，可能根本不会提出这种超出原职责范围的建议。这正是授权的价值：不是取消边界，而是让真正关心结果的人有机会把项目推到更高的位置。

问：为什么QA需要大量外部团队？

Jan：我们也有内部QA，但规模较小，主要负责快速检查，并与外部测试团队协作。QA的需求波动很大：某个阶段可能只需要5个人，另一个阶段可能需要30个人同时玩游戏。为了峰值需求永久扩充内部团队并不高效，外部合作能让我们在需要时迅速扩大规模。

美术生产也采用类似方式：关键方向和一部分单位由内部完成，当内容需要批量扩张时，再与能够稳定投入足够人手的外部团队合作。这里解决的主要是规模弹性，而不是把质量责任完全交出去。

问：对还没有做过大型项目的小团队来说，与发行商等利益相关方沟通有什么建议？

Jan：前面的方法完全适用。发行商同样想做一款好游戏，也不希望钱和时间花在最终无法呈现在画面里的东西上。既然他们选择与新人合作，就知道你还没有经历过很多类似项目。

与其掩盖问题，不如提出正确的问题，并把困难开放、诚实地讲出来。如果你从不谈问题，对方反而会在想象中把问题放得更大。让他们持续参与，给他们看有吸引力的幕后内容，让他们真正理解和期待这款游戏。这样，当问题出现时，他们会知道你没有误导他们，也知道游戏开发本来就会遇到意外。

问：《战锤40K》拥有庞大的阵营和单位体系，团队怎样决定哪些内容进入游戏？

Jan：如果要做初代《战争黎明》的现代诠释，星际战士和欧克蛮人是必不可少的。我们也希望加入太空死灵；第四个位置则讨论了很久，因为可选阵营太多。最后我们想，能不能加入一个从未在《战争黎明》中成为可玩阵营、即使老玩家也会觉得新鲜的选择，于是确定了机械教。

具体到单位阵容，就要回到玩法角色和生产约束。机械教可选择的单位相对集中，我们能覆盖其中较大一部分；星际战士和欧克蛮人的单位数量极多，不可能全部加入，只能根据游戏需要的战术角色选择最合适的组合。

问：团队更看重老玩家，还是希望把新玩家带进RTS和《战锤40K》？

Jan：很多人告诉我，初代《战争黎明》正是他们进入《战锤40K》的第一款游戏，所以我们一直希望新玩家也能顺利开始。游戏里会有只有熟悉《战锤40K》和系列历史的玩家才看得懂的深层引用和彩蛋，但我们也希望完全不了解背景的人能够进入。

“以初代为指路星”也不意味着只参考这一款游戏。如果初代的做法今天依然有效，我们就优先沿用；如果初代没有解决某个问题，或者旧方案已经不适合今天，我们当然会从《战争黎明》二代、三代、《钢铁收割》以及其他RTS中寻找启发，也会提出全新的方案。