Unity 遊戲框架搭建 2019 (五十六/五十七) 需求分析-架構中最重要的一環&從 EmptyGO 到 Manager Of Managers

涼鞋的筆記發表於2020-06-02
Unity遊戲框架架構Go

我們的專案開始立項的時候，最常見的一個情況就是：幾個人的小團隊，一開始什麼也不做，就開始寫程式碼，驗證邏輯，遊戲就開始寫起來了。而公司的一些所謂的領導層面一開始就把遊戲定義為我們要做一個大作。這個事情本身就是一個笑話，因為沒有任何的規劃和設計，我們就妄圖寫出一個傑出的作品出來是不現實的。Unity 在好用，那麼以這個心態去做遊戲，一定會寫不出來好的遊戲來。— 劉鋼《Unity 專案架構設計與開發管理》

以上這段話說得很清楚了，就是做一個專案的時候一定要做規劃和設計，當然這是從整個專案的角度來看，但作為開發者，對我們來說就要從技術上進行規劃和設計，而技術上的規劃和設計其實就是要做架構。

架構要做什麼？

在專案的初期，我們直接把架構理解為準備即可。我們仔細回憶一下在一個專案的準備階段，我們都會做什麼？

筆者一般是先分析需求，需求分析清楚了，就會對需求進行模組拆分，拆分之後就會去逐個驗證技術難點,這時候會選擇一些外掛等等。等驗證完畢就算是準備完畢了。

當然這一系列操作是筆者主動意識下完成的，但是其實還有很多習慣性的操作，比如用 QFramework、用公司的程式碼規範。

這就是筆者的準備階段做的事情了。當然專案不是筆者一個人做的，而是有多個人做，而筆者的模組拆分階段就已經可以把專案的工作量進行拆分了，而團隊成員都是按照模組進行分工的。

這就是筆者一般做一個專案的時候做的準備，也就是架構，也就是規劃和設計。很普通的事情，可能大家都在做。

但是仔細分析每一個操作，它背後都有很多故事和原因的。

比如一開始分析需求，這個習慣，都是被迫養成的，因為如果一開始不清楚需求就開工，那麼就會導致對專案開發的走向判斷錯誤，走向判斷錯誤，那麼當專案擴張的時候就會手足無措，體驗非常差，而需求不清楚的話，在做專案的時候就會感到有力使不出，很難受的。作為一個開發者，雖然本職工作不是做產品或策劃，但是把業務需求理解清楚，會對專案的理解會更加深刻，而如果知道了每個業務需求背後的原因，自己做專案的心態都會變得不一樣。但是主動去理解需求是很多開發者不屑於去做的。不過我們可以好好算一筆賬，假如在非常清楚需求的前提下，去完成這些需求要花三週的時間，但是在對需求模稜兩可的前提下，去完成這些需求可能要花四周的時間。多出一週的原因，是因為需求模糊所造成的多餘的工作量。而把需求理解清楚，很簡單，一張紙一支筆花兩個小時，就清楚了。

當然以上這些情況是適用於開發流程比較成熟的公司，比如策劃提前兩個月就把需求明確好了，美術提前一個月就把美術資源搞好了，而開發者到手的資源和需求全部都是完整的不需要排查的。

但是市面上大部分公司做不到以上的流程，真實情況下，都是美術開發策劃同時開工的，策劃都沒想清楚就給了需求，給的需求往往都是非常模糊的，美術給的資源都要排查一次，這樣就導致開發者會多出很多工作量。

但是在這種情況下，更是要理解清楚需求。策劃自己都不清楚的需求，開發者要理解清楚，沒錯。開發者要想理解清楚需求，就要幫助策劃理清思路，也就是策劃要和開發多溝通，要理解策劃在做遊戲設計的時候在考慮什麼事情。

當然以上單對很多人來說都很難，因為太在乎面子，太在乎尊嚴，瞧不起策劃等等。一個專案好好做也是做，不好好做也是做，為什麼不好好做呢？同樣都是花自己的時間，如果不好好做那豈不是浪費了這段時間？

而一個開發者，最好是在最初就要有一顆積極的心態，什麼叫積極的心態，就是為了做好專案，可以不在乎尊嚴，不在乎面子，而是一心想做好它，為了專案可以在爭執的時候選擇妥協，因為決定一個開發者價值的是專案，而不是尊嚴和麵子。比如，到另一家公司去求職，你不能說這個專案是因為策劃 SB 才做成這樣的，而要說這個專案是我做的。

好了，說得有點遠了。總之，筆者只是想說，理解業務，分析需求是架構的第一件要做的事情。而做好專案是架構的最終目的。

OK，其實還有一種情況沒有講完，這種情況是大多數開發者遇到的，就是專案已經開始了，但是需求還是很模糊，這時候，對開發者的要求會比較高，這時候大家只要記住一點就好，要容忍當前專案的不完美，記住這一點，專案的配置就算是最低，在最艱難的環境下都有機會絕處逢生。但是如果容忍不了當前的不完美，比如策劃需求不清楚，老子就不幹了，這樣專案，那最終只會造成專案的 Delay，對自己對公司都不是啥好事。我們要做的就是，策劃需求不清楚，OK，找它聊去，總歸能聊明白的，聊完策劃也明白，自己也明白。如果還是不能完全明白，也沒關係，最起碼對需求的理解程度有所改善，這樣也是好的。

今天說了很多，結論就是，需求分析是最重要的一環，分析清楚了，更容易評估出工作量，更容易掌握對專案的走向，從而設計出面向未來的專案結構，總之，不要天天呆在電腦前寫程式碼，多花點時間去思考產品可以事半功倍。

從 EmptyGO 到 Manager Of Managers

以下為 劉鋼老師的《Unity 專案架構設計與開發管理》部分文字稿。

我們今天探討一個話題。Unity 的架構有很多方法，所謂的流派，如下所示:

  1. EmptyGO:
  2. Simple GameManager
  3. Manager Of Managers
    4. MVCS/MVVM
  4. ECS (Entity Component Based System)

Empty GO

006tNc79gy1fzftlqbxgaj30y60bldma.jpg
那我們一起來沿著一個思路走下去，看看怎麼樣的找到一個架構設計的最優方法。當我們談到 Unity 的專案設計，可能一開始的時候，我們會寫一堆 GameObject，比方說場景裡有一些主角、怪物或者一些靜態物體等等，我們習慣會去寫一些指令碼來控制這些 GameObject。而剩下的就是和這些 GameObject 沒有明顯關係的，一些 UI、Manager、記憶體池這些東西。我們習慣上，會建立一個 Empty 的 GameObject，然後把控制 UI、Manager、記憶體池這些東西的指令碼往這個 GameObject 上一掛，那麼我們的專案就算是有架構的東西了，非常值得鼓勵，這就算是一個架構的雛形了。那麼在接下來我們訪問資料的時候，通常需要 GameObject.Find 或 Object.FindObjectOfType 這樣的 API，那麼這個東西呢，速度慢慢不慢我們先不說。一旦說，他們之間的一些引用關係有一些變化的時候，我們就要一個個 Search Find 地查詢程式碼。那麼做著做著很快就會發現，這不是一個很好的方法。一旦你的專案 規模，慢慢地膨脹的時候，你就會發現，我單單的用一個 Empty 的 GameOject 來涵蓋所有無關的控制邏輯的時候，它不能滿足你的需求，尤其是一些 UI 攪在一起的時候，就會造成更大的混亂。

而假如，我們使用 MonoBehaviourSimplify 就不會產生這個問題了。

不過我們接著文字稿繼續。

Simple GameManager

006tNc79gy1fzftlurtvtj30wa0dctf2.jpg
由以上這個問題，我們想到，是不是可以對這個架構進行改變？那麼很多人都知道，我們是不是可以把這個 Empty GO 直接改成一個 Singleton，那麼恭喜大家，大家已經開始上路了。那麼這是一個最簡單的架構方法，事實上也是最常用最有意義的一種。思想非常非常地簡單，但是，他的確可以起到一個很重要的作用。那麼，我們把剛才提到的這個 Empty GO 變成一個 Singleton，這個時候我們說它有一個明顯的好處，當你所有其他的 GameObject 想要訪問這樣一些公共邏輯的時候，我只要拿到 Instance 去呼叫他的方法，從你的遊戲的任何一個位置，都可以訪問到這樣的一些邏輯，包括一些 UI 的設計，包括一些模組的訪問，我們都變得容易了起來。

到這裡呢，與筆者當初接觸 Unity 時所使用的設計工具模式是一致的，都是先使用單例。

我們在接著往下。

Manager Of Managers

006tNc79gy1fzftlxm6gzj30wf0gyn7y.jpg
事實上一款遊戲裡面，和 GameObject 沒有直接關係的邏輯控制是非常非常複雜的，尤其有好多好多的內容，如果說我們把所有這些內容全部塞到這樣一個 Singleton GameObject 上去，你很快就會發現，好像是說我們有這樣一個集中的地方控制很多東西，但是馬上也會發生混亂，也就是說自己也搞不清楚這樣一個龐大的檔案裡面到底有什麼東西，那我們說，有著這樣一個思想的話，接下去我們是不是可以寫多個 Managers，那麼這些 Managers 就會有明顯的分工。

在上圖中，上邊可以有一個所謂的 MainManager，那麼它下面會有所謂的 EventManager、AudioManager、GUIManager、PoolManager、LevelManager、GameManager、SaveManager、MenuManager。所有的這些東西大家都可以將它做成是一個 Singleton，那麼在它們之間互相聯絡的時候，我們主要拿到每一個 Singleton 的 Instance，那麼接下來就能方便地在模組與模組之間進行相互的訪問。那麼這個基本上成為了我們以後可以做遊戲的時候一個最主流最基本的方法。那麼對於一些所謂的中型以上的專案的遊戲架構設計，這就是一個非常實用的方法。我不敢說它是最好的，但是它應該是一個非常非常實用的方法。

OK，終於寫到這裡了，我們回顧一下之前我們所學的知識，我們使用過物件池、還有我們的 MsgDispatcher。對應上邊的 PoolManager、EventManager，而通過閱讀以上的材料我們知道，Manager Of Managers 是一個非常實用的架構。那麼我們可以不可以在我們的庫基礎上，一一實現上圖中的每一個 Manager 呢？當然是可以的，而這其實是一個非常不錯的目標。可以讓我們的庫稱為一個真正意義上的框架，因為我們的庫提供了 Manager Of Managers 的架構。

那麼我們從下一篇開始逐個去分析這些模組。並再第二次整理結束之後就一一實現它們。

那麼我們的庫，接下來就不叫它庫了，而是叫它框架。

今天的內容就這些，我們收穫了一個不錯的目標，庫的方向也越來越清晰了。

轉載請註明地址：涼鞋的筆記：liangxiegame.com

更多內容

相關文章