首页 > 代码库 > 【转载】关于技术美术的一些个人理解
【转载】关于技术美术的一些个人理解
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本身可以取消子物体的缩放继承来防止出现此问题。一些动画人员不知道该问题原因何在,连去跟程序提需求都不知道怎么提,彻底无法交流。这种情况下如何能在动画上有所突破?很多美术,只希望程序提供一个规范,然后自己就按部就班完成,坦白说,我认为如果持续这种意识形态而不改变,这辈子恐怕是难有突破了。
技术美术是很难寻找的,据我所知大部分业内的技术美术都是只会几句脚本的美术,包括一些业内知名公司,程序方面的技能可以达到比肩工具程序员的人很少。而达到这个级别或者说接近这个级别的技术美术又很难留住,第一,如果他是为了赚钱 ,那么去做游戏程序更有发展空间;第二 ,如果他是追求技术,从 自己的兴趣爱好出发,程序也很容易在他的方向中占据很大的比例,最终很有可能被带上纯程序的道路。偏向独立游戏开发者的技术美术比较容易保持本色,但也很容易因为自己的兴趣,转成真正的独立游戏开发者,最后脱离团队。但这些并不是问题,前提是,团队里的美术有喜欢研究技术的气氛,有研究精神。我一直认为,对于团队或者公司而言 ,人来人往不是坏事,只要研究能够积累,精神能够延续。此种气氛比招聘几个顶级的技术美术都要重要,若没有这个气氛,找来再多的人,也无济于事,因为美术和技术美术之间隔阂 的消除、信任的建立,很困难。如果在这种情况下,技术美术很容易被孤立,依旧留不住。所以,与其想招聘技术美术留住,不如花更大的精力去培养美术的研究气氛,若无此气氛 ,即便有技术美术留下,一来起不到最佳 作用,二来很有可能是混日子的菜鸟。
此外技术美术被很多人当作一个程序,这种想法是错误的,首先他是一个喜欢美术的人,可能未必喜欢拿这个当工作,但起码是能以做一些东西而自得其乐,在这个基础上他喜欢研究技巧,研究基础知识,紧跟技术变化。当然可能因为这些原因导致他在程序上越走越远,但不代表你应该把他当作一个程序。
这里我可以举一些我的例子,我喜欢研究骨骼绑定,所以我才做了这些,而不是因为我喜欢搞开发才做了这些玩意。
我因为喜欢玩特效所以才做了这些,并非是因为我喜欢搞开发。
同样,因为我喜欢三维动画,所以我拿到KinectSDK之后才会首先做这样的东西
http://i.youku.com/u/UMzU2MTI5NDI0
我也喜欢做模型,只不过确实不出色,这个就和代码完全无关了。
我认为,如果你将技术美术当作程序看,是一个很危险的信号。绝大多数人去学MaxScript或Mel、MayaPython都不会是因为想成为程序,他们都只是想让自己方便一些,或者少受一些软件现有功能的约束,同样软件也正是明白现实中的需求多种多样,无法全部满足,所以才会提供了脚本和SDK。
把他们当作程序,很容易让他们真的变成程序,脱离美术。这是最大的悲哀。
我在工作之后也没做出什么自己能认可的,可以拿得出手的东西,或许是悲哀中的悲哀,啊哈哈哈哈
【转载】关于技术美术的一些个人理解