您现在的位置是:首页 >学无止境 >闲聊游戏美术工作者的自我修养网站首页学无止境

闲聊游戏美术工作者的自我修养

阿赵3D 2024-06-17 10:48:31
简介闲聊游戏美术工作者的自我修养

  大家好,我是阿赵,这篇文章主要是聊一下我对游戏美术工作的一下看法,文章有点长,估计没什么人有耐心看得完。
  对我有所了解的朋友,应该知道,我大学刚毕业的几年,做的是美术工作,3D建模、画贴图、K动画、录音混音、后期合成等等,都做过。后来才转了程序。有朋友很好奇我是怎样从美术转程序的,所以我也曾经写了一篇文章介绍过,这里就不再详细说了。
  由于我做过几年美术,所以对于美术同事们的思考模式和心态我自认还是比较的了解,所以虽然后来做了一个程序员,但和美术同事合作一直都没有什么隔阂。
  在十几年的游戏行业里面,我合作过很多不同的美术团队,见过好的,也见过非常糟糕的。这里我想结合一下自己的一些亲身经历,说一些我个人认为比较值得注意的地方。

一、心态要摆正

  由于美术素材是最直观表现在玩家面前的东西。从玩家能看到的画面里面,100%都是美术的素材。玩家看不到策划文档,玩家看不到代码。
  所以有时候美术工作者会有一个游戏的成败都取决于自己的错觉,总是想通过美术的方式去解决很多问题,亲自动手去修改很多自己觉得不合理的地方。
  如果一个美术工作者产生了这种想法,实际上是心态已经出问题了,因为他觉得,一个游戏里面的内容都是美术做的,策划只是在讨论设计方案的时候给点意见,程序技术只是在美术的指导下把美术素材放到该放的地方而已。
  其实有这种错觉也很正常,特别是用Unity这种比较偏美术策划使用的游戏引擎。完全不懂技术的美术人员,用Unity引擎也能很快的用美术素材堆砌出一个看起来挺不错的Demo,所以很容易给人一种自己无所不能的错觉。
  但真实情况是,一个游戏由众多的岗位人员一起合作开发出来,虽然看到的都是美术素材,但实际上这些美术素材都是在策划的规划中,由技术人员通过各种代码框架,各种性能优化技术方案之后,才把经过特定方式处理的美术素材放到该放的地方。而这些策划的规划,还有程序的框架设计和优化,都是纯美术工作人员所不具备的知识。就像大部分策划人员虽然有想法,但不会实现,大部分程序技术虽然有搭建世界的办法,但却没有画出一张贴图的能力一样。每一个岗位都有他需要做的事情,都有该自己思考的部分。
  所以,谁都不是救世主,不要太紧张。

二、重视技术美术岗位

  很多游戏美术工作的领导者,比如美监、主美等级别的人员,都是纯美术出身,最常见的是原画师。
  我一直很赞同这种情况的,因为作为美术工作的指挥角色,在审美方面必须要有过人之处,必须有自己擅长的风格,技术好学,艺术难学。在体现美术修养方面,我个人认为,原画师的确是最容易体现水平的。
  以前我做美工的时候,很多3D模型师、动画师是培训班出来的,包括我自己也是。虽然技术上可能比较过关,要对着原画建个模型、k个动作什么的完全没问题,但可能连一张像样的画都画不出来。我觉得这种情况下,技术好的人可以做对应的工种,但并不适合用来把控整体的美术风格。在这种情况下,我觉得美监、主美级别的人,其实是不需要在某些方面的技术非常熟练的,比如他可能不会建模型,不会k动画,不会做特效,但他能把控整体风格,我觉得是OK的。
  那么问题来了,既然美术的领导岗位可以不懂技术,那么谁来懂技术呢?遇到问题的时候,谁说了算呢?这时候技术美术(TA)这个岗位就出现了。
  这里经常会出现一个误区,从纯美术游戏工作人员的角度看,技术美术是什么?不就是个写Shader的人吗?平时也没什么工作,遇到有些效果网上抄不到的时候,就叫TA去帮忙写一个效果,不就是这样吗?如果真的是这样想,那么这个美术团队就不要做游戏了,可以转行去做效果图或者影视方面的工作了,不然很快就会解散。
技术美术的工作包含了很多方面,比如:

1、根据需求制定整个游戏渲染的大框架,比如是使用什么渲染管线,使用什么样的颜色空间
2、定制美术资源的标准,比如根据项目的定位和设备的适应情况,定制3D模型的面数标准、骨骼标准、贴图大小和数量等
3、指定每一种特殊效果的制作方式,使用什么样的技术去实现特殊效果,这里不一定是写shader,比如一个特效,可以用粒子做,也可以用Animation做,用多少个摄像机去叠加,最后决定用哪种,或者自己做一种新的实现方式出来。
4、写Shader。这个是大家比较熟悉的部分了,不过很多美术团队都习惯去网上抄Shader来改,所以虽然觉得这个部分是TA的主要工作,但其实也可能没TA太多事情,当然这样的想法是不对的。
5、制作各种美术辅助工具,包括了写3D软件的插件、Photoshop的插件、Unity的插件,等等
6、直接制作某些方面的美术资源,比如场景灯光烘焙,需要用到比较复杂的烘焙参数设置,并且需要反复试验才能得出结果的。
7、检查各种美术资源的性能问题 8、等等

  综上所述,如果一个游戏美术团队有一个或者多个TA同事,我感觉他们不可能会没事做的。
  说到这里,可能有部分主美会有意见了,这些事情在没有TA的时候不是也照样做吗?
的确,有很多纯美术团队,到现在都还没有一个合格的TA同事。这些情况,要么是外包公司,所有的技术规格在发外包的时候已经指定好了。要么就是暂时还能支撑。
  为什么说暂时还能支撑呢?那是因为,各个岗位有经验比较丰富的人员在支撑,是凭着自己的经验去做事情的。比如高薪请一个特效师,有十年大厂工作经验,号称能解决特效大部分问题。
  什么是经验?就是在遇到一个问题的时候,我在上一个项目是这样解决的,我在这个项目用同样的手段去解决,应该就没问题。至于为什么要这样处理,其实不知道,或者只知道个大概。
  经验是一把双刃剑,在遇到熟悉的情况时,能快速的解决问题。但如果情况发生变化,条件已经不同的情况下,同样的技术手段可能解决不了。这个时候,就不能凭着经验来做事情,而需要懂原理的人来制定方案,TA正是这样的岗位。
  所以,这也是心态的一部分。不论主美也好,模型师、动画师、特效师等等都好,不要太在意面子和经验,要相信专业的人士,在遇到原则性技术问题的时候,一定要咨询TA,并由TA选择解决的方案。
  这一点都不丢人,并不是说,作为一个主美,或者一个资深的美术工作者,好像所有事情都要TA去决定,自己会没面子。其实TA虽然做了方案,但他画的图也不见得比你漂亮,做的动画也不一定有你生动流畅,只是各司其职而已。

三、各种规范要从细节开始养成习惯

  举一个和细节习惯有关系的小例子,不是为了贬低美术工作者的习惯,只是说明一个思维习惯问题。
  在几年前有一段时间,很多公司都流行起用Photoshop做界面,在PS里面美术同事根据图层来做分层,然后根据给图层做各种的命名来指定UI组件的属性,然后写个插件导入到Unity引擎直接生成UI界面预设。这个做法在我的公司也试过,毕竟不是很难的技术,写个脚本就能实现了。
提出这个解决方案的人的理由是,美术工作者不会用Unity,但基本都会用Photoshop,而且非常熟悉Photoshop,所以如果在Photoshop里面做界面,肯定会轻松简单很多。
  实际上我遇到的问题是,美术在用Photoshop拼图层作为界面的时候一点问题都没有,拼得挺好看的,但却经常会因为打错了字,大小写错了,多了个符号,少了个空格之类,导致生成出来的UI预设有问题。这些东西都不是很难,美术同事也都教得会,但出错的几率还是比较大,虽然可以写脚本去检查语法,但也防不住各种可能的出错,而且如果换个新人接手,又是一场时间不短的灾难。
  在我十几年的游戏工作经历里面,最成功的UI制作方案并不是用Photoshop做界面,而是在页游的时代,公司自己根据项目情况,做了一个UI编辑器,各种能使用的UI组件、列表都可以美术自己拖上去并生成代码。这样的编辑器,出错率低,效率高,才是理想的。
  回过头来看,这样的编辑器在Unity里面本身就已经自带有了,我们在场景里面建画布,拖各种控件到画布上,分层,直接选择对齐方式,然后我再写个工具,把场景转换成UI预设,并直接生成UI代码,不是挺好的吗?美术人员连这么复杂的Photoshop都能学会,难道学不会这么简单的Unity拼UI功能?这其实只是一种先入为主的抗拒学习心态而已,在多年前Unity只是一个比Cocos或者Flash知名度都低的小引擎时,作为美术工作者不想浪费时间学习Unity操作很正常,现在Unity已经变成了最主流的手游研发引擎了,学一学我觉得并不过分。
  所以使用Photoshop做界面导入Unity的方案,没用多久就被我否决掉了。原因很简单,美术工作人员缺的不是技术,而是各种的规范细节,Photoshop可以帮他们解决的只是技术方面的问题,没办法解决规范的习惯问题。
  这个说法可能会让很多美术工作者觉得难以接受,但这是事实。因为美术工作本身是一件很感性的事情,我画一张画,追求的是效果和意境,我会愿意花10个小时精力去画好一幅画,但可能不会花2秒钟来想一个合理的文件名来存储他,如果之前有一张叫aaa的图,那么这次就存一个叫aaa2的文件就差不多了。我认为美术工作者有这样的思维习惯是很正常的。如果程序敢因为我命名了aaa2而说我,我肯定会骂回去,我的画这么精美你不夸我就算了,就因为一个名字来说我,至于吗?
  但我们正在讨论的前提是,我们要做的是游戏引擎的美术资源,那么对于一个文件,他的命名规范、大小写、存放的文件夹、文件类别的分类、使用的单位、中心点的对齐方式等等,都是必须一丝不苟的按照规定去做,毕竟程序是理性的,只要你错了一点点,都有可能加载不出来的。你总不希望自己花了10个小时的图,因为被命名为aaa2这么简单的原因,就不能使用了吧?

四、不能只看表面

  在项目里面发现出问题了之后,最常听到的一句话就是,“在我的电脑上是好的”,这句话程序员也经常说,其实美术人员说得更多。
  比如一个模型放进去战斗场景之后,看不到,模型师说,在我的电脑看是好的,然后把模型预设截图为证。进一步检查,发现模型只有0.01米高,被草丛遮住了。做模型的时候缩放单位错误,是很常见的问题了,虽然一说出来大家可能都会说这是常识,但还是不停的有人犯错。
  再比如,加载了某个场景之后,游戏帧率从60fps直接降到了10fps。然后场景美术说,我没看出来场景有什么问题啊?然后查了半天发现,里面每棵树有几万面,放了个森林,而且每棵树的网格上还挂了碰撞体。非功能性模型不能挂碰撞体,尽量不要用Mesh碰撞,高面数的Mesh碰撞体会导致严重掉帧,这些问题一说出来,大家又会说是常识了,但还是不停的有人犯错。
  再比如,某个特效在打包到手机上时,显示错乱了。然后特效师又会截图为证,我在Windows的Unity编辑器下是显示正常的啊。又查了半天,发现特效师偷偷的从网上下载了个不知名的Shader,里面写了一堆乱七八糟的宏,导致在某些手机上不支持。
  不会写Shader其实不犯法的,也不丢人的。但乱用Shader,到了项目上线之后,你可能就有机会体验各种的突发抢险修查Bug修Bug情况了。所以我一直不建议在自己不了解的情况下随便在网上抄一个Shader来用的,假如出了问题,自己可能根本没有能力去解决问题。
  综上所述,在游戏引擎里面,很多需要注意的细节,并不像做装修效果图,或者影视动画一样,只要渲染出来的图看着没问题就没问题了,里面还有很多值得研究的地方。所以,还是需要一个靠谱的TA。

五、丰富自己的实现手段

  在游戏里面,要实现一种效果,往往有不止一种手段。
  比如我要做一个过场小动画的效果,可以用Unity的内置Animation来k动画,可以用Timeline来做动画,可以用第三方的剧情插件来做,也可以自己写一个控制播放器来做。方法有很多,但不同的方法有自己的利弊,可能并不适用于所有的情况。如果只会一种手段,那么到了这种手段不能用的时候,怎么办呢?
  比较常见的情况是做特效。对于有些特效师来说,特效就等于粒子系统。就算是简单放一张图片上去,他也用粒子,只是把发射数量变成1,然后持续时间接得上就行了。然后如果要显示几张图片按顺序显示,也是套几层粒子发射器,一个触发一个,每个就发射一个粒子。
其实大可不必这样的,一个粒子系统看着无伤大雅而且功能强大,实际上你用到里面的功能可能连1%都没有,但你也要创建一个完整的粒子系统,走它的生命周期,占用所有发射器属性的内存,只是为了渲染一张图片,两个三角形?直接拖个面片上去多好,如果要多个出现,K一个Animation上去也是一样的。如果要叠加的透明方式,在网格渲染或者UI上面挂一个指定Shader的材质球就可以了。而且粒子系统有时候不适合用,比如放在UI上面的特效,如果用粒子做会有层级叠加的问题,如果直接用图片做,就没有问题。
  同样的问题也会出现在其他美术岗位上,比如动画,2D动画可以是序列帧动画,Spine、龙骨,3D动画可以是骨骼动画、顶点动画,动画融合的手段也可以根据不同的动画来实现。批量渲染可以是静态合批、动态合批、GPU Instancing 、SRP Batcher等。
  所以不能一招鲜吃遍天,在业余的时间,还是要多研究一下同样领域中各种不同的技术,让自己多一些选择。

六、沟通很重要

  这好像是一句废话。但实际上还真的很多人都不喜欢沟通。
  举个亲身经历的例子,策划给美术下了一个单子,需要做一个新功能的地图,附带策划文档。周期是5天。美术接到单子之后说没问题。大家相安无事到了第4天晚上,策划过来问地图做得怎样了,然后美术给出了一张完整的高精度设计图,告诉策划提前了一天完成了。结果策划一看,设计方向完全错了,时间只剩一天了,推翻重做似乎来不及了,不推翻?那就只能硬吃下去,根据错误的设计来改策划文档了。
  为什么会出现这个尴尬的局面呢?实际上美术团队内部设计这个地图,也是经过了讨论,草图,再讨论,修改,再修改之后,才给策划看的。那为什么不在草图阶段就直接给策划看呢?然后每一个讨论修改的过程,也让策划参与进去呢?这样可能会在过程中消耗一点时间,但起码大方向不会错。
  有些美术团队可能是这样想的,如果我给你看草图,你是不是会认为我画的水平很低?不如我画到自己满意为止,才给你看,让你觉得我水平不错?其实大可不必这样,就算是非美术人员,作为一个游戏从业人员,最起码应该也知道草图的含义是什么,不会因为看到草图就认为水平低的。
  从思维习惯来说,纯美术人员思考的方向和策划人员思考的方向是会有偏差的,因为美术人员从整个美术表现上去看,会自己定一些重点表现的地方,和一些不足的地方,并且根据美观程度去强化重点,弱化缺点。但这些重点和不足,只是美观上的。而从策划的角度看,有些信息加上去之后,的确会变得不好看,但这个信息却是游戏玩法的核心内容,就算不好看,也得加上去。
  这种矛盾不是没办法解决,但需要多方面的沟通,互相迁就和妥协,才能得出一种较为满意的解决方案。
  所以美术人员在项目里面看似很独立,经常一个美术团队就关着门在一个房间里面。但实际上,美术团队需要沟通的地方很多,需要和策划沟通思路方向,需要和TA讨论实现方案和技术标准,需要和程序技术对接资源使用方法,等等。

  废话说了一大堆,也不知道对不对,如果各位有兴趣也可以讨论一下。

风语者!平时喜欢研究各种技术,目前在从事后端开发工作,热爱生活、热爱工作。