前往
大廳
主題

[自動混亂] 自動測試

DK | 2022-12-24 22:36:11 | 巴幣 2208 | 人氣 590

嗯,首先,先來看段影片吧:

這是《自動混亂》的自動測試工具。
當然呃,玩得不是真的很好啦,目前不開鎖血作弊的話只能勉強打贏第一關 XD
總之來介紹一下。

緣起
過去翻新敵人的 AI 時,我就默默想過也許總有一天可以試著用相同的系統來做自動測試,但終究沒有付諸施行。而最後逼我得做的其實就是那個《自動混亂:零式》啦 XD
《零式》第一版的遊戲機制又快又混亂,雖然其實打起來也很爽(自己講),但問題就是很累。而因為遊戲設計概念是要存活十分鐘,大多機制都跟時間直接綁定,要從頭測試到目標時間又很慢,但跳關過去又不一定足以驗證體驗。
實作自動測試機制之後,除了我可以放手給他玩以外,我還可以調整倍速讓他玩,加快我驗收特定測試成果的速度。對於一個本來只想要簡單做一做就放出來給大家玩的《零式》來說,自動測試著實讓我的開發過程可以花更多時間在快速迭代設計上。

總之在《零式》有了這麼一個印象不錯的經驗後,替《自動混亂》實作自動測試機制的想法就更切實了。不過畢竟在《零式》的玩家只需要反覆戰鬥就好,《自動混亂》可沒有這麼輕鬆,就一直拖著。

後來因緣際會在 Sigono 參與《龍脈常歌》的 iOS 版移植(以後再找時間寫一篇相關的文章),使用了 Sigono 內部的自動通關系統(延伸閱讀),在許多修改需要快速迭代驗證的情況下發揮了重大的幫助。
因此終於決定要將《自動混亂》的自動測試系統建立起來。

《自動混亂》的自動測試目的
之所以持續心心念念自動測試,不外乎因為《自動混亂》的無接縫設計。完全無載入、無換場景的體驗是遊戲的本體,換個講法就是《自動混亂》的體驗需要完全的「沉浸感」,這等遊戲做完才好解釋為什麼要這麼執念於此 XD
總之也因為這樣,很多可以確保遊戲穩定運行的方式都做不到。電腦出事可以重開機,程式出事可以重新執行,而遊戲或多或少都仰賴關卡的轉換、玩家的死亡當作一個重設點,將遊戲程式狀態退回去一個已知可以正常運行的狀態。
在我的遊戲中,玩家唯一會觸發重設效果的情境,就只有關閉並且重開遊戲,也因此隨之而來有許多效能與程式邏輯完備性的挑戰。

《自動混亂》的自動測試實作
基本目標就是要將玩家在遊戲內有機會實現的互動都盡量嘗試執行。
而如果要總結自動混亂的玩家潛在互動的話,大概就是:
  • 在一個房間內進行戰鬥並且解決所有敵人
  • 前往獎勵節點取得獎勵,需要時要選擇獎勵內容
  • 選擇一個出口,走到出口前並且與出口互動
  • 可以與商店互動
  • 可以死亡
  • 可以無上限重複遊戲的循環
第一點沿用敵人 AI 的機制就可以做出一個大致堪用的成果:
  • 可以大致穩定挑戰到第一關的頭目
  • 運氣好可以打贏第一關的頭目
  • 運氣超好可以見到第二關的頭目(不過還沒打贏過)
不夠強沒關係,但至少可以一定程度模擬出玩家與這個遊戲的互動:
  • 會選敵人攻擊
  • 會評估周遭配置來移動
  • 會在緊急狀況下衝刺閃避
  • 會受傷
其他要素則盡量跟玩家使用相同的機制去操作,例如說模擬玩家操作選單的方式、潛在可以玩壞選單的方式。理想上會嘗試正常走到目標地點,不過因為我的 AI 設計從來都不是為了能穩定抵達終點而設計的移動機制,所以大概 20 次會卡死一次,這時候就使用超過一定時間就直接傳送到目標地點的方式彌補。
而最後,當我需要看到更完整的流程時,就可以把角色的血量鎖起來,讓他硬拚到底 XD

自動測試成果
當然呃,已經抓到不少 Bug 了 XDDDDD 讚嘆自動測試系統!
總之自動測試系統真的是個無視勞基法限制可以 24 小時值勤的好夥伴,大團隊的大作品自然會需要,但實際上小至個人開發者的情境下,能準備好這樣的系統會有無上限的效益。
不過如果不是在遊戲開發初期就隱約規劃了可以安插自動測試的區域,現在事後實作起來也就不會如此順利了。推薦大家在寫任何系統的時候都可以隱約預想一下讓未來可以做這件事需要些什麼。

希望可以繼續這樣下去維護整個專案的健康度,對於一個超級講求沉浸感的作品來說,任何錯誤都有可能會讓玩家沒辦法達到我希望挑戰的體驗。
近期 Steam Deck 送達後,這樣也很方便擺著在一旁自己跑,偶爾看到奇怪的現象時就可以記錄下來研擬怎麼處理。而純粹當作效能測試也很方便,可以看清楚我的遊戲在 Steam Deck 上跑起來的狀況如何 XD

總之總結一下我使用到現在的好處:
  • 可以持續檢驗專案的健康度,無論是系統互動還是整體效能表現
  • 可以無限嘗試,代表有更高的機會找出觸發機率極低的錯誤
  • 可以很快地進行遊戲平衡的最低限度檢驗
  • 缺遊戲截圖的時候就開自動測試起來錄影一場然後選個截圖 XDDDDDD

下集待續?
其實還有些主題可以寫,不過下一篇應該會推遲到《零式》上市後再寫惹。
希望很快能再見(?

創作回應

新手方
蠻好奇你是怎麼知道測試失敗了?
2022-12-25 00:03:13
DK
大概有三種情境:
1. 累積很久的遊戲時數後可以輕易被肉眼捕捉的大錯誤,例如說視覺上的錯誤、直接卡死在某個關卡內
2. 程式噴錯誤資訊時的自動截圖
3. 單純放著在旁邊自動跑,偶爾看到奇怪的現象就記錄下來之後追蹤一下可能發生的原因
2022-12-25 00:23:02
DK
更理想點的情境應該要設計一些參數,在遊戲過程中一邊紀錄,然後事後可以提供統計資訊參考執行結果啦 XD
2022-12-25 00:37:18
BCMagician
你好~
好奇實作上是原遊戲內AI + 錄影 + 偵錯截圖 嗎?
還是有搭配其他套件/工具這樣XD 想了解一下可能可以怎麼擴展到其他遊戲上
2022-12-26 08:06:15
DK
目前的概念大概是:
-每個遊戲中具備互動性的功能都有寫一組單元測試
-自動測試系統本身可以偵測互動的出現,然後對應啟用單元測試
-發生錯誤時會截圖(這倒是不是為了自動測試而寫的,不過在這邊派上了用場)

理論上可以做錄影但是沒做錄影:
因為單人開發本身沒啥可用時間,就算做錄影我也沒空去看,所以我真的很在意的時候就自己用肉眼抓一次遊玩過程中的問題這樣。我的遊戲循環設計得很短所以暫時這樣做沒有太大的困擾,就用工人智慧解決了 XD
2022-12-26 08:54:09
DK
不過理想上確實應該做成一個 CI 流程會在每次發 PR 的時候自動建置、執行錄影,然後留存備份,未來要參照過去遊戲的樣貌也比較簡單。
但總之因為單人開發所以先省了這塊 XD
2022-12-26 08:55:21
BCMagician
感謝回應~
互動功能 with 單元測試 + 錯誤偵測截圖,確實是挺夠用了。
有截圖通常可以知道八九成,剩下一成再去那個功能單元run一次就好。
真的變成比較大型的專案,再弄連錄影的一整套比較有CP值xD
2023-01-07 16:52:58

相關創作

更多創作