在進行項目架構階段,游戲框架可以解決一部分問題。剩下的架構問題還需要根據不同的項目解決。總之游戲框架是游戲架構的一部分。 ## 關于錘子和釘子: 最近又拿起了《代碼大全》和《暗時間》，想起來《暗時間》的作者維護了一個個人博客,就去逛一逛。 這幾天一直琢磨一句話:手里拿著錘子看什么都像釘子。于是翻到了博客[《錘子和釘子》](http://mindhacks.cn/2009/01/16/hammers-and-nails/)。我的這個行為很好的闡述了什么叫:手里拿著錘子看什么都想釘子- -。 看完之后深度自省了一下- - 文章很有趣,推薦大家讀下。 對于框架,用錘子和釘子來比喻不太恰當,框架就像一把劍,而項目就是錘子。 框架需要經過項目的千錘百煉,才會越來越鋒利(當然我的意思不是為了寫框架而寫框架,框架是副產品,真正鋒利的是自己)。 對于這句話:手里拿著錘子看什么都像釘子。我的觀點是:如果以前沒使用過這把錘子,當你使用這把錘子的時候,就會給你帶來新的視野,新的角度去思考問題。 比如以前自己開發游戲都沒有框架這種概念的,寫代碼都是重新造個小輪子,輪子很不好用,當時視野又小又不知道有其他替代的解決方案,當聽到游戲框架這個詞的時候才開始去思考關于框架的問題,當開始著手搭建自己的框架時,才會開始注意到以前沒注意到的東西。 所以,開始打造自己的框架吧! ### 關于架構: 首先推薦一篇關于架構的好文:[10年感觸：架構是什么？——消滅架構！](http://www.manew.com/thread-89749-1-1.html)，文中作者很通俗地解釋了什么是架構: > 架構是一個約定，一個規則，一個大家都懂得遵守的共識。那這是什么樣的約定、什么樣的規則、什么樣的共識呢？ > 我以包為例，我經常出差，雙肩背包里裝了不少東西。筆記本電腦、電源、2個上網卡、鼠標、USB線、一盒大的名片、一盒小的名片、口香糖、Mini-DisplayPort轉VGA接口、U盤、幾根筆、小螺絲刀、洗漱用品、干凈衣服、襪子、香水、老婆給我帶的抹臉膏（她嫌我最近累，臉有點黃）、錢包、Token卡、耳機、紙巾、USB線、U盤等。這個包有很多格子，最外面的格子我放常用的，比如筆、紙、一盒小的名片等；中間的格子一般放的是衣服、襪子、洗漱用品、香水等；靠背的那個大格子放了筆記本電腦，和筆記本電腦相近的小格子放的是兩個上網卡、Mini-DisplayPort轉VGA接口、大盒名片、記事本，和筆記本電腦相近的大格子放的是電源、鼠標、口香糖等。 > 我閉著眼睛都可以將我的東西從包里掏出來，閉著眼睛都可以將東西塞到包里！但是，非常不幸的是，一旦我老婆整理過我的包，那我就很慘了，老是因為找不到東西而變得抓狂！更不幸的，要是我那個不到兩歲的“小可愛”翻過，就更不得了了。 > 這個包就是我放所有物品的“架構”，每一個東西放置的位置就是我的“約定、規則、共識”。倘若我老婆也知道我的“架構”、我的“約定、規則、共識”，那么不管她怎么動我的包，我都照樣能夠輕易的拿東西或者放東西。進一步，如果我的同事也知道我的“架構”，知道我的“約定、規則、共識”，那么他們什么時候動我的包，我也毫無所知！ ## 架構的典型組成部分: 以下分類來自《代碼大全》3.5小節的《架構的典型組成部分》,并用我的框架來做了一遍對比。 ### 由框架解決的架構問題: #### 主要的類: 書上寫的是:架構應該詳細定義所用的主要的類。在我的框架里,提供的主要的的類有QFSM(狀態機),QMsgDispatcher(消息分發器)。在未來還會提供ResourceManager,GameManager等,現在框架中有一份實現,但是其實現有些復雜,不易閱讀和理解,等有比較容易理解的實現時候會對其寫一篇文章,還有一些主要的模塊需要客戶端自己實現。 #### 資源管理: 包括資源加載/卸載,音頻、模型、紋理等,是模塊化管理資源還是統一管理資源?,我的框架目前有一份實現,但不夠易用,未來會提供易用版本。 #### 國際化/本地化: 很多游戲都會有海外版,國內版,各個國家的版本,如何進行切換/翻譯?(我的框架未來會提供)。 #### 輸入輸出、錯誤處理: 我的框架未來會提供錯誤日志。 #### 性能: 1.如何檢測?框架應該提供相應的數據。 2.指標如何確定?速度?內存?成本?，游戲開發中還有Draw Call,GC等等(我的框架未來會提供)。 ### 由客戶端解決的架構問題: #### 程序組織: 包括文件結構應該反映文件或文件夾之間的關系,要思考以什么方式組織比如:先按照模塊分文件結構再按照MVC或者先按照MVC分,然后再按照每個模塊來區分，再推薦一篇好文:[Unity3D手游開發實踐《騰訊桌球》客戶端開發經驗總結](http://www.gameres.com/654759.html)()(文章略長),文章的第一小節就有講到關于文件組織。 #### 數據設計: 書中指的是設計數據庫表。在游戲框架中是指提供給客戶端使用的數據結構定義,包括何種結構定義玩家的數據信息,策劃表結構的定義等等。好的數據結構定義 + 爛的代碼質量 \>\> 壞的數據結構定義 + 好的代碼質量。 #### 業務規則: 屬于游戲邏輯范疇,需客戶端實現。 #### 用戶界面設計: 用戶界面組件之間如何通信,如何管理?用戶界面和業務規則還有數據之間如何通信?通信方面已提供消息分發器(QMsgDispatcher)。 #### 安全性: 資源如何加密,如何防破解,防反編譯,安全數據檢查,服務器驗證等等。 #### 可伸縮性: 可伸縮性是指滿足未來需求的能力，包括程序的可擴展性,用戶量增長時系統的策略等等。 #### 互用性: 如果預計這個系統會與其他軟件或硬件共享數據或資源,架構應該描述如何完成這一任務。 #### 容錯性: 舉個例子:當界面跳轉時,系統不可以接受輸入(我的框架不提供)。 #### 關于買還是造的決策: Unity可以有很多可以使用的插件、C#庫可以使用,很多問題迎刃而解,(我的框架不會包含任何插件,項目不同需要的插件也不同)。 ## 核對表摘自《代碼大全》: 1. 程序的整體組織結構是否清晰?是否包含一個良好的架構全局觀(及其理由)? 2. 是否明確定義了主要的構造塊(包括每個構造塊的職責范圍及其他構造塊接口)? 3. 是否明顯涵蓋了"需求"中列出的所有功能(每個功能對應的架構塊不太多也不太少)? 4. 是否描述并論證了那些最關鍵的類? 5. 是否描述并論證了數據設計? 6. 書否詳細定義了數據庫的組織結構和內容? 7. 是否支出了所用關鍵的業務規則,并描述其對系統的影響? 8. 是否描述了用戶界面設計的策略? 9. 是否將用戶界面模塊化,使界面的變更不會影響程序其余部分? 10. 是否描述并論證了處理I/O的策略? 11. 是否估算了稀缺資源(如線程、數據庫連接、句柄、網絡帶寬等)的使用量,是否描述并論證了資源管理的策略? 12. 是否描述了架構的安全需求? 13. 架構是否為每個類、每個子系統、或每個功能域(functionality area)提供空間與實踐預算? 14. 架構是否描述了如何達到可伸縮性? 15. 架構是否關注互操作性? 16. 是否描述了國際化/本地化的策略? 17. 是否提供了一套內聚的錯誤處理策略? 18. 是否規定了容錯的辦法(如果需要)? 19. 是否正式了系統各個部分的技術可行性? 20. 是否詳細描述了過度工程的方法? 21. 是否包含了必要的"買 vs 造"的決策? 22. 架構是否描述了如何加工被復用的代碼,使之符合其他架構的目標? 23. 是否將架構設計得能夠使用很可能出現的變更? 24. 你,作為一名實現該系統的程序員,是否對這個架構感覺良好? ### 歡迎討論! 轉載請注明地址：涼鞋的筆記：[liangxiegame.com](http://liangxiegame.com) ## 更多內容 * QFramework 地址：[https://github.com/liangxiegame/QFramework](https://github.com/liangxiegame/QFramework) * QQ 交流群：[623597263](http://shang.qq.com/wpa/qunwpa?idkey=706b8eef0fff3fe4be9ce27c8702ad7d8cc1bceabe3b7c0430ec9559b3a9ce66) * **Unity 進階小班**： * 主要訓練內容： * 框架搭建訓練（第一年） * 跟著案例學 Shader（第一年） * 副業的孵化（第二年、第三年） * 權益、授課形式等具體詳情請查看[《小班產品手冊》](https://liangxiegame.com/master/intro)：https://liangxiegame.com/master/intro * 關注公眾號：liangxiegame 獲取第一時間更新通知及更多的免費內容。