鐵之狂傲
標題:
【轉載】發現問題與描述現象的方法
[列印本頁]
作者:
soking
時間:
08-6-27 10:38
標題:
【轉載】發現問題與描述現象的方法
發現問題與描述現象的方法
笛卡兒(Descartes)在他的「方法論」中說:「將每一個問題盡可能地且恰如所需地分成許多部分,使得每一部分都可以輕易地解決。」這也是分析與綜合方法的展現。
延續上次文章提到的
遊戲中的QA
,這次來談談實務經驗上,我們針對一個問題的發生,可以怎麼樣去作出分析,讓別人能夠精確的認知,這樣的方法不僅僅限於遊戲中的QA,更可以廣泛應用於面對未知問題的時候,嘗試思考的邏輯,啊,話說這個方法叫做「T型理論」,不是阿獸獨創的,想知道來源大概要去搜尋卡內基或是什麼管理理論吧?
一個問題發生的時候,一般人往往只在記憶中留下對於情緒感受有反應的記憶,例如說:「很突然、怪怪的、好像有問題……etc」,這樣的情況源於普通人對於狀況的記憶都是只專注於自己的感覺,而非問題的本質。
在日劇「司法八人組」之中有段有趣的課堂狀況,在上課途中忽然闖進一名男子手持球棒襲擊上課的教授,整件事情的過程就在一眨眼不到十秒鐘的時間中,上課的眾人眼前發生,接著在間隔幾分鐘後的指認時,全班卻無法達成統一的意見,而形成交錯指認的混亂情況。
明明是發生在眼前的實況,人們卻會被其他人意見所影響記憶,然後把眼前的事物作出了扭曲的描述與判斷,由此我們可以知道,人類的情感記憶影響是有多麼的大,以至於會干涉到理智的判斷。
所以呢,當我們在面對一個問題的產生時,可以依照三個階段來拆解,將一個模糊曖昧的問題描述變成可條列式描述的狀況,並且能進一步的進行交叉分析,步驟如下:「現象」、「原因」、「步驟」。
一、現象:
嘗試描述事實,並且盡量將個人好惡的差異性降低,需明白自己的描述是否為事實或是個人觀感而造成的問題,例如說:「這道菜是辣的。」這是一個事實的描述,然而「這道菜味道很差勁,而且又辣。」,這樣的描述卻容易混淆訊息傳達的重點,因為味道差勁是個人觀感,然而在第二個描述之中,「辣」的要素只感覺是負面的傳達,卻不知道在味道的評價裡面佔了多少影響的成分。
如果描述更精確的成為:「這道菜有酸臭腐敗的味道,並且很辣。」這樣的描述能夠更進一步將整個現象作一個完整的表達。
以遊戲問題的回報來說,避免只說:「這地方感覺怪怪的。」而是去描述你所遭遇的問題,例如說:「這個跳躍人物動作會閃爍」、「這個介面顏色很花找不到重點」、「無法分辨敵我雙方」等等,嘗試將遊戲中所遭遇的問題情況,轉化成可以被分析的狀況,能讓問題的狀況變得更明確。
二、原因:
發現問題的狀況之後,進一步去思考可能的因素,這個階段是作出盡可能的推論,將問題的「發生原因」有哪些可能性羅列出來,有時候在遊戲開發之中遇到的問題,並非是單一要素所造成而可能是多重解。
分析出「發生原因」後跟「現象」進行交叉比對,我們有可能直接釐清大多數的問題,例如若有個問題是「認為這個關卡太過於簡單」,那麼針對這個問題所產生的「現象」可能有:
‧一下子就過關了
‧敵人容易發呆
‧沒什麼損血、死亡
然後針對這些現象加以分析,或許我們會認為有這些原因:
‧一下子就過關了
‧關卡太短
‧地形沒有變化
‧缺乏阻擋物件
‧敵人威脅性不足
‧敵人容易發呆
‧AI判斷有問題
‧偵測的判定距離錯誤
‧敵人的動作模式順序可能需要調整
‧沒什麼損血、死亡
‧玩家裝備、數值太強
‧玩家擁有完全剋制敵人的強力武器
‧放置敵人的組合有問題
像這樣子,交叉分析之後,或許一個問題的概念馬上就會很清楚的被分解,甚至答案立刻就呼之欲出了!
三、步驟
發現了問題之後,這個問題能否被重複的驗證檢查呢?
若是以遊戲的Bug來說,一個Bug的發生回報,很重視的就是再現性的步驟問題,因為若是無法找出Bug的再現規律,那麼這個問題的回報會變成隨機性的問題,而若是嚴重的當機問題,則非常之嚴重,可能負責程式的夥伴需要從前述的現象與狀況之中,嘗試著從原始碼去解析可能的Bug存在。
那麼,仔細的從「現象」之中來作「步驟重現」也是很重要的,這樣的問題回報就可以讓複數的人加入檢查,尤其是在團隊合作的遊戲之中,更是需要這類將工作處理成讓別人能夠進入或接手的狀態。
[
本文章最後由 soking 於 08-6-27 10:40 編輯
]
作者:
soking
時間:
08-6-27 10:41
這是阿獸在遊戲製作板上發的教學文章,與思考有關,還請各位過目看看吧~
歡迎光臨 鐵之狂傲 (https://www.gamez.com.tw/)