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