基于游戏背包系统的设计方案.pdf

基基于于游游戏戏背背包包系系统统的的设设计计⽅⽅案案

⼀⼀、、项项⽬⽬介介绍绍

该项⽬是针对制作⼀款游戏，在本⽂中，们只选取其中的⼀个功能进⾏分析，们选择背包系统作为们的设计⽬标。

背包系统的核⼼是，背包界⾯负责显⽰游戏中玩家拥有的游戏道具，在逻辑上保存玩家的道具物品信息，并对背包中的物品进⾏使⽤、出售、升级等操作。

⼆⼆、、运运⾏⾏环环境境和和技技术术选选型型说说明明

项⽬游戏主体分为游戏内逻辑与游戏外逻辑，游戏内部主体逻辑使⽤Ｃ＃语⾔编写，使⽤单例模式、观察者模式、⼯⼚模式等架构编辑游戏主体逻辑。游戏外部UI系统及界⾯

主要使⽤Lua语⾔编写，通过事件通知交互机制完成消息传递。使⽤成熟的ToLua框架完成Lua与Ｃ＃代码的逻辑交互。系统的⽹络通信部分设计使⽤Socket通信与protobuf协议

结合的⽅式进⾏。

三三、、架架构构风风格格

在项⽬模块开发中，是基于MVC框架进⾏的，将各模块业务分拆成三部分：Model：保存游戏中对象的数据结构，例如⾓⾊信息、物品信息等等。Controller：处理游戏业务逻

辑。例如核⼼玩法、物品使⽤等。View：游戏世界中可以见的对象，和Model绑定，在游戏中展现物体及UI对象。MVC具体使⽤⽅法为使⽤Manager类控制操作流程，UI类设置

游戏内按钮、⽂字、图⽚等，Data类等设置为对应数据基类，进⽽实现程序前端数据展⽰与后端数据存储逻辑分离。游戏中的背包系统也使⽤MVC框架结构，使⽤Manager类控

制游戏流程，UI类设置游戏内按钮、⽂字、图⽚等，Data类等设置为基类，实现程序前后端分离。

四四、、设设计计模模式式

对于背包物品，最重要的机制是需要实时获取服务器对物品的相关修改，出于模块化的需求，由于物品涉及的模块众多如战⽃掉落、任务领取、玩家购买等等，物品的相关修

改需要独⽴负责，尽量减少与其他模块的耦合程度，因此物品相应的⽅法设计使⽤使⽤观察者模式的设计模式，通过服务器推送通知的⽅式进⾏更新。

分析：在软件⼯程中，模块的内聚和耦合是度量模块化质量的之⼀。观察者模式适⽤于当对⼀个对象的改变需要同时改变其他对象，⽽⼜不知道具体有多少对象有待改变的情

况。当对象之间的关系具有⼀对多的相关信息依赖时，⼀个被观察者对象的信息状态数据发⽣改变时，将对外发送通知，对该事件添加监听的所有观察者可以同时对其变化进疔

⾃⾝更新。这种模式可以通过低耦合度的⽅式灵活的处理⼀对多的对象数据关系。观察者模式实现了表⽰层和数据逻辑层的分离，定义了稳定的消息传递机制，并抽象了更新接

⼝，使得观察者可以⾃定义⾃⾝的表现，从⽽通过抽象的耦合⽅式连接观察者与被观察者．观察者对于被观察者是透明的，被观察者只拥有抽象观察者的列表，每个具体观察

者都符合⼀个抽象观察者的接⼝。但这种模式在使⽤通知更新的同时将造成⼀定的性能损耗，且没有相应的机制使观察者知道被观察对象变化产⽣的原因。如果在被观察者之间

有循环依赖的话，易造成循环调⽤导致系统崩溃。

对于游戏背包系统来说，背包中物品会受到其他模块的影响，但其他模块并不关⼼对于物品的处理⽅式，因此选择观察者模式的设计模式。

五五、、协协议议设设计计

背包模块需要在⽤户登录游戏后，从服务器获取该⽤户的物品相关信息，包含货币信息、⽤户相关显⽰物品信息等等⽤以在主界⾯中显⽰，因此需要在登陆成功后尽快向服务

器发起请求，但此时⽤户数据可能会因为服务器未完成数据的打包⽽报错，故此请求发送时间由服务器消息推送决定，在BagManager中定义服务器物品信息初始化完成消息通

知，⽤户完成登录后，当收到物品信息初始化完成消息后，向服务器发送物品信息请求。由于物品中存在体验类物品，在获取物品信息时，需要创建计时器同⼀管理物品过期相

关事件。

六六、、逻逻辑辑视视图图

七七、、执执⾏⾏视视图图

执⾏视图展⽰了系统运⾏时的时序结构特点，⽐如流程图、时序图等。执⾏视图中的每⼀个执⾏实体，⼀般称为组件，都是不同于其他组件的执⾏实体。如果有相同或相似的

执⾏实体那么就把他们合并成⼀个。

执⾏实体可以最终分解到软件的基本元素和软件的基本结构，因⽽与软件代码具有⽐较直接的映射关系。在设计与实现过程中，们⼀般将执⾏视图转换为伪代码之后，再进

⼀步转换为实现代码。

因此，执⾏视图其实表现的是系统中间⽐较动态的那⼀部分。鉴于此，们可以通过流程图来表⽰执⾏视图：

（这⾥的流程图，并不是专业的UML流程图，⽽是⼀种让⼈⽅便理解的执⾏流程，即页⾯跳转、操作等，通过这⼀种流程，来展⽰玩