social game

social game 前端思考

socail game 前端的语言主要采用actionscript3.0,由于游戏小，从策划到程序实现一般会用3-6个月就可以完成。但是现在的social game慢慢的也在集成mmorpg网游的一些功能，大有越做越复杂之感。

从我做的第一个项目几百k到现在的7～8M，由此可见，游戏确实越来越复杂了。

因此，将项目的一些基本的common抽取出来，形成一套开发框架，是非常有必要的。这样即缩短了开发的时间，也方便后续的开发。

库项目，因人而异。我总结一下我遇到的几个项目所相同的地方。

1、地图引擎。

     主要包括：坐标转换，寻路，检测碰撞，深度排序。

     有的游戏不需要地图引擎，比如开心农场，这样的游戏中地图的信息是固定的，没有人物的行走也没有物品的随意摆放等功能，所以没有必要用这个部分。

     这种2.5D的地图引擎，相信很多做过webGame的朋友们都不会陌生。网上也有很多这种类型的openSource。

      例如，as3isolib ,pushButton 等。

2、资源加载

     包括图片，swf，配置文件等信息的loading。

      有些资源是在游戏初始的时候就要加载进来，有些资源则是在游戏运行时加载的。

      加载资源看似简单，但是出现问题也不好解决，主要的问题是程序域和安全域。

3、前后台通信

     这个部分之所以独立出来，是因为后台和前台才用的通信机制很有可能是变化的。

如果我们做实时游戏，使用socket通信。一般social game使用http请求。这个可以之间看到我们来回请求的数据信息。但是如果和后台通信数据量巨大。那么就可以使用amfphp，他传送二进制数据，至少比http请求多了一层保护。但是使用firbug插件，我们依然可以解析出来看到数据。

4、本地化资源

      这个部分主要是文字资源，我们根据当前用户的语言，获取不同的文字资源。

      主要的问题：当我们在游戏中使用嵌入字体的中文。问题就来了，中文的字体文件动辄就10几M，比游戏swf还要大。而且字体资源要在Game.swf加载之前初始化，这样明显会增加loading时间，得不偿失。

所以一般的解决方法是不使用嵌入字体，但是这样就降低了美观的效果。另一种解决方法就是将中文资源转化成unicode码，然后这些unicode码embed进来，编译成swf。这些都是在发布游戏之前，开发人员要做的工作。

5、皮肤

     贴皮肤是flex的一个强项。flex有专门制作皮肤的工具，按照css的语法，即可想操作html元素一般的操作flex元件。

只要改变皮肤的swf文件，就可以替换皮肤。但是如果界面不是用flex组件做的，而是就是使用flash ide做的元件，那么替换皮肤就是一个比较大的工程。

一个方法是使用aswing做界面，他模仿了flex很多可取之处。但是aswing做界面对程序来说是个痛苦的过程，他将ui的界面美化工作转嫁到了程序这里。

6、Quest任务

      Quest便是social game向webGame学习之处了。

      Quest分为主线任务支线任务。完成一个任务会激发下一个任务和相应的任务奖励。基本的思想都是如此。不同的游戏有不同的任务配置文件即可。所以将它单独地独立出来就很有必要了。

    主要的问题：主要在于策划的任务关联性故事性，有的任务起学习作用，有的任务起承上启下的作用，所以一条线串起来用户可以更好理解游戏。

7、 活动

      功能性的东西开发完了，后期就处于维护阶段。

维护主要做的就是活动的更新。这些东西如果能够抽象出一套模板出来，每次只要更新内容，不需要投入太多的精力时间去开发，便是最好的维护了。

主要问题：活动经常会出现不同的需求，不一定非的用原先的模板。这就要求这个模块做的灵活，可扩展。

以上这些东西我个人认为都是可以抽象出来作为类库的。好处多多，自不必说了，呵呵。

至于不同之处，下面我就略微讲一下，不能面面俱到，还望TX们谅解。

1、场景物品的生成。

     例如我们addChild()一个物品到场景中，这个物品肯定是displayobjec,那么他使用png的方式呢，还是movieclip。以前项目小的时候，我们习惯使用movieclip后来发现这样cpu会不断的计算这些矢量的东西，于是改用png。png会吃一些内存，但是至少cpu不会占用太多，反而不会特别的卡。各有优劣吧。

2、   场景的操作。例如，对场景物品的移动，旋转，删除等等。不同的游戏有不同的实现方法。我遇到过两个不同的实现方法。一种是抽象出一个GameMode。不同的操作对应不同的GameMode。例如DeleteGameMode,MoveObjectGameMode 等。这样GameMode 互相独立 含有不同的逻辑，便于管理和维护。

还有一种方法就是点击物品，物品出现不同的选项，你可根据选项进行操作。这样的方法简单。还很好理解。

3、界面UI和游戏数据

     做着一个部分，很多人都会想到使用mvc模式。

     adobe 公司推出的cairngorm3 和第三方openSource提供的pureMVC以及一个robotlegs。

     这三种框架都各有优劣，主要看是否是合适自己的项目。都不合适的话，自己可以因地制宜的专门为自己的项目定制一个。

好了，现在想到的就只有这些，里面涉及到的技术细节以后有时间在做整理。还希望广大同学多做批评指导。