【游戏开发】游戏生产的标准与工业化，管线Pipeline的概念与设计（项目管理，资产管理）

本文所有内容均来自互联网 & AIGC，无加密资料，引用已注明出处（见参考资料），侵删

参考资料：

• pipeline：1,2, 3，4, 5
• 游戏开发：1, 2, 3,

1、管线（Pipeline）是什么？

1. 定义
   • 在游戏开发领域，游戏管线（Game Pipeline）是指一系列按顺序处理的阶段，这些阶段用于将游戏的各种资源（如模型、纹理、动画等）从原始数据转换为最终在屏幕上显示的图像和音频，并且处理游戏中的各种逻辑运算。它就像是一个工厂的生产线，原材料（游戏资源）在这条生产线上经过多个步骤的加工处理，最终成为一个完整的产品（可玩的游戏画面和体验）。
2. 主要阶段
   • 资源加载阶段
     • 游戏开始时，需要从存储设备（如硬盘、固态硬盘）中读取各种资源，包括3D模型文件（如.obj、.fbx格式）、纹理贴图（.png、.tga等格式）、音频文件（.mp3、.wav等）。例如，在一个3D角色扮演游戏中，要加载角色模型的几何数据和对应的纹理，这些数据量可能很大。这个阶段还可能涉及资源的解压、解密等操作。
   • 几何处理阶段
     • 对于3D游戏，需要对加载进来的模型进行几何处理。这包括顶点变换，如将模型从模型空间转换到世界空间，再转换到视图空间。例如，一个游戏场景中有多个建筑物模型，每个模型的顶点位置都需要根据其在游戏世界中的位置和摄像机的视角进行正确的变换，以保证它们在屏幕上的位置正确显示。
   • 光照处理阶段
     • 计算光照效果是游戏管线中的重要环节。光照模型有多种，如简单的漫反射光照、更复杂的Phong光照模型或者基于物理的渲染（PBR）光照模型。以PBR为例，它会考虑光线的反射、折射、能量守恒等物理特性，让游戏中的物体表面光照效果更加真实。例如，在一个赛车游戏中，赛车车身金属质感的表现就依赖于精确的光照计算，不同角度的光线照射会产生不同的高光和反射效果。
   • 纹理映射阶段
     • 纹理映射是将2D的纹理图像应用到3D模型表面的过程。通过指定模型顶点的纹理坐标，可以将纹理准确地贴合在模型上。例如，在一个第一人称射击游戏中，游戏中的武器模型表面有各种细节纹理，如木纹、金属纹理等，这些纹理通过纹理映射阶段被正确地添加到模型上，增强了模型的真实感。
   • 光栅化阶段
     • 这个阶段主要将经过前面处理的3D几何图形转换为屏幕上的2D像素。它会确定哪些三角形（3D模型通常由三角形网格组成）覆盖了屏幕上的哪些像素，并计算出每个像素的颜色等属性。例如，在一个2D像素风格的游戏中，虽然模型本身比较简单，但仍然需要经过光栅化阶段来确定它们在屏幕上的像素位置和颜色。
   • 后处理阶段
     • 后处理是在画面基本成型后对整个画面进行的一系列效果处理。常见的后处理效果包括抗锯齿（减少画面边缘的锯齿感）、景深（模拟真实相机的景深效果，使远处物体模糊）、色彩校正等。例如，在一款画面精美的动作冒险游戏中，通过色彩校正可以营造出不同的氛围，如暖色调的白天场景或冷色调的夜晚场景。
   • 音频处理阶段
     • 游戏中的音频也需要进行处理。这包括加载音频文件，根据游戏场景和事件触发声音播放，调整音量、音高、音效的空间位置（如3D音效，让玩家感觉声音是从游戏世界中的某个方向传来）等。例如，在一个恐怖游戏中，当玩家靠近一个隐藏的怪物时，怪物发出的声音会逐渐变大，并且通过3D音效让玩家能够辨别怪物的位置方向。
3. 游戏管线的重要性
   • 游戏管线的合理设计和优化对于游戏性能和画面质量至关重要。一个高效的游戏管线可以充分利用硬件资源，如GPU（图形处理器）和CPU（中央处理器）的性能，减少资源浪费，提高游戏的帧率（每秒显示的画面帧数），从而使游戏运行更加流畅。同时，通过精心设计游戏管线中的各个环节，可以提升游戏画面的真实感和艺术表现力，增强玩家的游戏体验。例如，采用先进的光照模型和高质量的纹理映射可以让游戏场景栩栩如生。
4. 不同类型游戏的游戏管线特点
   • 2D游戏
     • 2D游戏的管线相对简单。它可能没有复杂的3D几何处理和光照计算（部分2D游戏有简单的光照效果模拟）。资源加载主要集中在2D图像和音频上，光栅化过程相对直接，将2D图像按照一定的规则绘制到屏幕上。例如，简单的2D平台跳跃游戏，主要的管线流程可能就是加载关卡图像、角色图像和对应的音频，然后进行简单的图像绘制和音频播放控制。
   • 3D游戏
     • 3D游戏管线更为复杂。由于要处理3D空间中的几何图形、光照、纹理等多个复杂因素，各个阶段的处理都需要大量的计算。特别是对于大型3D开放世界游戏，游戏管线需要高效地处理海量的模型、纹理和光照数据。例如，在一个3D大型多人在线角色扮演游戏（MMORPG）中，游戏管线要同时处理多个玩家角色、复杂的建筑和地形模型，以及各种动态光照效果，这对游戏管线的性能和优化要求极高。

1.1 管线解决什么问题（例子）

我们在工作中会碰到如下问题，Pipeline 就是来解决下面的问题的。

Pipeline 是管理项目的信息和数据的流动

• 信息被高效、正确、及时地传达到位
• 数据的来龙去脉、前世今生、脉络关系管理的清清楚楚明明白白
• 没有放之四海而皆准的 Pipeline 系统，一定要根据项目的实际情况，只有适合你的 Pipeline才是好的 Pipeline。
• 如果是一个几人的小团队，喊一嗓子就能沟通到位的事情，没必要花时间精力去折腾 Pipeline系统，得不偿失；或者项目的美术资产很少，也确实没必要。
• 如果你的目标是工业化，或者想知道工业化应该包含什么方面，那么就需要pipline了。
  开发和维护 Pipeline 系统的人，在影视行业，叫做 Pipeline TD（Technical Director）。

1.2 一个动画电影的完整制作流程（例子）

一个动画电影的完整制作流程

• 下图（来源）：
• 可以看到，（Pipeline）TD 们都是在小房间之外（不参与内容制作）走动，负责监控和维护，保障整个管道正常运行的人。
• 三个岗位的工作内容角度，将 Pipeline 要管理的范畴，分为三大类：
  项目管理
  Review
  资产管理（文件和 metadata 的管理）
• 这三者并不是隔离的，而是紧密结合在一起的，之间的数据和信息流动是要丝滑的、无缝的。
  其实 Review 是包含在了项目管理中的，按照影视的说法，就是分 Production Management 和 Asset Management。
  

1.3 游戏管线的意义（定义）

背景：

• 也许是对主机游戏品质的向往，也许是原神早已将移动端游戏拉到新维度，近几年传统游戏厂商纷纷入局，通过扩张团队规模，增加研发成本，建立海外工作室吸引全球化人才等方式"砸出"公司级重度产品。
• 但做为第九艺术的游戏，似乎和 “高效率”、“工业化” 存在天然冲突。只有工具化、自动化是不够的，3A流程不是所有游戏的标准答案；只有艺术性也是不够的，成本、时间是任何一个项目都面临的难题。
• 如何在创意与落地间找平衡，如何确保团队有明确的目标并且所有资源被恰当得进行分配。如何保证资源能量产，项目能上线，并且团队有足够产能产出够运营消耗的资源。随着团队规模，项目复杂度的上升，因地制宜的管线是一种可行的解法。

以一些常见的情况来举例：

• 有多少团队会在“结版本出包”这件事上让整个团队停下来几天，甚至数周？
• 有多少团队会出现游戏资产的质量参差不齐，有的很精致，有的很拉跨？
• 有多少团队会经常出现”开发瓶颈“——大家在经常要等某几个人，这几个人的进度决定了整体的进度？
• 而这些问题之所以存在，正是因为”电子游戏“是一种”拥有商业属性的高技术浓度装置艺术“。这种产品与传统互联网产品完全不同，反倒是和汽车工业等有点像。

“管线”就是“pipeline”的硬翻。

• 可以将其理解为工厂中的流水线，每个生产单位只专注处理某一片段的工作，以提高工作效率和产量。
• 放入游戏中，管线可以拓展为一个公式，即管线=流程+标准+工具。

总结

• 管线必要吗？不必要。 重要吗？对重度项目非常重要。
• 不为了看似“工业化”而设定步骤，开发没人使用的工具。 但同样不非黑即白，否定流程，标准对一个大型团队生产力的价值。
• 一个只狼的分享，模型制作环节弥补了原画非常多设计不准的问题。发达国家的游戏行业在整体流程上的控制成熟度是更高，这需要大量的磨合和积淀，有一天我们也能做到。但在此之前，落地同样重要，对大型项目而言，除了堆积人力，因地制宜的管线也是有效的解决方式。

2、 如何设计管线？

背景：

• 每个游戏项目因为其选择的核心玩法、渲染风格、叙事方式或者纯粹的体量要求，都会导致管线的特异性。
• 这个所谓的“管线”在一个项目中，不是一个，而是会有许多个。
• 这些管线交织在一起，形成针对不同资产、不同阶段的游戏内容生产轨道。
• 它们彼此关联，互相影响。
• 好的游戏开发管线有两个最显著的作用：提高质量下限、优化整体效率。

2.1 设计流程

众所周知，工业化的基础是标准化。而标准的制定，却是整个环节设计的”第3步。

第1步，是做Demo和立项 —— 大家先说清楚我们做的是啥。

• 很多时候立项只是因为有个“点子”。这本身没有问题，但是实际上这个点子是否成立是需要实际论证甚至验证的。
• 又可能你脑子里想的内容不多，但是为了让Demo成立，会衍生出一堆东西来。
  
• 在这个阶段中，我们还需要确定几件事：
  a. 美术资源品质要达到什么程度。
  b. 标准形态下的核心玩法需要做到什么程度。
  c. 达到这个程度，当下最合理的工作流是什么样的。
  d. 为了展示上述内容，我们有什么资源是必须新做？

第2步，制定里程碑 —— 别一下子把摊子铺太大，大家一起向一个方向用力。

• 在这个阶段，大家需要圈定好项目的边界和范围。然后根据团队的能力和预算，分好开发阶段。尽可能不要在实际开发走起来之后，发现做每一件事都需要打补丁和产生不可预估的前置任务。
• 在这个阶段中，我们需要确定几件事：
  a. 项目一共有多少内容量。说清楚有多少功能、多少玩法、多少系统。
  b. 根据我们的产能，制定多个可以量化内容的阶段。每个阶段不能超过三个月。
  c. 详细的拆解每个里程碑的开发内容，排清楚开发顺序。

第3步，现在，我们就可以面向目标定标准了。

• 这里的标准主要包含两部分：
  a. 流程的标准 —— 大流程包括了谁先谁后，前置环节做到什么程度才能启动后置环节，每个不同类型的需求由谁发起，谁跟进，每个环节的负责人如何指定，最终结果谁负责。
  b. 资产的标准 —— 除了各类美术资产，也包括策划资产、技术资产，甚至会议记录的内容。
• 而管线的设计也就由此开始：
  a. 简单的游戏资产管线设计：明确的规范游戏开发的每个环节，包括资产的生产，人员的协作，并作的验收，多个成果的组合。
  你必须可以明确的描述游戏开发流程中每个资产从无到有的各个环节的负责人，以及每个开发任务的前后置关系。
  
  b. 不同事项的依赖关系和优先级定义：
  有些需求虽然看似明确，但却依赖于其他的需求的结果；
  有些需求虽然看似关键，却是个无法确定耗时的“研究”；
  有些非常耗时的研究和探索，可能会导致后续工作流的变化；
  有些工作项是尝试性的，可能其成果不一定会真的有用。

第4步：管线的维护和优化

• 优化单个环节工活儿的时间
  i. 人员的适配在这个环节是最有感觉的。优秀的项管人员能将合适的人放在合适的活儿上。
  ii. 很多工具、插件也是在这个部分发力的。
• 优化整体时间
  i. 时刻关注耗时的高峰，将削峰作为使命。
  ii. 减少瓶颈环节的存在感
  iii. 合理的利用工具进行职权转移
• 持续提高环节通过率

总结：

• 游戏开发管线必须建立在一个明确的目标的基础上，这个目标包括了核心玩法、美术目标、发行策略等。
• 游戏开发管线的重点在于让游戏能够稳定、高效的生产出来，而并不能解决游戏是否出彩、是否好玩、是否赚钱的问题。它更多的是保证下限。
• 很难说有没有一种范式可以适配所有游戏的开发。因为运作顺畅的管线和这个团队里的每个人都有关系。
• 做发行的时候，发现80%的项目都是做不完的。而所谓“做完了”的项目也有80%最终没能走到上线那一步。
• 虽然大环境一定是有锅要背的，但是我们身在其中却也只能继续前行。

——————————————————————
定义与流程

1. 明确游戏目标和需求
   • 确定游戏类型和风格
     • 不同类型和风格的游戏对游戏管线的要求差异很大。例如，对于一款2D像素风格的休闲游戏，其重点可能在于简单的图形绘制和基本的音频播放，管线设计相对简洁。而对于3D写实风格的大型角色扮演游戏，就需要复杂的3D几何处理、高质量的光照和纹理映射等环节。
   • 考虑目标平台性能
     • 游戏的运行平台（如PC、主机、移动设备）的硬件性能是设计游戏管线的重要因素。如果是面向移动设备的游戏，需要考虑其有限的GPU和CPU性能、内存大小和带宽。例如，移动设备的GPU处理能力相对较弱，在设计管线时要避免过于复杂的光照计算和高分辨率的纹理映射，以保证游戏的流畅运行。
   • 分析玩家体验期望
     • 了解玩家对游戏画面质量、帧率、响应速度等方面的期望。例如，竞技类游戏玩家通常对帧率要求很高，希望游戏能保持高帧率以获得流畅的操作体验。所以在设计游戏管线时，要着重优化性能相关的环节，确保高帧率的实现。
2. 规划管线阶段和流程
   • 确定核心阶段顺序
     • 一般游戏管线包括资源加载、几何处理、光照处理、纹理映射、光栅化、后处理和音频处理等阶段。要根据游戏目标和需求确定这些阶段的先后顺序。例如，在3D游戏中，几何处理通常在光照处理之前，因为光照计算需要基于正确的几何位置来进行。
   • 考虑并行处理机会
     • 为了提高效率，可以寻找能够并行处理的环节。例如，在资源加载阶段，可以同时加载模型和纹理资源，因为它们通常存储在不同的文件中，互不干扰。另外，在一些现代图形处理中，几何处理和光照处理的部分计算也可以在GPU中并行进行，减少总的处理时间。
   • 设计数据传递方式
     • 每个阶段之间需要传递数据，要设计好数据的格式和传递机制。例如，在几何处理阶段将处理后的顶点位置和法线等数据以一种高效的格式传递给光照处理阶段，避免数据冗余和不必要的转换。可以使用中间缓存或者共享内存等方式来优化数据传递。
3. 选择合适的技术和算法
   • 图形处理技术
     • 根据游戏风格选择光照模型。对于写实游戏，可以采用基于物理的渲染（PBR）光照模型，如Unreal Engine的PBR实现，它能够真实地模拟光线在物体表面的反射、折射等物理现象。对于卡通风格游戏，可以使用简单的Toon Shading（卡通着色）技术，通过简化光照计算来营造卡通效果。
     • 纹理映射方面，根据游戏需求选择合适的纹理过滤方法。如双线性过滤可以使纹理在拉伸或压缩时更加平滑，三线性过滤则在处理多层纹理（如Mip - Map）时效果更好。
   • 音频处理技术
     • 对于3D音效，选择合适的空间音频算法，如OpenAL库提供的算法可以有效地模拟声音在3D空间中的传播和定位。在音频压缩方面，要根据游戏平台和音频质量要求选择合适的压缩格式，如MP3用于背景音乐的压缩，ADPCM用于简单音效的压缩，以平衡音频质量和内存占用。
   • 性能优化算法
     • 采用遮挡剔除技术，在几何处理阶段剔除那些被其他物体遮挡、用户看不到的部分，减少不必要的渲染计算。例如，在室内场景中，墙壁后面的物体可以被剔除，不参与后续的光照和光栅化处理。
     • 利用实例化技术，当游戏中有大量相同的物体（如一片森林中的树木）时，通过实例化可以减少数据存储和渲染计算。只需要存储一份物体模型数据，然后通过变换矩阵等方式来渲染多个实例。
4. 进行性能测试和优化
   • 建立性能测试框架
     • 设计一套测试方案，用于测量游戏管线各个阶段的性能指标，如每个阶段的处理时间、内存占用、GPU和CPU使用率等。可以使用专业的性能分析工具，如NVIDIA的Nsight工具（用于GPU性能分析）和Intel的VTune（用于CPU性能分析）。
   • 找出性能瓶颈
     • 通过性能测试，找出游戏管线中耗时最长或者资源占用最多的环节。例如，可能发现光照处理阶段的复杂光照计算导致GPU使用率过高、帧率下降。这时就需要对这个环节进行优化，如简化光照模型或者采用更高效的光照计算算法。
   • 持续优化调整
     • 根据性能测试结果，对游戏管线进行持续的优化调整。这可能包括调整算法参数、改变数据结构、优化代码实现等多种方式。例如，将一些频繁调用的函数进行内联优化，或者使用更高效的数据容器来存储游戏资源，以提高内存访问效率。
5. 考虑扩展性和维护性
   • 设计可扩展的架构
     • 游戏在开发过程中可能会增加新的功能或效果。例如，可能会在后期加入新的后处理效果，如动态模糊或者屏幕空间反射。因此，游戏管线的设计要考虑到这种扩展性，预留接口或者模块，方便新功能的添加。
   • 保持代码的清晰和可维护性
     • 采用良好的代码架构和编程规范，使游戏管线的代码易于理解和维护。例如，将不同的管线阶段封装成独立的函数或类，每个阶段的代码有清晰的注释，这样在后续开发或优化过程中，开发人员可以更容易地对特定环节进行修改和调整。

2.2 例子1 角色设计-DNA模式

• 大部分玩家通过主线任务或进入场景的第一眼美术风格来理解世界观。文案组通过“反包”，填充辞藻，将游戏逻辑通过任务剧情重新表述，以更合理的方式商业化，同时也需保证玩家在跳过剧情的情况下继续体验游戏。
• 以贩卖角色的多英雄射击项目为例，在经典的玩法框架下，策划需要卖人设、卖剧情。单纯的玩法先行会使角色冲突，例如在科幻的世界观下很难合理包装法术英雄。因此我们拉起DNA流程（如图所示）。
• DNA主要由Design玩法，Narrative叙事，Art美术三个核心职能构成，主要目的（1）让玩法、世界观、美术有效协同、三位一体，高度自洽（2）在设计环节投入更多人力、时间成本。释放制作人力，投入核心设计。（3）预先验证，减少正式制作环节的不确定性。
  
• 不是所有项目组都需要DNA流程，如果项目组的商业化模式并不是贩卖角色以及其衍生品，或者一款主导小而美玩法的游戏。让玩法先行，或者叙事、美术先行都是成立的。设计阶段的步骤、各职能话语权的比重需要根据游戏类型和团队能力而定。

2.3 例子2 角色管线 PBR与NPR

PBR-真实化

• 继续以角色管线举例，目前市面比较常见的是PBR（Physically-Based Rendering）制作流程。
• 使用PBR主要有两点优势。
  第一，模型更加精美。在不同场景光照下，不管是布料柔软度还是纹理凹凸感，都带给玩家更逼真的体验感受；
  第二，PBR提供了一种稳定的美术工作流程，从制作中低模—>高模—>将高模拓扑为低模—>展UV—>烘焙法线贴图—>贴图绘制。
• 成熟的生产管线能保障模型最差效果。

NPR-风格化

• 随着二次元文化的发展，更多二次元游戏进入大众事业，不论是美式卡通风格的《守望先锋》、《堡垒之夜》，还是日式卡通风格的《原神》、《绝区零》。
• 和追求真实感的PBR不同，追求风格化的NPR渲染管线逐渐进入大众视野，近年甚至有变得主流的趋势。
• NPR全称为Non-photorealistic rendering，很多厂商也称其为卡渲，PBR流程将更多时间用于材质处理、NPR用于打光渲染。
• 通过轮廓描边、材质、阴影、边缘光、后处理等步骤对渲染管线进行改造，根据项目风格定位，来确定不同实现方法，例如着色，是通过Cel shading模仿传统卡通赛璐璐风格，将色彩从多色阶降到低色阶，减少色阶的数量；还是使用Tone based shading，基于美术指定的色调插值进行风格化。针对不同的项目，角色管线负责人和技术美术会有不同选型。

对比

• PBR阴影符合现实规律，为了场景的好看、人物的效果，
• NPR光源对人物的影响并不是完全实时的状态。
• 和PBR中制作流程不同，NPR往往是项目组技术美术通过对shader的扩展和引擎内部的深度改造，最终实现美术效果。

但在整个过程中，我们在正式铺量前，要保障：

• （1）充分调研，确定游戏美术风格。东方玄幻、西方魔幻、赛博朋克还是日式二次元。对应角色走PBR制作管线？NPR制作管线？NPR制作的基础上增加部分PBR流程？
• （2）结合制作管线、团队人才储备，确定权责清晰的审核流程。例如相比于PBR，NPR可以省去中模、高模、烘焙法线贴图等过程，
  好处是缩短制作周期，减少制作人员拉扯。
  坏处是模型整体效果难以控制，一出现不满意的情况容易从设计阶段开始推翻，带来大量返工。可以高薪聘请专门负责这块的角色主美，让他在制作管线中卡死角色三视图审核环节。
  同时将头发、裙摆拆成单独管线，配置最有经验的模型进行审核。

标准

• 一般来说，我们可以将游戏生命周期分成三类：预研、研发、上线运营。
• 直观的看，海外的3A大厂育碧和国内的头部大厂网易的研发流程是相似的（如图所示），渐进明细。只是育碧各时间节点下的阶段更细。我们用育碧举例各品质资源和时间节点的关系：
  L0资源：主要是所有关于特性或者物件的文字描述或原画资源。在Preproduction阶段帮助项目明确方向，帮助成员了解自己负责的内容。
  L1资源：要确定美术资源的尺寸、碰撞以及基础的贴图和颜色。开发团队会一直使用到Alpha阶段。
  L2资源：原则上所有特性或者物件，在Alpha时期就应当全部有了第一个游戏内的样子，白盒资源几乎不出现在工程中了。
  L3资源：所有特性以及物件应该在Beta阶段做到了最终质量，只是还有一些 bug 需要在Beta的集中debug时期修复。
  L4资源：不是所有资源都会引用此质量等级，在非常少的场景中起到较大的烘托作用的物件才需要此类质量。
  

3、管线设计中的两个点

3.1 项目管理与review（流程）

项目管理的目标

• 任务分配、排期
• 任务的上下游关联
• 任务的资产关联
• 跟踪资产完成度、发行版本、项目进度等

项目的流程

• Project（最顶层的，游戏项目、电影项目，或者因为某些原因拆分出来“子”项目）
• Phase（或者叫Sprint，指一段时间，加很多个 milestone，用来做阶段性排期，比如游戏要上线的6.0 版本等）
• Asset（包括影视的 Sequence/Shot、游戏的美术资产、关卡等）
• Task（将 Asset的制作拆分出来的最小级别的、可以分配到具体人的任务，并且有期望起止时间和预计时长）
• People（干活儿的，可以是个具体的美术人员，也可以是家外包公司）
• TimeLog（记录每个 Task 的制作实际制作时长，用来衡量工作效率或者是任务预算是否合适）
  

Pipeline 的主要精力

• 让美术及时看到反馈，可以是发邮件、发即时消息
  甚至让美术直接在自己的 DCC 里面看到，把反馈图片贴在场景里
  根据新的Note 反馈，自动创建 Task，方便追踪后续是否解决了该反馈
  美术可以更方便的上传 Version
  批量上传 Version
  视频标准化：画面水印、文件分辨率、文件编码、色彩空间、规范命名…
  统计：task 有多少个 version、多少个 note，跟task 的bid 比，滞后了还是超前了，反向修正排期，让排期更合理。
  增加更多格式支持，比如支持 3d文件预览

哪个软件具备上述提到的大部分功能

• Excel
  Arthub
  Eagle
  百度网盘
  JIRA
  Trello
  ShotGrid
  Ftrack
  易协作
  TAPD
  腾讯会议
  腾讯文档
  Perforce
  Git
  SVN
  Frame.io
• 在影视行业，体量大点的公司，选用的基本是ShotGrid 或 Ftrack
  而中小型公司市场，则基本被 CGTeamwork 所垄断

1. 项目管理在游戏管线设计中的应用

   • 项目规划阶段

     • 定义项目范围和目标：明确游戏管线设计的具体内容，包括要实现的功能、支持的游戏类型和平台等。例如，对于一款跨平台的3D动作游戏，项目范围可能涵盖从PC到主机的不同硬件环境下，能够实现高效的3D模型加载、高质量的光照处理和流畅的动画播放等功能的游戏管线设计。
     • 制定项目计划和时间表：将游戏管线设计过程分解为多个任务，并为每个任务分配合理的时间。例如，资源加载模块的设计可能需要两周时间，包括调研现有加载技术、选择合适的文件格式和开发加载代码等子任务。可以使用甘特图来清晰地展示各个任务的时间安排和依赖关系，确保项目按计划推进。
     • 组建项目团队：根据游戏管线设计的需求，挑选具备不同技能的人员，如图形程序员、音频工程师、测试人员等。确保团队成员清楚了解自己的职责和项目目标，比如图形程序员负责游戏管线中的几何处理和光照计算部分，音频工程师专注于音频处理阶段的设计。

   • 项目执行阶段

     • 任务分配和跟踪：将项目计划中的任务具体分配给团队成员，并定期跟踪任务进度。可以使用项目管理软件（如Jira、Trello等）来分配任务，团队成员可以更新任务状态，方便项目经理及时了解每个任务的进展情况。例如，如果一个程序员负责纹理映射模块的优化任务，项目经理可以通过软件查看该任务是否按计划完成，是否遇到问题等。
     • 风险管理：识别游戏管线设计过程中可能出现的风险，如技术难题、人员变动、时间延迟等，并制定相应的应对措施。例如，若在光照处理阶段遇到了性能瓶颈，可能的风险是无法达到预期的游戏画面质量或者帧率下降。应对措施可以是提前准备备用的光照算法，或者安排更多的时间进行性能优化。
     • 沟通协调：保持团队成员之间的良好沟通是项目执行的关键。定期召开项目会议，讨论项目进展、问题和解决方案。例如，每周举行一次管线设计会议，图形程序员可以汇报几何处理阶段的新优化思路，音频工程师可以分享音频处理的测试结果，大家共同讨论如何更好地整合各个管线阶段。

   • 项目监控和评估阶段

     • 性能监控：在游戏管线设计过程中，持续监控各个阶段的性能指标，如加载速度、处理时间、资源占用等。与项目计划中的预期性能指标进行对比，及时发现偏差。例如，如果资源加载时间超过了计划中的预期，需要分析是因为资源文件过大、加载算法效率低还是硬件问题导致的。
     • 质量评估：对游戏管线设计的质量进行评估，包括功能完整性、稳定性和兼容性等方面。通过功能测试、压力测试等方式确保游戏管线能够在各种情况下正常工作。例如，进行不同硬件配置下的兼容性测试，检查游戏管线在低性能硬件上是否会出现崩溃或者严重的性能问题。
     • 项目调整：根据监控和评估的结果，对项目计划和游戏管线设计进行必要的调整。可能需要修改时间表、重新分配任务或者优化设计方案。例如，如果发现某个管线阶段的性能严重影响游戏整体性能，可能需要调整该阶段的设计思路，或者增加优化任务的时间和资源。

2. 流程管理在游戏管线设计中的要点

   • 流程标准化

     • 定义标准流程：为游戏管线设计的各个阶段建立标准的操作流程。例如，对于资源加载流程，规定先进行文件格式验证，然后按照一定的顺序加载模型、纹理和音频资源，最后进行资源的初始化和缓存。这样可以确保每个团队成员在进行相同任务时遵循相同的规范，提高工作效率和质量。
     • 文档化流程：将标准流程以文档的形式记录下来，方便团队成员查阅和学习。文档内容可以包括流程的详细步骤、输入输出要求、相关技术说明等。例如，在光照处理流程文档中，详细说明采用的光照模型、参数设置、数据传递方式以及与前后阶段的接口关系。
     • 流程培训：对新加入团队的成员进行流程培训，使他们能够快速熟悉游戏管线设计的工作流程。培训可以包括理论讲解和实际操作演示，让新成员能够理解每个流程环节的目的和操作方法。

   • 流程优化

     • 定期回顾流程：定期对游戏管线设计的流程进行回顾，寻找可以优化的环节。例如，分析资源加载流程中是否存在可以并行处理的部分，或者是否可以采用更高效的加载算法来缩短加载时间。
     • 收集反馈意见：从团队成员那里收集关于流程的反馈意见，他们在实际工作中可能会发现一些流程上的不便或者可以改进的地方。例如，负责后处理阶段的成员可能提出，目前与光栅化阶段的数据交接流程比较复杂，容易出现数据错误，需要进行简化。
     • 实施流程改进：根据回顾和反馈的结果，对流程进行改进。在实施改进措施后，要再次进行测试和评估，确保流程的优化能够带来实际的效果，如提高工作效率、减少错误率等。

   • 流程控制和监控

     • 设置流程检查点：在游戏管线设计的关键流程节点设置检查点，确保每个阶段的工作符合要求后再进入下一个阶段。例如，在几何处理阶段完成后，设置一个检查点，检查模型的顶点变换是否正确、法线是否计算准确等，只有通过检查后才能进入光照处理阶段。
     • 监控流程指标：监控流程的关键指标，如流程的执行时间、资源利用率、错误率等。通过对这些指标的分析，及时发现流程中的问题并进行调整。例如，如果发现某个流程的错误率突然上升，需要分析是因为流程本身的缺陷、新的输入数据导致的还是其他外部因素引起的，然后采取相应的措施来解决问题。

3.2 资产管理（数据）——data、metadata、assert

Data vs Metadata

• 数据data：.max 、 .mb 、 .hip 二进制文件，无法记事本打开
• 元数据Metadata：xml 、 json 、 yaml 等，可以记事本打开
• 摄影为例，Data 就是你拍的图像文件，Metadata是这张照片的 ISO、焦距、光圈、拍摄时的地点、曝光。

data的存放方式

• Data 通常会比较大，毫无疑问，是存放在文件存储系统，比如我们的硬盘、 NAS 、百度网盘、 P4V 、 SVN 、 Git 等等地方。
• 在视效行业，Data 文件的存储，基本采用 NAS 。
• 存储是影视公司的头等大事，它涉及访问速度、写入效率、快照系统、日志系统、权限管理、吞吐量、存储带宽、协议延迟、冷热数据分层、分布式存储等等，总而言之，不是简简单单的找个地方放文件就行了，是个很花钱的东东。
• 例子：
  要不是咱们公司咬咬牙买了 isilon，旧存储根本扛不住《上海堡垒》项目啊。
  为啥呀，多买几百块硬盘不就行了呗！
  咱们旧存储服务器相当于老式火车，车厢全靠火车头带，能挂载多少节有极限，不是想扩容就无限扩的；刚买的这个是复兴号，每节车厢都自带动力，想扩容多少都没问题。

data（进引擎之前）

• 进引擎之前的，就是.max 、 .fbx 、 .mb、 .spp 等等文件

• 管理软件有 P4V 、 Git 、 SVN 、Alienbrain等，以及，只存放在美术本地硬盘上… …

• 就算是使用了上述的存储管理，也并不是每个工程文件版本都上传的，大部分还是项目组强制要求，必须至少传一个最终版

• NAS
  每个美术，把 NAS 服务器映射为统一的一个盘符，比如 x:/ ,相当于美术插了一块“移动”硬盘，跟 D 盘一样。只是这块盘，每个人都有，而且都是同一个。
  影视的工具、Pipeline系统代码直接部署在NAS 上，把 NAS 上的代码文件更新了，工具就更新了
  
  影视行业最常用的，但 NAS 在游戏领域比较少 ，大公司是有一些 IT 安全方面的考量。

• P4V
  专门给游戏行业设计的。尤其是，如果引擎工程也使用 P4V 了的话，从美术角度讲，可以减少一个需要理解的系统。
  P4V 主打的版本管理，在 DCC 这里，它没用啊，二进制文件它 merge 不了，就算是非二进制文件，它也 merge 不了，你让美术去解决两个 sd 文件的冲突？美术打爆你的狗头

• 云储存
  类似百度网盘。

• SVN 、 Git
  主打版本管理，同P4V，二进制文件它 merge 不了，大文件他甚至传不了

data（进引擎之后）

• 游戏项目工程，必须必须必须选择一个有版本管理功能的软件，如 P4V 、 SVN 、 Git。

Metadata

• Matadata 则存在两种方式，以 json 或者 xml 文件形式，一般存放在它要描述的 Data 旁边。
  
• 命名规范
  规范命名主要的目的是，给资产文件提供一个全局唯一的标识。
  当我们提到一个资产的时候，就知道在哪里可以找到对应的文件。
  当我们看到文件的名字，就可以确定资产的位置和类型。
  有了规范的层级和命名，Pipeline 工具就可以自动化帮你上传下载、导入导出。
• Metadata 怎么记录
  最好是美术使用 Pipeline 工具，在文件被上传/同步到服务器上时，自动提取出来，自动上传到metadata 数据库里。

————————————————————————————————————————————————————————

assert

• 一个资产有不同组成部分，每个部分都有文件数据和元数据，海量的资产就组成资产管理系统。
  工程文件，我们取个代号叫 workfile：美术工作的文件，通常是 DCC 的 project file，比如 ma、mb、max、hip、 psd、spp
  图片或视频文件，我们取个代号叫 dailies：可以通过review 系统进行查看的文件，比如 mp4、mov、avi、png、jpg，如果 review 系统支持3d 资产查看，那么也可能是fbx、obj 等格式
  上下游交接文件，我们取个代号叫 element：比较“干净的”，通常是第三方格式，比如三维资产的 obj、fbx、abc、usd等，二维资产的 png、jpg、tga、exr
  

• 工作区 vs Publish区
  

assert 1-工程文件 Workfile

• 标准命名：美术仅提供文件命名的描述部分descriptor，命名的其他部分则由Pipeline 系统来完成。比如 goblin 的某个动画文件，美术需要提供类似walk这样的描述，则该文件会被自动命名为char_goblin_ani_walk_v001.ma，文件命名规范需要根据项目资产特点来制定。
• Publish（升级）：将 workspace文件进行升级，并上传到文件管理系统中。此处也需要上传适当的 metadata 到 Pipeline 数据库里，比如它的上个版本是谁，比如它依赖引用了哪些文件。
• Checkout（下载）：从文件管理系统中下载指定版本文件到 workspace下，原因可能是自己workspace删除了，或者是A的任务交给B做了，B需要从文件管理系统中下载A提交的文件。
• 版本回退：把文件回退到某个之前的版本，基于之前的版本继续制作。
• 质检：文件在publish之前，需要做一些检查，以防文件有垃圾节点之类的，造成文件打不开。
• workfile类型的文件，跟行业、公司、项目类型、环节，基本无关，Pipeline 系统可以轻松管理。

assert 2 媒体文件 Dailies

• 通常是视频或图片，体现工作内容，用于给导演、总监、主美、组长等进行 Review/监修/审查。
• 标准命名：一般跟对应的 workfile 名字一致。
  标准化图片、视频：统一的水印、分辨率、色彩转换、编码方式等等
  最好附带辅助工具，如三维软件拍屏工具、截图工具、录屏工具、拼图工具…
  publish 到 Review 系统中，并且记录该文件依赖的 workfile 信息到 Pipeline 数据库中。
• 此部分的工作，跟用哪个DCC，相关度很小，主要是跟 Review 系统有关。
• dailies 类型的文件 ，跟行业、公司、项目类型、环节，基本无关，Pipeline 系统可以轻松管理。

assert3 交换文件 Element

• 通常是第三方格式，用于不同DCC之间、不同人员、不同环节之间进行资产交换。
  影视的 DCC 除此之外还有：Hiero、Clarisse、Katana、Mari、ZBrush、Modo、SP、SD、Photoshop、Pftrack、SynthEye… …
  
• 导出：不同DCC的不同环节导出不同的第三方格式文件。记得要记录 workfile 的信息。
• 质检：很容易理解，我们不能把有问题的资产引入系统中。
• 导入：不同DCC的不同环节导入不同的第三方格式文件。
• 更新通知：当有新版本element导出时，可以通知到使用了此element 的workfile（的拥有者）
• 更新：有新版本element时，用户可以更新，最好是一键，同时用户也可以切换到任意旧版本element。
• 导入、导出的脚本是一对，最好也有版本控制，这样制作中途element有变动，比如参数不同了，旧版本导出脚本导出的element，可以使用旧版本的导入脚本进行导入，减少了脚本要各种兼容历史遗留的问题。
• 这个同时也是流程千变万化的主力部队，是跟行业、公司、项目类型、环节，大大相关。

assert 缓存文件 Cache

• 在影视，一般是一种自产自用的文件，比如把 houdini 一大堆的节点，解算出缓存，然后再导入回houdini 中，用结果继续进行节点连接。这种文件的特点是占用空间大，删除可再次生成，在项目结束进行打包的时候，完全不需要备份。
• 游戏还有一种 cache，中间转换文件，例如 fbx 导入八猴进行烘焙，再把烘焙出来的文件导入到 sp 等进行其他贴图绘制。
• 游戏行业制作环节大大缩减，一个人需要负责多个环节，比如有些项目动画师也得做绑定。需要我们帮助美术减少修改操作步骤，跨软件 Live Link 进行数据实时传递。

assert 关系

• element、dailies 都是从workfile产生的，那么有一个原则，只要有 dailies/element 一个版本，就必须保存产生该文件的workfile。
• element 会被别人（其他美术）用到，但凡涉及到文件被其他人“观察”了，就要保存其源文件，以便“还是觉得半个月前看到的那个版本更好”“我用的xxx版本是没问题的”时，可以找到源文件。
  
• 还有一点：只是导入engine 时，参数设置需要更新，那么 element不用重新出，只需重新导入engine 即可，如果导入时已经记录过了引擎资产<->element的关系，那么此时就可以对涉及到的引擎资产，自动化批量重新导入。
  

assert 资产浏览器

• 可以独立运行版的，不打开任何DCC、不开游戏引擎、暂时不用下载任何资产文件，就可以浏览资产的 Asset Browser！
• 当定位到具体的资产后，我们要展示这个资产方方面面的信息：
  查看它的原画设计
  它的模型、模型的工程文件最新是哪个版本
  总共提交过多少次 Review
  绑定是哪个美术做的，什么时间完成的
  它有多少面、有无骨骼、贴图几张
  它被放置在了哪些关卡，哪些位置，被放置了多少次，能在游戏地图中标识出来
  可以用DCC打开它的任意环节的工程文件（此时才需要下载该文件）
• 这里能做的事情太多太多了，一定要留有API接口，方便其他TA、TD，或者自己，随时新增更多功能，因为关于资产的所有信息都在，你可以对它为所欲为。
• 这个 Asset Browser，最好是可以在DCC（常用的DCC就是houdini，maya，max，cinema4D和blender等全能三维软件） 和引擎里打开；选中DCC 和引擎中的某个资产，可以获取该资产的详细信息；可以根据上下文和某些规则，比如是哪个城市，自动推荐合适的建筑物。发挥你的脑洞，发挥美术的脑洞。

————————————————————————————————————————————————————————

1. 数据（Data）管理
   • 数据类型与存储
     • 在游戏管线中，数据类型丰富多样。包括3D模型数据（顶点坐标、面片信息等）、纹理数据（颜色、图案等）、动画数据（骨骼动画的关键帧、蒙皮信息等）和音频数据（声音样本、声道信息等）。这些数据需要合适的存储方式。例如，3D模型数据通常以特定的文件格式（如.obj、.fbx）存储，这些格式定义了如何记录顶点、法线、纹理坐标等信息。纹理数据可以存储为.png、.tga等格式，不同格式在色彩空间、压缩方式等方面有所不同。
     • 对于大型游戏项目，数据存储的结构和策略非常重要。可以采用分层存储的方式，将经常访问的数据（如当前游戏场景中的角色模型和纹理）存储在高速缓存（如内存）中，而不常使用的数据（如备用的游戏关卡模型）存储在硬盘等大容量存储设备中。例如，在一个开放世界游戏中，玩家周围一定范围内的地形和建筑数据存储在内存中，随着玩家的移动，适时地从硬盘加载新的数据区域。
   • 数据加载与传输
     • 数据加载是游戏管线的重要环节。在加载过程中，需要考虑加载的顺序和速度。对于依赖关系明确的数据，要按照正确的顺序加载。例如，在加载一个带有纹理的3D模型时，先加载模型的几何数据，再加载纹理数据，并且在加载纹理数据时要确保纹理坐标与模型顶点的匹配。为了提高加载速度，可以采用多线程加载技术，同时加载多个数据文件。例如，在游戏启动时，使用一个线程加载角色模型，另一个线程加载游戏场景的纹理，从而减少总的加载时间。
     • 数据在游戏管线各阶段之间的传输也很关键。传输的数据应该是经过处理且符合下一阶段输入要求的。例如，从几何处理阶段传输到光照处理阶段的数据，应该是经过坐标变换后的顶点位置和法线方向等信息，并且要以一种光照计算模块能够高效读取的格式进行传输。可以采用数据缓冲区或共享内存等方式来实现数据的平滑传输，减少数据复制的开销。
2. 元数据（Metadata）管理
   • 元数据的定义与作用
     • 元数据是关于数据的数据。在游戏管线中，它提供了游戏数据的额外信息，用于更好地管理和理解游戏资产。例如，对于一个3D模型文件，元数据可能包括模型的作者、创建日期、模型所属的游戏场景类别（室内/室外）、模型的用途（角色/道具）等信息。这些元数据可以帮助团队成员在资产管理过程中快速定位和筛选所需的模型。
     • 元数据还可以用于游戏运行时的决策。例如，根据模型的元数据中记录的用途，游戏引擎可以在特定场景下选择合适的渲染策略。如果一个模型的元数据标注为“远景道具”，游戏引擎可以在渲染时采用较低的细节级别，以节省计算资源。
   • 元数据的存储与维护
     • 元数据可以存储在多种位置。一种常见的方式是将其与游戏数据文件关联存储，例如在文件头或专门的附属文件中记录元数据。对于基于数据库管理的游戏资产系统，元数据可以存储在数据库表中，与对应的游戏数据记录建立关联。在存储元数据时，要确保其格式的一致性和可扩展性。例如，采用XML或JSON格式来存储元数据，这样可以方便地添加新的元数据字段，以适应游戏开发过程中的新需求。
     • 维护元数据需要在游戏资产的整个生命周期中进行。从资产的创建阶段开始，就应该记录准确的元数据。在资产的修改、更新过程中，也要同步更新元数据。例如，当一个3D模型经过重新设计后，要更新其创建日期、修改记录等元数据信息。同时，要定期清理和整理元数据，删除无用的元数据字段，确保元数据的准确性和高效性。
3. 资产（Asset）管理整体策略
   • 资产分类与目录结构
     • 对游戏资产进行合理分类是有效管理的基础。可以按照资产的类型（如模型、纹理、动画、音频）、游戏场景（如城镇场景资产、野外场景资产）、功能用途（如战斗相关资产、解谜相关资产）等多种方式进行分类。例如，在一个角色扮演游戏中，可以将所有的武器模型归为一类，所有的城镇建筑模型归为另一类。同时，建立清晰的目录结构来存储这些资产，便于查找和使用。例如，在文件系统中设置“/Assets/Models/Weapons”目录来存储武器模型，“/Assets/Textures/TownBuildings”目录来存储城镇建筑的纹理。
     • 资产目录结构应该具有灵活性和可扩展性。随着游戏开发的推进，可能会增加新的资产类型或场景，目录结构要能够方便地容纳这些新内容。例如，当游戏添加了新的水下场景时，可以在“/Assets”目录下轻松创建新的“/Underwater”子目录来存放相关的模型、纹理和音频资产。
   • 版本控制与资产更新
     • 在游戏开发过程中，资产会不断更新和修改。采用版本控制软件（如Git、Subversion等）来管理资产的版本是非常必要的。通过版本控制，可以记录资产的修改历史，方便回溯和比较不同版本之间的差异。例如，当一个纹理资产经过多次颜色调整后，通过版本控制可以查看每次调整的内容和原因。
     • 对于资产的更新，要建立有效的更新机制。在更新资产时，要考虑其对游戏管线其他部分的影响。例如，更新一个3D模型可能会影响到与之相关的纹理映射、光照计算等环节。要确保更新后的资产能够顺利地融入游戏管线，并且不会破坏游戏的整体性能和功能。在更新后，要进行充分的测试，包括功能测试、性能测试和兼容性测试等。