玩转cocos2d引擎 《全民小镇》手游快速开发
这里主要介绍一下《全民小镇》手游开发中，美术相关的技术方案、规范、流程以及一些经验总结。
我们使用cocos2D –x引擎，cocosBuilder做为UI和动画工具。
有cocosStudio 和 cocosBuilder两个选择（后面简称studio 和builder），studio是在pc下运行，builder 是 for mac，前台鉴于studio不是特别稳定，加上个人习惯于mac下开发，所以选择了builder。
手游开发大家都知道“快”，如何快：
1， 前期准备阶段，研究分解分析标杆产品，减少探索带来的成本和风险，继承原有我们页游flash开发中对图片压缩管理的经验；
2， 开发中期量化阶段，标准化流程化，大家出资源的速度应该都差不太多，我们就所能保证的，就是保证出来的美术资源能够直接被前台所用，避免不能使用带来修改的成本，这样达到快的目的。
我们的一个游戏场景，这个分类各游戏大同小异。
上述是根据美术内容进行的分类，这里是根据格式，我们可用的格式。
png+plist是逐帧动画，ccb是builder的工程文件，相当于psd。
这里是根据储存和加载的方式分类，一种是放在app安装包里，玩家更新app时直接获得，动态更新是玩家登录游戏后动态从网络即时加载的。
分类很大程度上会决定我们的美术资源格式和流程。
png是首选，jpg备选，pvr与etc分别是ios 与 android更合适和优化的格式，需要从png和jpg转换，部分其他项目已经使用了。小镇暂时没有使用的必要，可能后续会进行一次转换优化整理。
动画与特效，在使用层面，部分特效与动画其实是一个概念，只是内容不同而已。
一种是png+plist逐帧动画，最后打包到一张png图片上；
一种是builder的时间轴动画。
手游开发，美术关心的视觉，前台关心的一系列稳定效率网络问题。美术与前台的衔接，一方面是互相pk，保证各自的质量，一方面是相互平衡，找到最佳的解决方案。
移动设备不同于以往端游和页游，在上述问题，都是以往不那么需要考虑，而在这些问题上，美术恰是最大的源头。
这些都决定了手游美术资源一些与以往不同或者更需强调的特点。
综上，这些是我们最需要关心的。
美术资源的大小，不仅在文件体积上，也在乎所占内存上，以往pc机上的游戏几G内存这个是不需要考虑的；
使用大量的叠加模式，时间轴动画，全屏特效，除了cpu耗费，卡顿，也会带来电量的快速消耗；
一个资源的更新要顾及玩家不同网络情况的下载，因为很可能玩家会下载不下来而无法看到和使用该资源，同时要兼容不进行更新的老玩家app的体验。
背景与地台资源，注意右侧关于更新方式的图标和文字
左上是商城等UI用图，右上是建筑主体，下方是逐帧动画，没有动画的建筑商城等UI直接使用主体的图片。建筑是必须动态更新可以即时下载的资源。所以必须保证文件尺寸。
左上和左中，右中是UI上的半身像，蒙黑直接用半透的黑色png，对于前台实现起来最为便捷有效；右上npct UI头像。
Npc也是付费点，也必须可动态更新。
UI相关部分，
仍请注意更新方式。
广告运营活动，
这些也是必须动态更新的资源，对文件尺寸要求比较高，比起建筑更新起来更频繁而且文件尺寸也更大，重点关注对象。
《全民小镇》第一版本初次安装包
每次更新的安装包，主要为美术资源，运营广告，也包含部分配置。
制作方法和流程保证上述的标准，保证资源有效的制作。
cocos2D –x支持两种，一种是png+1个plist，一种是上面我们选择的这个3个文件的，更规范和方便管理，拓展强些。
这里是大概原理，切片描述的plist，其实是xml，+png，把拼好整图逐个还原回来，补充拼图时裁切的空白像素，移动好相应的偏移，动作描述包含有多少个动作，每个动作的每帧使用了哪个切片，持续多久切换下一个。
Plist动画我们的制作工具，逐帧做好后我们在flash进行打包和输出配置，使用texturePacker输出整图和切片描述的plist。
主要原因是我们从页游开发转过来，flash是熟悉的工具，也提供了一整套动画制作的方案，我们上手最快。
（也有同事分享说studio也可以方便制作该动画格式，具体还没有去关注过，因人而异，怎么快怎么选）
右侧脚本是我们自己使用的打包工具，输出动作描述plist，重新生成切片id，因为这个在整个游戏里需要保持唯一。
1，每一个mc就是一个动作，按动作命名好，安排好逐帧；
3， 使用脚本脚本输出plist，只有使用到的图片才会被挑出来，放到一个单独的mc里，flash也可以进行png整图打包，但是优化度没有texturePacker好，所以我们打包部分用texturePacker进行。
使用到的jsfl脚本
Jsfl脚本的工作流程
具体建筑、车辆的美术资源构成
一个建筑分为base主体部分，animation动画部分，和shop商城缩略图，动画分为刚才说的3个文件，所以一个完整的建筑分为5个图，如果没有动画，那么就base一个主体图。
现在为了更好的动画表现，结合对资源尺寸还有效率的要求，一个建筑已经支持2个动画了，一个常规动画，一个可以用叠加效果的动画，比如光效。
这个是配置工具，左上第一个页签，位置配置，配置base和animation的偏移位置，以便在游戏中还原，右上两行数值是偏移坐标。
同时，这个工具可以预览动画，左侧为npc的不同动作，行走、站立等。
第二个页签功能是配置点击区域，在cocos2D –x中像素检测是个非常麻烦的事情，而且效率还低（源自前台同学），该方案是参考了其他标杆游戏指定的，生成一个多个点组成的封闭多边形，保存成配置，前台判断是否点击在该区域内。
第三个页签是将每个建筑单个的点击区域配置，打包成一个整体的文件。
经验源自以前页游开发
常见的固定尺寸的UI窗口，剧中在屏幕中间即可，按最小机型制作。
我们制作时只考虑iphone4，iphone5，ipad，其他机型或者动态适配，或者整体缩放（如低分辨率的touch）。
另一种，全屏UI
从大到小，细分：
红色部分，上面标题向上靠拢，下方向下靠拢，适应屏幕高度变化；
蓝色部分，左侧固定宽度，右侧可拉伸适应屏幕宽度变化；
绿色部分，上面左侧黄色固定宽度，右侧是3*2的按钮，固定宽度；只有中间部分动态拉伸；
下面黄色部分，左侧固定宽度，右侧动态拉伸。
Builder自带的尺寸与位置的设置方式，自动完成适配，调整好后不需要前台算宽高来拉伸窗口；
绝对值
容器百分比
相对容器尺寸
固定高度，横向百分比
固定宽度，纵向百分比
多种解决方案(这个我们没有使用)
两种字体，一种系统自带，有的项目把字体比如雅黑粗圆等放入app包内，增强表现，多了几Mb，看各项目平衡，我们使用了系统自带字体，描边等实现复杂，效果不太好。
一种图片字体，可以更丰富特殊的美术表现，但是底层对自间距不支持，比较坑，如果前台有时间可以改底层来支持。
字体制作的两个工具，都是for mac
自己打包，在手工画矩形这里设置切片，输出配置的plist。
灵活性最强，ps里画好单个的，用ps或其他拼好整图导入即可，使用起来慢。
直接设置字体大小、渐变、描边投影等参数，直接输出打包好的png和配置，最常使用。
因为我们的游戏会缩放地图，最小约0.5，最大2倍，资源模糊是必然的，
为了保证第一眼给新玩家带来比较好的视觉表现，使用了该方案。
右图为资源尺寸，程序里缩小。
9宫格对于文件尺寸来说可能差异不大（比如连续大色块），但是所占内存资源大大不同，按图片的面积进行计算的，一个面板是否使用9宫格可能会相差几Mb在内存中。
我们曾经要动态更新的一个建筑，面积很大，右侧为加了各种光效动画的最终效果（实际中是动态的），这个逐帧动画为更新带来了比较大问题。
使用时间轴动画
打包整图需要小于1024*1024，超过的话一尺寸过大，二有可能会有显示或者bug的风险（源自前台）。
1， 使用jpg+叠加效果；
2， 整图打包进动画；
3， 动画只有特效部分；
4， 去色，全部用白色；
5， 使用通道抠出变化了的像素，129Kb仍然不让人满意，目标100以下；
6， 最终，将部分不影响效果的部分，如水池，涂白，减少颜色数，尺寸终于降下来了。
想说的是：
除了技术方案，设计方案也会大大影响文件尺寸，当然反过来也有影响，这么严格的尺寸要求下，如何把效果做到最好，也是美术该考虑的问题。
后续的支持与解决
看了百科上一个同学的分享上之后针对我们游戏做的一个尝试和测试，使用flash模拟，原理一样。
法线贴图+灯光，形成一个随灯光变化的灰阶图，在与漫反射贴图做叠加，形成一个2D但是可以随光线有各面明暗变化的最终建筑或者物品。
Demo里使用到的一些资源。
Demo就不放了，有兴趣的同学可以rtx我。
附demo 截图：
