social game 前端思考
2011年11月09日
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。
这三种框架都各有优劣,主要看是否是合适自己的项目。都不合适的话,自己可以因地制宜的专门为自己的项目定制一个。
2011年11月09日
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。
这三种框架都各有优劣,主要看是否是合适自己的项目。都不合适的话,自己可以因地制宜的专门为自己的项目定制一个。