現在的商業遊戲開發,業務層絕大多數都是在Lua層實現。UI作為業務一哥,首當其衝。上一篇文章我們講了UI框架在C#層的封裝,這篇文章核心介紹下在Lua層的封裝。還有之前遺留的幾個問題數據層和顯示層的抽離,還有復用組件這裡都做一個介紹。
為了理清楚思路,我們這裡用一個簡單的圖來畫一下,我們需要做哪些東西,以及為什麼要這麼做。
通過簡單的不知什麼圖的圖來理了一個簡單思路,得出的結論是有很多東西需要寫。
第一類就是上面這中,普通的界面,他獨立存在,不依賴與其他功能可以直接打開的,那麼這類界面我們單獨分類,獨立出來基類繼承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 嘴炮王者