webgame模块划分

转自:

http://blog.csdn.net/txiejun/article/details/5924108

模块划分:模块划分主要包括“核心模块划分”和“子模块划分”。核心模块的划分思路是这样的:它们是游戏启动所必须的,相互之间是紧密联系的,还要经常的被子模块调用;而相对的,子模块的划分思路是:他们在游戏启动过程中不是必须的,可以在游戏过程中再加载,子模块相互之间基本上完全没有联系,一个子模块的增加和删除不会影响到任何其他子模块,子模块可能需要调用主程序的接口或者获得主程序的数据,但主程序绝对不应该依赖某个子模块。

        明确了模块划分思路再具体看看哪些部分应该划分为核心模块,哪些部分应该划分为子模块。一般情况下,核心模块按照游戏启动顺序包括:一个壳子SWF → 配置文件包 → 登录注册SWF → 主程序SWF → 主UI的SWF → 公共素材包。而子模块相对来说简单很多,比如具体的某个小游戏,某个场景,以及某个场景里的触发功能等等。下面我对核心模块逐一略做解释。“一个壳子SWF”:这是一个体积很小,但意义很大的SWF;它后面总是跟着随机变量,确保每次用户加载的都是最新的;它里面定义着一些需要经常更新而且每次更新都必须保证用户也在第一时间就得到最新值的变量;它里面最好有一个简单背景图,保证用户在超低网速的时候输入游戏网址不至于长时间面对一片空白;它里面有安全策略的设定,是我们游戏和很多第三方平台合作的基石;它里面还定义着主程序被加载进来之前的游戏启动流程等等。“配置文件包”:核心模块版本号啊,全局文字说明啊,service接口定义啊,各个核心模块需要的配置信息啊什么的,一般是一些XML文件。“登录注册SWF”:这个简单,在加载重量级的SWF前,先加载登录注册SWF,可以保证用户第一时间就能打开登录注册界面,而且可以有效节省服务器带宽。“主程序SWF”:这个就是我前面费了好大劲讲的主程序部分了。“主UI”:主程序和主UI为什么要分开两个SWF,我前面已经提过了,后面还有说明,这里暂时不讲。“公共素材包”:公共素材包是一个游戏不可缺少,但也不能过分依赖的东西。它包括一些全局的道具和效果,比如表情、技能特效、场景传送门等等。公共素材包里面最好就是一些简单的动画,体积小功能简单,严禁在公共素材包里添加上百K的东西,或者代码上百行的小模块,公共素材包建议500K以下。

        看了上面的讲解,你可以能觉得核心模块分那么多,太麻烦了。不错,在我看来,对SWF加载流程的分解和控制,对异步程序的掌控正是衡量一个AS程序员是否经验丰富,是否足够老道的重要指标,很多从其它语言转到AS并有多年编程经验的朋友,架构方面可能和AS程序员差不多,甚至比很多自学成才的AS程序员做的更好,但这方面往往不如长期与CPU和SWF体积搏斗的老牌AS程序员。核心模块划分的越合理,用户体验往往越好,后期编写和维护代码的效率会越高,但在前期会比较麻烦,而且对架构师的架构经验和能力必须提出更高的要求。什么都不分,主程序、素材、核心模块都弄在一个SWF里,用户一开始必须先下载完这个SWF,或者弄了一堆核心模块和超多公共素材,用户一开始必须面对loading条不停的周而复始,必须等所有核心要素全部加载完成才能进行一些基本操作的做法,从架构角度上讲,是最简单的做法,因为不用过多考虑复杂的异步和SWF拆分问题,但从用户体验和长远的开发维护上讲是非常不利的。根据我们的经验,用户登录前加载的所有资源体积应该控制在200K左右,而用户进入游戏主场景前,加载的资源总数应该控制在1M左右。还有前面提到过的那位用了pureMVC后项目编译一下要十几分钟的朋友,估计就是把所有东西都弄到一个SWF里的做法。主程序随便改动测试一下,就要十几分钟,牵一发而动全身,开发效率从何谈起?根据我们的经验,任何主程序、核心模块还有子模块的编译,都必须在10秒以内,这才是合理的——我的机器是07年花了3000多买的戴尔品牌机。

原文地址:https://www.cnblogs.com/naiking/p/2301381.html