2024年-FlashMMORPG游戏引擎及工具开发概述学习课件

Flash-MMORPG游戏引擎及工具开发概述

12024/5/7主题:1.游戏核心架构设计3.辅助应用工具2.游戏算法与优化22024/5/7WEBGAME核心(引擎)基础架构1.游戏核心架构设计特性:1.有效地提高开发效率2.有利于团队分工开发3.有利于2次开发及扩展基础架构事件,心跳管理机制对象管理机制通信管理机制资源管理机制组成:1.事件心跳机制(系统)解决交互,互动等问题2.对象管理机制(系统)抽象对象,类架构3.资源管理机制(系统)各种资源或配置文件管理4.通信管理机制(系统)解决核心内外通信问题核心(引擎)是由多个系统组成的共同体,每个系统都负责管理自己专属的职能,系统间协调工作最终完成一项或多项功能(效果).32024/5/7职能系统模型----职能管理器特点使用特定的通信协议,并经由唯一的进出通道(通信代理)与外界进行通信.从属管理器以单例形式存在,并以特定的命名空间进行封装.基于相同的接口或子接口实现自身的通信协议(命令)及对外访问方法职能管理代理A从属管理器[a1]从属管理器[a2]职能管理代理B从属管理器[b2]从属管理器[b2]职能管理代理D从属管理器[d1]从属管理器[d2]职能管理代理

C从属管理器[c1]从属管理器[c2]1.游戏核心架构设计定义:职能管理器是由一个或多个子管理器(子管理系统组成),及一个通信代理组成.经由代理管理接受请求或回馈信息.42024/5/7事件心跳管理机制

---------指令管理器事件,心跳管理机制1.游戏核心架构设计52024/5/7指令管理器(职能管理器)

----事件,心跳管理中心定义:由心跳指令及事件指令这两种实现了IOrder接口的指令来作为通信信息载体,并通过指令管代理进行注册分流.到其从属管理器 (心跳管理器,事件管理器)进行对循环或触发类交互的管理中心事件,心跳管理机制publicinterfaceIOrder

{ functiongetexecHandler():Function; functiongetcallbackHandler():Function; functionsetUp(execHandler:Function,args:Array,callbackHandler:Function)}心跳管理器事件管理器指令通信代理指令管理器组成:1.事件管理器

AS3事件机制的特征2.心跳管理器

心跳管理的注意事项特点:

1.通信载体实现了共同的接口(Iorder)

2.以回调机制取代事件机制的大部分功能.62024/5/7一.命令管理模式publicinterfaceIOrder{ function

setid(value:int):void; functiongetid():int functionexecHandler():Object; functioncallbackHandler(args:Array):Object; functionsetUp(execHandler:Function,args:Array,callbackHandler:Function);}事件,心跳管理机制创建指令创建一个心跳指令/事件指令注册指令经由指令管理器的唯一入口根据指令的类型对指令进行注册分流执行指令指令分流后到达心跳管理器或事件管理器后进行相应的操作回调根据注册的指令的相关定义或执行回调操作指令模式与as3的事件机制的优势与区别:1.事件机制传递一个事件,需要放到事件流当中.要一层接一层的封装事件.然后通过实现了IEventDispatcher接口的对象将一个事件派发出去.

这个过程可能创建的实例很多.而且因为要安插到事件流当中进行冒泡遍历.当注册的事件越多消耗越大.2.指令模式则是以预先封装好的方法及回调方式组装成一个指令原型,通信过程不需理会嵌套的层级数,直接对应用对原型的方法进行回调,而且指令原型实例只有相关的2个方法没有其他相关属性.不像事件机制需要整个对象进行引用,再加上生命周期结束后便可方便御载,销毁.72024/5/7二.事件及心跳管理机制

AS3的事件机制(事件流三个阶段)Target.addEventListener(EventType.EVENT_NAME,eventResponse)

捕获阶段该阶段包括从舞台到目,标节点的父节点范围内的所有点。

目标阶段:该阶段仅包括目标节点.

冒泡阶段:冒泡阶段包括从目标节点的父节点返回到舞台的行程中遇到的节点事件,心跳管理机制对象回收注意:1.保证该对象没有存在引用关系

(实例属性的要保证为null)2.随意注册事件侦听(弱引用).3.对象的任意引用事件管理器:对核心的所有交互对象的事件侦听进行强制注册,收集管理,并实现统一的注册,销毁等接口82024/5/7心跳管理器:事件,心跳管理机制心跳:以一定的时间间隔为标注,间隔时间内调度一次的事件模式.目的:更好更合理的对需要进行心跳的对象进行统一管理,且节省不必要的性能浪费.途径:DisplayObject.ENTER_FRAME:

特征:动作的执行以帧频为频率.每次执行必须最大程度保证当前帧的逻辑及渲染已经完成.(根据执行的情况可能会出现丢帧显现)适合于偏向渲染的心跳处理.如组件,可视对象涉及渲染的属性修改.等Timer

特征:能自定义制定的时间间隔进行心跳处理而不依赖于帧频,但帧频的执行对其也有一定影响.执行的间隔的准确度跟当然cpu消耗有直接关系.适用于偏向逻辑型运算的心跳处理setInterval

是一个封装好的Timer管理器.但没有实现群组,队列等功能的Timer的工厂模式实现.于as2时的区别主要在于as2时setInterval只要事件间隔到,就会马上执行下一轮代码块,而不管之前的代码块是否已经执行完毕.

setTimeout能在执行完制定次数后自动销毁的计数器,是基于setInterval的一个实现扩展.功能要求:能实现动态创建timer并对相应注册的指令进行操作.对于相同心跳的指令进行群组共同注册到统一timer心跳下以减少timer数目增多导致的性能下降.能进行增,删,改,查,销毁等操作.根据实际需求还可以实现对同一对象下所有心跳频率的统一停止开始,销毁等功能.该部分功能特别适用对于管理场景下不同角色或怪物的速度,逻辑等92024/5/7packageflash.utils{importflash.events.*;finalclassSetIntervalTimerextendsTimer{varid:uint;privatevarrest:Array;privatevarclosure:Function;privatestaticvarintervals:Array=[];functionSetIntervalTimer(closure:Function,delay:Number,repeats:Boolean,rest:Array){super(delay,repeats?(0):(1));this.closure=closure;this.rest=rest;addEventListener(TimerEvent.TIMER,this.onTimer);start();this.id=intervals.length+1;intervals.push(this);return;}//endfunctionprivatefunctiononTimer(event:Event):void{this.closure.apply(null,this.rest);if(repeatCount==1){if(intervals[(this.id-1)]==this){deleteintervals[(this.id-1)];}}return;}//endfunctionstaticfunctionclearInterval(id_to_clear:uint):void{id_to_clear=id_to_clear-1;if(intervals[id_to_clear]is){intervals[id_to_clear].stop();deleteintervals[id_to_clear];}return;}//endfunction}}破解playerglobal.swc的SetIntervalTimer部分实现的代码事件,心跳管理机制心跳管理器:基于与事件管理器相同统一的管理接口对核心的所有交互对象的循环间隔调用进行集中优化管理.注意:1.timer实例越少越好,相同间隔的轨到统一timer管理.2.相同倍数的间隔timer,改用最小公倍数为间隔.3.逻辑型心跳适用Timer实现,重绘型适宜用EnterFrame4.实现对象实例的所有心跳命令的统一分组,回收或暂停102024/5/7通信管理机制

-------模块及系统间的通信1.游戏核心架构设计通信管理机制112024/5/7信件指令

-----扩展命令模式的通信载体Message=Head+Body通信管理机制.系统通信管理

1.全局数据的存储,查询

2.配置数据及常量的管理

3.统一接口形式访问管理.模块通信管理:对所有模块都将注册其中并对其进行管理,模块通过接口方法send将信息发送模块管理器,并由模块管理器发送信件对内通信:

(核心内)系统间通信系统内部通信对外通信:

(核心外或2次开发)

1.模块间通信

2.模块内部通信

3.与服务端等外部程序间的通信通信管理与模块作为游戏核心的一个重要系统机制的同时也是沟通不同系统的的桥梁一个Message(信件)应由两部分组成即Head(信件头,标记信件的通信类型,发信人,收信人等基本信息的载体)及Body(信件主体,通信的行为逻辑,及回调等具体方式的Iorder接口的实现)分类:通信管理:122024/5/7MODULE—模块模块间通信(ModuleToModule)模块与服务端通信(ModuleToSevice)模块内部的通信(SubModule--订阅式通信)模块化开发通信管理机制说明:

核心(引擎)开发的模块部分主要是为了解决核心外或2次开发时不同功能组成的协调工作,而提供一种模板式开发方式.并且封装及提供统一的通信模式模块-Moudle

(MVC)publicinterfaceIModule{functiongetview():IBaseSpritefunctionsetview(value:IBaseSprite):voidfunctionregister(moduleName:String):voidfunctionsend(message:IMessage):voidfunction

getproxy():IProxy}132024/5/7通信管理机制1.登录2.角色(装备切换)3.导航/技能快捷栏,(键盘操控管理,拖拉管;理)4.地图(bitmapdata

矩阵处理)5.好友(图文混排,html文本,tree数据结构)6.消息(系统消息,私聊信息,集群信息)7.商店(ui组件设计)8任务

(ui组件设计)9.类型:主线,支线,循环,活动,常规10.内容:对话,打怪,收集,押送,探险,特殊11.组队(跟随,同步)12.宠物(跟随,同步)13.坐骑14.法宝15.帮会16.国家17.挂机模块化开发模块分类:特点:1.相似度高(一般继承核心的基础模板,不同模块开发者可以相互开发)2.高效(结构清晰,不需要费太多心思去想怎么独立实现,不清楚还可以借鉴其他模块)3.基于核心提供的通信机制(模块开发者可以不需要理会核心的具体实现,并且可以基于核心提供的通信机制完成所有通信类问题)4.模块通信的message结构决定了能够将一个封装好的动作指令传递到其他模块其他模块在接受到信息后可以不需要重新组织而直接调用相关指令方法142024/5/7解决模块内部的通信问题

--------SubModule(订阅模块)模块一般是一个mvc结构

这也意味着一个模块将会有多个界面组成,但功能模块的唯一性.

由此而导致的问题是 1.怎么在模块的某些子界面里调用模块的通信接口进行通信 2.模块在接受到别的模块发送的信息时如果要求该模块下某个组成部分进行操作时,怎么进行通知.SubModule的创建就是为了解决,这两个实际开发中经常遇到的问题而产生的.它的工作原理如下.

这里边我的解决方案是采用订阅的方式,通过模块管理器对模块进行订阅式处理.将一个SubModule挂钩到一个模块后,SubModule会通过模块管理器将其注册到该模块下,并在接受信息的接口方法里遍历其所有注册的SubModule(订阅模块)进行信件广播.而SubModule(订阅模块也可以自身的注册信息通过模块管理器查找到该所属的模块并调用该模块的方法进行信件发送)等操作.不需要使用时只要在该模块移除该订阅模块即可.通信管理机制152024/5/7对象管理机制对象管理机制1.游戏核心架构设计162024/5/7WEBGAME可视对象结构:对象管理机制可视基类游戏场景可视对象位图序列可视对象效果类或非交互性物品交互性物品(4叉树优化)角色宠物Npc其他加载器2进制加载对象SWF加载器图片加载器其他组件模块可视对象控件布局导航器172024/5/7游戏中的可视化对象管理基于统一基类:IBaseSprite1.实现可视对象的事件行为,心跳行为的统一注册管理等.2.所有信息存放于实现统一接口的信息体(IBaseVo)中,用于实现数据与界面分离.3.能实现实例进行的独立完整御载及销毁.图形化管理.1.webgame一般尽量使用位图序列作为呈现对象,具体根据项目要求.2.灵活使用catchAsBitmap(当可视对象渲染频率较少时,或只移动时,MovieClip类时间轴对象对帧画面进行独立catch而不要对整个进行catch)3.矢量对象素材能减少加载的内存消耗,但增加cpu负担(一般做法是加载时用矢量,运行后使用catchAsBitmap转换为位图)Ui组件库1.创建自己的轻量级组件库2.Fl组件包第三方组件库AsWing,Flex

Spark组件框架对象管理机制182024/5/7鼠标事件的替代方案--动态4叉树的应用1.解决点击事件中因对象上之上深度的可视对象的存在而阻碍事件的触发.2.实现高效制定范围的对象搜索3.减少深度排序的对象列表数4.用于怪物的简单ai搜索行为5.用户动态绕行阻碍.减少cpu的消耗及内存的使用1.对于非交互类可视对象禁用mouseEnabled及mouseChildren2.addChild(),addChildAt()等方法消耗巨大(排序类操作最好验证判断后使用)3.尽量少用滤镜(消耗较大,创建了两份内存)4.避免大消耗方法使用

如:Array.push()<

Ayray.unshift()<Array.splice()Array.pop()<ArrArray.shift()<Array.splice()

(数据添加后排序)5.少用Alpha与混合模式6.尽量public替代seter()与geter(),消耗相当于方法的调用7.尽量使用函数嵌套.8.实例数越少越好,脚本越多效率越差(虚拟机的反射遍历)游戏中的对象优化192024/5/7资源管理机制资源管理1.游戏核心架构设计202024/5/7资源管理机制统一的资源加载,能对加载的资源进行队列,优先级别加载实现素材的共享,最大限度的减少内存的开销.能对不同资源进行分类加载管理解释;能携带相关加载信息.加载器跟提取器分离,资源加载请求加载完毕后要对加载器的请求进行销毁回收.防止因为应用链状关系复杂而导致实际操作中对象的回收失败.212024/5/7资源管理流程:Target请求资源vo资源vo资源vo优先资源组资源vo资源vo资源vo队列资源组图片资源Image_Loader图片加载器SWF资源SWf_LoaderSWF加载器2进制资源Bing_Loader2进制文件加载器资源加载队列分类加载销毁请求资源池Image_Loader图片资源Image_Loader图片资源资源池Bing_Loader2进制资源Bing_Loader2进制资源资源池Swf_LoaderSWF资源Swf_LoaderSWF资源派发加载事件资源提取管理等222024/5/7OTHER--算法及辅助工具3.辅助应用工具2.游戏算法与优化232024/5/7242024/5/7用途:1.指定范围内搜索对象2.替代点击事件3.实现简单的AI;4.优化排序,A*等高消耗算法的遍历对象数目……….缺点:需要在初始化时进行一次建树;面积越大耗时越久,注意:不是每个对象更改了就遍历一次树,每次遍历的消耗是巨大的.只需对象位置变化时修改对应的节点即可四叉树作为一种数据结构,同样广泛应用于游戏中,(3d游戏)以预先或动态建树的方式达到快速遍历次,减速遍历次数等数据查询工作.252024/5/7原理rectWidth=Width/(4^(n-1))rectHeight=Height/(4^(n-1))W_1=100001W_2=10000/4=2500Sn=42W_3=10000/4*4=10000/16=625Sn=203W_5=10000/4*4*4=10000/64=156.25Sn=844W_6=10000/4*4*4*4=10000/256=39.0625sn=3405W_6=10000/1024=9.765625sn=13646W_6=10000/4096=2.44140625Sn=64607W_7=10000/16384=0.6103515625sn=2184410000像素高宽,逸代6次总节点个数:4+16+256+1024+4096=(4-4096*4)/(1-4)=646014*1=44*4=164*4*4=32….4^n效率影响因素:精度及深度精度:最底层矩形的大小深度:逸代的次数公式:逸代过程中:矩形大小变化与建树节点数目的关系:：每次逸代的节点个数为:(4^)262024/5/745度深度排序

【Function:getOnlyDepthFunc（target:DisplayObject,source:Array）:Object】target--物品列表中的某一物品。source--物品列表（包含target）这个条件方法的最终结果是要返回当前某一物品在一个物品列表中的唯一确定深度【itemDepth】以及除去了target的剩余物品列表【residualSource】。（可以不需考虑其他物品的深度变化，因为这里只关心target的深度，而事实上因为每次确定一个物品的深度时都有可能导致剩余物品的深度变化所以也是不需要考虑其他物品深度变化的）好，先不要问这个方法怎么实现，具体实现下边会提到。下边说说我的这个算法的设想假如现在有一个长度为n的物品列表【sourceN:Array】，因为假设的已知条件方法【getOnlyDepthFunc】可以返回某一物品在物品列表中的确定深度，我们是否可以通过逸代这个【getOnlyDepthFunc】方法并且参数target以每次执行完后得到的剩余物品列表【residualSource】的某一个物品，source则以每次执行完后得到的剩余物品列表【residualSource】去赋值，并且把每次得到的在该片段物品列表中target的唯一确定深度【itemDepth】储存并整理还原为原物品列表【sourceN:Array】所对应的物品深度，那么我们就应该可以得到最总我们想要的深度已经排好序的物品新数组了。上边就是我的设想，这里为了方便大家理解，这里再点一下要注意的一些地方。方法【getOnlyDepthFunc】返回的深度只是参数source列表里的确定深度，但由于每次逸代的剩余物品列表【residualSource】是总物品列表【sourceN】的剩余片段列表，所以他们存在一个耦合性。处理上我是这么做的，在排序我前先声明一个跟【sourceN】一样长度的空数组【rebackSource】；然后从第一次开始，以第一次得到的深度为索引，将索引对应的物品赋值给【rebackSource】数组对应的位上。然后逸代下一次。因为第2次开始已经是剩余物品列表。所以得出的深度【itemDepth】只是相对于每次返回的剩余物品列表【residualSource】的对应唯一深度。但正因为是剩余物品列表，所以我们可以通过从开始项到得到的深度索引【itemDepth】项，不为undefiend的项数，来得到在总列表中的位置。也就是【residualSource】列表的具体项。然后把这次的target赋值给该位置。逸代一共执行品列表【sourceN:Array】长度次。不用考虑效率，因为每次都是剩余列表的长度都在减少，而且不用排序，是一个高效的嵌套循环。272024/5/7T-RC-RT-LC-LB-LT-CB-CC-C[B-L][B-C][B-R][C-L][C-C]

[C-R][T-L][T-C][T-R]01

2

3

4

5

6

7

8公式：item.sideR=(target.[B].y-item.[L].y)item.sideL=(item.[B].y-target.[L].y)item.sideB=(target.[T].x-item.minZ.[L].x)item.sideT=(item.[T].x-target.[L].x)当item.sideR<0时，item于target的右边；当i