Table of Contents
本文內容整理自 2024 UR meetup 使用者研究實務研討 的 HackMD共筆文件。
1 九日對赤燭的挑戰
赤燭遊戲過去製作的《返校》、《還願》,屬於純敘事的解謎研究,搭配遊戲機制就可以推進故事,但是九日屬於動作遊戲+敘事,可能要面對與過去的玩家不同類型的族群。
獨立遊戲的三角習題
- 玩家市場:該做什麼
- 做遊戲的根本
- 創作理念:想做什麼
- 想表達的東西
- 擁有自由的創作權
- 開發能力:能做什麼
- 小團隊的開發量能有上限
- 評估開發規模
遊戲開發需要在理念、市場與團隊能力當中取得平衡
2 一連串的測試過程
Prototype 測試
- 目的:測試遊戲的機制可玩性&可行性
- 對象:團隊成員
- 形式:很彈性的讓研究、開發,跟測試同步去進行(不進美術、方塊人測試)
Alpha測試(兩年)
- 目的:對於遊戲的整體可玩性、架構與概念上做專業評估
- 對象:獨立遊戲開發圈好友
- 形式:到赤燭公司會客室用大螢幕玩
- 邀請產業內的友人來進行測試,用 OBS 測試,在YT上進行私人直播,可以同時觀測到:遊戲畫面+測試者的表情
這種方式可以知道知道在獨立遊戲領域,如何才是「夠格」的遊戲,不過前期有很多未完成的內容,測試者誤會時就會打斷測試以口頭告知,這也成為測試時的一個限制。
YT 私人直播測試的好處
- 不怕機密資料外洩
- 權限可以跟 google 整合
- 可重播,沒有保存問題
Demo:跟募資一起發佈
- 目的:行銷與火力展示,將粉絲導入 Discord
- 對象:全世界感興趣的玩家
- 形式:將 Demo 上架到 Steam,參加新品節(遊戲還沒完成可以 Demo 增加關注度)
主要觀察國內外實況主反應,海巡 Steam 評論區與論壇的心得文,收集回饋,增加排行榜提升熱度,對實況主而言也更有娛樂性。將粉絲導入 DC
Beta 1: 最小單位 Vertical Slice
提供垂直切片來測試,切片代表的是遊戲的一部分要和最終成品有幾乎一樣的體驗,例如:有十關,先拿一關出來做,目標是調整主角進階能力的操作性、關卡設計的方向,對象就是募資贊助者,算是比較短的體驗,讓募資的玩家自己下載,玩完後填寫問卷。
Beta2&3:更大的Vertical Slice
可玩的關卡越來越多、越來越大「配合數據收集」逐步拓張遊玩內容,讓玩家體驗完之後可以快速地填寫問卷,讓開發&設計可以知道怎麼調整
問卷設計重點在於區分受眾:
- 敘事玩家vs 遊戲動作遊戲玩家
- 在意玩法、美術、劇情
- 過去的遊玩體驗,了解相關競品&對標
- 各方面體驗的滿意度(1~5分)|開放的質性內容,審慎評估抱怨點是因為玩家的喜好差異,或是遊戲本身體驗不足
關鍵問題(講者認為最有幫助):
- 遊戲中您最享受的時刻或印象深刻的體驗是什麼
- 遊戲中您最不喜歡的時刻或互動體驗是什麼
- 假如您有神奇魔法可以瞬間改變遊戲內容,您會想要改變遊戲的哪個部分或增加哪假如您有神奇魔法可以瞬間改變遊戲內容,您會想要改變遊戲的哪個部分或增加哪個功能?
- 在遊戲中您有沒有任何想做卻不能做到的事情?
質性的關鍵問題:最喜歡與不喜歡?遊戲特色是否會想繼續玩下去?
藉由善用 youtube、discord 等工具,赤燭在顧及成本的同時努力提升遊戲體驗。
3 最後一哩路:上市前測試
目前持續進行中(有付費),透過 DC 社群招募受測者&開發者好友,藉由 DC 平台回報 bug
Discord 用於研究的好處
特色:
- 訊息不受到演算法的限制
- 粉絲高互動動:文字、語音、實況
- 可安裝、開發各種 Bot
適合測試研究的功能:
- 子頻道權限
- 直播遊戲測試
- 以討論串、論壇功能收集問題
- 直播功能,隨時分享測試過程、隨時觀看玩家遊玩體驗
- 論壇功能,透過 tag 整理並分類問題
成功案例:Heptabase
遊戲玩家的特性:粉絲、玩家都非常積極主動參與測試,一方面可以搶先遊玩,還能對遊戲做出貢獻,很多遊戲玩家會大方分享並展露喜好
當發現問題的時候,也要敏捷的辨別問題類型
- 設計問題:很嚴重!但不一定能改
比如:想做的東西但玩家不買單、沒 get 到,這種問題意義最重,改起來也最困難、也可能不一定能改。 - 實作問題:趕快修
比如 BUG,不過也不一定是開發的鍋,可能美術要補。 - 易用性:盡力而為
介面、元素,讓易用性維持在一個程度上,同時評估開發量能,會先修重要的地方。 - 玩家意見:僅供參考
有些玩家樂於分享主觀意見,但可能是個人想法而已,需要辨別哪些是遊戲想著重的地方。
快速迭代與修正
從直播觀察或是從測試直撥中得到回饋,包含直播時的觀察、玩家主動回報,都會記錄在內部文件,每天分類問題:可以直接指派修正、需要團隊討論,來去快速的修正調整,
數據分析用來做什麼?
- 觀察裝備使用率:有哪些我們精心設計了但玩家不用?
- 遊戲難易度確認:哪些關卡卡特別久?或太快破關?
4 結論
- 團隊成員直接參與觀察測試過程,會對於產品問題更有直接的感受
俗稱:不見棺材不掉淚QQ - 開發時程有限,盡快收集種樣資訊做決策
但也很常計畫趕不上變化 - 使用 DC 等社群工具作為與 User 互動的場域,在社群行銷、工程測試以及收集體驗回饋上一舉三得
5 Q&A
Q:請問觀看直播時會看到臉嗎?
A:會的,透過 OBS 可以結合遊戲畫面&玩家視訊。
Q:好奇從赤燭轉換到九日的過程中,要怎麼衡量不同遊戲玩家族群對遊戲設計的影響?在開始九日前有做了什麼樣的用戶研究嗎?
A:想拓展非台灣、亞洲圈族群,走向國際市場。團隊主要以自己想開發的遊戲主題去做設計,並沒有去以用戶研究找出遊戲方向。確立遊戲主題之後則是有進行境品分析。
Q:想知道用 OBS 測試完,分析的重點是什麼?以及分析的方式?
錄完之後會簡單的聊聊與訪談,需要時才會回放遊戲情形來看。主要是在 DC 進行,修 bug、看玩家遇到的 Bug 是不是解掉了
Q:遊戲通常要玩很久才會玩到後面的關卡,要如何在短時間內可以測到後面的關鍵關卡?還是直接測後面的?
這也是赤燭遇到比較難的議題。沒有辦法直接跳,教學跟內容都沒有累積,後面的內容有可能會因為測試的少,而沒有那麼好
Q:請問數據分析看到關卡、道具使用率低,會如何處理?
有證據可以和團隊挑著討論,或者沒有對應的使用情境,BOSS 太難可以用數值平衡調整,但用數據的話都是比較好處理的,有些問題會牽一髮動全身,這就比較麻煩
Q:好奇為何英文叫做 nine soul?
Nine Sols 是 九個太陽 Sols 是取自 Solarian 不是soul,會和Dark soul 搞混XD
Q:關於收集回饋的幾個問題的綜合回答:
A:判斷回饋類型蠻吃個人專業和經驗判斷,理想上是讓製作人判斷,但製作人太忙就會是大家各自有空或有能力就判斷 (前段時間是我每天會掃一次所有問題然後分配,後來太忙就請別人紀錄後照著我之前分配的邏輯大略分給工程師、美術、設計師等等)
我們會在 Notion 上紀錄問題後,將問題丟給和該問題有關的人,就算丟錯人看到不屬於我的工作,也可以再轉給負責的人就好。整個 workflow 也是迭代後的結果
而有些問題需要討論才能解決,會是比較在意的人自己去邀大家來討論,遇到意見不同會先各自提出方案和討論共識,還是沒有共識就讓製作人決定
個人意見類型的問題就是他的回饋常常會是從不同類型的遊戲經驗帶來的,比如說手遊會有很明確的任務引導,玩家回饋說我們的關卡容易迷路和任務引導不明確,但是我們九日的一大塊重點就是在探索,因此本質上就不會做明確的引導,而是要給玩家自由度,來獲得自己發現的成就感。
Q:想知道對你們來說最重要的幾個數據指標分別是什麼?
道具使用率,各關卡、頭目戰遊玩時間
Q:beta 1 到 beta 3 花多久時間間隔?會找多少玩家來測試呢?
各半年左右,是募資參與的人就可以測試,所以也沒有硬說要找多少人
Q:剛提到遊戲是個有影響力的文化,請問有拓展到歐美的規劃嗎?
已經進行中,我們的宣傳片下方主要留言都是英文
Q:如何衡量太難還是太簡單?時間長短是一個好的衡量指標嗎? 是從過去經驗估算出一個合理的時長嗎?
大部分人都太快打贏就是太簡單,時間是一種客觀指標,主要會和競品來估計遊玩時間的長短(ex: 一場戰鬥打多久,花多久才打贏),另外再稍微詢問玩家的體感時間(進入心流反而覺得時間過很快)
Q:很多新的設計,敘事玩家不一定買單,貴團隊如何評估此時是要教育玩家還是要調整設計?
比較難的是要讓動作玩家對敘事感興趣,並且不要讓他們覺得煩躁,設計上花了很多心思處理並且在測試後調整。敘事玩家可以選擇簡單模式甚至自己調整數值