基於游戲背包系統的設計方案

一、項目介紹

    該項目是針對制作一款游戲，在本文中，我們只選取其中的一個功能進行分析，我們選擇背包系統作為我們的設計目標。
    背包系統的核心是，背包界面負責顯示游戲中玩家擁有的游戲道具，在邏輯上保存玩家的道具物品信息，並對背包中的物品進行使用、出售、升級等操作。

二、運行環境和技術選型說明

    項目游戲主體分為游戲內邏輯與游戲外邏輯，游戲內部主體邏輯使用Ｃ＃語言編寫，使用單例模式、觀察者模式、工廠模式等架構編輯游戲主體邏輯。游戲外部UI系統及界面主要使用Lua語言編寫，通過事件通知交互機制完成消息傳遞。使用成熟的ToLua框架完成Lua與Ｃ＃代碼的邏輯交互。系統的網絡通信部分設計使用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
物品是否可合成	canCombine	Int	32	N
物品是否可出售	canSale	Int	32	N
物品出售價格	salePrice	Int	32	N
物品額外屬性	effectParam	Int	32	N
物品圖片資源路徑	iconPath	String	不限	N
物品唯一編號	tid	Int	32	N
物品數量	count	Int	32	N
物品鎖定數量	lockCount	Int	32	N
物品詞綴	attrInfo	Int	32	N

十、系統概念原型的核心工作機制

    每個視圖都是從不同的角度對軟件架構進行描述和建模，比如從功能的角度、從代碼結構的角度、從運行時結構的角度、從目錄文件的角度，或者從項目團隊組織結構的角度。

    軟件架構代表了軟件系統的整體設計結構，它應該是所有這些視圖的集合。但我們不會將不同角度的這些視圖整合起來，因為不便於閱讀和更新。不過我們會有意識地將不同角度的視圖之間的映射關系和重疊部分了然於胸，從而深刻理解軟件架構內在的一致性和完整性，這就是系統概念原型。

    基於以上各視圖，我們就可以總結出此項目的概念原型，以下總結本系統的工作流程：玩家通過點擊特定的背包按鈕，進入到背包頁面，查看背包物品，可以通過屬性對物品進行分類查看，然后選擇需要使用的物品，或者對物品進行升級，亦或者對物品進行出售。玩家進入背包的時候，會接受服務器的數據包，了解服務器是否已經准備好，如果已經准備好，請求服務器發送所需要的數據包給到客戶端，然后通過界面展示給玩家。