寫在前面：猛然想起，已經很久沒有寫遊戲設計相關的文章了，最近沉迷GamePlay的實現，並且跟風研究ECS框架，屬實是有點兒「不務正業」了。昨天晚飯時和同事說起一些策劃領域的事，覺得很有意思，索性整理成系列文章，和小夥伴們分享，權當是拋磚引玉。

（之前要是很多系列文章隨隨便便開坑，但都沒有填平，這個之後逐步完善吧。）

定義

今天和大家聊聊遊戲中的「掉落」。所以首先我們先一起給掉落下一個定義。對於任何一個遊戲玩家來說，所謂掉落，就是：

擊殺遊戲內怪物會掉落在地上遊戲道具的功能。

不過這個說法不夠完善，也不太嚴謹。我們再盡量抽象一點的概括。

• 首先，不一定是通過擊殺怪物，也可以是其他途徑；
• 再者，不一定是掉落在地上，也有其他的表現形式；
• 最後，也是掉落的核心，遊戲性的體現——「隨機性」；

所以這個定義應該回答幾個問題：誰掉落？掉落什麼？怎麼掉落？為了回答這幾個問題，我們試著重新下一個定義：

掉落是指遊戲玩家通過和遊戲對象交互觸發的，通過一套隨機規則最終產生玩家可獲得的遊戲道具（採用掉在地面或其他表現形式的）的過程。

當然，這只是我給掉落的一個定義。如果你有更好的定義，歡迎評論中交流。

設計

定義是設計的羅盤，保證設計不會跑偏，我認為一個好的設計就是滿足定義的，解決問題的。

我對「系統策劃」的理解，是不能停留在「需求」層面的，一個有價值的系統策劃，應該更深入的關注「設計」層面。換句話說，從寫「需求文檔」轉而變為寫「設計文檔」。然而可悲的是很多人沒有這種意識，而更多的人是沒有這種能力的。

這裡所說的需求文檔，就是指「我要什麼」，通常是站在玩家的角度，從外向內的去提出需求；而設計文檔，是指「我要的怎麼實現」，這需要更進一步的，由內向外的去推敲。將需求抽象成一步步可實現的功能點。

我在實際工作中的方式就是參與或者直接負責表結構的定製。表結構是策劃和程序之間溝通的媒介。這樣就可以最大可能的約束代碼的實現，並且幫助程序更方便的理解需求。實施經驗證明，如果策劃放任表結構不管，那麼程序做出的表結構可能是很難以維護的。策劃和程序在表結構上產生的分歧，本身就是「需求」和「實現」之間的分歧。這種分歧在寫代碼之前暴露出來，無疑是好事。

話說回來，繼續聊「掉落」，還記得我們在上文中聊到的三個問題么。我設計表結構時的思路就是每一張表分別回答上邊的問題。這也是每一張表的「職能」。下面舉例說明：

• 掉落組表：掉落的約束
• 掉落包表：掉落物的隨機規則
• 掉落物表：掉落物的表現

掉落機製作為遊戲中的底層機制之一，是供給上層使用者調用的，而掉落本身不需要關註上層調用者具體是誰。可以是怪物死亡、可以是寶箱開啟、可以是抽獎類活動。

掉落組

掉落主表，供上層調用，和掉落包一對多，用以規定歸屬對象、歸屬類型、掉落表現和其他限制。

掉落包

我在從前的文章中說過，「隨機性」是遊戲性的三要素之一。而掉落的核心恰恰在於隨機性。

所以這麼重要的東西，想也知道我們不可能使用完全隨機（「真」隨機）。

我一般的方案是使用兩種方式：

• 萬分比掉落：按照概率掉落的，多個掉落物互不影響，各自進行隨機判斷的方式。
• 權重隨機：按照一組掉落物中每個掉落物的權重，隨機出一個的方式。

此外，對於權重隨機，這裡我進行一波拓展，那就是隨機次數和隨機去重。這也是比較常見的功能需求，很好理解。

最後，另一個有意思的需求就是掉落包的嵌套。這個功能其實有利有弊。但我認為利大於弊，因此一般也會要求實現。所謂掉落包的嵌套，是指掉落包不僅可以索引掉落物，也可以索引其他掉落包，來達到更複雜的掉落規則。

至於掉落包嵌套可能帶來的循環引用的問題，完全可以在策劃填表時通過自己製作（或者程序幫忙製作）檢查工具來判斷。在數據配置這一層就要杜絕。

掉落物

實際上，掉落包可以直接索引Item表。是否需要掉落物這一層，主要因項目類型而定。這一層的職能就是處理各種不同的美術表現。

比如，遊戲中掉落方式多種多樣，有些道具掉落在遊戲場景中是模型方式，有一些是圖標方式，另一些還可能是粒子方式。這時就可以考慮通過填表來控制，來為策劃爭取更多的功能自由度，同時解放程序小夥伴。也未嘗不是一件好事（豈不美哉？）

後記

遊戲中的功能模塊，一類是更為獨立的玩法或養成系統，另一類則是為整個遊戲提供底層支持的核心機制。在本系列文章中，我想和小夥伴們更多的聊一聊在大多數遊戲中適用的更為底層的機制的設計思路。以後有機會再開新系列和大家談談這些機制的代碼實現過程。

預告一下，之後的文章中咱們聊聊遊戲里的「刷新」、「技能」及「屬性」等功能的設計思路。

小弟不才，見笑。

推薦閱讀：

相关文章