Unity 游戲框架搭建 2017 (六) 關於框架的一些好文和一些思考

在進行項目架構階段,游戲框架可以解決一部分問題。剩下的架構問題還需要根據不同的項目解決。總之游戲框架是游戲架構的一部分。

關於錘子和釘子:

最近又拿起了《代碼大全》和《暗時間》，想起來《暗時間》的作者維護了一個個人博客,就去逛一逛。

這幾天一直琢磨一句話:手里拿着錘子看什么都像釘子。於是翻到了博客《錘子和釘子》。我的這個行為很好的闡述了什么叫:手里拿着錘子看什么都想釘子- -。

看完之后深度自省了一下- -

文章很有趣,推薦大家讀下。

對於框架,用錘子和釘子來比喻不太恰當,框架就像一把劍,而項目就是錘子。

框架需要經過項目的千錘百煉,才會越來越鋒利(當然我的意思不是為了寫框架而寫框架,框架是副產品,真正鋒利的是自己)。

對於這句話:手里拿着錘子看什么都像釘子。我的觀點是:如果以前沒使用過這把錘子,當你使用這把錘子的時候,就會給你帶來新的視野,新的角度去思考問題。

比如以前自己開發游戲都沒有框架這種概念的,寫代碼都是重新造個小輪子,輪子很不好用,當時視野又小又不知道有其他替代的解決方案,當聽到游戲框架這個詞的時候才開始去思考關於框架的問題,當開始着手搭建自己的框架時,才會開始注意到以前沒注意到的東西。

所以,開始打造自己的框架吧!

關於架構:

首先推薦一篇關於架構的好文:10年感觸：架構是什么？——消滅架構！，文中作者很通俗地解釋了什么是架構:

架構是一個約定，一個規則，一個大家都懂得遵守的共識。那這是什么樣的約定、什么樣的規則、什么樣的共識呢？

我以包為例，我經常出差，雙肩背包里裝了不少東西。筆記本電腦、電源、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手游開發實踐《騰訊桌球》客戶端開發經驗總結()(文章略長),文章的第一小節就有講到關於文件組織。

數據設計:

書中指的是設計數據庫表。在游戲框架中是指提供給客戶端使用的數據結構定義,包括何種結構定義玩家的數據信息,策划表結構的定義等等。好的數據結構定義 + 爛的代碼質量 >> 壞的數據結構定義 + 好的代碼質量。

業務規則:

屬於游戲邏輯范疇,需客戶端實現。

用戶界面設計:

用戶界面組件之間如何通信,如何管理?用戶界面和業務規則還有數據之間如何通信?通信方面已提供消息分發器(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

更多內容

• QFramework 地址：https://github.com/liangxiegame/QFramework

• QQ 交流群：623597263

• Unity 進階小班：

  • 主要訓練內容：
    • 框架搭建訓練（第一年）
    • 跟着案例學 Shader（第一年）
    • 副業的孵化（第二年、第三年）
  • 權益、授課形式等具體詳情請查看《小班產品手冊》：https://liangxiegame.com/master/intro

• 關注公眾號：liangxiegame 獲取第一時間更新通知及更多的免費內容。