【策劃篇】如何寫出完備、可落地的遊戲功能需求？

如果你是一名遊戲策劃，你一定遇到過，甚至經常遇到這樣的情況：

自己構思了一個非常精妙的玩法或者功能，興沖沖地寫好策劃案、提好需求，結果開發評審中被告知，A太複雜了做不了，B和另外一個功能有衝突不能做，C的開發週期很長一個版本做不完，一通減肥瘦身，最後玩家玩到的就是個半成品，然後被瘋狂吐槽。

更有甚者，還會出現D漏了與另一個模組有關聯的部分，臨近封版才發現，E這裡沒考慮到和另外一個功能的相容性問題，上線了被發現有bug，那就不僅僅是被吐槽這麼簡單的事情了。

實際上，遊戲本質上是一種十分複雜的軟體，尤其是體量大、功能多、玩法豐富的遊戲，最典型的就是開放世界遊戲。如果你是這樣複雜遊戲的策劃，那麼寫策劃案、提需求就不僅僅是要管好自己的一畝三分地就行，否則就會出現上述ABCDE這樣的問題。

那麼本期《遊門弄斧》，就讓我們以原神裡的尋寶羅盤為例，聊聊我覺得一個優秀的遊戲策劃應該如何寫案子、提需求。


模組化構思——先感性，再理性，再感性

首先我想問下大家，你覺得原神裡的尋寶羅盤好用麼？

其實遊戲功能做出來不好用甚至有bug，90%的原因本質上都是在需求構思階段就出了問題，只是策劃不知道，等到後面被開發指出做不了，只能被砍得面目全非，甚至開發都沒看出問題，最後產生更大的問題。

因此為了避免這種情況，最有效的方法，一定是在構思需求、寫策劃案的階段，就要儘量完備。而為了完備，策劃就得知道自己這個可能看起來很簡單的設計，到底與哪些模組有關，要和誰溝通收集資訊。這個過程我稱之為先感性、再理性、在感性。

首先要感性地想一想，自己想要一個什麼效果，實現什麼目的。

例如我想給玩家一個工具，按一下就可以幫玩家指出距離自己最近的還沒有開啟的寶箱，一方面可以獲得寶箱裡的獎勵，同時也是將區域探索度刷到100%的途徑。

這個過程是十分感性的，設計出發點就是為了解決玩家遊戲中找寶箱時煩躁、迷茫的“感覺”，預期的道具效果也非常模糊，並不存在客觀上“最好”的方案。

但我必須要根據對這種“感覺”的體會和思考，給這個功能確定預期效果，以及邊界條件，例如：

• 如何幫玩家標記這個寶箱？是地圖示記，還是3D場景中標記，還是指向一個方向的一條線
  

• 需要區分寶箱型別麼？寶箱有戰鬥的、解謎的、探索的，都要標記麼
  

• 對寶箱的獎勵有要求麼？例如必須是和探索度/原石相關的寶箱，還是說只要他是一個寶箱，甚至不是寶箱，只要是一次性獎勵就行？
  

這些問題我都需要在第一次感性思考中想清楚，別人是無法替我做決定的，因為他們並不知道我的設計目的，即使知道了，對於這種感性的問題每個人都有自己的看法，可能另一個人從感性上會覺得只要是獎勵都應該提示，而我作為負責人得有自己的意見，這是我的工作職責，也是體現設計能力的地方。

實際上我也碰到過沒想好這些就去找其他人“對需求”的情況，於是別人一個反問，自己一下就矇住了，因為開始沒想過，此時臨時思考或者下意識的反應就很容易給出並不正確的結論。

然後需要再理性、客觀地想一下，這個功能涉及到哪些模組，後續要跟誰溝通。

• 寶箱在場景裡，由關卡策劃負責擺放，那肯定和關卡策劃有關
• 我確定了只和地圖探索度、原石相關的寶箱，那需要和系統策劃中負責地圖探索度設計、原石投放相關的人聊聊
• 這個東西以一個隨身小道具的形式提供給玩家使用，這種物品的使用方式和表現效果需要3C/道具策劃參與
• 還要和負責道具邏輯實現的開發聊聊實現方案
  

你看，看起來只是一個做尋寶工具的需求，現在就已經牽扯到至少4類不同的人了，只有和這些人都聊過之後，我才有可能知道我的需求能不能做、怎麼做、做出來會是一個什麼效果。

到這裡依然沒有結束，我還得感性地腦補一下整個流程，把自己帶入到玩家視角去使用這個道具，看看會不會有“完美情況”以外的“意外情況”。

• 首先是玩家拿到這個道具，這一上來就發現漏了一個點，這東西怎麼給玩家？肯定不能是活動，那麼是常駐的世界任務？還是玩家鍛造合成？如果是鍛造合成，那麼配方如何獲取，合成材料怎麼定，這些需要再和系統策劃聊一聊
• 然後玩家用了一下這個道具，此時有沒有可能附近已經沒有寶箱了？這樣引出了一個問題，這個道具能搜尋多遠範圍內的寶箱呢？這個問題需要再後續跟開發大哥聊一下
• 玩家用了這個道具，道具給出了一個方向，這個方向足夠明確麼？會不會指向地下或者天上這種一眼不知道如何前進的地方呢？而無論是地圖示記還是3D場景標記都會遇到同樣的問題，因此我得再問下開發大哥，這種情況下有什麼可能的方案
  

總結一下，需求構思階段，需要明確需求涉及到的功能模組和相關人員，並透過儘量完整全面的“腦補流程”，把可能存在的問題都羅列清楚，方便後續的溝通。

善於溝通——先小聊，再大聊，再小聊

經過前面的步驟，我已經儘可能把我自己能夠想到的問題都羅列出來了，接下來就到了溝通的時間。

首先我要“小聊”，找到前面提到的每個模組的相關策劃、開發，去確定有疑問的地方。

• 問關卡策劃，寶箱的放置有沒有什麼說法，天上地下這種需要找到正確入口的寶箱有沒有定位入口的方式
  

• 問系統策劃，和探索度、原石相關的寶箱有哪些，有沒有什麼區分方法
• 問道具策劃，這樣的羅盤在使用過程有沒有什麼坑點
• 問道具開發能搜尋到多遠範圍內的寶箱
  

小聊的目的是為了找到專業的人，補充我的知識盲區。

對於大型遊戲專案來說，沒有誰能做到完全熟悉每一個遊戲細節，因此當一個需求和某個模組相關時，就得找到對應的人去確定細節有沒有問題，不能自己想當然。

例如在“小聊”中我就可能被告知。

• 關卡策劃在配置過程中，不存在寶箱與出入口關聯關係，只能知道寶箱在A洞穴中，但並不知道A洞穴的出入口在哪裡
• 系統策劃的設計是，所有以寶箱為外形的獎勵，都是包含原石的，可以用這個方法區分
  

• 開發表示，“找寶箱”這個過程最簡單的方案，只能找到玩家附近一定距離內已經載入的寶箱，玩裝潢置越差，這個範圍越小，而且無法找到本來不存在，需要透過解謎或者任務才會刷出來的寶箱。
  

這些資訊都是在溝通前僅憑我自己的知識無法知道的，而這些資訊又會影響我對整個功能的設計。

不過幸好我提前進行了“小聊”，提前知道了這些資訊，還有修改設計的餘地，例如：

• 知道無法提供關於入口的提示，那麼從引導性上，常駐3D場景標記>地圖示記>方向指示線，可以考慮將標記寶箱的方式從指示線改為場景標記
  

• 知道簡單版本的找寶箱方案無法找到解謎後才會刷出來的寶箱，那麼找寶箱的方案就得替換，不能直接在已載入的場景裡找，得從地圖資料中找
  

然後是“大聊”，也就是開需求評審會。

需求評審會上所有與需求相關的人都會被召集，於是有的策劃會認為這是聊細節的好時機，不需要自己跑上跑下，可以“一站式”解決問題，就把前面提到的所有問題都留到需求評審會的時候才確定。

但這就會帶來3個問題：

• 1是大量時間都是在1對1溝通，其他人乾坐著，浪費大家時間
• 2是一旦需求複雜，細節一多，大家的耐心被消耗完了，越到後面的內容越容易出錯，因為大家都不想聊了
• 3是如果會上發現之前的設計有問題，就只能靠下意識的反應修改需求，設計質量無法保證
  

所以，就和表白一樣，需求評審會應該是勝利的儀式，而非衝鋒的號角。

大家聚在一起，是為了處理不聚在一起就無法解決的問題，為了發現那些多個模組、多個功能之間互相耦合產生的隱藏問題。


例如：

• 關卡策劃和系統策劃聚一起之後才發現，雖然確實所有寶箱都提供原石，但是有的寶箱需要完成了某個任務才具備解鎖條件，這種寶箱需要提示麼？
  

• 關卡策劃和開發聚在一起之後才發現，有的寶箱雖然只有1個，但解鎖這個1個寶箱需要去N個地方還隔得老遠，這種情況下要如何提示玩家？
  

• 道具策劃聽著聽著說，有的寶箱解謎是依賴小道具的，而這個羅盤也是個小道具，豈不是玩家要一直來回切換？
  

實際上，複雜、大型的遊戲裡設計新功能最難的並不是設計功能本身，而是這個功能與太多其他功能有關聯，且隨著遊戲內容越來越多，遊戲複雜性越來越高，這種耦合性帶來的麻煩也會越來越多。

因此，開發評審會的“大聊”就是為了儘量在進入開發階段前，就把所有可能的問題、麻煩全都暴露出來，儘早進行評估、評審，避免做到一半，甚至功能上線了才發現，那時候就真的騎虎難下了。

其中有的問題和麻煩是當下無法解決的，例如小道具的切換，當前無法做到快速切換，但未來是可以增加相關功能的。

而有的問題甚至可能完全無法解決，例如寶箱的解鎖條件太複雜，不是一個“尋寶羅盤”就能提示的，那麼就需要用別的方式，例如透過支線任務引導，或者將其不計入探索度統計裡。

但無論如何，只有知道了這些問題的存在，才有可能修正前面的設計。如果真的存在無法調和的矛盾或者困難，那需求該砍就得砍，不做了。

如果經過“大聊”確定可以做，那麼就到了最後的“小聊”，也就是和每個部分相關的具體負責人聊實現細節。

• 道具怎麼給到玩家，打造材料如何設計
• 怎麼搜尋寶箱，解謎後才生成的寶箱要透過什麼方式查詢，是否要增加配套的功能邏輯
• 發現寶箱後的提示方式是什麼，找到和找不到的表現細節分別是什麼
• …………
  

總結一下，對於遊戲策劃來說，溝通是非常重要的一項技能，能不能高效地透過“小聊”“大聊”把功能需求相關的問題都搞清楚，是非常體現策劃能力的。

另一方面，大家的時間都很寶貴，不要把一大堆人拉上，結果討論的全是2個人就能對清楚的內容，甚至是因為“覺得”某人“可能”相關就拉進群裡/拉進會里，這些都是懶惰的表現。

知其所以然——拆分需求，瞭解原理，預留後手

溝通結束，就進入開發階段了……嗎？

其實不然，一些策劃喜歡直接把複雜需求作為一個整體扔給開發，然後坐等開發完之後驗收。但實際上，複雜的需求往往是可以拆分的，策劃可以，也應當參與到拆分工作中。

這會有3方面的好處

第一、不再需要整個功能全部做好了才能驗收，給最佳化、修改提供了時間

例如，找寶箱的功能做好了，但提示寶箱位置的功能還沒做好，怎麼辦？

沒關係，找寶箱功能在提需求時可以單獨拆分成一個需求，要求能透過除錯功能直接顯示找到的寶箱的ID、座標，這樣就能單獨驗收這一個功能。

然後就可能發現，由於有的任務會影響場景，在某些任務進行的過程中，有的寶箱並不會顯示出來。


由於發現及時，那麼還有修改的空間，可以趕緊聯絡開發看看怎麼處理這個問題。如果等到提示寶箱位置的功能也做好了才開始驗收，很可能就來不及改了。

第二，驗收和測試時有更多手段測bug，提升測試效率

測試時我們往往希望針對某一種特殊情況進行單獨的測試，但實際遊戲中的環境是十分複雜的，想透過正常途徑或者已有的除錯工具湊出這種情況並不容易，此時就需要我們在拆分需求時預留好測試手段。

例如我想測試一個特殊地點的寶箱被標記在地圖上時是什麼效果，玩家在不同位置觸發這個標記時是否都很容易找到過去的路。但搜尋寶箱本身是找最近的寶箱，我換個位置可能就鎖定到另一個寶箱上了。


此時我就需要在拆分“標記寶箱位置”的功能時額外指出，我還需要一個介面，透過輸入寶箱ID的方式來測試標記效果，避免“搜尋”功能干擾我測試“標記”功能。

第三，當出現bug時，有更多的Debug手段定位問題

複雜、耦合功能的Debug往往是非常麻煩的，經常是出了問題不知道是哪個步驟錯了，拉上一大堆人查來查去。

正常情況下查bug的工作確實與策劃無關，合格的開發應當在程式碼中預埋相關的log用於查bug，但作為整個需求的發起者，策劃也並非不能為此做貢獻。

如果提前進行了功能拆分，也約定了除錯介面和相關的log資訊，當遊戲中的實際表現與預期不符時，策劃自己就能透過除錯介面和log定位到是哪個步驟出了問題，直接cue對應的開發。

例如測試提了個bug，說在某個位置使用羅盤沒有任何反應，我在同樣的位置先用“搜尋最近寶箱”的介面，發現確實找到了寶箱資訊，ID是114514，但用“標記寶箱位置”的介面無法標記出114514號寶箱的位置，那麼顯然問題就出在標記的部分，可以直接通知做這個功能的開發。

總結一下，一個複雜的需求在寫策劃案時，就應當拆分為若干個相對獨立的子需求提出，並約定好驗收、測試的介面和log資訊，這會極大地提升整個需求的開發、驗收、測試效率，是專案管理中非常常見的技巧。

結語

綜上所述，在大型遊戲專案中設計一個需求，不僅僅只是設計需求本身，而是一項包含了設計、溝通、實現、專案管理等多個方面的工作。

很多策劃會在工作中抱怨，自己精妙的遊戲設計總是在實現的過程中受挫，甚至與開發大哥產生矛盾，覺得是開發的水平不行、不重視。

但實際上，遊戲作為一種非常複雜的軟體系統，設計與實現本身就是密不可分的，再好的設計，不考慮實現導致難以落地或者落地後出了問題，那也等於0。

而一名優秀的遊戲策劃，在提需求、寫策劃案時，就得多想、多聊、多思考，而不是事後因為忘了A、不知道B、沒考慮到C、做不了D、沒測到E，最後交給玩家一個閹割的不好用的甚至有bug的功能。


原文：https://zhuanlan.zhihu.com/p/684909430