webgame模組劃分

轉自：

http://blog.csdn.net/txiejun/article/details/5924108

模組劃分：模組劃分主要包括“核心模組劃分”和“子模組劃分”。核心模組的劃分思路是這樣的：它們是遊戲啟動所必須的，相互之間是緊密聯絡的，還要經常的被子模組調用；而相對的，子模組的劃分思路是：他們在遊戲啟動過程中不是必須的，可以在遊戲過程中再載入，子模組相互之間基本上完全沒有聯絡，一個子模組的增加和刪除不會影響到任何其他子模組，子模組可能需要調用主程式的介面或者獲得主程式的資料，但主程式絕對不應該依賴某個子模組。

        明確了模組劃分思路再具體看看哪些部分應該劃分為核心模組，哪些部分應該劃分為子模組。一般情況下，核心模組按照遊戲啟動順序包括：一個殼子SWF → 設定檔包 → 登入註冊SWF → 主程式SWF → 主UI的SWF → 公用素材包。而子模組相對來說簡單很多，比如具體的某個小遊戲，某個情境，以及某個情境裡的觸發功能等等。下面我對核心模組逐一略做解釋。“一個殼子SWF”：這是一個體積很小，但意義很大的SWF；它後面總是跟著隨機變數，確保每次使用者載入的都是最新的；它裡面定義著一些需要經常更新而且每次更新都必須保證使用者也在第一時間就得到最新值的變數；它裡面最好有一個簡單背景圖，保證使用者在超低網速的時候輸入遊戲網址不至於長時間面對一片空白；它裡面有安全性原則的設定，是我們遊戲和很多第三方平台合作的基石；它裡面還定義著主程式被載入進來之前的遊戲啟動流程等等。“設定檔包”：核心模組版本號碼啊，全域文字說明啊，service介面定義啊，各個核心模組需要的配置資訊啊什麼的，一般是一些XML檔案。“登入註冊SWF”：這個簡單，在載入重量級的SWF前，先載入登入註冊SWF,可以保證使用者第一時間就能開啟登入註冊介面，而且可以有效節省伺服器頻寬。“主程式SWF”：這個就是我前面費了好大勁講的主程式部分了。“主UI”：主程式和主UI為什麼要分開兩個SWF，我前面已經提過了，後面還有說明，這裡暫時不講。“公用素材包”：公用素材包是一個遊戲不可缺少，但也不能過分依賴的東西。它包括一些全域的道具和效果，比如表情、技能特效、情境傳送門等等。公用素材包裡面最好就是一些簡單的動畫，體積小功能簡單，嚴禁在公用素材包裡添加上百K的東西，或者代碼上百行的小模組，公用素材包建議500K以下。

        看了上面的講解，你可以能覺得核心模組分那麼多，太麻煩了。不錯，在我看來，對SWF載入流程的分解和控制，對非同步程式的掌控正是衡量一個AS程式員是否經驗豐富，是否足夠老道的重要指標，很多從其它語言轉到AS並有多年編程經驗的朋友，架構方面可能和AS程式員差不多，甚至比很多自學成才的AS程式員做的更好，但這方面往往不如長期與CPU和SWF體積搏鬥的老牌AS程式員。核心模組劃分的越合理，使用者體驗往往越好，後期編寫和維護代碼的效率會越高，但在前期會比較麻煩，而且對架構師的架構經驗和能力必須提出更高的要求。什麼都不分，主程式、素材、核心模組都弄在一個SWF裡，使用者一開始必須先下載完這個SWF,或者弄了一堆核心模組和超多公用素材，使用者一開始必須面對loading條不停的周而復始，必須等所有核心要素全部載入完成才能進行一些基本操作的做法，從架構角度上講，是最簡單的做法，因為不用過多考慮複雜的非同步和SWF拆分問題，但從使用者體驗和長遠的開發維護上講是非常不利的。根據我們的經驗，使用者登入前載入的所有資源體積應該控制在200K左右，而使用者進入遊戲主情境前，載入的資源總數應該控制在1M左右。還有前面提到過的那位用了pureMVC後項目編譯一下要十幾分鐘的朋友，估計就是把所有東西都弄到一個SWF裡的做法。主程式隨便改動測試一下，就要十幾分鐘，牽一髮而動全身，開發效率從何談起？根據我們的經驗，任何主程式、核心模組還有子模組的編譯，都必須在10秒以內，這才是合理的——我的機器是07年花了3000多買的戴爾品牌機。