偏見VS傲慢?為何遊戲總改不好,聊聊遊戲製作過程中的調優調研做法
最近看到一些產品的失敗都被歸咎於逼氪、太肝、得出的結論過於籠統,如果一個遊戲都是如此歸因,那豈不是做不肝、不氪的遊戲就能成功呢?
為何使用者與設計師之間存在著如此不可調和的矛盾,更有甚者使用者之間的反饋也會互相沖突。所以在產品的設計/調優過程中一直存在一些聲音的干擾這時候要如何的兼顧做取捨,不被使用者牽著走從而聽到正確的聲音成為設計師/運營的命題,所以有了以下的一些經驗方法可以分享出來。
一、聽取使用者的聲音(訪談+社群+問卷)
使用者的話要聽嗎,答曰肯定是要聽,使用者是大家的衣食父母,那怎麼聽,用什麼來聽,才是大家最關心的事情,以下是一些常用的調研方式。
a.使用者訪談
使用者直接訪談1V1(電話、面訪),是瞭解使用者對產品感受最深度的方式,所面對的使用者越核心,給出的反饋越精準,故而一般都會進行多組使用者的深度訪談,以追求到控制變數。訪談中分為兩類:訪談就更深挖一些玩家個人觀點,ce測試是觀察玩家、追問為主。
在訪談的時候,除非是從業者(專家),對玩法評價時會表達出較為籠統的、主觀的感受,如不好玩,不喜歡等,需要我們引導感受去往某個設計歸因,讓使用者能從面——線——點更深入的評價 。
集體對一個設計產生評價時,如果集體的統一性夠強,就說明設計的方向問題可能性大,但如果無法統一,則需要去了解因為什麼發生了變數,如:使用者的遊戲習慣不同,使用者的生活習慣不同等因素導致。
眾口難調,曾經在原神出的時候,曾面對過一個塞爾達使用者,對原神充滿偏見,覺得美術是抄的、玩法不好玩,但其實沒仔細體驗過原神/非手遊使用者,你就算變出個塞爾達手游來也不能滿足他們的需求,在這種情況下,往往會劃定使用者圈層,並且為圈層使用者中進行一定的權重加成。
比如在最近剛上的星穹鐵道中,發現不喜歡回合制的使用者除非把核心改動改掉,否則很難滿足他們的遊戲訴求,所以還是需要先劃定圈層對使用者反饋進行取樣、控制變數,以提取核心資訊,所以找對使用者是使用者調研的前提。
陰陽師使用者圈層
我們就得到了一個使用者主觀感受表述,問題集中度較高則需要引起重視,但很可能會遇到如下問題:使用者由於過於害羞/過於激進無法在人面前展示對遊戲真實的評價,使用者的數量有限導致樣本偏差,如在某個地區的拉到的訪談玩家會具有某個地區的共有屬性。
定性CE訪談報告
b.社群反饋
最直接接觸到使用者的渠道是社群:包括TapTap,b站評論等形式,這一層普遍能反應核心使用者的感受,透過使用者單當面輸出的反饋形式來。
在這一個方式上,能反應出客觀事故:如戰雙的黑卡事件反應出運營問題、也能反映出主觀感受:如某2遊NTR事件反映出文案問題 。
使用者主要也是透過這個渠道來了解遊戲發生的狀況,社群運營好了也是遊戲生態的一部分,變成更熱愛遊戲玩家衍生出眾多二創,給遊戲帶來額外的生命力,甚至會成為使用者留存的重要原因。
但也容易被帶節奏,如出現的某個小BUG,遊戲的類似貼圖被煽動,導致一定程度上的所謂“帶節奏”。
需要自己沉下心去分辨哪些模組是真的有問題哪些模組是沒問題的,越表層的設計如文案、美術、運營事故越能直觀表現,越需要引起重視,越底層的越需要分辨,這就是所謂調優沒這麼容易的原因。
舉個例子:映月城與電子姬,針對網友對手遊的的吐槽,該遊戲破天荒的做出了無限體力,免費月卡等形式吸收玩家,但實際的運營效果並不理想,說明更深層的內容要更要慎重考慮意見。
c.問卷調研
為了傾聽到更多使用者,需要進行用研問卷設計,並不是所有的使用者都會在社群裡發表自己的感受,故而會在遊戲裡發放用研問卷讓使用者填寫。
在面對設計時,若所有玩家對某個設計反饋不好集中度高,並且連內部體感上都有問題,越淺層意見,越可視覺化的的設計問題真實性越明顯,就越需要優先修改,修改優先順序為:美術>互動>文案>戰鬥>關卡>系統>商業化>數值,如:忘川風華錄一開始版本升星操作繁瑣,但是涉及到越深層的就越需要謹慎。
在面對玩家對修改意見不一致的,可以透過交叉分析,獲得各個R級/各個活躍層架/各個遊戲進度(後臺資料取),以辨別系統面對的使用者感受是如何。
比如:付費彈窗設計,小R甚至零氪,極少在這種價效比上花費金錢,但是大R卻是很喜歡這個系統的他們會認為很划算——衍生出了不同使用者對不同系統的評價不同,需要適當調整分層的權重來獲得真實面對使用者的評價,進一步進行取捨
AFK彈窗設計
遊戲中用研問卷對遊戲設計部分的評價,往往是主觀感受,但是涉及到數值模組,大家都會不約而同的選擇——獎勵給的不夠多。
但如果因為獎勵不夠多而給多,把玩家的下一步數值目標給填滿,反而玩家輕易獲得當前目標,一大段時間內即進入了能力比挑戰強的狀態,心流上趨近無聊,進而玩家上線沒動力,導致玩家流失反而是得不償失的。所以在數值設計上的模組設計師需要非常謹慎,因為這是牽一髮而動全身的,這也是為什麼有些問題玩家一直噴但是設計師不改的一個影射。
小結:使用者研究能幫助我們完成基礎的問題發現,未來期望的方向與主觀感性的感受,。
但實際落地時候需要考慮到的是改動成本與價效比,並且使用者與使用者之間可能發生衝突,需要把資訊重要程度梳理。
使用者是主導我們發現問題的鑰匙,但不能被使用者牽著走喪失了設計本心
調研模型
二、看使用者的行為(資料分析)
遊戲不同於網際網路產品的是,遊戲裡面涉及到經濟、人文、數學模型等較為深度的設計,故而並不是使用者層就可以明顯感知到的,需要額外的手段來輔助我們驗證設計更深層次的東西,故而需要結合資料分析來看:
A.遊戲基礎運營資料分析
使用者的留存、LTV、活躍、ARPU等常見運營資料是一系列設計後彙總的核心指標,目前手遊市場已經非常發達,對各個品類/競品的核心指標都會有標準,故而在外層往往更注重這些資料,一般超過了預期就需要做使用者行為的基礎分析即可。
所以才會有為什麼某個設計玩家在噴,遊戲依然堅持這個設計——因為在收入等關鍵資料上有所提升,或決策層短視等原因拋棄了這群會退坑的玩家,選擇服務沉默的付費玩家。
但基礎運營資料如果出現了問題,如果第N天的留存摺損比較強,則需要更細一步具體梳理使用者行為。
遊戲基本通用指標
B.使用者數分行為分析
此處是遊戲內部使用者的具體行為分析,相對於用研分析可以看到使用者的客觀行為,比如使用者數值養成飽和度、使用者的商業化行為,使用者的關卡滯留率、通關速度等在使用者主觀反饋上取樣不到的資料。
比如某個系統被設計出來但是參與率異常低,我們故而能知道系統設計可能出現了問題,但是還有以下可能:
- 系統規則本身不合理導致使用者主觀不喜歡這個系統,從用研反饋上能明顯收集到較多;
- 系統本身投放的養成資源已經溢位/.產出價效比分配價效比低,玩家在數值上對這個系統沒有追求;
- 系統的介面層級較深、導致使用者找不到/不符合系統定位層級;
- 日常的任務系統不設定該系統引導;
- 該系統本身是一個邊緣系統,需要對遊戲系統定位,產銷、價效比有一定的的瞭解感知等等等等。
我們在面對資料時,做到了發現資料——部分歸因——但是做不到建議,
在很多資料分析上上看到的僅是潦草的幾個:建議調整系統,建議改善卡點,最佳化留存等隔靴搔癢的建議。
但準確定位問題找到原因,並且提供更有方向/更落地的建議能夠更好的服務於專案就需要進行競品調研,對同型別遊戲有深度瞭解,避免閉門造車的情況。
PS:如果資料過於災難,建議調整產品方向而不是調優這麼簡單了
三、看同行的做法(產品拆解)
有時產品質量過關了,但是在市面上出現了比較先進的設計方式而導致玩家差評/玩家資料表現不佳,在設計時沒考慮到,就比如:三國志幻想大陸的全域性加速。
有時候是出現產品基本的設計存在明顯改良空間,透過一系列產品拆解對比,可以找到自身產品的問題。
如新手節奏打點,成長節奏等,也可以透過系統比對找到可能的歸因,並且得出一定的最佳化方向(需要有一定的遊戲拆解能力)。
曾經在面對回合制的自動掛機系統中,使用者的評價呈現極端的兩面性:部分玩家覺得掛機刷怪沒什麼,但是部分玩家覺得為什麼還要持續的掛機,仔細拆分來看會發現大有不同。
習慣了掛機系統的玩家回合制遊戲的經驗較為豐富,而不習慣掛機的玩家遊戲經歷比較泛,熟悉魔靈的設計師就知道在這套框架下不適用於改動掛機獲取裝備的形式,因為魔靈自身的養成扁平,策略度深,數值目標需要自我尋找搭建,故而需要這麼一個強數值壓力,要求穩定陣容的玩法來迫使玩家認識魔靈。但從表層感受去否定一個深層設計,容易造成遊戲無法構成閉環,從而導致玩家流失。
魔靈掛機
在反拆競品時,受有幾種方法可以驗證競品是否比我們更好/有效果:
- 主觀拆解,用自己的設計經驗、體驗經驗去感受設計好壞;
- 運營資料分析,若競品在某個版本上了某個系統,起到了較好的活躍作用,則改系統推測是有效(從第三方資料平臺可以捕捉到);
- 資料分析對比,這涉及到較為機密的公司機密,一般需要有比較豐富的資料庫來做benchmark(大廠積累的優勢也在這);
- 人脈打聽,如果有相關認識的人,不如當面問問某個設計點是怎麼想的,為什麼這麼做,效果如何。
系統橫向比對
四、規劃與總結
- 用研更能反饋主觀意見與感受,可以在發現問題之外定位到更近準的感受,但缺點是對問題的發現度上不夠客觀 ,容易被部分使用者帶節奏,研發需要保證自己的主見;
- 運營資料是遊戲的命脈,先看分數再分析原因,資料分能更客觀真實的記錄使用者的行為,但比較難反應使用者的主觀感受;
- 拆解可以獲得更多先進的產品,避免閉門造車,最好透過多種渠道去反推設計、設計效果來獲得方向啟發;
最後根據排期與人力梳理優先順序,可以利用kano模型、遊戲設計階段與重要性(表層的設計一般影響前期留存、而底層設計影響後期留存),去解決優先順序高的問題。
原文:https://zhuanlan.zhihu.com/p/621289774
相關文章
- 《傲慢與偏見》中的幾句翻譯
- 傲慢的渠道:下架侵權遊戲為何這麼難遊戲
- 在製作遊戲的過程中,我都解決和改進了哪些問題遊戲
- 支付寶小遊戲調研遊戲
- 論系統管理員的傲慢與偏見
- 三維偏序的優秀做法
- 遊戲製作之我見:) (轉)遊戲
- go dns解析過程及調優GoDNS
- JVM調優總結-調優方法JVM
- 人類本性都有傲慢與偏見,那麼人工智慧會有偏見嗎?人工智慧
- 省錢又不失格調!九個遊戲製作省錢大法遊戲
- 跟你聊聊怎麼設計真正的動作遊戲(五):何為“戰鬥節奏”?遊戲
- Cortana小娜失敗背後,微軟的傲慢與偏見微軟
- 分享製作骰子機制角色扮演遊戲的過程(上)遊戲
- 記一次SQL調優過程SQL
- 開發中hive常見的調優策略Hive
- JVM調優總結(十)-調優方法JVM
- 2020遊戲研發力量調查(移動遊戲篇)遊戲
- Newzoo調查:紐西蘭玩家偏愛益智遊戲 沙特雲遊戲玩家佔比最高遊戲
- 無線通訊中的IQ調製,BPSK調製,QPSK調製,16QAM調製的理解
- Unity製作遊戲中的場景Unity遊戲
- 一次效能優化調整過程.優化
- 用dbms_profiler調優儲存過程儲存過程
- 炒冷飯的遊戲,為何總能“真香”?遊戲
- 記一次"截圖"功能的專案調研過程!
- 遊戲的留存為什麼那麼難調?遊戲
- 為何RPG是遊戲中的王者?遊戲
- 聽Odyssey Interactive講述多平臺遊戲《Omega Strikers》的製作過程遊戲
- 軟體專案需求調研過程管理小議(轉)
- 小遊戲的製作遊戲
- Oracle 調優總結Oracle
- Oracle調優總結Oracle
- 調研
- Voodoo分享:爆款遊戲《Tower Run》和《Roof Rail》立項研發與調優Odoo遊戲AI
- 荷蘭公司設計智慧書籍 傲慢與偏見者禁讀
- 一次 kafka 消費者的效能調優過程Kafka
- 談談軟體開發中的調研物件與被調研物件 (轉)物件
- 談談軟體開發中的調研物件與被調研物件(轉)物件