u3d遊戲客戶端架構

主要是mvc架構，

m層為資料層，兩個用途：1儲存資料；2傳送資料更新資訊；

v層為檢視層，兩個用途：1接受使用者從介面上的操作；2根據m層的資料顯示相應的介面；

c層為控制層，兩個用途：1處理和介面無關的**邏輯；2接受和處理網路資料；

繼續……

按照自己的經驗，遊戲中的mvc架構有兩種思想，1，以mvc架構為主，整個框架就是乙個mvc架構；2，以物件思想為主，物件中使用mvc架構，整個框架使用乙個平行結構。先看看使用mvc架構的方式，如下圖：

各個模組分為mvc三部分，有些模組可能只有其中一部分，比如只有view，只有model等。不同模組的mvc三部分對於其他模組也是可見的，比如bagview可以訪問rolectrl，也許不需要訪問，這裡只是舉例說明，rolectrl對於bagview是可見的。

整個框架的執行流程如下：

a 玩家在介面上操作的情況：

1 玩家的輸入在view層處理，比如玩家在包裹面板上使用了乙個道具，此道具的作用是給玩家乙個buf，操作由bagview處理；

2 bagview將使用道具的操作轉換為和介面無關的操作，傳送給bagctrl，比如將介面上該道具的位置轉換為包裹中的索引位置；

3 bagctrl在收到請求後將操作組裝成請求包，通過networkio傳送給伺服器；

此時，操作的前半部分就已經結束，操作帶來的影響需要伺服器處理

4 伺服器返回操作結果，比如此時返回了兩個協議，通過networkio中對包的協議分析，分別傳送給bagctrl處理和rolectrl處理；

5 bagctrl根據包的內容，此處應該是包裹中扣除乙個道具，呼叫bagmodel的方法，扣除指定的道具；

6 bagmodel將資料更新，並傳送包裹更新的事件到事件管理器；

7 事件管理器將包裹更新事件廣播出來；

8 bagview註冊了包裹更新事件的監聽，bagview在收到事件後判斷是否需要更新介面顯示，如果需要，則獲取bagmodel的資料，根據資料更新介面；

包裹的處理就已經完成了

9 rolectrl根據包的內容，此處應該是玩家擁有了乙個新的buf，呼叫rolemodel的方法，增加buf；

10 rolemodel將資料更新，並傳送玩家資訊更新的事件到事件管理器；

11 事件管理器將玩家資訊更新事件廣播出來；

12 roleview和headview都註冊了玩家資訊更新事件的監聽，

13 roleview根據當前玩家狀態決定是否需要更新玩家3d形象，如果需要，則獲取rolemodel的資料，做相應更新，比如在頭頂加乙個特效等；

14 headview根據當前玩家狀態決定是否需要更新玩家頭像資訊，如果需要，則獲取rolemodel的資料，做相應更新，比如在面板上加乙個buf的圖示等；

b 處理網路包的情況，其實就是上面流程中從步驟4開始到最後。

整個流程中需要注意幾點：

1 在接受玩家的操作之後，如果沒有特殊需求，view不能直接更改顯示，顯示的更改都要根據model發出的事件來觸發；否則，在多個條件影響同乙個view時，會出現錯誤；

2 view不能直接修改model的資料，只能讀取，model的修改只能由ctrl來做；否則整個框架在遊戲規模變大之後會變得相當混亂；

3model的作用只能是修改自身資料，並且傳送事情出來，不能有其他操作；

由於完全開發各個模組各個層之間的可見關係，會將整個框架變為乙個很複雜的網狀結構，給拆分和擴充套件帶來很大的麻煩，所以在可見性上做以下限制：

1 model層不能呼叫任何其他模組方法，只能呼叫事件管理器方法傳送事件；

2 control層只能呼叫自己模組的model層方法；也就是說control層不能修改其他模組model層的資料；如果乙個control必須要更改另外乙個model的資料，可以通過呼叫另外乙個control的方法來間接修改；

3 control層之間可以相互呼叫；因為處理網路io的包時不管怎麼樣都需要在乙個地方處理各個模組之間的互動，所以可以放在control層；

4 view可以呼叫其他模組的control層，但是不能view呼叫其他view，如果出現這種情況，一般都是設計不當造成的；

整個框架的呼叫關係就如下所示：

先寫到這裡……