技術標籤：設計模型系列

遊戲開發中的策略模式

博主公司今年的新專案是一個重度養成中度策略的塔防遊戲（參考國外的random dice），雖然最後專案算是垮了吧（一測的留存實在太低），但是還是需要總結一下程式碼（總結才會進步）。
遊戲大致：玩家在遊戲時，可以不停建立符文，每個符文都擁有自己獨特的技能，相同型別的符文還可以合成，創建出來的符文會對敵人不停的攻擊。看起來好像需求不難，其實符文的技能邏輯深度不淺，眩暈，中毒，攻擊攻速BUFF，減速BUFF，以及好多神奇卻又不重複的技能設定。關鍵是每個符文的養成效果還不一樣，有的造成三個影響，有的造成兩個。於是策劃犯難了，問我該怎麼配表才能方便我這邊code。

於是該博文的主題登場了-策略模式。
引用網上對於策略模式的舉例，就像我們出門旅遊，可以飛機，地鐵，大巴，輪渡。具體選擇哪樣就得視情況而定。每種交通方式就是一種策略，本質就是一種演算法，策略的使用受到外部環境的影響。（咦，好像條件語句就能滿足需求了吧）不能滿足，因為大量的if else不好維護，等下用博主的專案舉例為啥不好維護。
策略模式簡直就是為博主的需求量身打造的。一個符文的具體技能效果以及養成效果就可以視為一種演算法，一種具體的strategy。不同的符文建立就引用屬於他的策略，客戶端不需知道當前是哪個符文在使用，完美的迴避了if else。這就解釋了為啥使用if else不好維護。一測為止，就有30個不同的符文，如果這30個符文用條件語句來實現，想想就頭大，程式碼得多冗長。
可能有人會問，一個符文一種策略，看起來好像也不簡潔吧，參考dota100多位的英雄，難道寫100多份的策略？這種擔心很有道理，這其實就是策略模式的缺點，每種演算法不同，程式碼不好複用。但就以博主來說，截止一測，博主一共code了30個符文。命名的時候引用了符文的ID，於是每次策劃修改了哪幾個符文，我根據ID，就修改相應的程式碼，其實還好，比我想的要輕鬆。
下面附上博主的LUA程式碼，以一號符文為例。
為了各位看官看的順利，博主把方法具體實現刪去，大家只要知道大致框架即可。

-----火焰符文，id：1-----
-----對範圍內的敵人單位造成火焰魔法傷害-----

module "Skill1Strategy"
 


Strategy = CC.Class:Subclass("Strategy")

--[[
    @desc: liziObjs:用來儲存粒子物件，當暫停或繼續遊戲時，粒子物件應當隱藏或者顯示
    author:{author}
    time:2020-06-08 12:07:49
    --@tVal: 
    @return:
]]
function Strategy:Init(tVal)
    self.boolAttack = true
    self.character = tVal.character
    return self
end

function Strategy:GetMofaDem(  )
    
end

function Strategy:GetAct(  )

end

function Strategy:GetAtkSpeed(  )

end

function Strategy:Effect(tVal)

end

function Strategy:Clear(  )
    self.liziObjs = {}
    self = nil
end

//new一個符文，並持有相應的strategy,下面只是虛擬碼
local id = 1 --一號符文
character = Character:New():Init(id ) 
character.skillStrategy = require “Skill1Strategy”.Strategy:Init()

//當你使用該符文的技能效果
character.skillStrategyL:Effect()

當然，博主後來反思，還是有可以改進的地方。比如可以把符文和技能邏輯分離，就是說毒單獨一種策略，減速單獨一種策略，而不是一號符文一種策略，二號符文一種策略。這樣的好處是：策劃後期如果加入一種組合符文：具有好幾種效果。那我就可以進行組合一下，程式碼複用率一下子就高起來了。事實上博主在下個專案中就是如此行的。