不知道有沒有人發現網站右下角可以關燈
前言
先前有幸參與了《九日 Nine Sols》與《沉沒意志 Minds Beneath us》這兩款今年指標性的國產遊戲的發售前測試，跟著頂尖團隊跑完這樣測試的流程真的蠻有幫助的，有很多值得學習的處理方式。
不過這篇主要要講的只有 bug 回報的流程。
在他們實作 In-game Bug Reporter 以前，主要仰賴使用者手動在 Discord 的 Bug Report Forum 當中回報。
。
關於如何在 Discord Server 中建立 Forum Channel，請看官方教學
為什麼需要 In-Game Bug Reporter（遊戲內 Bug 回報系統）？
我開個 Google 表單讓有意願回報的玩家直接回報不就好了，搞這麼麻煩做什麼？
因為有幾個重點是手動外部回報很難做到的事情：
- 傳送發生問題的截圖、影片
- 傳送發生問題當下的 Log 檔、存檔、硬體資訊等等你在除錯的時候會希望可以調查的任何資料
當然你也可以在表單要求玩家填寫、附上資料，只是這通常就兩種結果：
- 太麻煩了不回報了
- 附了，但還是不夠精確，成為無法重現或甚至不明白在描述什麼的 bug
但這樣的結果也不能說是玩家/測試者的錯，這樣歸因也沒有意義。身為開發者也只能盡可能降低回報的阻力以及提升回報的價值，讓有意願回報的玩家能夠順利的回報，開發者也能順利的從回報資料中找到發生 bug 的原因。
Bug 回報系統的需求
回報流程的需求列出來大致上有：
- User Interface
- 照遊戲專案需求來設計
- 發送/接收 bug report 的 API
- 方便使用
- 安全性，防止被惡意攻擊
- 儲存方式
- 價格
- 方便檢索、後續整合
- 隱私與資料安全
綜合以上幾點，九日開發團隊的易衡提出了「既然手動回報都在 Discord 了，那乾脆直接拿 Discord 來做這件事情吧」
（主要參考 Hades 的回報流程，他們盡可能將其他的回報管道統一引導至同個地方，來降低整理資料的麻煩）
實際嘗試了之後確定這件事情感覺超級可行的，以 Discord 來達成根據上面需求的話大致是這樣：
- User Interface
- 照遊戲專案需求來設計 -> 無關
- 發送/接收 bug report 的 API -> Discord Webhook
- 方便使用 -> 需要一個 for Unity/C# 的 Discord webhook library ，所以我寫了一套開源 Unity-DiscordWebhook
- 安全性，防止被惡意攻擊 -> 危，這點稍後補充
- 儲存方式 -> Discord Channels
- 價格 -> 完全免費
- 方便檢索、後續整合 -> Discord Forum 本身的介面就已經很 user-friendly （有標籤、有搜尋功能）了，後續整合可以透過 Discord API 去爬資料
- 隱私與資料安全 -> Discord 本身可以限制各頻道權限，敏感資訊可以送到私密頻道；資安的部分是 Discord 要負責也不關我的事
總之這套流程實驗下來非常可行，因此才有這篇文章想要推廣這套方法給更多開發者，接下來細項解釋就我所知各步驟的實現方式。
各步驟的實現
User Interface
很看專案自己的實作方式，像 Hades 的 Bug Reporter 就是個很優秀的案例。
這裡面包含了：
- 截圖，Hades 這套工具甚至允許你直接在上面畫線加註
- 選填的 Email ，讓使用者有辦法後續追蹤
- Bug 描述的輸入框
- Submit 按鈕
- 寫明你會送出的資料（存檔以及系統診斷）以及宣告資料的使用目的（僅用於調查此回報項目）。
- 這一點尤其重要，會牽涉到個資法的問題，如歐盟的 GDPR。
發送方式：Discord Webhook
簡單說這個東西就是：你可以在 Discord 頻道設定內加入 Webhook ，之後可以透過 Webhook API 來發送訊息至該頻道。
方便使用
為了在 Unity 上方便使用，我寫了一套 Unity 版本的 Library – Unity-DiscordWebhook。
用起來還蠻方便的（自己說），除了我們自己的 Bionic Bay 之外《九日 Nine Sols》與《沉沒意志 Minds Beneath us》也都是使用這套來實作自己的 in-game bug reporter，拿來幫我背書：）
題外話
我在寫了差不多 6 成的時候才想到應該先查一下 Asset Store 上有沒有，而也真的已經有一套 Webhooks for Discord，而且它寫法和我 87% 像都是 builder pattern，但實際上我並沒有買過那套插件只能從商店截圖來猜它的功能性。
帶猜測性的比較：
| Feature | Unity-DiscordWebhook | Webhooks for Discord |
|---|---|---|
| Embeds | 還未支援（看情況未來更新） | Yes ✅ |
| Awaitable | Yes ✅ | No |
| Upload Files | 支援檔案路徑、Byte Array、Texture 為參數 ✅ | 僅支援檔案路徑為參數 |
| Helper | 自帶一鍵 screenshot, zip 功能 ✅ | 我不知道 |
| Price | Free ✅✅✅✅✅✅✅✅✅✅ | 4.99 USD |
| Long-Term Support | 問作者 | 問作者（付費插件應該比較在乎） |
功能面上身為一個 Web Request API 卻沒有 Awaitable method 我就不採納了，其他功能都是實作過程中有需要才補上的。
查到其他 github 上的開源專案還有 lumpn/unity-discord、T3R1X/UnityDiscordMsgSender、MorganSkilly/Unity-Discord-Webhook-System，它們基本上都缺少關鍵功能（例如上傳檔案）或是壞了，而且我就想寫成 builder pattern 比較爽。
安全性，防止被惡意攻擊
針對這個 webhook 能想到的惡意攻擊主要就瘋狂洗版來癱瘓有效資訊的取得，而想要不被惡意攻擊我能想到就兩個方向：
- 擋住惡意攻擊本身，讓接收端要去偵測並封鎖惡意攻擊。
- 這一點我沒有很熟，但我知道你管不到 Discord 怎麼接收訊息，所以你能做的是避免直接暴露 Webhook 連結，你會需要一個中間層去接收來自 client 的訊息、經過處理、篩選後再轉送至 Webhook 連結。
- 現在網路上有很多 Serverless Function 的服務可以做到這件事，如 Vercel REST API，但我沒有研究這塊，有興趣的請找易衡。
- 擋住惡意使用者，一開始就把使用者限縮到可信任的圈圈內
- 即內部團隊人員、可信任的測試者等等，說白話就是什麼都不管、兩手一攤、我相信人性本善之術。
我們大部分都只會把系統開放給內部測試玩家，所以基本上都是基於 2. 的方向什麼都沒處理也很省事。即便、就算、萬一、哪怕還是出現了惡意攻擊，你身為管理員也可以立刻從 Discord 頻道設定中把該 Webhook 給註銷掉及時停損，我覺得應該是可以接受的風險。
儲存方式：Discord Forum & Channels
這部分其實也看專案想要怎麼處理這些資訊。
拿沉沒意志的案例來說，發一個 bug report 會自動在名叫「內部bug回報-bug-report」的 forum 當中開一篇文章，且會自動附上版本號、當下截圖、流程位置、硬體配備、存檔、Player.log 這些重要的 debug 資訊。
後面 Showcasing 有完整流程截圖。
可追蹤性 / 匿名性
目前這套流程比較麻煩的點是透過 webhook 發出的回報並不會直接連結到使用者帳號，所以後續如果希望和該回報者確認錯誤的細節的話會比較難聯繫上。
但…這也是優點！
第一，非常有可能玩家是沒有 discord 帳號的，你不會希望要求所有玩家想回報問題都得辦個 Discord 帳號；此外，就是有人想要匿名回報，如果強行要求帳號制回報的話也會成為那些人回報的阻力。
所以現在我們認為可接受的方式還是讓使用者自己填 Username 或是期待他們主動在回報討論串留言補充資訊（例如影片）。
當你要把這個服務推到全世界玩家使用的情況，匿名性尤其重要。
有非常多國家的個資法是有明確規範你要如何處理「個人資料」，一旦你上傳的資料牽扯到個資就必須套用他們的規則來給予使用者相對應的權利，最常見的就是歐盟的 GDPR。
有興趣看到底還有哪些隱私權政策可以直接參考 Unity 的法律資訊 Game Player and App User Privacy Policy，裡面涵蓋了非常多不同國家法律所要求的權利。
總而言之完全不建議將送出任何含個人資料的內容，除非你確認過你的使用區域沒有相關的個資法來約束。
隱私與資料安全
如果使用者範圍很小或者不介意的話（假如只有內部人員使用），是不太需要關心這個議題。
若此回報系統是公開給大量玩家使用的情況下，建議避免將一些比較敏感的資訊直接放在公開頻道。
例如，或許有些玩家不希望暴露自己的硬體規格或者不希望自己的存檔被公開給非開發者的人存取，這樣會增加玩家回報的阻力。即便回報本身的資料是匿名無法追蹤的，也會變相讓這些玩家不願主動現身補充說明。
想解決這個問題的話可以先把資料送到開發者的私人頻道、然後 Forum 文章內容再去連結那則訊息，這樣沒有權限的人就只會看到「無存取權限」，例如：
資料檢索、後續整合
首先 Discord 本身介面就有蠻強大的搜尋以及標籤功能了，如果沒有整合需求的話我覺得挺堪用的。
若想要把這裡回報的 bug 資料整合至團隊內部使用的其他服務，可以透過 Discord API 來爬這些資訊，我沒有做這件事就不展開來談了（去問易衡）。
Showcasing
Bionic Bay 換影循跡
按下 F8 會截圖然後彈出回報視窗，這實作比較簡陋只需要填 username （透過 PlayerPrefs 儲存所以一台電腦只要填一次）然後選擇送出至哪個頻道。
| In-game UI | Discord |
|---|---|
 |
 |
實際上會送出的資料如下圖：
- 回報者 Username
- 版本號
- 回報的地點（關卡、角色座標、相機位置），複製 code 可以在遊戲中快速傳送到指定地點
- 回報當下的截圖
- 附件內有 Player.log 、硬體規格（CPU、GPU、RAM、VRAM、OS、Resolution、Refresh Rate）
這我們自己專案的給團隊成員使用的實作，所以比較有辦法講比較細。沒有特別在遊戲內加入 text field 是因為使用者就是我們團隊本身，要我在遊戲內打字我還不如直接去 discord 頻道回覆補充說明就好。
這個系統也常常被我們拿來當快速截圖、傳送 Player.log 的方式，我是真心很喜歡這個流程，省下以前一大堆的資訊傳遞缺失的麻煩。
九日 Nine Sols
| In-game UI | Discord |
|---|---|
  |
|
- 使用者可以寫下暱稱、標題與 bug 描述。
- 送出後可以透過按鈕直接連結到該回報的文章
- 記錄了版本號、截圖、硬體規格、遊戲存檔。
沉沒意志 Minds Beneath Us
| In-game UI | Discord |
|---|---|
  |
|
（感謝 Ta David Yu 提供圖片、影片）
- 使用者可以選擇要回報的標籤（tags）、回報者名稱、回報標題
- 送出後可以透過按鈕直接連結到該回報的文章，因為 UI 只給能填寫標題所以鼓勵回報者主動在該文章底下補充資訊
- 有額外一個「不再顯示這個視窗」的勾選框，貼心
- 記錄了版本號、當下截圖、目前流程位置、硬體規格、存檔、Player.log 這些重要的 debug 資訊
之後若還有其他可展示的案例一律會放在 github repository 上更新。
總之就是
我覺得這整套流程蠻值得學(抄)習(來)使用的，尤其小團隊沒有太多時間去研究整套流程和一些 know-hows，之後若有更多開發者進來使用後能碰撞出更優秀的解決方案那就好了。
雖然這篇文章本身並沒有針對「怎麼實作」這件事著墨太多，有興趣的看看 Unity-DiscordWebhook 的 README（雖然我還沒寫中文版，真有需要的話我再補）。
銘謝 Acknowledgement
- jerryee 易衡 – 流程發想者，有額外問題都去問他
- Ta David Yu – 實際應用、協助測試功能與提供相關截圖影片
- DK Liao – 實際應用與協助測試功能
- Yorube 校閱
- 《九日 Nine Sols》與《沉沒意志 Minds Beneath us》 團隊授權公開他們的 Bug Reporter 與 Discord 截圖
其實我是要假借這篇文宣傳沉沒意志，他們在經歷了六年的開發期後終於在 7 月 31 日的時候上線了。
Steam 連結: https://store.steampowered.com/app/1610440/Minds_Beneath_Us/
他們是學生團隊畢業開公司繼續製作當初的畢製，年紀比我大一屆，經歷了如此漫長的六年開發期後終於上市了。
說實話我也才跟他們的開發者認識不到一年，甚至比較常聊也是近三個月左右才開始的，還是很為他們感到高興。我自認蠻清楚這種長時間開發下對自己專案的鈍感與不安會讓腦子不太正常，不管最後成績如何，成功上市就已經算某種程度的大解脫了。
今年真的是國產精品獨立遊戲大爆發的一年，雖然幾乎都是 N 年磨一劍這種超不健康的開發週期下所磨出來的作品 – 開發週期長是個選擇，但朝著一個過去沒有做過的方向直接全職耗費 N 年的時間真的是一件很可怕的事。不過結果論來說還是很高興能看到這些作品的出現能為整個產業帶來一點什麼
– 我希望如此。
也不禁感嘆旁邊幾個紛紛畢業了，自己怎麼還在這。
最後強調一下遊戲名是「沉沒意志」，不是「沉默意志」不是「沈沒意志」不是「沉沒抑制」不是「陳莫意志」，是「沉沒意志」。
：好的，沉默意志。