現在的商業遊戲開發,業務層絕大多數都是在Lua層實現。UI作為業務一哥,首當其衝。上一篇文章我們講了UI框架在C#層的封裝,這篇文章核心介紹下在Lua層的封裝。還有之前遺留的幾個問題數據層和顯示層的抽離,還有復用組件這裡都做一個介紹。

馬鑫:Unity遊戲開發筆記-UI框架?

zhuanlan.zhihu.com
圖標

為了理清楚思路,我們這裡用一個簡單的圖來畫一下,我們需要做哪些東西,以及為什麼要這麼做。

通過簡單的不知什麼圖的圖來理了一個簡單思路,得出的結論是有很多東西需要寫。

  1. 顯示層的基類也就是類似UIBase
  2. 這裡有一點圖上沒有提到,就是對於繼承UIBase的分類。我先去網上偷幾張商業遊戲的圖片我們來看看現在遊戲中的需要我們區分的類型有哪些。這裡我挑選了老東家的《天使紀元》來做一個簡單的說明。圖片來自於百度,侵刪。

第一類就是上面這中,普通的界面,他獨立存在,不依賴與其他功能可以直接打開的,那麼這類界面我們單獨分類,獨立出來基類繼承UIBase假定為UIBaseNormal類。

第二類界面就是上面這種,由多個獨立的界面的構成,但是又依賴與某一個功能的打開。如上圖的貴族認證界面就是依賴與VIP貴族的打開。這類界面我們也單獨分類,獨立基類繼承自UIBase假定名字為UIBaseToggleWind類。這裡有人可能有疑問,為什麼這裡還是按照上面的邏輯去直接寫不就好了,點一個Toggle我新打開一個界面。理論上可以這樣寫,但是程序員耐不住策劃需求啊~萬一哪天策劃說貴族的這幾個頁簽我不想放在這裡了,我想放在充值界面,貴族界面我想顯示簽到頁簽。你可能就會被勸退,因為設計層面沒有支持到。你只能慢慢挪動你的代碼。所以我們的UI框架需要支持父節點和子節點的綁定,當然這個綁定可以讓策划走配置,你想放哪兒就放哪兒。

第三類就是上圖我們箭頭指向的,不獨立但是可復用的Object。這類框大家都知道,遊戲中顯示道具信息的通用框,隨處可見。對這類型的框,我們獨立也要封裝,同樣繼承UIBase我們可以叫他UIBaseSlot。


3.上面展開思路有點多,那麼第三點就是需要一個顯示管理層,管理各個模塊的創建,顯示等等,功能類似C#層的UIManager,但是明顯C#的基礎介面設計已經不能滿足我們的需求了,那就++++++。

4.數據層的基類 取名DataBase好了 這裡要寫一點經驗值的東西了,我們遊戲中的數據變更一般選擇角色後,切換場景時,斷線重連,註銷賬號等地方,所以我們設計數據的基類一定要獨立出來這幾個介面。

5 數據管理層 統一管理繼承DataBase的所有數據管理類。取名DataManager好了~Emmm 詞窮啊~

6 中間層事件管理的封裝,EventSystem是解耦神器,這個中間件後續的文章,單獨獨立出來一篇介紹。Todo~

7 忽然想起來一個很重要的點,就是業務層Lua基礎代碼生成工具,重複性代碼還是需要讓工具來幫你做的~

思路大體理的差不多了~下面我們開始寫~

Tobe Continue.........

本篇持續更新~

後續會傳一些關鍵的代碼~畢竟我也還沒寫呢~233333 嘴炮王者


推薦閱讀:
相关文章