“食物鏈底端”策劃的升級之路——如何獲得團隊的認同
導語
本期真經閣邀請到了騰訊十年老策劃,寫過文案,碼過指令碼,弄過技能,配過音訊,拉過數值的Bruce,為好奇遊戲行業的你,剛進入遊戲行業的你剖析遊戲策劃的“難”,以及近年來“難上加難”的策劃又該如何升級,成為一個少挨玩家噴,少被開發打的合格遊戲人。
一.我們中的大多數人
如果給各位策劃崗位的同行劃分一下,可以總結出三種型別的策劃。前兩種是極少數的極端情況。左側圖的策劃,PUBG,戰術競技(Battle Royale)型別的開創者,這種策劃大佬的存在基本等同於遊戲專案的靈魂,掌控遊戲世界規則的男人。右側,行業新兵,被程式和美術鄙視的物件,食物鏈底端的工具人。
而第三種,也就是作為策劃的大多數人,我們在團隊裡有一定的話語權,但更多時間還是在執行需求,有多個專案經驗,結果有好有壞,而像我們這種普通策劃,想要在團隊中獲得“地位”/認同,靠什麼?
有人說,靠專案。這個是必然的,如果一個策劃的履歷上有幾千萬使用者量級的爆款專案經驗,那他就是所有團隊眼裡行走的香饃饃。但問題在於,擁有爆款專案經歷的策劃應該也只有極少數人,所以我們還能靠什麼?
有人說,靠能力。但這也涉及到策劃崗位一個很尷尬的處境,眾所周知,遊戲研發團隊裡,除了管理型崗位,就是美術程式策劃三個支柱。美術的能力怎麼看?一幅原畫出來,畫風是否適配,功底是否到位,一目瞭然;程式能力怎麼樣?寫一段程式碼出來,邏輯是否嚴謹,一目瞭然。策劃呢?靠方法論,而問題在於方法論是沒有統一的衡量標準的,因為每個人對於遊戲設計都有自己的方法論。
說到這裡,我想表達的是,能力與專案都是策劃的資本,但是如何在工作中獲得團隊成員的認同,讓人信服,歸根結底,可以用遊戲裡的詞彙來形容,那就是升級,累計聲望。接下來我也會分成四個階段,將這個看似很虛無的方法論來落地到實際工作中,策劃崗位該如何實施它,提升自己在團隊中的“地位”。
二.入門先鋒:方案設計
作為策劃新人,正式踏入這個崗位的第一步,來自你的導師或是上級的第一個任務,要麼是對應專案的分析報告,要麼是一份與細分崗位掛鉤的策劃案。無論是做關卡策劃,技能策劃,活動策劃,這一點相信大家都有同樣的經歷。
由於這時的你還只是個懵懂的新人,所以這第一份策劃案,通常不會要求你能給出前無古人後無來者的創意,這份策劃案最重要的就是它的完整性和可執行性。
(一)定位
要寫一個策劃案,你會碰到什麼情況呢?有的Leader可能會給你詳細地描述他的需求,有的Leader可能會拋給你一個參考的遊戲專案,讓你自行揣摩。而當一個策劃新人遇到這種短小精悍的需求時,你需要做的是定位需求。
1.知道做什麼比怎麼做更重要:很多情況下,新人在遇到Leader對任務描述比較簡短時,或是不敢追問,或是覺得自己有很多想法可以發揮,多半都會選擇盲目地領了需求後亂寫一通,於是這種策劃案交上去,最終導致的是與Leader的想法不一致,策劃案只能面臨被否決,回爐重造的命運。
2.那麼如何定位需求呢?我個人傾向逐級拆分核心需求:剛才的例子延伸出來便是我早年曾經的專案經歷,當時在拿到這個需要“微創新”的PVP戰鬥需求後,我首先做的便是在與Leader的溝通中確認好逐級的核心需求。
要知道在2014年的時候,射擊手遊同步PVP還是一個很難實現的事情,許多射擊型別手遊採用的還是非同步PVP,所以當時我與Leader進行了確認,是同步還是非同步戰鬥,於是第一個核心點出來了,需求要做同步PVP戰鬥,也就是實時戰鬥。
接著,這個玩法的適用性,Leader給出的答案是,希望能夠隨時隨地戰鬥,所以第二個核心點出來了,希望能隨時匹配到玩家進行戰鬥,也就是實時匹配。
最後是關於戰鬥的體驗,這個PVP玩法中,是否允許數值的縱深,當時討論之後,確認既要表現出一定的付費體驗,又要基礎對戰平衡,所以我們需求的是相對平衡性,也就是數值天秤。
(二)預設
當我們完成了對需求的定位,將其分拆成為核心點後,我們來到了下一步,如何進行策劃案的編輯。在這一步,我所提出的問題是:你寫策劃案的思路是怎麼樣的?
1.設想問題,理清設計細節:這裡要給策劃新人們提供一個建議,像寫作文一樣,給你的策劃案打草稿,在這裡我們所做的依舊是給這個PVP需求完善它的框架,你需要將腦海中的想法,創意都在鍵盤上敲擊出來,一個個地設問,推敲,取捨;想清楚這個玩法系統中各個節點的問題,好應對策劃案提交後面對來自其它開發人員的問題,防止一臉懵逼。
2.推導功能,開發關鍵模組:理清設計的細節問題後,緊接著便是結合,在進行需求定位時確定下來的核心點,推匯出的功能模組。第一個核心點,實時PVP涉及的是戰鬥方式和戰鬥關卡模組,隨時隨地PVP的核心點所關聯的是匹配機制與AI對戰功能模組,而與平衡性相關的則是涉及職業,裝備等的數值天秤。
(三)對口
策劃作為需求的發出方,但執行需求是團隊中的各個專業成員,所以在編輯策劃案時,我習慣多加一個步驟,與對口的成員討論方案,得到他們的反饋意見來進一步完善策劃案。而在溝通過程中,也瞭解了不同專業的人,他在看策劃案時的偏好與關注點不盡相同,但總結來說,便是抽象的長段文字比不上具象化的重點演示。
1.流程-簡單明瞭的邏輯圖:我一開始拿給程式看的流程策劃案也是句句斟酌,十分詳盡的一份文件,但是當程式看到這樣一份文件時,表情是微妙的。其實也不光是程式,對於我們這種普通人而言,閱讀大段文字通常都會讓人心生牴觸,如果不得不讀,還會面臨許多因人而異的理解偏差。所以,為了保護我方程式的腦細胞,最後那一大段文字變成了如上所示的邏輯圖。每一個節點的開始,結束,中間的判定過程都可以非常清晰地看到,所以這也使得實際流程開發的過程十分順利。
2.玩法-清晰明確的示意圖:玩法的展示也是同樣的道理,在進行一些專案的PVP玩法開發時,有時玩法的創意部分便不是由具體指定的關卡策劃來主導,而是鼓勵每一個人的玩法創意。所以在跟開發溝通需求時,歷史再次重演,他們對著初版文件也是一臉茫然,於是文字版策劃案重新改了表現方式,轉變為一張玩法具像圖,而這種具象化的展示讓開發很快便抓住重點,包括掩體的位置,對角線,距離等要素。這樣一來,便是有疑問,照著圖來溝通,也省了無數口水。
3.體驗-論證法:最後再提一個比較貼近實際應用的技巧。在開始敲定核心需求的時候,之前提到了,Leader的其中一個要求是玩家能夠隨時隨地戰鬥,這就涉及到戰鬥AI的引用。而在設計過程中,除了AI的行為,反應時間等等設計,比較有意思的點發生在設定AI射擊命中率的時候。當初我們在設定射擊命中率時,一開始給到程式的方案是採用純百分比的命中率設定,比如給AI設定五五開的命中率,但卻發現在AI的射擊命中率在實際的遊戲環境中遠遠達不到我們所設定的需求。後來我們搜尋相關的資料時,發現了魔獸世界的團隊在一次分享中所提及的判定機制-命中修正。這個判定的邏輯是,在擁有足夠基數的情況下,AI的戰鬥次數越多,命中率越能夠貼合我們的需求;並且在純隨機的少量樣本情況下,也能夠基本滿足我們的需求。於是關於AI命中率設定,就變成了給出基礎值,然後再做修正,並在這一過程中將AI的命中率拉回一個平滑的狀態來最終滿足我們的PVP對戰需求。寫策劃案的我們,難免會各式各樣的需求中觸及自己的知識盲點,但是多跟身邊的專業人士請教,在網上搜尋資料,也許就能站在行業前輩的肩膀上來解決問題。
一份策劃案,人人都可以寫,但是你對設計方案的呈現方式,你對設計細節的把握,小到在優化過程中多一個和對接需求人同步的步驟,在策劃案中增加一個目錄供人查詢等等這些技巧,都關係著這份策劃案的成敗。而對於剛入職的新人策劃,設計方案的需求過程都是提高團隊成員對你認同感的打分過程,如果你連第一關都過不去,那麼在之後的工作裡就可能會漸漸失去主導一個策劃案的機會,只能負責其中一個模組,甚至是陷入永遠在做執行的窘境。
三.進階標兵 推動執行
我們繼續看一個新的例子,在上一個階段,我們完成了策劃案的編輯,Leader拍案叫好,我便拉上開發開始分需求,做玩法,對接童鞋給了答覆,沒問題,一個月搞定,我記下來,一個月後看成品。等到某天Leader走過來問了一句,進度如何了的時候,我便照搬了程式給的答覆。於是Leader眉頭一皺,我才發現事情沒那麼簡單。
這種情況不是個案,而是發生在很多策劃的身上。有一些策劃同學習慣性的把推動需求執行這一任務劃分到PM的負責範疇,認為策劃只負責最終驗收。但是,這種情況下,最終的成品可能因為策劃在執行過程中的長期缺失而變樣,所以我認為,策劃在需要在需求被執行的過程中主動地推動,跟蹤進度,而這並非意味著你需要每天去催需求進度,逼著開發把四十米的大砍刀拿出來。
(一) 準備
1.兵馬未動,糧草先行:前面我們也講過,策劃案的編輯過程中我們需要預先設想可能面對的問題,而在開始執行需求之前,你同樣需要關注這個需求的實現基礎能有一定的瞭解和預期。這包括你在引擎,架構,動畫,特效,動作,音訊等等方面進行惡補,作為策劃的你需要擁有足夠廣的知識面。因為只要當你對這些方面有足夠的瞭解,才不會產出一個天馬行空的需求,有人會質疑這是在扼殺創意,但實際上,這是在幫助你的創意得到落地的機會。比如你提出的需求裡需要一套技術方案,那麼你需要提前瞭解一下這套方案能否實現,能夠實現到什麼程度,以及原因。紙面上的策劃案不可能涵蓋所有問題,所以這是需要你跟對接需求人提前確認的點;再比如,開發週期的問題,一個足夠有創意,可行性高的策劃案,最後因為開發所需週期過長,無法趕上線節點的憾事,便是可以通過提前的溝通與瞭解避免的。
2.心中有底,從容應對:開工如開戰,當你拉上程式,美術來組成一個策應組,開始做需求的那一刻,也就是整個開發小組對策劃進行打分的時刻,你的策劃案,你的講述都會影響開發小組對你的認同程度。這也是為什麼我一直在強調知識面與預設問題的原因,因為當你完成對策劃案的演示過後,才是戰鬥的開始。程式會追問你編輯條件的細節,而美術則會針對需求中花裡胡哨的表現效果提出底層架構不支援等等質疑,而如果你完全沒有防備,天真地以為這些問題都是專業向的,與策劃無關,等到開工會上被提問時才一臉懵圈地給出:這個問題先放後面/我不知道等等這型別的答覆,那麼開發小組的成員就會對形成一種心理預期,這個策劃連基本細節都沒有理清便要開始執行,未來的返工是必然的,浪費我的才華與時間,扣分。所以,不要認為這些條件框架是在扼殺你的創意,因為如果你在美術,程式面前碰了壁,得不到他們的認同,那麼你的需求就不會得到100%的執行。再進一步講,當你的需求對於開發小組的童鞋來說是一個挑戰時,你需要有足夠的專業知識,來支援你說服他們,接下這個挑戰。
(二) 興趣
1.提煉賣點,興趣參與:工作不僅僅是工作,進入遊戲行業的人或多或少都保有遊戲的熱愛,但在經過一個個專案的需求洗練後,難免會出現對相似需求的厭倦。所以在推動執行的時候,作為策劃,你需要充分的調動這種開發小組的積極性,你要有足夠的忽悠技巧,提煉出這個需求的挑戰點與創意點,讓程式有興趣來主動地實現需求。比如此前為了吸引身為暴雪重視老粉的程式大佬,化身標題黨,將一個技能編輯器的需求文件起名為:“超越魔獸的技能編輯器,牛不,趕緊過來完成曠世功業!“,雖然拉穩了仇恨,但無疑成功吸引了程式老哥的全部注意力。當然,這裡所舉只是我較為浮誇的忽悠方式,但道理是相通的。
2.拉攏實現 過程參與:每個團隊的情況不同,但大多數情況下,在策劃提完需求之後,程式和美術只負責實現,而最終的驗收成果只由策劃負責。這一過程中,我建議作為牽頭需求實現的策劃,應該找到恰當的時間節點,將開發小組集合到一起,在小黑屋裡一起體驗實際的demo,無論是為你的成果驗收提供新視角,還是提高團隊凝聚力,都是絕佳的方式。
(三)同步
一個技能編輯器的需求,在策劃的想象中,應該是視覺化,可隨意組合搭配,且編輯效果即時可見的。而最終程式給出的編輯器成品,是英文,技能只可單個編輯,且效果需要執行Unity才可展現。也就是說,你提需求時所要達成的目的大打折扣,這個需求廢掉了。所以不要想當然,策劃在開始推動需求之前需要與對接人溝通並對未來效果有一個預期,而不是等到成品出來才發現偏差過大。
再比如美術,當你找了一堆酷炫的圖片或視訊擺到美術面前做參考圖,說這個需求要達到這種效果,而美術跟你說,好,我評估一下。這個答案新人策劃可能會理解為美術說可以,但實際上他可能已經在心裡打折了。策劃的參考圖≠美術的心理預期。
尤其是特效,由於製作流程的原因,特效的完成時間幾乎是排在開發週期偏後的時間段,而如果等到特效成品出了才發現有問題,想要搶在時間線前進行優化或者重做顯然極度困難。所以我的建議是,不僅是需求方要給出參考圖,也可以要求美術給出他的預期效果圖,不一定要花費很多時間畫一張效果圖出來,美術也可以從網路上找出一張他認為能夠達到的效果圖或者視訊,只要雙方都有具體影象作為依據,策劃也就能瞭解需求的美術表現是否能夠合格了。
在開始實施需求的階段,策劃面對的是整個開發小組的成員,而方才總結的幾個技巧,也都是為了在推進過程中,保證需求的不偏差。即使大部分研發團隊都有專門的PM來負責排工作表,規劃每日的開發進度。但是對於策劃,作為需求最終的驗收者來說,以周,甚至是以天為單位,與你的開發小組進行溝通,同步的做法,無論是對你個人,還是對團隊成員來說,都是每天一小步的上升和認同過程。
四.獨當一面 問題處理
策劃案寫好,需求實現完,恭喜你已經初步獲得了團隊成員的認同,但你做出來的東西,使用者是否買單,才是對你工作的最終評判。當一個玩法上線後,再完善的設計在面對大量使用者的體驗後都有遭遇滑鐵盧的可能,所以這時我們來到了第三階段,考驗的是策劃的問題處理能力。
(一) 篩選
一個玩法上線,就要做好面對鋪天蓋地的吐槽。首先,來自外部使用者的反饋,因為使用者屬性不一,對玩法的看重點不同,所以沒有任何事情是完美的。其次,是來自專案組內部成員的意見,包括運營,程式,甚至是從Leader層給到他們對未來玩法的優化方向。所以如何平衡“眾口難調”的問題,讓大多數使用者能夠滿意便是關鍵。那麼,究竟要如何從海量的玩法反饋中去偽存真,快速定位問題呢?
基本上所有玩法系統上線時都會提經分需求,經分細節呈現因人而異,而拿一個PVP戰鬥系統為例,當時的經分系統主要涵蓋了如圖所示,三個角度下的細分資料。而這些玩法資料的收集,因為在遊戲上線之後,玩法的改動基本上除了一些能夠通過熱更新或者緊急修復解決的BUG修復,優化更新都需要一定的週期,所以經分系統有助於我們快速地定位問題,甚至通過數值編輯,比如匹配區間,產出獲取等調整來響應玩家的反饋,提升玩法滿意度。
(二)把握
下一步,通過將經分系統的資料與玩法上線後的一系列反饋,包括玩家調研,來自Leader,運營等等團隊成員的意見進行交叉對比,策劃便能夠對整個玩法上線後的情況有一個全盤的瞭解。打個比方,在一次新上線的PVP系統調研中,玩家對生化人威脅程度的投票顯示為適中,但是通過經分系統,我們卻可以看到資料反饋是生化人的威脅較大。
這種看似自相矛盾的結論其實很常見,因為調研很多時候收到的只是一小部分玩家的反饋,給出的是個人的直觀感受,而資料便是以科學的方式給你拉取出了所有玩家的平均水平,兩者缺一不可。
(三) 聯絡
所以我們需要做的是,將片面的問題聯絡到玩法整體來觀察,拿PVP玩法來說,便是看局內聯絡。上面所舉的例子中,殭屍是一個實際威脅,而玩家在面對威脅時,總共有3個要素在影響他的PVP體驗,首先對抗生化人玩家需要武器裝備,如果玩家初期沒辦法快速獲得裝備,就是前期失敗的主要原因。再來,玩家有野外的威脅,也就是當開局一段時間,天黑之後,玩家呆在戶外時,壓力值會不斷增高,對你的身體造成一些不良的反應,進而導致失敗。所以玩家一般在壓力值的逼迫下,只能尋找房屋來避免壓力值的攀升,而夜晚還有生化潮的威脅,也就是大批生化人的圍攻,它們的襲擊目標則是以待在房屋內的玩家為主體。所以策劃在看待一個問題反饋時,不能單憑資料中顯示遊戲對局前期失敗率高,就判定遊戲難度高於預期,而是要聯絡玩法整體來看,看是生化潮重新整理頻次過多,還是壓力值的攀升速度過快,又或者是裝備投入的不足。否則,盲目地根據玩家的反饋對遊戲做改動,又或者是單憑資料便開始對玩法做加減,勢必會引起新一輪的吐槽。
在第三個階段,策劃要做的是在玩法上線後及時地跟蹤資料,進行分析反饋和推動優化,而當專案組的成員看到你在處理問題時的能力後,整個專案組對你的認同感自然拔高,覺得這個策劃的靠譜程度又一步提升。
五.坐看全域性 提煉總結
最後,進了全域性觀的樹立階段,策劃需要能對一個遊戲進行整體的提煉總結能力,也就是說,拋開你負責的專案之外,你需要緊跟行業潮流,對市面上的遊戲有一個深度的瞭解,而不是玩了以後一句真香就沒有下文了。
有一些人分享應用文章,或者是這種寫這種分析文章的時候,十分詳細,從槍支武器的型別數值,地圖大小再到復活機制等等全部應用點都羅列了一遍,這些應用點重要嗎?重要,但是如果你對一個遊戲的分析只停留在這一層面,那充其量只是對這個遊戲進行了統計整理,更重要的是,透過這些設定,我們能夠看到的設計思路是什麼?拿《Apex 英雄》為例,這些應用點背後所體現的是整體遊戲戰鬥節奏,數值體系以及地圖設計理念,而你的分析目的,是關注於它這麼做的好處/壞處分別是什麼?
例如在我對《Apex 英雄》的體驗中,我個人的體驗總結是,它的戰鬥節奏是充滿爽快感的;它通過架構豐富的對戰手段,用數值系統提升了玩家的生存空間;它的地圖設計總結來說,減少了很多的迂迴,然後加入了區域分割的概念,它的核心體驗,對戰體驗是更加爽快,對戰手段更加豐富的,開放地圖戰術競技對戰。而抓住核心之後要再深挖分拆到模組,回顧他們具體的設計點對核心體驗所產生的影響,將整個遊戲的點線面串聯起來,如在《Apex 英雄》中,就可以分析以下3個模組的設計點與核心體驗的聯絡:
復活機制:鉅額血量的倒地盾、自帶復活道具的設計大大減緩玩家對戰死亡的代價,使玩家更願意參與戰鬥。
功能性效果:增加豐富的對戰手段,放大對戰體驗,擴充套件“探查、機動、惑敵、救助、防護、陷阱、分割戰場”的體驗需求。
關卡節奏:通過高遮擋的分割獨立區域,減少遠距離攻擊, 而在建築的設計上則減少了二重房間,並通過窗戶無法翻越的設定,來減少迂迴戰略空間,控制對戰節奏。
當然,這裡所提種種也只是個人的見解,但我所想表達的是,只有通過對核心體驗以及深挖模組的把握,才能夠從整體上形成對一個遊戲的理解與分析。而閒暇之時多進行提煉總結,或者對自己玩遊戲時的體驗進行記錄,這個過程獲得別人的認同,或者磨鍊寫作能力都是錦上添花,最重要的是你自己在過程中收穫的遊戲理解。而如果你的文章見解能夠激發討論,與行業內的策劃交流彼此的視野看法,也是美事一樁。
結語
開這門課,寫這篇文章的時候,也想過,可能許多人會覺得裡面提到的都是日常工作中的一些細節而已,但是見微知著,無論是策劃案的編輯,需求的推動執行,上線反饋的處理還是看似無關緊要的遊戲分析提煉,都決定了一個策劃的成長以及團隊成員對他的認同度。大家都知道的事情不一定都做得好,如果你做好了,做極致了,便是你脫穎而出的機會。文章寫完,如果能對剛踏入遊戲行業的你有所幫助,便是它最大的價值了。
相關文章
- 如何用20分鐘就能獲得同款企業級全鏈路灰度能力?
- 遠端IT運維的升級,“團隊協作”運維
- 職場寶典:遊戲策劃菜鳥如何入門打怪升級成為“老策劃”?遊戲
- Supercell投資一覽,獲得青睞的團隊都有哪些?
- 如何獲得PMP認證證書
- 食物鏈
- 團隊拓撲:減少軟體團隊的認知負擔 - mimacomMac
- TDengine 的儲存引擎升級之路儲存引擎
- 升級JDK8的坎坷之路JDK
- Git 團隊協同開發Git
- 如何從挨踢的食物鏈底層“往上爬”
- 什麼是TOGAF以及如何獲得TOGAF認證
- 如何讓策劃加入你想要的功能?
- 團隊如何組織?前後端團隊與業務功能團隊的比較後端
- 技術管理進階——如何規劃團隊的技術發展方向
- 位元組半年,我的認知升級
- 品友全面升級集團戰略 AI賦能商業決策AI
- 一隻node爬蟲的升級打怪之路爬蟲
- vue升級之路(三)-- vue-router的使用Vue
- 食物鏈題解
- 網際網路獲得大規模的安全升級時會發生什麼?
- XView 架構升級之路View架構
- vue升級之路(四)-- VuexVue
- 如何管理一個散漫的團隊
- 如何實現高效的團隊合作?
- 打怪升級之路—Security+認證通關攻略(401還是501)
- 如何升級fedora的版本
- 一般來講,大公司都有自己的決策團隊
- Android Target 31 升級全攻略 —— 記阿里首個超級 App 的坎坷升級之路Android阿里APP
- 採購團隊如何從物聯網中獲益?
- 第0篇---電子小白的打怪升級之路
- AngularJS 遺留專案的升級改造之路(一)AngularJS
- 獨家揭祕國內唯一一家獲得Oculus投資的VR遊戲團隊VR遊戲
- 談談“認知升級”
- 遊戲策劃知識點——如何在玩遊戲的時候培養“策劃思維”遊戲
- jq獲取上級、同級、下級元素
- 團隊管理者最重要的是做好計劃管理
- 女策劃更能抓住女玩家的需求? 90後女主策認為細節是關鍵