首先我想說的是，這是一套機制，並不是單獨的一個系統，所謂機制就是一種從邏輯思想到代碼實現的小竅門的組合，只有當你把它運用到一個實際項目中去了，它才能幫助你建立一個系統。我不敢說它是最好的，但這套東西幫我完成了一個又一個項目的製作，我覺得現在可以簡單的拿出來和大家分享下思維。事實上這也並不是什麼很玄乎的東西，我的Buff的機制更像是Flash的Dispatch機制。更簡單的說，你可以把它理解爲一種回調機制，在必要的時候進行邏輯回調。我想這一句話應該是可以概括整個機制的工作原理了。
舉個簡單的例子來說明，作爲一個設計師，在設計系統的同時應當思考好這個遊戲的系統中的各個回調點，而他們也正是Buff系統發揮能量的地方，Buff回調點有哪些（當然我可能會把它歪到WoW，畢竟這最早的設計靈感來自WOW）？我簡單列一些：
1，BuffOccur
我認爲這是最核心的回調點之一，應該說你把這套機制運用在任何遊戲中他都必須由這個時間點，就是當任何情況Buff被添加到一個角色身上的時候（可能來自技能、可能來自道具、可能來自GM命令，等等等等），往往他最傑出的作用就是改變角色的屬性、或者是被控制狀態。之所以說這是機制是思維方式，因爲它並不關心你的遊戲有哪些狀態或者屬性，但是這裏有一點比較容易搞混的就是初級策劃往往會認爲昏迷就是一個Buff(debuff)，可是事實上昏迷是一種組合狀態，他在LoL裏面的形態是剝奪移動能力、剝奪攻擊能力、剝奪商店使用能力的組合（我不知道是不是真的，但是我在做起凡三國爭霸2的時候是這麼做的，這套機制最早運用的遊戲就是那個，雖然我離開起凡後這套系統的代碼被刪除了）。因此在BuffOccur這個回調點，有着很多的事情會需要做，那麼同樣的，BuffRemoved回調點也就有了同樣的職責。
2，BuffOnTick
也就是通常我們最常見的，每3秒造成傷害、治療；或者我們可以做每3秒製造一個AOE，甚至每3秒爲自己添加一個護盾等等，他的核心在於沒一定時間觸發一次，但請你注意不是所有的遊戲都適用這個回調點。
3，BuffRemoved
在移除Buff的時候，重新計算屬性等肯定是需要在這個時間點工作一次的，那麼事實上還有很多的效果也可以在這個時間點被調用，典型的是痛苦無常和生命綻放（都來自WOW），痛苦無常是當驅散的時候對驅散者造成傷害並且沉默，因此我們需要傳入導致buff終結的人（可能是null）和BuffRemove的時候剩餘時間，由此判斷是否真的完成了，那麼剩餘時間越多造成傷害越高也就成了可能的設計；而生命綻放則更加簡單，在Removed時候給持有者進行治療就可以了。
4，BuffBeHurt
在受到攻擊的時候觸發，大多盾類技能由此而生，這個回調點應當Return一個Int或者Float，用於傳遞給下一環，已獲得新的傷害，而當所有的執行完畢之後，造成的最終傷害就會是這個數字，那麼把受到的傷害變成治療是多麼簡單的事情？可是否應該有，還得看遊戲的Patterns。
5，BuffOnHit
在攻擊的時候產生，雖說字面上是OnHit，你仍然可以把isHit像isCrit一樣傳給回調函數，戰士的壓制（老版本）在攻擊被閃躲時可以發動，更早的獵人在閃避攻擊後可以提高招架？其實都是這個時間點來做的。
6，BuffBeforeKilled
很多時候BuffBeHurt並不能完成一些設計，比如說必定能殺死目標的傷害被完全吸收（賊爺爺的假死），這時候我們要確定這個角色原本應該死了，因此就需要設定出這樣一個回調點。
7，BuffAfterKilled
當殺死一個角色的時候，恢復自身X%的HP，這時候你就需要這個回調點，精確的在角色死亡後發生。
機制始終是機制，或者說是思維方式，他真正的運行還是取決於遊戲本身，回調點我只是隨便舉個例子而已，事實上根據遊戲不同，完全可以增加或者刪除回調點，比如一個MT卡牌遊戲他就完全不需要onTick這樣的回調點，但他可以有BeforeMove（角色行動前）等回調點，這取決於遊戲本身機制。同樣的每一個視覺特效都可以在每一個回調點去播放，你可以設計好這樣的規則不是嗎？
接下來，我們就在這個機制的基礎上分析一下LoL的一些技能，我印象最深的那些，我已經很久不玩LoL了：
1，蠻王的6秒真男人，一個Buff，在BeforeKilled時候調用，Return1作爲最後設定的HP，並被寫在回調代碼的最後。
2，盲僧、瑞文的連續技能，事實上這也是你肉眼看不到的Buff（機制正是如此奇妙，未必被直接運用，正如我所說，他是一種思路），當有Buff的時候技能A變成技能B，移除後恢復，OnSkillCast的回調點（往往技能施展中會需要回調點，因此回調點還是根據遊戲具體分析出來的）。
3，火男的昏迷，火男的法術會爲目標添加一個Buff，而法術在OnHit的時候會檢查如果存在這個Buff則執行XX效果導致昏迷，否則普通效果。
4，安妮的昏迷，你如果有仔細看了2並思考了，這不是問題。
5，大嘴的自爆，在角色死亡的時候產生免疫性Buff，Buff結束時產生AOE，如果你這麼思考，這會簡單很多。
這套機制在實際工作中，我們需要如何去分工呢？事實上已經很清晰了：
策劃：需要設計出所有的回調點，事實上策劃如果完全不瞭解程序的效率等問題是無法設計好的，最好還能大概瞭解所謂回調機制，因爲除了回調點意外，你還需要設計出回調時候傳的參數，以及返回給程序的參數及其工作順序，除此之外一些基礎的表象也需要去製作，如buff的名稱，那麼在做表的時候會有2種風格，在起凡的時候我可以不用太關心，因爲每個人都會用Lua寫回調函數，但之後的項目中，我是用了我常推薦的Tag機制，比如策劃填寫一個Buff效果些daze_60之類的我就可以把它分析爲60%機率昏迷目標等。在設計這些東西的時候爲了更有效地避免誇誇其談，策劃對於實現的瞭解還是非常重要的，而事實上我們這裏已經是策劃動手寫邏輯代碼了，這問題就相對好辦些。策劃除此之外還應該歸納出特效播放點、數據同步時間點等等和遊戲核心機制相結合的東西。這世界上也有很多好的創意，但你必需知道機制士兵不能幫你實現的，更重要的是你要知道自己想做什麼和怎麼去做，因此設計buff的時候切勿濫用機制，機制用的不好反而弄巧成拙，而合理的拆分Buff的效果也是一個策劃的價值所在。
程序：程序的工作則是優化好回調點和策劃可能濫用到家的循環，這是非常頭疼的事情，因此很可能需要更好的機制替他們實現一些該死的邏輯優化，可是這並不是最重要的，最主要的工作還是完成一些底層接口功能，比如在某個綁點上播放某個特效之類的，這些是策劃都是即使會寫邏輯代碼也寫不好的東西，也正是程序員強勢所在（因此我並不認爲遊戲程序員非得精通遊戲，但必須瞭解一二，才能大概思考一些優化、渲染的邏輯）。
美術：視覺特效肯定少不了你的，搞不好還得弄動作，音樂跑的了音效跑不了，做吧，策劃會整理出大量的需求列表的，如果上面說做那就做了。
在你瞭解了Buff的工作機制之後，你纔有資格進一步的談創意，不然都是胡扯蛋，你都不知道怎麼去做，你怎麼去創造呢？那麼假如讓我把呂布加入到LoL中，我會給他設計什麼樣的被動技能呢？就讓我們一起YY下（確切的說知道實現方式的YY纔是有價值的）：
被動：人中呂布，任何普通攻擊（我想LoL的普通攻擊應該也是有標記的，起凡當時是skillId==28近戰、30遠程，事實上我不太贊成這樣的skillId特殊標記法）的時候會爲呂布添加1層“人中呂布”（另外一個buff）
“人中呂布”到15層、25層、35層、45層、50層時更換視覺特效(BuffOccur BuffRemoved)。人中呂的特性是15層開始普通攻擊有機率造成雙倍傷害，25層開始受到傷害有機率減少20%，35層開始釋放技能獲得導致目標昏迷2秒，45層開始釋放技能恢復自身25%生命，50層時技能對20%生命以下目標一擊必殺，死亡是損失一半層數(beKilled)。這麼牛逼的效果？是啊，中國人當然應該牛逼了。慢來，才YY開始，這算設計好了？早呢，爲了這些效果，你需要在“人中呂布”Occur Remove中去根據當前層數添加刪除Buff：
人中呂布_雙倍傷害，普通攻擊OnHit投隨機數決定是否傷害x2。
人中呂布_機率免傷，BeHurt時候投隨機數決定是否降低一定的傷害。
人中呂布_強力攻擊，Onhit判斷不是普通攻擊則給目標一個2秒的Buff1層。
強力攻擊_昏迷，Occur攜帶者昏迷屬性爲true，Remove就不需要設置false了，因爲他可能還有別的buff讓他昏迷，但是Remove和Occur的時候都要重新計算一次屬性狀態就對了。說到這裏，這個Buff互相堆疊又是很討厭的邏輯，2個SS可以給同一個目標釋放腐蝕術，產生2個，但是自己卻只能對1個目標上1個，等等等等。
人中呂布_技能恢復，OnCast的時候（事實上LoL應該只有OnHit，這也可以），判斷不是普通攻擊則回覆生命。
人中呂布_斬殺，OnHit判斷目標生命比，決定是否造成999999傷害。
至於主動技能，我也懶得想了。
作爲一個遊戲設計師，你必須清楚地能夠區分開Skill Buff AoE等，這樣才能讓你想做的東西思路更清晰，讓程序運行效率更好（至少程序優化的思路會更清晰）。對於遊戲的分析，不應該停留在猜測其系統、數值的程度上，更進一步剖析一個類型的遊戲，就可以研究出更好的機制來。作爲一個研發設計師，應該把更多的時間用在研發上，而不是夢想着一款遊戲能賺多少，多思考思考機制和新的手段，理性而博學了纔能有更好的創意，纔是整個行業進步的動力。
舉個簡單的例子來說明，作爲一個設計師，在設計系統的同時應當思考好這個遊戲的系統中的各個回調點，而他們也正是Buff系統發揮能量的地方，Buff回調點有哪些（當然我可能會把它歪到WoW，畢竟這最早的設計靈感來自WOW）？我簡單列一些：
1，BuffOccur
我認爲這是最核心的回調點之一，應該說你把這套機制運用在任何遊戲中他都必須由這個時間點，就是當任何情況Buff被添加到一個角色身上的時候（可能來自技能、可能來自道具、可能來自GM命令，等等等等），往往他最傑出的作用就是改變角色的屬性、或者是被控制狀態。之所以說這是機制是思維方式，因爲它並不關心你的遊戲有哪些狀態或者屬性，但是這裏有一點比較容易搞混的就是初級策劃往往會認爲昏迷就是一個Buff(debuff)，可是事實上昏迷是一種組合狀態，他在LoL裏面的形態是剝奪移動能力、剝奪攻擊能力、剝奪商店使用能力的組合（我不知道是不是真的，但是我在做起凡三國爭霸2的時候是這麼做的，這套機制最早運用的遊戲就是那個，雖然我離開起凡後這套系統的代碼被刪除了）。因此在BuffOccur這個回調點，有着很多的事情會需要做，那麼同樣的，BuffRemoved回調點也就有了同樣的職責。
2，BuffOnTick
也就是通常我們最常見的，每3秒造成傷害、治療；或者我們可以做每3秒製造一個AOE，甚至每3秒爲自己添加一個護盾等等，他的核心在於沒一定時間觸發一次，但請你注意不是所有的遊戲都適用這個回調點。
3，BuffRemoved
在移除Buff的時候，重新計算屬性等肯定是需要在這個時間點工作一次的，那麼事實上還有很多的效果也可以在這個時間點被調用，典型的是痛苦無常和生命綻放（都來自WOW），痛苦無常是當驅散的時候對驅散者造成傷害並且沉默，因此我們需要傳入導致buff終結的人（可能是null）和BuffRemove的時候剩餘時間，由此判斷是否真的完成了，那麼剩餘時間越多造成傷害越高也就成了可能的設計；而生命綻放則更加簡單，在Removed時候給持有者進行治療就可以了。
4，BuffBeHurt
在受到攻擊的時候觸發，大多盾類技能由此而生，這個回調點應當Return一個Int或者Float，用於傳遞給下一環，已獲得新的傷害，而當所有的執行完畢之後，造成的最終傷害就會是這個數字，那麼把受到的傷害變成治療是多麼簡單的事情？可是否應該有，還得看遊戲的Patterns。
5，BuffOnHit
在攻擊的時候產生，雖說字面上是OnHit，你仍然可以把isHit像isCrit一樣傳給回調函數，戰士的壓制（老版本）在攻擊被閃躲時可以發動，更早的獵人在閃避攻擊後可以提高招架？其實都是這個時間點來做的。
6，BuffBeforeKilled
很多時候BuffBeHurt並不能完成一些設計，比如說必定能殺死目標的傷害被完全吸收（賊爺爺的假死），這時候我們要確定這個角色原本應該死了，因此就需要設定出這樣一個回調點。
7，BuffAfterKilled
當殺死一個角色的時候，恢復自身X%的HP，這時候你就需要這個回調點，精確的在角色死亡後發生。
機制始終是機制，或者說是思維方式，他真正的運行還是取決於遊戲本身，回調點我只是隨便舉個例子而已，事實上根據遊戲不同，完全可以增加或者刪除回調點，比如一個MT卡牌遊戲他就完全不需要onTick這樣的回調點，但他可以有BeforeMove（角色行動前）等回調點，這取決於遊戲本身機制。同樣的每一個視覺特效都可以在每一個回調點去播放，你可以設計好這樣的規則不是嗎？
接下來，我們就在這個機制的基礎上分析一下LoL的一些技能，我印象最深的那些，我已經很久不玩LoL了：
1，蠻王的6秒真男人，一個Buff，在BeforeKilled時候調用，Return1作爲最後設定的HP，並被寫在回調代碼的最後。
2，盲僧、瑞文的連續技能，事實上這也是你肉眼看不到的Buff（機制正是如此奇妙，未必被直接運用，正如我所說，他是一種思路），當有Buff的時候技能A變成技能B，移除後恢復，OnSkillCast的回調點（往往技能施展中會需要回調點，因此回調點還是根據遊戲具體分析出來的）。
3，火男的昏迷，火男的法術會爲目標添加一個Buff，而法術在OnHit的時候會檢查如果存在這個Buff則執行XX效果導致昏迷，否則普通效果。
4，安妮的昏迷，你如果有仔細看了2並思考了，這不是問題。
5，大嘴的自爆，在角色死亡的時候產生免疫性Buff，Buff結束時產生AOE，如果你這麼思考，這會簡單很多。
這套機制在實際工作中，我們需要如何去分工呢？事實上已經很清晰了：
策劃：需要設計出所有的回調點，事實上策劃如果完全不瞭解程序的效率等問題是無法設計好的，最好還能大概瞭解所謂回調機制，因爲除了回調點意外，你還需要設計出回調時候傳的參數，以及返回給程序的參數及其工作順序，除此之外一些基礎的表象也需要去製作，如buff的名稱，那麼在做表的時候會有2種風格，在起凡的時候我可以不用太關心，因爲每個人都會用Lua寫回調函數，但之後的項目中，我是用了我常推薦的Tag機制，比如策劃填寫一個Buff效果些daze_60之類的我就可以把它分析爲60%機率昏迷目標等。在設計這些東西的時候爲了更有效地避免誇誇其談，策劃對於實現的瞭解還是非常重要的，而事實上我們這裏已經是策劃動手寫邏輯代碼了，這問題就相對好辦些。策劃除此之外還應該歸納出特效播放點、數據同步時間點等等和遊戲核心機制相結合的東西。這世界上也有很多好的創意，但你必需知道機制士兵不能幫你實現的，更重要的是你要知道自己想做什麼和怎麼去做，因此設計buff的時候切勿濫用機制，機制用的不好反而弄巧成拙，而合理的拆分Buff的效果也是一個策劃的價值所在。
程序：程序的工作則是優化好回調點和策劃可能濫用到家的循環，這是非常頭疼的事情，因此很可能需要更好的機制替他們實現一些該死的邏輯優化，可是這並不是最重要的，最主要的工作還是完成一些底層接口功能，比如在某個綁點上播放某個特效之類的，這些是策劃都是即使會寫邏輯代碼也寫不好的東西，也正是程序員強勢所在（因此我並不認爲遊戲程序員非得精通遊戲，但必須瞭解一二，才能大概思考一些優化、渲染的邏輯）。
美術：視覺特效肯定少不了你的，搞不好還得弄動作，音樂跑的了音效跑不了，做吧，策劃會整理出大量的需求列表的，如果上面說做那就做了。
在你瞭解了Buff的工作機制之後，你纔有資格進一步的談創意，不然都是胡扯蛋，你都不知道怎麼去做，你怎麼去創造呢？那麼假如讓我把呂布加入到LoL中，我會給他設計什麼樣的被動技能呢？就讓我們一起YY下（確切的說知道實現方式的YY纔是有價值的）：
被動：人中呂布，任何普通攻擊（我想LoL的普通攻擊應該也是有標記的，起凡當時是skillId==28近戰、30遠程，事實上我不太贊成這樣的skillId特殊標記法）的時候會爲呂布添加1層“人中呂布”（另外一個buff）
“人中呂布”到15層、25層、35層、45層、50層時更換視覺特效(BuffOccur BuffRemoved)。人中呂的特性是15層開始普通攻擊有機率造成雙倍傷害，25層開始受到傷害有機率減少20%，35層開始釋放技能獲得導致目標昏迷2秒，45層開始釋放技能恢復自身25%生命，50層時技能對20%生命以下目標一擊必殺，死亡是損失一半層數(beKilled)。這麼牛逼的效果？是啊，中國人當然應該牛逼了。慢來，才YY開始，這算設計好了？早呢，爲了這些效果，你需要在“人中呂布”Occur Remove中去根據當前層數添加刪除Buff：
人中呂布_雙倍傷害，普通攻擊OnHit投隨機數決定是否傷害x2。
人中呂布_機率免傷，BeHurt時候投隨機數決定是否降低一定的傷害。
人中呂布_強力攻擊，Onhit判斷不是普通攻擊則給目標一個2秒的Buff1層。
強力攻擊_昏迷，Occur攜帶者昏迷屬性爲true，Remove就不需要設置false了，因爲他可能還有別的buff讓他昏迷，但是Remove和Occur的時候都要重新計算一次屬性狀態就對了。說到這裏，這個Buff互相堆疊又是很討厭的邏輯，2個SS可以給同一個目標釋放腐蝕術，產生2個，但是自己卻只能對1個目標上1個，等等等等。
人中呂布_技能恢復，OnCast的時候（事實上LoL應該只有OnHit，這也可以），判斷不是普通攻擊則回覆生命。
人中呂布_斬殺，OnHit判斷目標生命比，決定是否造成999999傷害。
至於主動技能，我也懶得想了。
作爲一個遊戲設計師，你必須清楚地能夠區分開Skill Buff AoE等，這樣才能讓你想做的東西思路更清晰，讓程序運行效率更好（至少程序優化的思路會更清晰）。對於遊戲的分析，不應該停留在猜測其系統、數值的程度上，更進一步剖析一個類型的遊戲，就可以研究出更好的機制來。作爲一個研發設計師，應該把更多的時間用在研發上，而不是夢想着一款遊戲能賺多少，多思考思考機制和新的手段，理性而博學了纔能有更好的創意，纔是整個行業進步的動力。
吐槽一下，10年，韓國遊戲原地踏步卻追上了中國遊戲，因爲我們在倒退，急功近利的心態和不思進取是罪魁禍首。每當看到兒童遊戲裏面到處都是神仙道般的引誘充值的點，我就感到悲傷，寓教於樂也是遊戲精髓之一，爲什麼我們不能教會孩子更多解決問題的辦法卻要讓他們整天收集裝備砍怪？我們的孩子們應該玩比我們那時候更值得驕傲的遊戲，而不是一些山寨那些遊戲還做得更爛、但收費更離譜的東西。"our spieces is to take the best , and to spread around everybody so that everyone grows up with better things, and start to understand the subtleties of these better things"——喬布斯如果20年前開始搞Taobao可能蘋果現在會更有錢，再將一部分精力和資金投於軟件業可能蘋果會更上一層樓，但他選擇了堅定地做好自己熱愛的事情。
轉自：http://bbs.gameres.com/thread_215027_1_1.html
