>>>  技術話題—商業文明的嶄新時代  >>>

簡體     傳統

GameRes發布，文/猴與花果山，轉載請注明作者和出處


所謂主玩法系統什么是游戲的主玩法系統？這個要追述到一些最近2年才從大佬們嘴中流行出來的系統分類：

核心玩法系統：一個游戲的亮點，無論在市場推廣的時候還是在策劃研發的時候，都是十分重視的系統，絕大多數手游的核心玩法系統表現為戰斗系統。這個系統理論上會花最大量時間去設計開發，因為游戲的一切玩法理論上都是圍繞著他延伸的。但是理論上始終是理論上，我們研發的是游戲產品，不是研發游戲。

主玩法系統：主玩法系統，其實就是大佬們嘴中所說的游戲“可玩性”，當然系統越多的游戲可以玩得東西就越多，數據理論上也會越好，這當然是沒錯的（請不要用BLZ反駁，大佬們認為這世界上是有奇跡的），“可玩性”故名思義就是可以玩得東西么。你不這么認為？我原來也不，只是我重新定義了“可玩性”這個詞而已。那么什么主玩法系統呢？通俗易懂的說法就是：游戲中那些可有可無的玩法系統，沒有這些系統游戲一樣能玩，因此很多時候是被硬湊出來的，最常見的就是秦時明月的武將突破，突破以后僅僅提高了數字，假如游戲設計的時候不設計這塊能不能玩？當然！甚至玩起來目標更清晰，游戲更偉大，但是不這么設計，渠道發行不買單阿——收費點少了，影響數據。所以我們在游戲中必須加上成千上萬個主玩法系統。由于海量的存在，主玩法系統最終成了游戲研發過程中最花時間的部分，本貼的討論目的實際上也就是為了簡化這個過程。

其他系統：郵件、公會、好友之類的系統，即使是應用軟件都會有的系統，沒人認為開發這玩意兒存在什么問題，事實上也是再弱的團隊一周內就能搞定這些玩意兒了。

被弄丟的管理中樞機制

　　明確了什么是主玩法系統之后，我們很快就能從腦袋里拿出很多很多已經設計好的主玩法系統來，并且在很多游戲中已經確實實現了。可是我們實際開發中通常犯了一個錯誤，就是把這些系統想復雜了，甚至每個系統去單獨開發邏輯，雖然也并沒多花多少時間，但是在調試、后期擴展的時候頭疼不已。

　　最常見的頭疼現象：策劃設計了一個抽卡系統，一開始說了我們能抽到的都是武將和碎片，開發完了運營說話了，我們還能抽到體力，這時候就開始勞命傷財了，策劃去擴展表項，至少得把MagicNumber的意義擴展了吧，程序則對應去實現代碼，當然最頭疼的不是實現本身，而是再啃一遍已經封存了的代碼。

　　事實上我們可以嘗試這樣一個做法——先一句話描述一下你要開發的那些主玩法系統，會是如何？我簡單的舉幾個例子：

抽卡系統：玩家按照規則支付一定的元寶，然后隨機抽取，最后獲得武將或者碎片。
簽到系統：玩家每天可以簽到一次，根據一定規則，最后獲得當天可以獲得的貨幣或者道具。
吃飯系統：玩家每天一定時間內，可以吃一次，最后獲得一定數量的體力。

　　當我們說到這里的時候，你應該不難想到，之后深入要設計的無非就是抽卡得支付元寶規則、隨機規則、簽到的規則等規則，以及最后獲得的東西的內容范圍。沒有經驗的策劃可能會在這里認為這樣的設計就沒有問題了，事實上這樣的設計只是停留在玩家交流階段，任何有經驗的程序員都會問一個問題：“你最后獲得的東西一定不會擴展了？比如抽卡一定只能抽到武將或碎片？”，這時候沒有經驗的策劃甚至會拍胸脯保證。可事實上在這里，我們弄丟了一個核心的東西——我們需要的是一個管理中樞，由這個管理中樞來管理東西（我也不知道怎么稱呼好了，thing恐怕是最合適的了）的獲得。

　　假如我們按照上圖這個邏輯來整理邏輯，你不難看出：

　　1，在我們需要獲得任何東西的時候，我們都向管理中樞提出請求，當然中間可以插入（但不建議）一個額外的條件判斷。

　　2，所謂的“分析請求”實際上就是這個管理中樞的核心工作。

　　3，分配各種東西給玩家對應的數據塊。比如道具、比如體力，我們知道通常這些東西，包括我們所理解的道具本身都會產生不同的結構，比如武器和藥丸和鑰匙之類的，最終真的用同樣的數據結構嗎？如果不，我們是不是至少需要每個都有一個數組去記錄？那么這些東西在策劃填表的時候是否本身就該區分開？（至少某些表格的內容會有明顯區別）

　　這個思路其實就是所謂的“管理中樞機制”的核心所在，他的好處在于一個更高的可擴展性，以及后期程序不用太大的去改動代碼，簡單的例子就是：

　　簽到系統：最初策劃的設計是，每天簽到可以得到配表中的道具（擴展的什么連續多少天獲得什么我們姑且不說，各家有各家的做法，但原理相同于每天簽的東西），但是運營認為不夠，除了道具我們還要能簽到小弟，還能簽出碎片。這時候我們傳統的做法是做一個禮包之類，而禮包本身其實就是這個管理中樞，只是沒有機制化的管理。

　　從我們的這個機制來看，簽到系統是如何工作的？

　　我們對比傳統做法和管理中樞機制，區別僅僅在于最后一步“發放獎勵”的過程。但玄機也在這里，因為最后一步決定了一個可擴展性和策劃表項的問題，當然這里的可擴展性僅僅只是可以給的東西的可擴展性。

　　我們先看下傳統的表項會有什么數據？

　　1，id：還是有比較好。

　　2，時間：可能是用于幾月幾號，也可能是簽到多少天，這個具體看策劃設計的規則，但肯定有一個時間。

　　3，獎勵道具id：獎勵什么道具。

　　4，獎勵道具個數：就給1個肯定滿足不了需求吧。

　　那么現在問題來了，運營說話了，我們要簽到給小弟，怎么辦？做法2個：

　　1，增加一種道具叫做小弟，得到道具給小弟，聰明的做法。

　　2，傻瓜做法，增加表項：獎勵類型，這個MagicNumber決定了獎勵的是道具還是小弟，0=道具，1=小弟，自然的，原來的“獎勵道具id”和"獎勵道具個數“根據這個MagicNumber值不同也被賦予了不同的意義。

　　無論你怎么做，最后的結果是，程序必須去增加一個道具獲得方式，改變讀表的代碼是少不了的工作，畢竟你表項改變了，至少某些數據的意義發生了變化。這樣的擴展手法其實是不良的，那么看看我們的管理中樞機制是如何工作的？

　　還是先看一下表項有些什么數據？我們可以把它分為2個表，其中一個叫做東西表，這個東西表的用途不僅僅是在簽到，她的數據一樣可以用于抽簽等其他系統：

　　1，id：別的數據掛過來的依據。

　　2，執行腳本：事實上對于策劃來說，需要的只是填寫一個String，甚至如果環境允許就直接在里面寫函數了。程序在“分析請求”的時候要做的事情就是執行這個腳本。Array<Dynamic>->Dynamic （Haxe），傳入的數據是腳本參數，返回的是獲得的東西，所以都采用Dynamic。

　　3，腳本參數：腳本需要的參數，Array<Dynamic>，根據每個腳本需要去傳。

　　我們嘗試虛擬2條數據，一條是獲得id=333的道具20個，一條是獲得id=216的武將，如果武將已經存在則是她的靈魂碎片。則數據為：

thing[0]=[script="gain_item", param=[333,20]];
thing[1]=[script="gain_buddy", param=[216]];

　　我們在通過簽到去掛向這個表，簽到的表項為：

　　1，時間：同傳統模式。
　　2，獲取：int，也就是對應thing的id。

　　除了簽到外，其他表一樣可以索引thing的數據，比如我們需要一個抽簽表，表項為：

　　1，thingId：對應到thing表的id。        
　　2，出現加權：這個thing被抽取的概率。
　　3，必出多少
　　4，在多少次中：和3共用形成“1000次抽取中必出3個這東西”的效果，此處不作詳細解釋。

　　說到這里，你應該大概能看出這個機制的一個好處，但是這里還有一個疑問應該留在你心里——“一條是獲得id=216的武將，如果武將已經存在則是她的靈魂碎片”這玩意兒應該如何去做？這里通常思路會犯一個錯誤：我們直接在腳本中判斷：

if (iHaveBuddyById(216)==true){
   giveSoulShard(216, Math.ceil(Math.random()*10));//錯在這里
}else{
   giveBuddy(216);
}

　　我們可以看到上面一段偽代碼中，有一個嚴重的錯誤，就是當我們判斷到已經有武將了，沒有通過這個中樞機制就直接給了靈魂碎片，這形成了一個錯誤的邏輯交叉：

　　既然分析請求已經執行了腳本，那么要么就是給出武將要么就是給出碎片，因此在給出武將未果的情況下，應該重新提交一個請求給自己，那就是給出碎片的請求：

　　這樣才是一個正確的執行流程，因為我們需要保證，游戲中給的任何東西都是走這個中樞機制的，為什么要這作，因為這里有一個真正的可擴展性存在，舉一個簡單的例子：

　　1，我們要設計成就了——獲得過100個道具，請注意是獲得過，而不是你的背包里實際有！那么你必須要有一個點去統計你獲得過多少個道具。

　　2，我們要設計挑戰了——獲得楊過之后獲得小龍女，然后獲得尹志平，請注意，獲得順序必須是這樣的，楊過-〉小龍女-〉尹志平，那么在這個流程上該干什么？你看出來了嗎？

實際游戲開發中的使用感覺

　　其實說到這里你應該已經多少看出來了，這個機制用于游戲的絕大多數主玩法都沒問題，因為所謂的主玩法無非就是玩家通過一定規則獲得一定好處。而這個機制的關鍵就在于把好處抽象成一個東西，整體管理。

　　而在實際開發中，我們發現程序在完成了這個機制的coding之后，不需要對這個機制的代碼在作什么改動，只需要在對應的系統中提供腳本接口和維護功能就可以了。但是這玩意兒有一個門檻，就是對于策劃的抽象能力要求會略微高那么一點，如果用一個數字來形容的話，一般策劃需要60以上，而玩這個機制的策劃需要64以上。

GameRes游資網 2015-08-23 08:38:44