Management

[2011] 遊戲軟體管理經驗談(1)-遊戲軟體專案的開發概論


遊戲軟體管理經驗談

發佈區域:PTT GameDesign版(telnet://ptt.cc),部落閣Black Straits Historical(https://ndark.wordpress.com/)

版權所有,禁止轉錄

作者:NDark,目前任遊戲公司軟體工程師(專案主程式)
時間:2011 秋

遊戲軟體專案的開發概論

一個遊戲軟體專案的開發,如同其他類型的專案一樣,大致包含了這些步驟:

  1. 發想:要做什麼樣的遊戲?
  2. 分析(規畫):要做這樣的遊戲要做哪些事情?
  3. 分派:這些事情要怎麼給誰作?
  4. 執行:這些事情實際上被完成。

各步驟並沒有限定要花多少時間來完成,多半是視乎遊戲的規模而定,可以短到一週,也可以長達一年以上。

這邊並沒有把測試與驗證排到步驟中,並不是代表我不注重QA。反而是,由於什麼都可以QA也可以什麼都不QA。如果要作,這些時程就應該自然地明顯列在各個步驟的執行中。

拿著名漫畫七龍珠為例,賽魯遊戲中悟空與悟飯走出精神時光屋時就持續維持超級塞亞人的狀態,測試與驗證就像這個狀態一樣,是應該自然的保持在製程中,在危機之時才能發揮更強大的力量。

然而,要長時間維持這樣的狀態(超級塞亞人)是必然需要痛苦的鍛鍊與適應。這個鍛鍊是整個團隊一併承受的洗禮,也就是不僅僅是程式及測試人員,還包含管理高層,專案管理層,美術,尤其是企劃人員必須有能力通過這樣的歷練。

品管,驗證不是輕描淡寫可以帶過。

執行期多半會切為幾個里程碑,通常會包含至少一個原型製作來確定發想的內容是真的有趣的。但是原型到底要做到什麼程度?是很令人玩味的。

  1. 一種說法是做到量產之外的工作。一個關卡,一個主角,一個怪物,一種道具。
  2. 另一種說法是完成發想中所要強調的特點玩法。
  3. 最後一種是做到可以展示的程度。那麼就要考量到底來看展示的人喜歡看到什麼程度。(這就有點經驗法則了)

不管要做到什麼程度,必須有一個認知:原型製作的目的就是作發案或提案後的驗證。既然是驗證,就會有成功與失敗。就跟投資股票一樣,不在於預測股票價格會往上還是往下,而在於當往上(成功)或往下(失敗)時,我們要怎麼做?

也就是說當我們發現原型完成後沒有達到當初預期的特點時,接下來要怎麼做?是整個砍掉重練?還是做小幅度的修正或補正後再來驗證一次?

同樣地,這時常常會有成本沉沒效應發生。也就是:都已經投入這麼多時間人力了,砍掉好可惜!
什麼時候要停損,是有賴管理階層勇於負起責任,而不是一味的放給製作團隊爛。

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s