PM如何改变艺术制作:AAA游戏案例研究

免责声明

在担任项目经理期间,我经常听到这样的评论:"我们为什么需要项目经理?他们到底做什么?他们只会说话,仅此而已。"这是一个相当普遍的看法。

因此我准备了一篇文章,讲述项目经理实际上能做什么(与他们的团队一起),以及这些工作对项目的影响有多大。就像我们项目经理和制作人喜欢的那样——用数字、表格和图表说话。文章包含三个部分:美术流程、日常流程优化和JIRA礼仪。

这个案例来自我的个人经验,重点讲述我们如何在一个AAA项目中从零开始建立装饰品部门,并最终优化美术制作,将速度提升了3.3倍。

非常感谢。祝阅读愉快。

美术流程

案例

我以项目经理的身份进入制作部门时,接到的任务是:建立一个装饰品部门,为战斗通行证和游戏内活动提供皮肤(以及更多内容)。

与此同时,我们已经有了一个角色美术部门。他们创建了八个处于不同完成阶段的角色,以及一个带有几何变化的高级皮肤。制作那个单一皮肤花了美术师16个月的时间。

我的任务是建立一个运作良好的制作流程,并在发布日期前完全满足发行商的要求:21+个带有新几何体的皮肤和40+个重新着色版本。之后,我们必须每月发布7+个不同类型的皮肤——而在接下来的一年里,这些数字要翻倍。

工作

首先,我分析了以前的经验和当前网格(角色和皮肤)的制作速度。利用Jira的数据和大量Excel表格,我们识别出几个薄弱环节。

美术制作路线图

总体上没有角色美术制作的结构化路线图,特别是装饰品方面。网格被视为角色开发流程的一部分,所有与之相关的工作都被放入三个大阶段——L0、L1、L2——从原型到最终精修版本。每个超大任务都可能超出冲刺长度,不仅是两个周期,有时甚至是三个或四个周期。

缺乏标准

每个网格都被当作研发功能对待。当我们比较不同案例中的L0/L1/L2阶段时,我们发现它们花费的时间完全不同——包括净时间(记录的工时)和总时间(从任务创建、移至"进行中"到标记为"完成"之间的间隔)。即使是相同类型网格的任务数量也有很大差异,其中一些任务的描述几乎无法理解。

一个突出的问题是:分配到任务的一位美术师从头到尾负责整个网格(从分配历史记录来看)。在制作过程中,没有逻辑节点可以让他在不损失质量或时间的情况下将工作移交给其他人。整个任务看起来就像一个巨大的、连续的工作块。

流程缺乏透明度

开发过程中发生了什么或如何进行都不清楚。任务更新的质量和一致性完全取决于开发人员自己。除了早晨的站会外,没有办法远程跟踪进度。如果美术师生病了,主管可以部分接管他们的任务,完全不留任何笔记,然后就结束它。

迭代次数

即使从基本的状态历史记录中也能明显看出,任务进入审查,然后返回,再次进入审查,然后又返回工作。更不用说完全没有评论解释为什么任务被退回工作然后又重新提交——一个字都没有。

我们与小圈子的核心成员聚在一起——我自己(作为项目经理)、首席美术师和美术主管——开始工作。

解决方案

首先,我们做了两个重要的高层决策,以停止顶层的混乱。

我们引入了等级

在此之前,项目中充斥着各种术语和标签:重新着色、涂装、皮肤、高级皮肤、老兵等等。每个词都指代不同类型的工作,这只会让我们更加困惑。我们放弃了所有这些,并引入了一份文档,清楚地概述了皮肤及其等级之间的差异。

"一个皮肤=一个史诗=一个分支"规则

我从角色开发团队借鉴了这个组织规则。一个史诗包括开发方面与皮肤相关的所有工作。每个史诗包含一个分支和一个专门用于该皮肤的拉取请求。反过来,史诗被链接到相关的赛季(或活动)计划/功能,以便更容易导航。

这是我们的起点。从那里开始,我们重建了整个工作流程。

我们摆脱了L0-L1-L2

相反,我们根据实际制作逻辑划分制作:设计→几何→纹理→实现。

每个阶段都被分解为更小的逻辑步骤,例如:\n概念:情绪板-2D草图-3D草图(如果需要)\n几何:低精度-高精度-FBX文件导入\n实现:绑定-游戏设计设置-美术审查-质量保证

皮肤本身也被分为三个部分:身体、武器和模组。这意味着从那时起我们可以有三个独立的任务,例如:\n身体-几何低精度,\n武器-几何低精度,\n模组-几何低精度。

这将以前的单一巨大工作块转变为类似乐高的构造器,可以根据美术师的工作量在他们之间分配。现在可以准确跟踪制作当前处于哪个阶段。

新的美术制作路线图

本质上,我们上面所做的一切都被列为一系列行动。这张图表帮助我们——以及任何可能需要在我病假或休假期间替换我的项目经理——了解在哪里以及哪些流程可以并行运行以节省时间。

史诗和任务的统一格式

史诗现在只包含严格与皮肤等级相关的任务——没有多余的内容。

每个史诗在其描述中都包含皮肤的概念,以及制作人的验收标准。

这减少了混乱,让美术师清楚地了解每个阶段的期望。(后来我们进一步完善了任务描述,但那涉及日常流程的主题,接下来会讲到。)

我还在Confluence中设置了一个独立的部分,其中有一个Mira板,列出了每个任务的所有这些描述,并附有项目经理的注释,解释何时以及应该创建什么任务,以及可以简单地复制粘贴到任务主体中的Jira公式。

估算

我们试图分解任务,使其易于规划。项目使用两周的冲刺,所以我们旨在找到一个共同的结构:在不过多超出边界的同时,仍然为每个任务提供一个逻辑完成点。

非常感谢我的同事们——没有他们的经验,我们无法如此精确地分解。仅依靠Jira数字会困难得多,因为在美术制作中,个人专家的技能很重要,在设计估算时,我们必须在我们能实际交付的内容和我们想要实现的目标之间找到一个黄金中间点。这就是我们得出的公式:一个开发步骤=一个冲刺加两天,最多如此。

现在美术师可以看到他们每个任务有多少时间,以及离完成还有多近。通过适当的沟通,这成为了一个支持工具。如果美术师看到他们还剩三天完成任务,但知道自己完不成——他们可以主动告诉我。

这意味着我不必"控制"开发人员;他们拥有帮助我的所有工具,并在我们可能错过截止日期的地方发出红色警报。

结果,我们实现了开发人员自主权。打开史诗时,美术师发现了一个准备好的、完全准备好的任务,他们可以立即开始——即使他们一开始不完全确定该做什么。我们使审查会议和评估标准透明化。

结果

直奔主题。仅数字。

这就是案例。

\ \ \