獨立遊戲開發者分享會 120527 遊戲品質管理

主講者：NDark

本投影片內容描述我們在定義產品的「品質」上，時常出現的問題，並說明遊戲專案品質控管與一般軟體專案不同的困難點，乃至於最後我們如何看待、並改善品質管理這件事。

Transcript

1. 遊戲品質管理 NDark 5/27 @ IGDSHARE
2. 首先要先介紹我自己
3. NDark „ 學生時代：參加三屆遊戲設計比賽 „ 研究所：電腦圖學 „ 2006-2010 國防役：工研院技術研發 „ 2010-2012 遊戲公司專案主程式 „ （目前）科技公司技術研發 „ 2009 Feb. 分享會1 (參加) „ 2010 Aug. 分享會2 (舉辦) „ 2011 Feb. 進階AI概念 (igdshare) „ 2010 Jan. 容易被遺忘的遊戲設計模組 „ 2011 Oct. 遊戲軟體管理經驗談 „ 2012 May 遊戲品質管理 „ 2013 ？軟體專案文件管理？
4. NDark „ 借用王銓彰先生某投影片的圖片
5. NDark Hardware System(API) Engine MiddleWare Game Management( Production or Workflow ) Market Before 2005 2010-2012 Collision／Terrain AI／Task 2011：Funny Table (lead programmer) 2010：Sangokushi Taisen (maintain) 2010：Hero of Robots (support)
6. 在開始之前
9. 遊戲品質管理 1. 什麼是品質？ 2. 問題在哪裡？ questions and answers 1 3. 如何測試？ 4. 一環扣著一環 。 questions and answers 2 5. 到底要測多久？ 6. 如何能不產生bug？ 7. 其實我們就沒這麼重視它。 questions and answers 3
10. 什麼是品質？ „ （問題） „ 品質是否等於好？
11. 什麼是品質？ „ 什麼是好？誰來定義品質？ { 通常是那個有權力的人 “公司是一個很抽象的概念… 我們不是對公司做生意， 而是與那個握有權力的人做生意” „ 最簡單的情況是，當有權力的人說可以了就是可以 了。就是這麼簡單。
12. 什麼是品質？ „ 當有權力的人說可以了就是可以了。 { 不管在企業公司內部做遊戲，還是獨立製 作，其實問題都是相同的。
13. 問題在哪裡？ „ 只要是人就會犯錯 { 只要是人每天心情就不一樣 { 只要是人一天就是只有八小時 { 當木牌變為石柱再變為石敢當的時候就會 造成執行人員的困擾。 { 當有權力的人說話：那麼原本不可以的也 會變成可以。相反地，原本可以的也會變 為不可以。
14. 問題在哪裡？ „ 品質不代表零錯誤，代表？ “某些” 標準 „ 這就是為什麼要開會？要把討論的事項白紙黑字寫下來的原 因。 „ 讓要達到的標準具體化，不是感情用事，就是品質管理。 „ 不是我覺得可以。而是我們立下一些目標，嘗試去達到它。 „ 如果沒有達到，若非我們不夠努力，也有可能是目標設定錯 誤。 „ 當有力人士說可以的時候，原本沒達成的目標也會變自動達 成。 „ 越到出貨，標準越容易達到。
15. 問題在哪裡？ „ 但是遊戲專案要怎麼具體化？ { 這個畫面到底怎樣好？ „ 在還沒做出來之前我們怎麼知道我們能夠做到怎樣好？ { 只要腦袋還算清醒的人都知道美，好玩，有趣， 惡搞，以及梗根本就無法量化。 { "我要做到這個畫面感動人心"，感動誰的心？感 動全部團員的內心？ „ 那我只要搞的大家加班然後凌晨四點來檢驗，必然全數 通過。 „ 有目標的考試必定有漏洞。（戰爭機器也有Lag。）
16. 問題在哪裡？ „ 好永遠都可以更好1 { 但是所有的專案資源都是有限的。 { 所以我們必須體認到一點 沒有所謂完美。 „ 好永遠都可以更好2 { 每一次修改都會讓產品朝向目標更接近一點， { 但是邊際效應會越來越低。就跟讀書準備，考試 驗算一樣。
17. 問題在哪裡？ „ 比較糟糕的情況是 { 當目標因為人的情感在飄的時候。 { 也就是人在壓力下的時候，特別容易慌 張，做出錯誤及反覆的決定。 "在恐懼，怨恨，競爭，日常運作，時程的壓力，甚至 是貪婪的引誘下，人就會做出錯誤的決定。"
18. 什麼是錯誤的決定？ 二選一
19. 問題在哪裡？ „ 沒有所謂完美。 效率優先 邊開火邊移動 （我不用跑得贏獅子， 我只要跑的贏你就好）
20. questions and answers 1 1. 沒有所謂完美，好永遠都可以更好。 2. 品質不代表零錯誤，代表某些標準。 3. 只要是人就會犯錯。
21. Outline 1. 什麼是品質？ 2. 問題在哪裡？ questions and answers 1 3. 如何測試？ 4. 一環扣著一環 。 questions and answers 2 5. 到底要測多久？ 6. 如何能不產生bug？ 7. 其實我們就沒這麼重視它。 questions and answers 3
22. 如何測試 „ 測試規格書 { 一定會有企畫規格書（？） { 但是不能用企劃規格書來做品質管理，因為那是給實作人 員看的 { 測試規格書要讓測試人員可以逐項測試 { 測試規格書越細越好，細到說明一個介面動畫的開始與結 束。 { 但是企劃規格書更動的時候測試規格書也要一併更動。 „ 這是一個大工程。 { 幾乎不是一般團隊的企劃或測試窗口可以辦得到。 { 完美不存在。
23. 如何測試 „ 要寫到什麼程度？ 1. 寫到有權利決定的人要求的程度。 2. 通常是怎麼寫都不可能寫到那個程度。 3. 因此及早讓重要人士把遊戲的全部流程都看過， 然後逼他把問題講出來是很重要的。 4. 把重要人士同時請來也很重要，避免重要人士之 間的意見不同，導致改來改去的現象發生。 5. 搞清楚重要人士他不喜歡的是什麼？偏好是什 麼？比較容易過關。
24. 如何測試 „ 如果是獨立開發 { 依然存在有力人士。不要鐵齒。 { 甚至那個難搞的有力人士就是自己。面對 自己最深的恐懼！
25. 一環扣著一環 „ 遊戲軟體是很複雜的軟體 { 是在每一個畫格中掙扎的系統。 { 一般視窗軟體流程都是固定的能用除錯軟 體（visual studio）逐行除錯，但到了遊戲 軟體就不完全work。 插播：我從第一個專案就在寫AI相關的部份。
26. 一環扣著一環 „ 幾乎每次新專案都是完全不同的系統 1. 極少人能夠在第一次面對未知挑戰時，就知道要 解決什麼問題。 2. 所以初代的系統通常都是一環扣著一環完全不能 分開看。 3. 因此軟體業常見的單元測試白箱測試在這樣的情 況下都派不上用場。 „ 至少在有限的時間是做不到的。 „ 至少在規格一直改的情形下是做不到的。 „ 若是能做到單元及白箱，那肯定是系列作或是同類型產 品。 „ 因為不能單元，所以只好黑箱，直接看結果 { 就算單元白箱做的再好最後都要黑箱，所以黑箱 測試最重要。而且只有黑箱才能找到設計問題。
27. 一環扣著一環 „ 所以就有鐵律：改了東西就必定有新BUG { 可能原本修好的錯誤又會浮現出來 { 可能原本正確的地方因為改了參數就變成 錯的 “side effect”
28. 一環扣著一環 „ 修改測試週期 功能完成1 測試回報 修改維護1 再測試 如果沒有解決回到修改維護 如果解決問題設定結案
29. 一環扣著一環 „ 修改測試週期 功能完成1 測試回報 修改維護1 再測試 如果沒有解決回到修改維護 如果解決問題設定結案 因為修改維護1 造成的新測試回報 （這就是side effect）
30. 一環扣著一環 „ 修改測試週期 修改維護1 因為修改維護1 造成的新測試回報 （這就是side effect） 修改維護2 再測試 因為修改維護2 造成的新測試回報
31. 一環扣著一環 „ 修改測試週期 功能完成1 測試回報 修改維護1 功能完成2 測試回報 修改維護3 因為修改維護1與 修改維護3 造成的新問題 解決問題設定結案
32. 一環扣著一環 „ 任何可能的改變都會導致錯誤無法降低 „ 這裡講的任何改變就包含了： 1. 改規格（功能，zoom in） 2. 增加關卡，增加道具（增加了陣列卻沒有相對全部程式的 容量），增加物件（增加了沒有綁碰撞的物件）。 3. 改參數 4. 改模型 5. 改圖 6. 換動畫 7. 改字(script) 8. 修bug(side effect)
33. 一環扣著一環 „ 測試規範的重要性：會發生的問題 1. 回報用口頭的方式，沒有記錄下來，忘記或漏 列。 2. 有回報，但是沒有釐清責任，造成沒有人認領或 處理。 3. 因為不同測試人員口頭回報，造成問題被重複處 理，工時浪費。 4. 有回報，有認列，有處理，但是處理完畢沒有回 饋，以致於問題目前的狀況只能用口頭的方式詢 問。 5. 管理層不能透過一個簡單的數據來了解目前的專 案的穩定度，甚至有欺上瞞下的事情會發生。
34. 注意！！測試規範 „ 及早測試與設計測試規範 { 如何發布？ { 如何測試？ { 如何回報？ { 如何修改？ { 如何再測試？ „ 及早組織及訓練測試團隊 { 只有一人也可以是測試團隊
35. 一環扣著一環 „ 錯誤回報內容的建議 1. 如何重現bug <Unite presentation> { No information is useless (windows process crash) 2. 不用提關於修復。 3. 舉出規格書。
36. 一環扣著一環 { 分清楚QA與試玩。 { “QA find execution issues / playtest find design issues” <Let‘s talk about why QA sucks@gamasutra> { 前者要找實作人員，後者要找設計人員。
37. 一環扣著一環 { give meaning to priority。 { 什麼是可行？困難度，成本。 { 什麼是重要？效果。 { 優先？ “綜效”
38. questions and answers 2 1. 分清楚QA與試玩 2. 測試規範 3. 測試規格書 4. 鐵律：改了東西就必定有新BUG
39. Outline 1. 什麼是品質？ 2. 問題在哪裡？ questions and answers 1 3. 如何測試？ 4. 一環扣著一環 。 questions and answers 2 5. 到底要測多久？ 6. 如何能不產生bug？ 7. 其實我們就沒這麼重視它。 questions and answers 3
40. 到底要測多久? „ 誰來決定： { 開發團隊／測試團隊／有權力的人 „ 通常有兩種方案 1. 測到大概(?)沒問題，就交給玩家，然後再 patch維護。(延展一定時間) 2. 測到0錯誤，表定的錯誤解決一定時間沒 有再發生錯誤。(不斷延展，完美優先) 3. 其實還有第三種，就是燃燒小宇宙。
42. 到底要測多久? „ 什麼叫錯誤？ 1. 圖不漂亮算不算錯誤？ 線的位置沒對齊不 好看算不算錯誤？ 2. 但是圖不漂亮還是得改。線沒對齊要改， 標點符號沒斷行要改，其實跟錯誤是一樣 的東西。 3. 這情況下就都通稱為品質。
43. 到底要測多久? „ 能不能做到零Bug？ { 戰爭機器也會Lag，也會發生劇情無法觸 發，王打不死的嚴重錯誤。 { 魔獸世界也會有卡點這種嚴重錯誤，甚至 作了透過GM來把玩家拉走的機制。
44. 到底要測多久? „ 假設（請作答） { 討論時間(A)： { 製作時間(B)： { 測試時間(C)：
45. 到底要測多久? „ 時程的反覆 final review final playtest final production test start test complete ( 0 bug or accetable bug-numbers) package ship product 測試時間(C) 製作時間(B) 討論時間(A) 怎麼測試有力人士都不過關的狀況 玩家反應 怎麼試玩有力人士都不過關的狀況 過關
46. 到底要測多久? „ 時程的反覆 { 當發生規格修改 { 最慘的情形 { 要花費的時間為：Ａ＋Ｂ＋Ｃ（不包含打 包）
47. 到底要測多久? „ 時程的反覆 { 只有錯誤（不符合規格）要修 { 比較好的情形 { 要花費的時間為：Ｂ ＋Ｃ（Ｂ的量看問題大 小） { 每發生錯誤都有可能要再花上Ｃ的時間， 其實很多人很難接受這樣的事實。 鐵律：改了東西就必定有新BUG!!!
48. 如何能不產生bug？ „ 不要改（code） { 因為壞code產生的速率比好code來得快。 „ 不寫code才能不創造bug 。 { 嚴格講起來是：改好了之後就不要因為沒有目的 就去改code。 { 當我們知道要改什麼，尤其是在保留測試時間的 情形下，才去改程式。 { 在有夠大的綜效的情形下才去改功能。 „ 只要上線，程式碼就是金光閃閃。（有錯的 系統都會變成其他系統要去遷就它）
49. 其實我們就沒這麼重視測試 „ <Let‘s talk about why QA sucks@gamasutra> 1. 因為測試人員是因為連企劃都不會所以才只能當 測試。 2. 因為我們打心底就認為測試人員是肉腳。所以甚 至測試人員要隔離。 3. 因為測試團隊只有需要才建立，隨時可以捨棄。 所以是約聘，打工。 4. 測試人員的未來發展就是離開測試團隊。 5. 一個不被重視的位置，當然沒有人會用心好好做 事，甚至也不被期待把事情做對。
50. 其實我們就沒這麼重視測試 „ <Let‘s talk about why QA sucks@gamasutra>的解 決方案 1. 徹底改變對品保的看法，把品保的地位拉 起來，找對的人。 2. 品保有發展，有權力，有建議空間。 3. 長期雇用品保人員，有信則有心。
51. 其實我們就沒這麼重視測試 信任 信用
52. 沒有什麼事是不可能發生的 „ 端看一件事情。帶來的效益有多高。付 出的成本有多慘。這就是效率優先。 插播：“雖然我們可以設計一套連最小威脅…” ＜丹尼爾‧吉伯特／快樂為什麼不幸福＞
53. 1. 沒有什麼事是不可能發生的。 2. 重視測試人員。 3. 每發生錯誤都有可能要再花上的時間。
54. 清明的心，正確的方法，熱情與專注。 Q&A ndark@hotmail.com Black Straits Historical：http://ndark.wordpress.com/
55. Apendix. 關於管理的電影 „ 阿拉莫：圍城十三天 { 菜鳥管理者怎麼贏得老鳥的尊敬。 „ 鳳凰號 { 沒有希望的困境下，怎麼經營團隊。
56. Apendix. 其他對於時程的建議 „ 有限度（不要花太多時間）的開發編輯器， { 因為編輯器的專業是是另一個領域，需要有額外 的專業人員來製作。 „ 先不要管編輯器， { 程式開放大量的參數給企劃修改。開後門讓程式 直接能更新參數至少在半分鐘內看到結果。 „ 先調出一版讓玩法真的有趣的參數（先確定 初版真的好玩）。才開始想量產的方法。