在大厂3年大型商业3A手游项目给我的<技术目标感>感悟

过去三年，小说君有幸参与了一款本世代大型游戏工业产品的研发。现在《星球：重启》已经顺利上线。非常感谢leader的信任，小说君得以直接接触了一些以往工作背景不熟悉的业务范围，从更全局的视角认知到一款大型游戏工业产品如何一步步从MVP版本成长为足以带给玩家持续游戏体验的线上运营产品。

开发过程中，将一些感悟记录成此文。写于2022年中，有删改，去掉了跟项目有关的描述。

本文以全球知名工作室Naughty Dog和MONOLITH的组织架构为切入点，探讨游戏研发流程中的项目目标、技术团队目标与技术个人目标以及三者之间的联系。

接下来又从两个维度探讨一名技术如何在研发流程中保持目标感（Sense of purpose）：

游戏内容生产的四条主要工作流：场景、角色、叙事、系统

游戏项目研发的全流程与关键里程碑节点：DEMO、MVP、alpha/beta、Early Access

全文约8000字，阅读时长约需15分钟

背景

什么是目标感？

感即感知（sense），目标感即对目标时刻保持感知的能力（Sense of purpose）。

我们对产品经理的要求是具有产品sense，对游戏策划的要求是有游戏审美，对技术的要求是具有技术审美和敏感度。目标感与上述业务向的能力处于不同的维度，更关注「大局观」。

怎么样才算有目标感？

• 始终保持对目标的感知。

对过去的、当下的、接下来的目标是什么保持清醒认知。

• 具备对目标的拆解、规划和落地执行的能力。

不仅要知道目标是什么，还要知道目标如何完成。

作为游戏项目的一名技术，如何保持目标感？

首先要认知一个前提：个人目标依托于团队，团队目标依托于项目。

认知到团队的目标是什么，并将个人目标与之对齐、统一。

为什么要保持目标感？

• 在一个中大型研发团队中，每位成员都有精细的分工以及独一无二的定位，团队中每位成员都需要对目前项目所处的进度、遇到的风险、接下来短中期要做的事情有清醒的认知。
• 设计师团队需要对游戏整体方向保持目标感，而技术团队同样需要对游戏目前的完成度和交付进度保持目标感。除此之外，技术团队还需要对工作流与关键技术的研发与落地保持目标感。
• 定期review与刷新目标与完成状态，可以避免整个研发团队走向错误的方向、浪费人力与开发资源，也可以避免出现战术上的勤奋掩盖战略上的懒惰的情况。

今天，我们不谈虚头巴脑的概念，仅就欧美日几个典型项目的同行的组织架构，来探讨下，技术在游戏研发周期中的目标应该是什么，如何保持目标感。

技术团队的目标

如前文，个人目标需要依托于团队，那我们先看看技术团队的目标是什么。

技术团队的范畴：包括但不限于：客户端、服务器、引擎、TA、技术策划、工具技术、技术中台等。

在讨论技术团队的目标之前，我们首先应该就以下几点达成共识：

游戏项目研发中，技术团队的工作内容是明确的：

• 大部分情况应该是在做成熟的、流水线式的工业品。
• 只有少部分情况是在做科研。
• 如果实际工作内容相反，那么有两种可能：

1. 承担了较多上级给定的科研任务。
2. 方向有误。

不论目标是什么，技术团队都需要用有限的资源，尽可能做到：

• 满足设计师与艺术家的表达欲。
• 为设计师与艺术家打造高效的内容生产工作流。
• 按时、保质、保量交付产品。

接下来， ——

游戏研发过程中，技术团队的目标是什么。

游戏项目的技术团队，如所有的技术团队一样，始终呈现两方面的目标：

1. 基于确定的成本，高质高效地完成业务。
2. 作为上级技术团队的一部分，摸索技术边界，形成积累与产出，反哺上级技术团队。

两方面的目标是相辅相成的。我们依次来看。

方便起见，我们把两方面目标分别简称为「业务目标」与「技术目标」。

一、业务目标

基于确定的成本，高质高效地完成业务。

业务目标具体来说是什么？

如前文，团队的目标依托于项目。

要理解技术团队的业务目标是什么，我们可以重新审视一下游戏项目的目标是什么。

一句话简单解释：

——以确定的成本，搭建游戏框架，快速生产游戏内容，供玩家消耗，让玩家持续获得乐趣与满足。

扩展开的话，就是：

• 上线前，重点倾向于游戏框架的打造，保证间隔较长（季度到半年为周期）的版本内容供给。
• 上线后，重点倾向于内容的持续高质高量填充，保证间隔较短（月度为周期）的版本内容供给。

这个描述还需要进一步细化。

目标是需要由人来完成的，我们可以通过分析团队的职能划分与分工，来拆解这个比较抽象的目标。

职能分工与细化程度随着工业化的发展而发展，且是一个不可逆的过程。

最早期的8位/16位机游戏，一个开发者能同时完成贴图制作、玩法设计、文本编写、游戏逻辑，产出一个像模像样的游戏。

接下来的团队作战，是我们熟知的程策美测四边形组合。

随着游戏规模的扩大，各个职能逐渐产生了细化：

• 美术职能出现了上下游的划分：原画、模型、动画、地编等。
• 策划职能出现了切面的划分：系统、关卡、文案、数值（数值类网游）等。
• 技术职能出现了切面的划分：引擎、工具、客户端、服务端（网游）等。

游戏规模进入3A级体量，不同职能内出现了更精细的工业分工：

• 原画分化出了概念设计、角色设定、场景原画等。
• 模型分化出了人体、场景等。
• 地编分化出了灯光、美术向的关卡设计等。
• 一些混合职能出现：技术策划、分镜策划/美术、AT/TA等。

大部分国内的游戏开发团队，基本上到3A这个阶段，分工与结构都大同小异。

但是，这远不是终点。我们如果将目光转向世界上更成熟地区的同行，会发现一些新的东西。

顽皮狗工作室算得上是目前世界上运转体系最高效庞大的游戏研发团队之一，我们看看能不能从中获取到一些灵感。

顽皮狗的最新作品The Last of US Part II（2020），有来自14个工作室超过2000人共同参与开发，其中仅仅是项目开发组就有470人。

我们通过简单梳理，可以对其各职能的协作方式一窥一二：

可以看出，相比之前整理的3A体量的团队分工，该团队的职能分工还额外具有以下特点：

• 有专门的关注游戏内容生产工作流的TD组。
• 文案区分了叙事和对话编辑职能。
• 动画师会根据项目的类型，划分具体的细分领域：Player、Melee、Technical、NPC、Cinematic、Story、Facial等。

当然，如此的分工也不是一蹴而就的。The Last of US Part II的团队历经了数代产品的积累。

作为对比，我们也回头看下The Last of US（2013）的团队构成，来看看他们有哪些演化：

相比之下，这个要早7年的产品研发团队除了人数上更少（300 v.s. 470），还有这么几个特点：

作为一款2013年发布的产品，其团队分工已经相当细：

1. 已经有TA团队，且出现了方向细分。
2. TD团队已经有相当的规模，专注角色和动捕工作流。
3. 由于叙事的重要性，很早就出现了cinematic animator，分镜猜测应该仍由designer完成。

• 2020相比2013，分工更加细化，出现了很多非常特定的子方向：

1. 由Dialogue演化出的专注叙事演出的Narrative。
2. Animator分化出了影视化相关的Cinematic animator。
3. TA也逐步区分角色和环境TA等。

作为对比，我们再看下工业化程度相对欧美较低的JRPG，以Xenoblade II（2017）为例，看下团队构成：

跟欧美同行对比，MONOLITH属于工业化早期的团队结构。几个值得注意的点如下：

• 大体上还是可以看到程策美三角结构。
• 没有TA。
• 没有QA，只有外部协作的Test Support团队（大概可以解释为什么这个游戏刚发布的时候那么多bug）。
• 除了日系游戏的特色（外部专家做主要角色的概念设计、三摄图等）之外，美术工作流的最上游统一为Artwork，应该是同时兼具了设定执行和原画的职责，没有欧美的Concept岗位。
• 程序和策划也有大量的外包岗位（Program Support/ Plan Support）。
• 由于Cutscene在JRPG中的地位比较重要，因此仍然独立出来了Cutscene小组。

了解了整个游戏研发团队的分工与结构之后，我们也可以逐渐对技术团队需要承担的职责与相应的业务目标有更清晰的认识。

再次回顾一下项目的目标：以确定的成本，搭建游戏框架，快速生产游戏内容。

因此技术团队的目标可以如此理解：

• 从技术层面搭建游戏内容生产和运行框架。
• 辅助其他职能快速生产游戏内容。

换句话说，就是服务于其他职能同学，构建高效的工作流，确保项目准时交付。

从前面对几个团队的结构拆解，在内容生产侧，我们可以得出这样几条关键的工作流：

• 角色
• 场景
• 叙事
• 系统

从玩家视角来看几条工作流的产出：

角色

• 玩家接触到的主角及所有抽卡角色的原画、模型、表现效果、动作等。
• 关键NPC的模型、表现效果、动作等。
• 3C（Camera、Control、Character）

1） 核心战斗、技能

2） 镜头

3）「打击感」

• 怪、BOSS。
• 其他重要模型（根据游戏类型有所不同，比如宠物、枪械、机甲等）。

场景

• 玩家接触到的场景元素。
• 虚拟世界的设定、原画、建模、氛围感。

1）地表、山、水、植被等。

2）环境中的光线、雾、各种天气效果等。

3）环境特效与模型等。

• 地图、关卡、场景玩法等。

叙事

• 玩家控制角色在游戏内的存在意义。
• 游戏设定：世界观、角色、地图、势力、年表等基础设定。
• 基础的引导、剧情、对话等。
• 过场CG、实时演出等。
• 各种增强虚拟世界代入感和沉浸感的交互机制。

系统

• 玩家可以认知到的游戏内能做的各种事情、具体玩法。
• MMO中比较典型的日程表涉及的各种玩法和活动。
• 游戏内的各种平面/沉浸感UI及交互。
• 各种商业化及数值养成机制。
• 社交。

从技术视角来看，四条主要的工作流，大体都分为三个阶段：

1. 设定&设计：方向性设计工作，属于单条工作流的最上游，最原始的需求方。
2. 预研&原型：原型生产工作，需要确定制作规范，因此通常由混合职能、经验丰富的同学来预研跑通，并打通量产的各个环节。
3. 量产&迭代：铺量大规模制作。

不同工作流的各个阶段，对技术的要求比较普适：

• 阶段1局部参与，需要与美术能协同做出实现上成本的判断。
• 阶段2深度参与，原型及规范确定后通常会开始铺量，铺量时如果出现问题往往会造成资源和人力的损失，因此需要考虑周全。
• 阶段3聪明地参与，铺量过程中会伴随着各种落地细节问题的解决，如果只是把时间浪费在解决各种细节问题上，会非常低效。需要想办法减少相关问题的解决时间，思考如何优化整个工作流。

接下来，我们简单梳理一下四条工作流的各职能介入顺序及上下游关系，以及对技术有什么样的要求。

角色

各职能介入顺序：

• 设定&设计：世界观设定或角色设定文案、角色概念设计。
• 预研&原型：角色原画、角色模型、角色灯光、角色TA、角色动作。
• 量产&迭代：角色相关的执行/外派等，对话编辑。

工作流对技术的一些描述关键词：

• 3C

1）动画，状态机，生产工作流设计。

2）镜头与操作的结合。

3）核心战斗/技能相关的策划/美术生产工作流设计，跨端数据结构设计、协议设计、流程设计。【理论上所有符合工业标准的生产流程编辑器，都需要符合WYSIWYG（What You See Is What You Get，所见即所得）原则。】

4）移动同步相关的跨端数据结构设计、协议设计、算法设计。

• 核心gameplay
• 角色TA
• 主角、NPC、怪等关键模型工作流的设计
• 实体交互
• AI、RVO、寻路等模块

场景

各职能介入顺序：

• 设定&设计：世界观设定、场景概念设计。
• 预研&原型：场景原画、模型、灯光、场景TA、关卡设计。
• 量产&迭代：特效、动作、场景相关的执行/外派等，关卡相关的执行。

工作流对技术的一些描述关键词：

• 生产工具

1）场景地编协同编辑

2）关卡/世界协同编辑

3）语义设计

• AT/TA，混合职能
• 全要素流式加载/LOD
• 环境交互
• 跨端数据结构的设计、框架协议设计
• Navmesh/体素，数据生产、runtime

叙事

各职能介入顺序：

• 设定&设计：世界观设定、场景概念设计。
• 预研&原型：场景原画、模型、灯光、场景TA、关卡设计。
• 量产&迭代：特效、动作、场景相关的执行/外派等，关卡相关的执行。

工作流对技术的一些描述关键词：

• 生产工具

1）影视化叙事能力

2）实时预览的分镜、镜头语言设计

3）实时预览的任务/对话协同编辑

4）高效的cutscene设计

• 跨端数据结构设计、协议设计

1）任务、对话、小交互

系统

各职能介入顺序：

• 设定&设计：系统设计、玩法设计
• 预研&原型：UI/UX
• 量产&迭代：特效、GUI

工作流对技术的一些描述关键词：

• 生产工具

1）GUI编辑器

2）基于表的配置数据管理

3）流程配置管理

• 跨端交互框架与协议定义框架

比较传统且典型的客户端服务端协作模式：

• GUI框架
• 系统开发框架
• 玩法框架

在四条主要的内容生产工作流之外，还有一些没有提到的但是同样关键的工作流：

• 全球化版本的多语言工作流
• 全平台资源生产管理工作流

对于技术团队来说，除了保证上述各条服务于主要内容生产的工作流高效运转之外，还有以下几条相对来说比较重要的工作流：

资源/包体/发布/外放工作流：

• 保障输出最终的交付产物的流程通畅，各环节无卡点，稳定、可靠。
• 资源收集、打包、发布、运行时加载。
• 保障玩家体验到高频更新、实时反馈的游戏产品。
• 跨端热更新、patch制作与外放能力。

效果落地工作流：

• 保障策划与美术生产内容在游戏内的落地效果符合预期。
• 致力于填补引擎/编辑器内表现与实际包体的gap。

性能工作流：

• 保障玩家体验到高质量的最终游戏产品。
• 制定项目各方向资产预算，保证产出包体性能符合预期。

对于单条工作流来说，技术也需要关注其规划与完成度的推进和落地。

不论是规划还是落地，仅靠技术或仅靠需求方都是不行的。

存在这么个黄金三角：

资源投入：

• 一经确定，双方的杠杆角色才能针对特定方向做出合理规划。
• 不会轻易出现投入缩水或增加的情况。

需求方的杠杆角色：

• 能在给定投入的情况下，对需要达成的目标和路径有认知。

技术的杠杆角色：

• 能在给定投入的情况下，对需要做些什么和规划有认知。

三者需要匹配、对齐：

• 双方杠杆角色的杠杆能力需要匹配。
• 资源投入与杠杆角色也需要匹配。

二、技术目标

接下来看技术团队目标的第二点，作为上级技术团队的一部分，如何摸索技术边界，形成积累与产出，反哺上级技术团队。

技术目标与业务目标不是对立的关系，而是相辅相成的。

技术目标是从技术的视角出发，在业务之外，更好、更高效地完成业务目标。

大体分为这么几类：

• 代码的规范与质量控制。
• 开发者的负担减轻，编码体验优化与提升。
• 已开发系统的Review & 常规重构。
• 技术债务的识别 & 偿还。
• 技术的积累与知识沉淀，组织内的共享。
• 承担上级技术部门的科研任务。
• 团队的技术自我表达。

我们从业务视角和技术内生视角，分析了技术团队的目标，这样对于技术个人，更容易对齐团队目标，找到自己在团队中的定位。

研发周期中的目标

仅仅是认知到技术团队的目标还不足以达到「目标感」。

一个游戏项目的研发周期短则一年，长则数年。

在项目的整个研发周期中，目标会有不同的表现形式。

具象来说，研发周期中会有各种「版本」形式的里程碑节点。

• 版本里程碑节点的主线：DEMO -> MVP -> Alpha -> Beta -> 正式版。
• 此外，还会结合各次测试的关键节点形成主干支线：CE -> TBT -> CBT123 -> OBT。
• 同时，还在各种周期期间分裂出多条子支线，比如版署线、合规线、各种同步进行的小规模测试线等。

在达成的目标的过程中，不同阶段，子目标也不尽相同。

前面在探讨目标的时候梳理出来的关键工作流，每条工作流都是研发过程中的一个切面。

从技术视角来说，如何定义一条工作流的阶段？

在游戏设计中，我们通常这样对一个切面做完成度划分：

其中：

• L4与L3的区分是因为由于美术职能的产能整体需求量更大，因此拉出了个区分阶段。
• 切面的负责人大部分精力投入在L2与L3之间的部分。
• 通常会避免对L4阶段的切面进行底层玩法重构。

参考这种定义方式，我们也可以对技术参与制定的工作流进行完成度阶段的技术视角划分：

其中，最大的分界点在于跑通和量产：

• 跑通，说明工作流符合设计预期与用户职能预期。（比如可以顺利生产出一个场景；可以顺利生产出一个角色。

• 量产，说明工作流足够好用，可以方便地进行大规模生产。（比如可以高效生产出第二个、第三个场景；可以高效生产出新的角色。

• 在进入L3之后，避免进行工作流上的底层重构。

理论上，每个技术方向，即使没有明确的生产输入输出项，也应该具备L1234层级的定义。

方向的负责人，需要明确L234的以下几点：

• 阶段定义
• 开发规划
• 收敛节点
• 验收标准

每个方向处于不同阶段时，目标总会有两方面体现。

目标是技术团队的目标，需要简单、清晰、明确：

• 对外目标：面向业务，熵增过程。
• 对内目标：技术内生，熵减过程。

负责人拆解各阶段的内外目标，并分配给关键的人。

• 关键的人对拆解后的目标最终结果负责。
• 负责人对目标实现最终结果负责。

项目本身处于不同阶段时，技术团队整体的目标同样具备这种双面特性。

接下来，我们简单介绍一下各个关键里程碑节点中的技术团队整体目标形态，这样各个方向上的内外目标也可以在每个阶段保持对齐。

一、DEMO

关键词：立项、堆砌、工作流定型

技术团队的对外目标：调动资源，配合其他职能输出一个能通过立项的版本。

• 通常对应于尖叫度测试和公司立项。

技术团队的对内目标：核心人员到位，并形成有效分工。

• 会出现一人身兼多工作流owner的情况。

DEMO通常呈现的是尖叫度测试内容，半小时到2小时之间。可以理解为更偏重玩法+艺术风格展示的第一版新手流程。

现今的3A项目没有过于明确的DEMO阶段，真实的DEMO可能更接近于更早阶段的原型（Prototype）阶段。作为对比，现在的3A项目DEMO，以立项为目的，内容量级其实已经相对充足：

各种工作流初见雏形，其中：

• 角色和场景至少需要处于L2的状态，并可以进行小样演示。
• 叙事处于L1状态，随时可以开始进行后续阶段的迭代。
• 系统取决于此时的DEMO目标效果，处于一种介于L0和L1之间的状态。

技术已经直接以团队形式介入，团队雏形形成。

典型事件：

• 框架性质的技术方案确定。
• 艺术风格确定。

1）主角、场景艺术风格。

2）角色、场景渲染风格。

• 主角核心战斗流程。
• 多人协作的研发规范确定。
• 关键职能关键工作流的owner需要清晰。

二、MVP

关键词：规范、流程化、边界

技术团队的对外目标：输出完整流程包，能明确验证各关键内容生产工作流运转顺畅。

• 通常对应于第一次成规模的测试。

技术团队的对内目标：各关键工作流owner到位，核心工作流无技术瓶颈。

• 基本所有工作流都有技术owner覆盖。

在主机游戏开发中，MVP通常意味着playable的第一个版本。

可以表现为一个切面，比如一小章节。

就版本本身的可玩性来说，已经与对外发行版无异。

对应于网络游戏开发，MVP至少需要让玩家能感受到「会再次打开这个游戏」的冲动。

从工作流的完成度来说，具有以下特点：

• 角色、场景达到L3，已经完整铺量了一批角色及至少一个场景。
• 叙事达到L2，有服务于MVP版本定位的内容量级生产。
• 系统达到L2，有服务于MVP版本定位的内容量级生产。

技术能按人头覆盖到各个关键工作流，其中重点工作流（如场景和角色）形成小团队覆盖。

• 为保证对外目标高效达成，此时资源、性能工作流已经成型。

典型事件：

• 角色、场景工作流已经进入稳定输出状态（L3）。
• 叙事、系统工作流完成预研及原型生产内容产出（L2）。
• 资源/包体工作流处于可用状态（L2）。
• 性能工作流处于起步状态（L1）。
• 外放工作流处于起步状态（L1）。
• 各职能的生产规范确定，除非有重大问题或缺陷，否则不会发生变更。

三、Alpha/Beta（外测版本）

关键词：铺量、技术落地、熵减

技术团队的对外目标：保证游戏版本除了内容量级之外，与运营版本已基本无差异。

• 可以应对对外较大规模的游戏主流程（3/7/15天）测试。
• 通常对应于正式的技术测试（TBT）、内测（CBT）。
• 产品侧会重点关注游戏核心玩法是否被玩家接受，关注次留/三留/七留数据。
• 技术侧会重点关注技术方案是否可以经受验证。

技术团队的对内目标：团队成建制，梯度合理。

• 此时在各个工作流中，已经有新人介入。

TBT、CBT等外测节点通常是网络游戏的特权，是不可多得的产品验证游戏设计循环、技术验证关键机制落地的机会。

典型事件：

• 角色、场景、叙事、系统工作流均已进入稳定输出状态（L3+）。
• 其中，角色、场景需要为运营版本打提前量，已经开始布局L4内容。
• 资源/包体工作流，需要同时应对多条版本线、多个测试版本，因此需要足够完备易用，处于待完善细节状态（L3）。
• 外放工作流，需要在版本末期应对大规模长时间测试，因此需要足够完备易用，处于待完善细节状态（L3）。
• 性能工作流重要性逐步提高，需要已经具备定位并解决重要程度占比超80%的问题的能力（L2+）。
• 技术目标已基本完成游戏内落地，经过测试验证。
• 技术债务偿还、代码质量关注在阶段内属于周期性的工作目标。

1）Precommit review、静态检查、重构等。

四、Early Access（运营版本）

关键词：熵减、效能

技术团队的对外目标：对外常态化运营。

• 游戏产品化运营。
• 损益表。
• 在确定的成本下，增加效能。

技术团队的对内目标：团队向外向内生长。

• 职能相对前述各阶段更固化，每个人成为损益表的一部分。

网络游戏一经进入上线常规运营状态，所投入资源做的每件事情都需要相比之前更精确地计算ROI。

技术团队需要保障各条工作流仍然保持高效内容生产，满足玩家日益增长的对高质量高数量内容的需求。

识别&定位&解决工作流中不顺畅的卡点，提升整个工作流链路的生产效率。

典型事件：

各工作流均进入稳态（L4/L4+）。

小结一下

游戏研发周期很长，在持续输出的过程中，保持目标感很重要。

研发过程中失去目标感，随之而来的就是：

• 规划不清晰。
• 花额外的力气，做不应该做的事情。
• 战术上的勤奋掩盖战略上的懒惰。

而保持目标感的关键在于三点：

1.作为技术团队的一分子，始终对技术团队目标与游戏项目研发目标保持认知与对齐。

在整个游戏项目的研发周期中，技术始终呈现两方面的目标：

让其他职能舒服高效地生产内容，即「业务目标」。

摸索技术的边界，反哺上级技术团队，即「技术目标」。

两方面的目标相辅相成，缺一不可。

2.对各条主干工作流及支线工作流保持认知，对各工作流在各研发关键里程碑节点上理应呈现的完成度保持认知。

我们尝试通过从工作流的角度认知业务目标。

先是分析了游戏内容生产流程在国内的演化，接着又通过分析欧美日同行的组织架构，拆解了经典的游戏内容生产工作流。

以工作流为单位，组织起来对游戏内容生产的认知，以及对业务目标的认知。

3.对游戏项目的研发流程保持认知，在任何时间都知道自己在做什么、将要做什么。

我们以研发关键里程碑节点为切面，在各个节点到来前做完、做对该做的事情。

回到文章标题，游戏技术保持「目标感」，用几句话来总结一下：

• 对项目目前所处进度、风险、规划保持清醒的认知。
• 对所负责的分工在不同研发节点的完成度和交付进度保持认知。
• 对工作流与关键技术的研发与落地保持认知。

文章来源于说给开发游戏的你，作者小说君fp