Arpg设计思想-开发必看

整体结构

图0

1.心跳机制

BigHeart心跳器，是游戏中统一的动力来源，提供游戏的动力驱动。心跳器会以一定的时间间隔跳动，感兴趣的监听者可以向心跳器注册。

心跳器驱动的有：每个游戏循环内场景的更新函数update(deltaTime)、定时对引用计数为0的动画资源、图标资源等做垃圾回收gc、活动以及领取奖励的倒计时等、向服务器发送心跳包。

因为游戏的动力都是来源于此心跳器,可以很好的解决flash插件的睡眠模式问题。即使自身丧失动力，也可以由外部容器定时调用心跳函数，来保证正常的游戏循环得以进行。

很多游戏都提供了对timer进行管理的功能，但职责更多的是创建timer，

并按不同时间间隔存放timer。而不能像心跳器这样避免很多timer实例的存在。

2.资源管理

加载器BoostLoader是单例类、全局唯一，游戏中所有的资源的加载都由加载器统一管理， Loader、URLLoader不再对用户可见（和php交互时用到的URLLoader，JS调用，封装的有HttpInterface类）。

加载器内部维护不同优先级的待加载队列，可以设置并发加载的最大数量，当前资源加载完成，或者正在加载的资源数量小于最大并发数量时，会从待加载队列中找出优先级最高的进行加载。当用户请求一个资源的时候，会首先查看其请求的资源是否已经在加载或请求队列中，如果已经存在，只需添加请求者信息到资源的请求队列中。资源加载完成后，通知所有的请求者进行处理。

为了明确职责，加载器只负责资源的加载，不负责存储，也不进行另外的解码等操作。已经下载完成的资源，交由其请求者处理后，加载器不再保存其引用。为了缓存游戏的地图区块图片、位图动画、图标、SWF皮肤资源，提供专门负责地图区块图片管理的MapDefManager、专门负责动画资源管理的管理器AnimationDefManager、专门负责图标资源管理的ImageDefManager、专门负责皮肤资源管理的SkinManager。有了这些资源管理器后，上层用户也不需要和加载器直接打交道，而是通过这些管理器请求资源。

具体的一个动画资源AnimationDef、图标资源ImageDef都保存有引用其的BmpAnimation、Image类的引用计数，会定时的清理计数为0的资源。

划分出不同类型的资源管理器，而不是一个统一的缓存管理器的目的也是为了明确职责，尽量使每个类只做一件事情，满足单一责任的原则。

3.网络

网络模块提供客户端与服务器间进行socket交互的功能。基本上每个游戏都会和服务器有两个连接以上的交互。一种就是先与账号服务器交互，账号验证后在整个游戏循环内一直保持与网关的连接交互。另外一种就是为了减轻网关的压力，在账号服务器验证过后，持有其发送过来的ticket，去直接分别连接场景服务器、聊天服务器、全局服务器，而不统一通过网关转发。

为了适用这些模型，提供一个ConnectionManager管理与服务器的各个连接Connection，每个Connection以ip+port作为key。每个Connection收到的数据统一交由Dispatcher类进行分发。对某个以cmd标识的消息感兴趣的用户，可以向Dispather进行注册接收。

如果想避免手动写消息结构的序列化以及反序列化的代码，可以利用类的反射机制，编写一个自动序列化器自动对消息结构进行序列化和反序列化的操作。例如使用技能的消息：

图3.1

4.场景 4.1分层结构

图4.1

4.2 Terrain设计

Terrain的设计主要有三种思路，目前很火的arpg游戏处理方式也都是下面三种之一，都是分块加载，但是加载之后的处理上有所不同：

1）整个地图是作为一个位图(fp9位图最大为2880,fp10中位图最大为4096,超过限制则可分成多个)来移动，

terrainData:BitmapData = newBitmapData(terrainWidth,terrainHeight);

但是加载采用切块的方法,当某个i_j位置的切块地图加载进来的时候，将此块地图数据通过copyPixel拷贝到terrainData的响应位置处。

2）地图是一个sprite容器,terrainSprite:Sprite = new Sprite().只将屏幕周围的区块给addChild进来。根据游戏主角的位置，调整terrainSprite的偏移。

3）地图是一个画布，terrainCanvas:Bitamp =new Bitmap();将屏幕周围的区块的位图数据画到这个画布上。根据游戏主角的位置，调整terrainSprite

的偏移。

4.3场景元素类的设计(部分)

图4.2

职能类部分的设计借鉴了Cocos2D中Action系列类以及Unity3D中Components系列类的设计思想，将场景元素的某部分特定功能抽取出来成为一个职能类，如AvatarCom、MoveCom、FlyCom。例如，如果某个元素需要有行走的功能，只需组合一个MoveCom的实例即可。而有些游戏则采用的是继承的方案，在角色、怪物和元素基类中间有个Animal的类负责行走逻辑，不利于扩展。职能类的设计避免了所有的逻辑都写在一个类中，从来形成一个具有几千行代码的

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库Arpg设计思想-开发必看在线全文阅读。