关于技术美术的一些个人理解

2011.7.21，凌晨蛋疼，遂更新了一下

技术美术是什么以及需要什么：

以我的了解，游戏行业的技术美术(Technical Artist)应该源于影视动画里面的技术指导或者叫技术总监（Technical Director）.此外还有R&D(research and development 研究与开发)这个往往和前面的技术美术或者技术指导的头衔搭配。虽然有技术美术和技术指导这两个职位，但要求却较为类似。大多数情况，技术指导是指有多年经验的美术，对于脚本的掌握只是可选技能，大部分是负责美术在日常生产中的软件、流程问题。技术美术相应的软件脚本例如MaxScript或Mel是必备技能，其他的脚本或语言例如Python、C#\C++之类作为可选技能，可以没有较长的美术工作经验，相比技术指导，技术美术的程序能力要强一些、美术工作经验可以很弱，负责一些工具的开发以及作为美术和程序之间的桥梁。二者只是分工定义略有不同没什么从属关系，而这个不同也是很模糊的。

至于技术美术需要什么，我个人认为，行事风格远比已经掌握了什么重要。所以，首先技术美术应当敢碰任何东西，只要是美术、图形和游戏的范围内，敢于学习任何领域的知识。这个听起来似乎简单，实际上不容易。可以看看周围，大多数人都是这么说的，但却不是这么做的。至于为什么要这样，因为在游戏的生产流程中会遇到各种杂七杂八的事情需要解决，可能要碰MaxScript，也许还需要碰Photoshop的JavaScript，没准还需要用Python或者C#处理一些常规的小问题，甚至于对已有的工具做些改动，当然最基本的作用还是作为美术和程序的中间层，负责双方的交流，做一个接口人，同样，为了做好接口人不得不去接触一些图形的概念，相关的数学概念以及游戏逻辑的概念。

其次，要喜欢做美术的工作或游戏，喜欢走全流程，从模型到动画、特效，当然能自己写一个游戏演示最佳，或者用已有的引擎写一个演示。在这方面美术和程序方面的技能不要求可以达到产品级别的质量，只要能粗略的做一下，了解到美术所用到的工具和技术也就基本差不多了。技能要求不高，但是要喜欢玩这些，也就是说需要有较高甚至极高的兴趣。为何需要喜欢玩这些？因为我认为，程序的工具经常令美术感到不好用的原因是，程序并非总是拿这些工具工作，所以他们考虑的是诸如扩展啊、灵活啊、稳定啊这些因素，可能美术最为常用的东西的方便与否反倒被忽略了。然后美术提出需求，递交给程序，然后程序一看，“哦，原来这个不好用，但是现在有更重要的工作要做，比如XXX漏洞，这个不好用的问题就先搁置一下吧”。于是，就被无限搁置了。如果说技术美术，只是会写一些脚本甚至说就是一个专业的程序，但是他平时并不用美术的工具，那么事情就还像原来一样，并不会有什么改善。在此时技术美术就充当了一个美术工具用户体验设计者的角色。而这个角色理想情况下是具有开发工具的的能力的。于是最佳状况就出现了——使用者即开发者。

此外还有一个很重要的原因就是，如果是一个完全不懂程序的人去和程序沟通问题（比如要为工具新增加一个功能），程序往往会直接回绝。其实道理也很简单，如果你不懂，很有可能我给你解释半天你依旧不懂，然后我的解释你也听不进去，为什么听不进去，因为不懂。所以理想状态下（比如每个程序会耐心解释一切问题,并且美术也会尽力去弄清楚）或许技术美术不需要懂程序，但现实是如此无情，这种耐心解释的状态有很大风险，因为极有可能耗费很多时间而徒劳无功（此时美术同学也不必觉得程序同学太***，如果有个人问你Max能做什么之类的问题，想想自己能耐心多久），所以程序知识就成了技术美术的必备条件，硬性技能、不可或缺。这里我可以举一个例子，曾有一个朋友需要一个Maya的插件，但是那个插件没有32位的版本。所幸作者是国人，并且放出过源文件下载，于是他就去找作者想要一个32的版本，作者直接回绝了他。然后这位朋友找到了我，我下了源码之后发现需要一些库的设置，然后我去找了作者询问，作者很爽快地告诉我，那些代码已经被舍弃，如果我需要某个版本的插件，只需要将相应的MayaSDK的文件发给他，他会编译一份发给我。很多时候就是如此，哪怕是稍微知道一丁点，都会对你和程序的沟通大有帮助。

此处插个题外话，我近期的工作中发现，很多时候，美术从没想过自己可以对游戏的视觉上做出多大突破。而实际上这种突破是需要美术切实参与的。我举一个最为明显的例子。动作，尤其是Max当中，Max有简单方便的CS，所以很多人不去了解骨骼的基础，导致了自己对骨骼和动画的理解就很粗陋，比如常见的Ik导致的颤抖、Gimbal导致的轴向变化，缩放导致的子物体的形变，会不知所踪，然后甚至会以为是软件的问题。如果要跟程序去解释需要什么功能，也解释不出来，比如说街霸中的DHALSIM，可以将手脚拉长，而Max当中默认情况，在单一轴向缩放会导致其子物体旋转时发生形变，Max本身可以取消子物体的缩放继承来防止出现此问题。一些动画人员不知道该问题原因何在，连去跟程序提需求都不知道怎么提，彻底无法交流。这种情况下如何能在动画上有所突破？很多美术，只希望程序提供一个规范，然后自己就按部就班完成，坦白说，我认为如果持续这种意识形态而不改变，这辈子恐怕是难有突破了。

技术美术是很难寻找的，据我所知大部分业内的技术美术都是只会几句脚本的美术，包括一些业内知名公司，程序方面的技能可以达到比肩工具程序员的人很少。而达到这个级别或者说接近这个级别的技术美术又很难留住，第一，如果他是为了赚钱，那么去做游戏程序更有发展空间；第二，如果他是追求技术，从自己的兴趣爱好出发，程序也很容易在他的方向中占据很大的比例，最终很有可能被带上纯程序的道路。偏向独立游戏开发者的技术美术比较容易保持本色，但也很容易因为自己的兴趣，转成真正的独立游戏开发者，最后脱离团队。但这些并不是问题，前提是，团队里的美术有喜欢研究技术的气氛，有研究精神。我一直认为，对于团队或者公司而言，人来人往不是坏事，只要研究能够积累，精神能够延续。此种气氛比招聘几个顶级的技术美术都要重要，若没有这个气氛，找来再多的人，也无济于事，因为美术和技术美术之间隔阂的消除、信任的建立，很困难。如果在这种情况下，技术美术很容易被孤立，依旧留不住。所以，与其想招聘技术美术留住，不如花更大的精力去培养美术的研究气氛，若无此气氛，即便有技术美术留下，一来起不到最佳作用，二来很有可能是混日子的菜鸟。

此外技术美术被很多人当作一个程序，这种想法是错误的，首先他是一个喜欢美术的人，可能未必喜欢拿这个当工作，但起码是能以做一些东西而自得其乐，在这个基础上他喜欢研究技巧，研究基础知识，紧跟技术变化。当然可能因为这些原因导致他在程序上越走越远，但不代表你应该把他当作一个程序。

这里我可以举一些我的例子，我喜欢研究骨骼绑定，所以我才做了这些，而不是因为我喜欢搞开发才做了这些玩意。