游戏开发中的策略模式

游戏开发中的策略模式

博主公司今年的新项目是一个重度养成中度策略的塔防游戏（参考国外的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()

当然，博主后来反思，还是有可以改进的地方。比如可以把符文和技能逻辑分离，就是说毒单独一种策略，减速单独一种策略，而不是一号符文一种策略，二号符文一种策略。这样的好处是：策划后期如果加入一种组合符文：具有好几种效果。那我就可以进行组合一下，代码复用率一下子就高起来了。事实上博主在下个项目中就是如此行的。