《小白大作战》设计中的血泪教训

发表于2015-05-01
评论0 1.7k浏览

前言

  小白居然是一个产品,启动这个项目并代号为小白时,觉得既亲切又疑惑,不知道是褒义还是贬义,当时理解为:可能是因为团队都是做客户端的,首次在web应用的sns这个领域摸索的小白s。现在回头看美术的尝试阶段,还挺小白的;这里就根据小白的性价比来揭秘一下所走的弯路,甚至有些是优化后还不直的路;希望大家在看别人“仆街”过的地方同时又有少许收获,最好可以给建议拉一把:)

  下图就是现在的小白,清新可爱角色扮演的回合制PK,(清新可爱是我们自己说的,别往心里去)。



角色采用3D渲染系列帧、场景直接分层手绘、特效flash矢量的联合制作方式。
  有人会问,搞个sns小游戏还用3D渲染这么费劲,要画原画又要做模型,还要调动作输出,市面上几乎都是flash ps直接2条龙搞定,这个拿当时参与制作的几个美术来说:没优势,都是做客户端采用32的制作经验,手绘系列动画、flash都不擅长。自我安慰这种制作方式搬到sns上可能会有细分市场,就这样按照传统客户端的制作模式开搞了,原画尝试主角怪物,场景原画出概念找参考,3D开始建模之类的•••••


目录

[隐藏]

·         1 1.角色部分

·         2 2.场景部分

·         3 延伸阅读

·         4 有感而发,我说两句(请选择“编辑”)

 

[编辑] 1.角色部分

  

  每个游戏的前期都不例外,3D角色方面除了风格比例五官不断调整PK之外,渲染方式也会尝试多种,小白先是想迎合市面上sns比较卡通手绘的感觉,开始尝试沟边的卡通渲染;下图是巴西的卡通材质及MAX自带的ink材质



也许是用来调试卡通渲染的角色配饰细节比较多,颜色过于饱和,出来的效果不理想,要么沟边到处扣得很紧,要么有锯齿,磨了好久没找到平衡点,时间也不允许磨蹭,索性把属于我们自身技术的含糊推卸给渲染器不给力,心安理得用回普通的渲染方式,就把小白搞成这样:



渲染方式定下来了,渲染的大小尺寸还没定,这种32的方式,图越小越不好表现,美术自私的要求角色渲染要大,五官,衣服上的细节才好表现;空白区域也要大,将来大动作大武器才有施展的区域,就这样小白输出尺寸是440x440,



还不知渲染大尺寸大带来后果的情况下,就先这样敲定了;接着就是考虑avatar的装扮问题,希望让玩家有更多的搭配,把角色拆分为(帽子、头发、面饰、衣服、武器)5个部分,本来还要增加背包/翅膀、坐骑的,后来讨论不要把小白做成太过于客户端,这样拆分足够了,就这么草率而又愉快的决定拆分成5个部分。
  紧接着是规划动作的种类,虽然是回合的PK,也想把动作种类做丰富些,2个物理攻击、2个魔法攻击、格挡、闪避、受击、失败、行走、站立、休闲,除此之外还规划了打坐、丢东西、击飞、胜利、逃跑,在制作之前计算过一张图片多少K,预计加载可以做多少张,调动作时也有意识的去减帧,但整套动作下来,系列png文件就有5.5M,单独加载自己的角色就要等很漫长了,还要加载背景、UI、对方角色,这样没法玩。要瘦身,先从动作种类、帧数上下毒手,牺牲动作的“很流畅”来节省资源,甚至还有好几个动作做成单帧摆个pose,但输出后还是有2.5M,仍然不理想,还有个法宝,压缩或者转格式,程序那边是播放关键帧的,这个正好要在flash里面插关键导出swf格式,导出影片时进行了80%品质的flash压缩,有点希望了,整套动作加起来750K左右。 

  继续小白,将avatar分成5个部分,每个部分的动作都转成swf,加载的速度可以接受了,但跑起来很卡,主要原因是分层太多,空白区域太多,每个层都是440x440的重绘区域,



这个怎么办?最后是程序给力,将每个动作截取最高与最低的有效区域png,配上对应位置信息,文件小了重绘区域也小了,加载速度还行运行也还流畅,如果有更好优化方案就等大家的分享了。
  下面就拿其中一个攻击动作拆分来示例
1、头发



2、身体



3、饰品



4、帽子



5、武器

 


角色方面还有一个可以拿出来当笑料的:表情切换(眨眼、痛、哭、笑),因为avatar的动作是不变的,所以切换表情的关键也是恒定的。
  最初的制作方式:需要用到多少个表情就在skin好的基础上复制多少个头出来,每个头都对应一个表情的贴图, 然后将它归类到选择区域供渲染脚本调用,还搞了脚本,以为很NB•••NB跟SB就那么一念之差……



脚本渲染是这样执行的:先把普通状态的所有渲染完,再把要切换表情那帧重渲染替换掉,虽然这些都由编写的脚本执行,但有几个表情就有几个头,手动归类很容易出错,经常会导致该哭的时候却在笑。
  后来的制作方法是把所有动作整合到一个max文件里,全部表情整合到张贴图上,通过在固定区域内移动UV记录关键帧来切换表情。



表情切换出错率就很低了,电脑也无需渲染多余的帧被覆盖


[编辑] 2.场景部分

  场景的制作方式也尝试了几种,角色决定用3D卡通渲染效果的同时,为了风格统一,自然就把场景也3D化了,首先原画出概念,再3D建模上材质渲染输出。下图分别从原画到3D输出的尝试:



100%局部表现方法没有对错,投入足够的时间精力是可以调出比较理想的效果,但看当时小白的进度排期及性价比来衡量;只有一个场景原画,画完了之后才能做3D模型,模型阶段不断的改啊磨叽的,完了上材质不断的调试,效果差不多了再进行修图,一张背景很顺利的下来至少也要3周,而且是单线程的,虽然公司有强大的CP做后盾,但这种效率不高,效果也不突出,后来觉得做成造型Q材质写实的清新风格,CP制作这种风格的技术也很成熟,同样还是依赖3D,效果如下



画面上就见仁见智,但时间还是没有节省多少,稍微要调整下构图造型,都要从模型弄起,伤不伤得起就可想而知了,后来还借鉴了其他横版游戏的制作方式,比如前景做3D,中景远景手绘;3D做打散的物件并渲染多方向,打算在同一张地图里的关卡都用这些元素来拼,但后来拼的效果区分不大,没有真正的解决问题。当钻到角落的时候, 工作室的专家Brian给了一些原画的作品,并建议说如果能画成这样,还需要做成3D吗?小白那时候就开始扭转了,不断的试CP,不断的骚扰Brian给建议,过程的辛酸遇到的困难就不描述了,反正看客也不会同情我,最终走上了背景手绘的小白路,小白也顺利上了路;后来从玩家的反馈及出了速战速决这个功能来看,我们当时一直磨care的战斗背景其实并不是玩家关心的,最终还是归属到游戏的核心使命“乐趣”。



以上是一些小白尝试过的,但不是建议尝试过的方法都不要用在产品上,主要还是看项目对产品的定位、周期跟人力精力,当产品要快速在市场上验证的时候就,美术也不要真的把它当艺术品来做,有可能认为精雕细琢是正确的事,更有可能是蒙在鼓里的艺术。当然有人认为这样说有违背精品,但游戏的精品不单是美术,美术也不要把高帽往自己头上带,主要还是产品在当时市场的定位,能不能在单位时间内做到恰到好处,小白做到了吗?回答不了。看完之后很多人想在XB与SB之间划等号。= = 但还是希望大家在看别人“仆街”过的地方同时又有少许收获,最好可以给建议拉一把:)没收获的会心一笑。

 

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引