Java游戏背包系统类设计方案
该项目是针对制作一款游戏,在本文中,我们只选取其中的一个功能进行分析,我们选择背包系统作为我们的设计目标。背包系统的核心是,背包界面负责显示游戏中玩家拥有的游戏道具,在逻辑上保存玩家的道具物品信息,并对背包中的物品进行使用、出售、升级等操作。
二、运行环境和技术选型说明
项目游戏主体分为游戏内逻辑与游戏外逻辑,游戏内部主体逻辑使用c#语言编写,使用单例模式、观察者模式、工厂模式等架构编辑游戏主体逻辑。游戏外部ui系统及界面主要使用lua语言编写,通过事件通知交互机制完成消息传递。使用成熟的tolua框架完成lua与c#代码的逻辑交互。系统的网络通信部分设计使用socket通信与protobuf协议结合的方式进行。
三、架构风格
在项目模块开发中,是基于mvc框架进行的,将各模块业务分拆成三部分:model:保存
游戏中对象的数据结构,例如角信息、物品信息等等。controller:处理游戏业务逻辑。例如核心玩法、物品使用等。view:游戏世界中可以见的对象,和model绑定,在游戏中展现物体及ui对象。mvc具体使用方法为使用manager类控制操作流程,ui类设置游戏内按钮、文字、图片等,data类等设置为对应数据基类,进而实现程序前端数据展示与后端数据存储逻辑分离。游戏中的背包系统也使用mvc框架结构,使用manager类控制游戏流程,ui类设置游戏内按钮、文字、图片等,data类等设置为基类,实现程序前后端分离。
四、设计模式
对于背包物品,最重要的机制是需要实时获取服务器对物品的相关修改,出于模块化的需求,由于物品涉及的模块众多如战斗掉落、任务领取、玩家购买等等,物品的相关修改需要独立负责,尽量减少与其他模块的耦合程度,因此物品相应的方法设计使用使用观察者模式的设计模式,通过服务器推送通知的方式进行更新。分析:在软件工程中,模块的内聚和耦合是度量模块化质量的之一。观察者模式适用于当对一个对象的改变需要同时改变其他对象,而又不知道具体有多少对象有待改变的情况。当对象之间的关系具有一对多的相关信息依赖时,一个被观察者对象的信息状态数据发生改变时,将对外发送通知,对
该事件添加监听的所有观察者可以同时对其变化进疔自身更新。这种模式可以通过低耦合度的方式灵活的处理一对多的对象数据关系。观察者模式实现了表示层和数据逻辑层的分离,定义了稳定的消息传递机制,并抽象了更新接口,使得观察者可以自我定义自身的表现,从而通过抽象的耦合方式连接观察者与被观察者.观察者对于被观察者是透明的,被观察者只拥有抽象观察者的列表,每个具体观察者都符合一个抽象观察者的接口。但这种模式在使用通知更新的同时将造成一定的性能损耗,且没有相应的机制使观察者知道被观察对象变化产生的原因。如果在被观察者之间有循环依赖的话,易造成循环调用导致系统崩溃。对于游戏背包系统来说,背包中物品会受到其他模块的影响,但其他模块并不关心对于物品的处理方式,因此选择观察者模式的设计模式。
五、协议设计
背包模块需要在用户登录游戏后,从服务器获取该用户的物品相关信息,包含货币信息、用户相关显示物品信息等等用以在主界面中显示,因此需要在登陆成功后尽快向服务器发起请求,但此时用户数据可能会因为服务器未完成数据的打包而报错,故此请求发送时间由服务器消息推送决定,在bagmanager中定义服务器物品信息初始化完成消息通知,
用户完成登录后,当收到物品信息初始化完成消息后,向服务器发送物品信息请求。由于物品中存在体验类物品,在获取物品信息时,需要创建计时器同一管理物品过期相关事件。
六、逻辑视图
七、执行视图
执行视图展示了系统运行时的时序结构特点,比如流程图、时序图等。执行视图中的每一个执行实体,一般称为组件,都是不同于其他组件的执行实体。如果有相同或相似的执行实体那么就把他们合并成一个。
执行实体可以最终分解到软件的基本元素和软件的基本结构,因而与软件代码具有比较直接的映射关系。在设计与实现过程中,我们一般将执行视图转换为伪代码之后,再进一步转换为实现代码。
因此,执行视图其实表现的是系统中间比较动态的那一部分。鉴于此,我们可以通过流程图来表示执行视图:(这里的流程图,并不是专业的uml流程图,而是一种让人方便理解
的执行流程,即页面跳转、操作等,通过这一种流程,来展示玩家可能会怎么使用到背包系统的,因此不够标准)
八、工作分配视图
工作分配视图将系统分解成可独立完成的工作任务,以便分配给各项目团队和成员。工作分配视图有利于跟踪不同项目团队和成员的工作任务的进度,也有利于在个项目团队和成员之间合理地分配和调整项目资源,甚至在项目计划阶段工作分配视图对于进度规划、项目评估和经费预算都能起到有益的作用。
九、数据库设计
属性 | 名称 | 类型 | 长度 | 主键 |
物品编号 | id | int | 32 | y |
物品名称 | name | string | 不限 | n |
物品描述 | desc | string | 不限 | n |
物品分类 | itemclass | int | 32 | n |
物品种类 | itemtype | int | 32 | n |
物品是否在背包中显示 | isinpackage | int | 32 | n |
物品是否唯一 | isunique | int | 32 | n |
物品是否可使用 | canuse | int | 32 | n |
物品是否可堆叠 | isstack | int | 32 | n |
物品最高堆叠数 | stacklimit | int | 32 | n |
物品是否可合成 | canbine | int | 32 | n |
物品是否可出售 | cansale | int | 32 | n |
物品出售价格 | saleprice | int | 32 | n简单的java游戏代码 |
物品额外属性 | effectparam | int | 32 | n |
物品图片资源路径 | iconpath | string | 不限 | n |
物品唯一编号 | tid | int | 32 | n |
物品数量 | count | int | 32 | n |
物品锁定数量 | lockcount | int | 32 | n |
物品词缀 | attrinfo | int | 32 | n |
十、系统概念原型的核心工作机制
每个视图都是从不同的角度对软件架构进行描述和建模,比如从功能的角度、从代码结构的角度、从运行时结构的角度、从目录文件的角度,或者从项目团队组织结构的角度。
软件架构代表了软件系统的整体设计结构,它应该是所有这些视图的集合。但我们不会将不同角度的这些视图整合起来,因为不便于阅读和更新。不过我们会有意识地将不同角度的视图之间的映射关系和重叠部分了然于胸,从而深刻理解软件架构内在的一致性和完整性,这就是系统概念原型。
基于以上各视图,我们就可以总结出此项目的概念原型,以下总结本系统的工作流程:玩家通过点击特定的背包按钮,进入到背包页面,查看背包物品,可以通过属性对物品进行分类查看,然后选择需要使用的物品,或者对物品进行升级,亦或者对物品进行出售。玩家进入背包的时候,会接受服务器的数据包,了解服务器是否已经准备好,如果已经准备好,请求服务器发送所需要的数据包给到客户端,然后通过界面展示给玩家。
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论