從事游戲行業1年多了，個中心酸不知從何說起。拋開非技術的不說，一個開發者需要面對的最大問題，可能就是和策劃頻繁改變的需求做斗爭了吧，這時候就體現了設計模式的重要性，拋開正式的設計方式不說，先講講我1年多以來遇到的問題和想到的解決策略吧

最容易卡死的功能：結算界面

幾乎游戲中所有的游戲模式都需要一個對應的結算界面，來展示玩家本關的通關情況，每種戰斗的結算有著相似的動畫流程，但是卻不盡相同的樣式。
?

由于歷史原因，第一個版本的結算被我改成了圖中所示的結構，乍一看好似也很清晰，但是這個結構中存在2個致命的問題：

1.戰斗類型的增加導致代碼和UI無法維護

由于最初的幾個結算界面顯示是極其相似的，大概涉及到幾種固定的類型：文本、可滾動的數字、砸星動畫、獲得的貨幣列表、獲得的道具列表、人物經驗進度條、確定按鈕。于是我把所有結算的代碼放在了同一個文件下，這樣他們就可以共用很多基本相同的函數，稍有變化的地方，就根據戰斗類型進行特判，大致的形式會是這樣：
?

function SetJieSuanXXX()

? ???if BattleType == GameMode_NORMA then

? ?? ?? ?--相應邏輯

? ???elseif BattleType == GameMode_ClimbTower then

? ?? ?? ?--相應邏輯

? ???elseif BattleType == GameMode_Esoterica then

? ?? ?? ?--相應邏輯

? ???end

end

復制代碼

在界面很少的時候，這很節省工作量，假如現在滾動數字的動畫需要統一修改，我只需要修改一個函數就可以了。但是策劃們并不會滿足于統一使用的效果，在后續增加的10多種結算中，出現了各種復雜的需求：

1.有些道具列表需要根據是否有同軍團的人參加來決定是否顯示

2.某些模式的經驗條顯示的不是人物經驗，而是該活動對應的經驗進度

3.某些模式如果突破了某個記錄，則需要顯示蓋章特效

4.對于某種戰斗，如果在今日活動的時間內，結算界面顯示為A，如果不在今日活動時間內，結算界面顯示為B

5.對于某種戰斗的結算，需要先顯示翻牌界面，再顯示結算（類似DNF）

這些只是簡單舉些例子，買QQ賬號平臺對于原來寫在同一個代碼文件中的做法來說，這無疑是個噩夢，增加一種戰斗類型的成本越來越高，你需要特判各種戰斗類型和是否有活動來決定UI的最終樣式。冗余的代碼越來越多，事實的情況是，代碼長度從最初的800行，在幾個月后變成了2000行。這樣的代碼根本無法交接，對一個不熟悉該模塊的人來說，與其維護，不如重寫。

2.觸發結算并不是單線邏輯

戰斗結束后，客戶端會做兩件事：1.向服務器請求結算。2.播放劇情動畫。而結算界面的顯示受制于這兩個條件，在劇情動畫播完，并且服務器的結算結果已經返回的條件下，再顯示結算。這無疑增加了代碼的復雜度，可能劇情先結束，也可能服務器先返回數據，而這兩個條件又分別包含了一部分結算需要的數據。曾經線上出現玩家的結算界面無法顯示，我們要花大量的時間定位出現BUG的位置，因為有太多種可能性了：

1.斷線重連丟包，導致服務器的結算協議沒有收到，沒有觸發條件2

2.先觸發了條件1，緩存了條件1包含的數據，然后再觸發條件2，但是緩存的數據有問題，導致最終沒有顯示

3.先觸發了條件2，因為某種原因，沒有收到條件1的事件

對于線上的BUG案例，我們并不能拿到詳細的LOG文件，過多的可能性導致一個BUG的查找難度大大增加。把最近新增的代碼全看一遍可能可以找出問題，但是大多數情況是根本沒有一個明確的方向。

基于上述的情況，一開始的幾個月，我幾乎不想再碰這塊代碼，不管是策劃增加新的需求，還是線上出現了BUG，都會消耗大量的時間。繁雜的工作迫使我必須改變它，我需要一個更加簡單，更加容易維護的結構。于是就出現了下面的版本。

這里有2個重要的改動：

1.觸發結算界面顯示的邏輯改為單線

2.增加一個結算入口，只負責轉發結算需要的數據，根據戰斗類型的不同，把數據分發到真正對應的結算界面。每種結算有著自己的代碼文件。

于是今后的卡死再也不用糾結是服務器消息沒收到還是劇情沒有播放完畢了，只需要看看服務器的消息日志就可以快速定位。增加新的界面也變得簡單，只要在入口之下再新建一個文件，來描述新增的結算類型就大功告成，不會跟之前的結算功能互相影響，即使出現問題也只需要修改新增的結算。

總結

以上是生活随笔為你收集整理的游戏设计模式实操经验：游戏结算功能实现的两个要点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。