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