|
|
国产游戏研发团队搭建自研体系经历了怎样的过程？目前我们的游戏研发技术在全球范围处于怎样的水平？腾讯光子工作室群近期在知乎上发起“国产自研游戏的发展之路”圆桌活动，本文来自圆桌议题“作为TA，如何改进流程工具，支持游戏美术更有效地进行艺术创作？”话题下的回答。
作者：Timmy
腾讯光子工作室群技术美术专家
在聊这个话题之前，先铺垫一下自己的工作经历背景：我是Timmy，来自腾讯光子工作室群，负责工具开发。来腾讯前，我曾在影视行业实习流程 TD 的工作，主要负责流程工具的搭建 Maya 绑定的技术支持。
进入腾讯之后，我负责开发各种 DCC 工具，其间先后参与了 Maya、3dsMax、Blender、Photoshop、Unreal 等软件的工具开发。一路走来，积累了一些在工具和流程向 TA 方面的工作经验，借此机会和大家分享。
TA的话题比较宏大，不同领域的 TA 视野也相差较大，本文章内容的观点主要站在工具和流程向 TA 的角度，如果哪里有错误的地方，欢迎指正。
上面的图片就是流传甚广的TA能力图谱。我的能力主要覆盖在侧边的Rigging、Tools、Pipeline 三个方向上，所以，下面就聚焦于这三个方向来聊聊。
作为 TA，如何改进流程工具，支持游戏美术更有效地进行艺术创作？
作为工具 TA ，我时常会自我调侃，说自己是美术爸爸的工具人。开发一个工具，美术只用一段时间，然后就再也没用过了...
但是，其实这些琐碎的问题可以抽丝剥茧地从更根源的地方着手，从而更高效地拿出解决方案。比如，我们来看这样一个实战场景：
实际项目过程中，我们会将很多美术资产发给外包团队处理，但有时候，可能因为沟通出问题，或是外包疏忽了，导致收回来的资源存在一系列的问题。
我曾遇到，外包发回来的资源没有按照项目规范中要求的方式来配置 Maya 的摄像机，导致输出的效果并不理想。还好，这种情况解决起来也不复杂，将摄像机的配置修改一下就好了。
然而，实际上出现错误的问题往往不止一个。如果人力去修复的话，一方面有可能会出现二次纰漏，另一方面有好几十个文件，修改起来非常浪费时间。这时候，我们自然就希望工具 TA 可以用代码批量修复这些问题。
所以，我当初先是快速地弄了个修复脚本来解决当前问题。考虑到不同批次文件采用的配置可能是不一样的，我还另外专门做了个修复工具，来修复文件。
然而，我花了很多时间做完之后却发现，这个修复工具并不能长期派上用场——因为这是针对当前情况定制的，下次美术外包可能又会出现其他问题，这个工具反而变得鸡肋。
作为工具 TA，如果我们只是做修复工具来充当救火队长，找不到问题的根源，那类似的问题还会大量出现，浪费大量时间。要想更好地支持美术团队，进一步优化工具，就必须找到——
一、问题的根源
剖丝剥茧，问题的根源有可能在美术和外包的沟通上。但是，有人参与的地方难免会出现纰漏，因此，自然会想到可以用工具来检查资源是否符合规范，以此规避人为疏忽的可能性。
工具本质上是一种基于固定规则解决重复问题，从而解放美术生产力的手段。美术规范也是规则，我们完全开发一套检查工具交给外包去用，在资源返回之前检查出问题，提前处理问题，避免问题资源流转到下游，倘若检查工具还附带自动修复功能，那就更省事了。
在制作检查工具时，TA 需要提前与美术沟通好相关资源的规范，可能涉及命名规范、路径规范、制作规范、性能规范等等，这需要良好的沟通以及丰富的项目经验。
当然，这个工具不只是给外包使用，也可以给内部美术使用，优化资源的发布流程。
找到了问题的根源，那么接下来就是——
二、解决方案
我在项目接入了开源的 pyblish 检查框架用来跑资源测试。
pyblish 分了 CVEI 四个流程 (Colleciton Validation Extraction Integration)
通过这套工具，文件如果不通过检查就无法正常发布，而这样就可以使美术修复文件的问题再流转，避免问题文件流转到后续的流程。
三、方案落地
在让新的工具方案落地时，需要尤其注意两点：
1、沟通成本问题。
虽然我在项目组，大多数情况下都是与团队面对面沟通的，但如果工具的使用者不断增加，那么对接本身也会十分费时，而且图标也最好加上中文注解，避免理解错误。如果在工具加上帮助按钮来跳转说明文档，也会省事很多。
有时候，这些文档也是给自己看的，工具太久没碰，作为开发者也可能会遗忘很多细节。
2、落地后的反馈与磨合
工具整理好之后要交给美术去测试，并听取他们的反馈意见。落地一个新工具和新方案，多少会让人抗拒，毕竟要改变原有的工作方式。因此清晰的文档和好的 UX 设计是非常重要的，这样可以减少沟通成本。
文档制作方法：可以用静态网站生成工具，比如：hugohexo mkdocs 去做，这样只要写 markdown 文件就可以生成网页。
四、问题延伸
有了工具之后，维护工具也是工具 TA 非常重要的日常。项目在发展，规范也在不断更新，因此工具也是需要与时俱进的。而这也逐渐引申出额外的问题，它们会切实影响到美术对工具的使用：
A、部署问题
解决部署问题，有两种解决方案：
1、共享路径，只要更新一处地方，大家都可以共享更新，但是网络波动可能会导致体验不好。
2、下载到本地，只要一次下载，后续不会有网络问题，但是本地文件可能会被修改。无论那种方式都需要一个工具去配置美术机器，共享路径会相对简单，只要将配置 UNC路径连接远程就可以了。下载到本地则需要有工具去下载和管理代码包，需要缓存来优化加载速度。
B、代码维护
如果时间允许的话，写单元测试是非常好的。
以前总是调侃自己不是在写代码，而是在写 BUG。但其实，如果有高度覆盖的单元测试，我们就可以通过单元测试来验证新添加的功能是否出现预期外的问题，比如：会不会因为修复一个 BUG引发了更多 BUG。
我们可以把遇到 BUG 的情况写成单元测试，每次发布之前都要确保单元测试通过，以此来降低 BUG 的出现概率。代码审查也是非常好的互相学习的机会，可以借此统一大家的代码风格。另外有经验丰富的人把关代码，可以规避很多坑。
在 Python 环境下也有很多工具可以辅助开发：
格式化代码可以使用 black isort；
检查代码可以使用 flake8 或者 pylint；
使用 commitizen 规范化提交信息；
可以配置 ci 流程，自动进行代码检查，避免遗漏。
C、工具依赖 和 版本回退
使用 rez 进行包管理。
rez 可以管理包的依赖和版本。使用 rez 的命令可以构建出一个隔离的环境规避美术机器自身的环境变量影响。另外“版本”和“依赖关系”配置在包的定义里。这样调度包的时候可以自动解决依赖问题，也可以更具需要回退版本。
思路拓展：影视流程的解决方案
其实上面提到的这些问题，影视行业同样会经常遇到。正因如此，影视行业早已有了很多成熟的解决方案。
比如说，使用 shotgrid、ftrack 之类成熟的流程平台，可以更好地管理上下游流程。
在成熟的平台上，美术甚至不用关心资源的存储路径，所有的流程都可以通过工具自动化实现。
在流程平台上配置好任务，美术只要在 DCC 中打开工具选择任务，工具就会自动将任务关联的资源打开，可以开始制作了。当制作完成之后，可以用工具进行发布，这个时候会自动更新到平台的数据，并且通知到上下游关联的人员。比如说，模型师做完了模型，会自动通知到主美来审核，审核通过之后，下游的绑定流程就会收到模型完成的通知，并且能够在相应的工具上获取到模型，开始工作。使用这些流程平台管理资产和任务会让整个制作流程更加自动化，平台承载的数据也让工具更加智能。
当然了，这些流程平台都存在不少的学习和使用成本，需要较多的二次开发才能更好支持游戏项目。很多项目已经有自己的一套工作模式，要切换到新的流程上，大都有水土不服的情况。要想克服水土不服，需要自上而下地推动这些流程落地。
文/Timmy
|
|
发表于 2022-6-23 09:26:33
