Cart项目的开发记录，关于Unity制作者独立开发流程。

最近搭伙的大神基友失踪，所以在报案寻人之余决定利用这段时间独自起一个项目——Cart疯狂购物车（暂定称呼）。现在已经完成前期工作，所以把流程写一下，方便那些刚刚使用U3D 并且喜欢单打独斗的新手对游戏开发流程有个大体的了解。

首先讲一下个人独立开发者的优劣势。
先说劣势吧：很明显，产能有限，不能做大项目。需要熟悉各环节流程，容易出现技术瓶颈。缺乏资金和时间支持，全职做生活要开销，业余时间做进度相当慢。制作过程单一主观，缺乏调研和推广环节，大部分作品因此而失败。

优势：方便把握全局，不需要策划概念的交流过程和传达损耗。各个环节的资源管理和适配效率高。成本低流程短（相对的）。最最关键的是自己的东西，全力以赴，容易出精品~~~

关于产能和产品定位补充一下，做为个人开发者首先要按照实际情况来确定项目类型，首先大中型RPG游戏是不适合单人制作的，因为这种游戏的开发周期一般都超过甚至接近一年，而且项目庞大后期控制难度大。主题类操控类的小游戏产品比较推荐。个人开发者的项目周期建议不要超过半年，因为开发者往往会针对当前的市场情况和硬件性能来生产对应的游戏产品，而半年之后市场和硬件平台包括软件技术变化相对已经较大，小产品投放后可能难以产生最好效果。手持平台的游戏主题选择建议越大众越好，如果是网络化的产品，那么建议越贴近女性越好，因为如果一个游戏女玩家越多，你就越不用担心男性玩家的数量，但是反过来则行不通，而且用户往往会是一些喜欢玩破解且不肯付钱的技术宅屌丝~~

下面开始讲主要的

首先是策划，这是作品成败决定性的一步，一个好的策划不但要玩过大量的游戏，而且能够准确的理解和剖析每个成功作品的成功因素。大脑能够准确的模拟游戏规则所产生的用户行为和体验。

当你确定一个比较好的规则时，就可以进行原型制作，就是Demo的Demo，只为测试游戏主规则的可行性，Uniry在这方便有着非常大的优势。原型甚至不需要模型和贴图，内置的资源拼接足够。比如Cart这个项目的原型，用内建的box搭成主体，Max里loft放样一条路径即可。

 
 

原型的游戏规则主代码只有3行。此阶段只为测试可玩性。除了游戏规则，控制方式和体验需要考虑仔细，如果是IOS游戏，有条件的话，最好导入真机测试一下操作手感。因为在手持平台，操作体验是非常重要的，操作方式往往会反过来指导规则策划的定制。在这个阶段，摄影机跟随模式，主角大小距离，操控方式和横屏竖屏显示方式都需要明确下来。

接下来补充一下美工和程序的相关标准制定。

很多新手可能会纠结使用JS还是C#开发的问题(Boo太小众暂不讨论。。)，对于执行效率上来说，因为最后都需要再次统一编译到对应平台，所以运行效率并没有太大区别。具体使用哪种语言来编写根据个人熟练程度和项目要求即可，对于新人来说我可以明确告诉你JS比较好上手，适合开发小型项目，而多人协作一般会采用C#。比如Cart这个游戏的Demo原型是使用Js编写的，而真正制作的时候我使用的是C#，因为之后可能使用到的插件大多是C#编写的，由于Unity3d两种语言脚本的沟通缺陷所以采用C#来减少以后可能遇到的问题。对于考虑到编程工具的选择和后期加密的问题，C#也优于Js。但并不是说Js不好，比如很多引擎效果都要优于U3D，为什么要选U3D，因为它轻便易用高效率，更加适合中小项目。 

对于美工的标准，跟大部分游戏标准没什么两样，导入一般使用FBX，Autodesk已经将FBX格式做为自己产品线的标准工作流文件，Unity3D官方也已经确认会将此格式做为标准资源，建议大家使用FBX来导出资源并熟悉FBX的导出参数以及规则。

Unity对于影响顶点的骨骼数量支持是有限制的，大家在建角色模型的时候需要注意。一般游戏推荐2骨骼，写实风格推荐4(最大)。

还有一点对于刚刚入行的新人比较重要，就是事先要对应好模型的缩放大小，虽然U3D导入FBX面板有缩放因子参数，但是尽量还是保持一个良好的习惯，首先调整建模软件的单位，比如max中一般为cm，导入因子默认0.01，这样进入U3D的时候1米对应的就是Unity的1单位（Unity中的1单位默认就是1米），为什么单位很重要，因为这些单位以后将直接影响Unity中的物理特征。

为保险起见，模型完成导出或者蒙皮之前最好将其重置并将坐标设为原点。
 

因为Unity3D是面对对象的引擎，所以一般来说只要是场景中需要重复使用的动态元素都做为单独的FBX导出，并在Unity中制作prefab来摆放使用，所以在建模工具中把模型坐标设为场景原点更加便于使用。

对于美工来说，熟练Unity的视口摆放操作和资源链接规则以及各个模块的使用方法是必备的技能。这也就是Unity美工很大一定程度会参与到引擎美术的工作中，提供更加方便程序使用的预置资源。 


原型制作好之后，如果结果符合策划的预期，那么就可以立项进行制作，首先会把原型中的元素替换为正式资源来形成Demo，那么美术必定在这个阶段先行，程序方便需要准备的是美术流程中所需要的Editor工具，比如有的项目中美工需要大面积的操作花草模型（别指望Unity内置地形，那东西在IOS下就是个废柴，大项目中一般会开发自己的地形组件），那么程序就需要针对这个需求来编写支持的编辑器脚本来方便美工批量操作和修改。

这里我介绍的是自己使用一套美术流程，建模工具如今不同以前，现在除了Max和Maya还有很多新生的工具，大家可以自行寻找学习，有些针对性很强的工具更加适合游戏模型的制作，当然具体工具选择最终还是完全看自己的习惯和熟练程度。

做为一位迂腐守旧的老年人，在Cart项目中我仍然使用的著名民工软件3Dmax。首先在max中建好主角的大体形象（自己一个人制作的好处是可以省略原画等等前期素材，因为美术形象完全是自己指导给自己）。
 
继续细化
 

模型的面数必须有概念。按照事先预想的量级，过多的细化单个模型并不是一件好事情，在过程中必须要做到控制每个顶点都能产生必要的剪影效果，如果顶点不存在剪影表现或者蒙皮控制的必要，那么一定要坚决剔除，积少成多，对于手持平台来说，模型的优化是相当有必要的。

很多人觉得我五万面导入真机测试不卡啊，没问题啊。在手持平台中，除了游戏运行的流畅度，耗电量和运行游戏的温度也是体验的重要组成部分。画面上节约出更多的性能，就会留给程序上更多的发挥空间，策划也能在这些空间上完善更多的游戏细则。

 


贴图的绘制方面，我推荐一个叫做3dcoat的工具~ 是个乌克兰的新兴软件，非常强大，可以直接在模型上绘制表面色贴图 高光贴图 半透明贴图 法线贴图（精确高低模法线还是用ZB，3dcoat是绘制法线，不精确）
这类插件和软件并不少，但是3dcoat是用下来最强大的一个~并且支持分层绘制，与PS高度协同~ 可以直接在软件中呼出PS分层编辑贴图。
 
 
 


很多开发的朋友问我有没有什么美术方面的速成方法，我觉得应该是烘焙，烘焙是提高模型视觉效果的最有效手段，哪怕是只上纯色，一旦经过烘焙，档次便会提升不少~~

在3dcoat中，烘焙的图层可以作为图层叠加在最上层，省去了手绘全局光效果的环节。
 


Unity3D另一个强大之处就是资源维护方便，项目目录可以直接作为工程目录使用，模型和贴图可以直接保存在项目目录内，配置好shader之后，建模和绘图过程中随时查看最终效果。所见即所得。 


在绘制贴图的时候，模型可能会进行一部分的tri线修正，完全确定之后，就可以建骨骼进行蒙皮了。蒙皮之前切记确认模型比例和大小，否则等辛苦蒙皮完毕之后发现比例错误，就欲哭无泪了。。。

下面是蒙皮制作的环节~使用的民工建模软件的bip骨骼系统，在之前bip一直是我钟爱并冷落maya的原因（虽然我叫mayaxiaoan。。但是却一直偏爱max~话说不会有Maya粉再跑来喷我吧。。。）~~~
 

蒙皮环节比较重要的事项就是顶点控制骨骼的限制。max中的skin命令可以在此限制。
 

因为在unity中skinmeshrender组件是十分消耗性能的，建议一般不要使用超过2骨骼的控制限定。这是在一个场景中跑多个角色的重要限制因素，记住它在实际运行中是按照角色数量成倍消耗性能的。


 

同时为了能够生成随机赛道，场景里的道路也是使用蒙皮来进行控制的，目前没有想到更好的方法。Unity中对于顶点的批量控制能力较弱。之前有想过shader级别弯曲的方法，但是由于游戏规则需要真实空间弯曲，所以shader弯曲效果不能满足需求。如果您有更好的想法可以回复告诉我~~~~ 


继续在3Dcoat中绘制赛道贴图
 

这部分需要注意的就是因为是拼接道路，所以注意循环接缝，这个模型是几段拼接之后导入绘制的，所以会顺便把接缝修好。
貌似流程方法之前都介绍过了，没什么好说的了，先直接上素材图吧~
 

接下来是制作手推车模型。

很多时候这种卡通类型的造型设计不需要过多的追究现实细节，只需要根据对这个物品的印象感觉来设计即可，即使现实不是这样，但是整体的感觉达到了，一样能够出彩。国内的游戏产品与国外对比 一般缺少夸张和想象力，当然这也与我们的教育方式有关~ 认识到这点 就要努力练习和克服~

 

 

将妹纸摆好自己喜欢的姿势放入购物车内~~（这段话看得我有点小兴奋）

一切素材就绪了，现在开始准备将资源导入Unity

这个过程需要严格按照Unity面向对象的原则来拆分进行。

首先将角色进行导入，并不是直接导入图中这个角色，而是把之前未加入动画原始角色和骨骼导入，然后再导入这套加入动画的骨骼，在U3D中作为动画文件使用。注意只要骨骼，因为骨骼已经包含了全部的动画信息，因此不需要重复包含模型。在unity3.5之前单独的骨骼导入unity直接提取动画文件指定给原始模型是不会播放动画的，原因是在unity中单独的FBX父级（也就是bip01）被识别为文件最顶级，（而包含模型的FBX很明显有两个物体，所以文件层级被识别为父级）这样纯骨骼FBX文件的动画层级会比包含模型的FBX动画层级少一级，造成动画信息无法对应，从而无法播放动画。在unity3.5中，对bip01进行了特别对待（这也是我喜欢bip的原因~），所以纯骨骼的FBX动画可以被正确的识别并指定给原模型~~~（所以之前那段看不懂可以忽略反正用3.5以后的版本就行了  ）


之后是购物车导出，再次按照对象原则，购物车可以作为整体导入，但是车轮因为需要在游戏中进行独立运动。所以车轮作为一个独立的对象单独导入。这种对象可以在max中用虚拟体Dummy来标识位置，到Unity中会显示为空GO，然后在Unity中复制出4个车轮替换到Dummy的位置。4个对象会使用程序来驱动，制作转向和旋转。

对于导出资源的mesh合并，之前漏掉一点，在现阶段的硬件设备中，对于硬件性能影响较大的指标除了面数，还有就是call（其实现在影响更大的还有shader）。call是指每帧中调用对象的绘制次数，一般来说，同一个材质的同一个mesh是作为一个Call来处理的（shader编写是一个call的前提下），所以按照这个原则，大家在制作资源的时候一定要尽量的把贴图集中起来，使用尽量少的张数，并在Unity中使用相同材质，在Unity中，这些使用相同材质的静态元素可以通过勾选Static来自动batch到一起（当然还有playerSettings中的Batching需要勾选）这样可以减少尽量多的Call，达到节约资源的目的，而这一步，在资源制作的时候就要严格规划好。

另外，这个call的因素也是为什么大家反感Unity自带GUI而辛苦学习NGUI的主要原因~（NGUI可以整合所有按钮素材到一张贴图，只消耗一个call，而大量使用GUI过后查看call则有一种被轮X了的感觉~） 


将妹子和车子在Unity中组装好，上贴图调整效果。

因为在max中动画是相对于车子的位置制作好的，并且坐标都在原点，所以在unity中调整起来也会方便很多。
 

 



最后加入随机赛道的脚本，运行一下（喷气口和焰火效果未制作 无视~~），至此Demo的基础游戏架构已经完成。

这个阶段如果对产品不满意，还可以推翻重新设计，大多数开发者会产生游戏已经接近完成了的错觉，但其实往往这个时候工作只进行了20%不到，我们很多时候会用1-2周时间制作好一个Demo，而将其完善成产品则需要数月的时间。无论是游戏主题还是周边组件，都需要认真的对待，保证每个环节的质量，才能做出真正让人满意的产品。很遗憾目前看到的很多产品只能称为作品级别，而非产品。当然也不能一概而论，毕竟Appstore越来越多的国内佳作也很亮眼，希望在利益的驱使下~~能够有更多更精彩的作品扑面而来吧~~~~
 

到这里是目前的进度，之后会按照项目的进展情况不断更新，敬请关注~~~~ 


作者：

mayaxiaoan

原文链接：http://tieba.baidu.com/p/2335319236