Pre-production v.s. Production: 來自Mark Cerny的遊戲開發方法

Mark Cerny是遊戲業著名的遊戲設計師、程式設計師、製作人,同時也是PS4與PSV的硬體架構師。他在2002年提出的遊戲開發方法,我認為是Agile在遊戲業的一種實踐,不論是遊戲設計師還是程式設計師,都應該需要理解其中的內容。

其中與技術人員息息相關的是「前期製作與正式製作」,本篇以技術人員的角度來解釋自己在這之內的定位與行動方針。

2002年Mark Cerny在D.I.C.E. Summit的演講影片:https://www.youtube.com/watch?v=QOAW9ioWAvE

(以下所有的引言內容都來自Mark Cerny的演講投影片,引言內容都是以設計師與管理的角度來描述的)

前期製作

1. 你不是在做遊戲,至少現在還不是
2. 你在做遊戲設計
* 3C: character, camera, control (角色、攝影機、操作)
* game look (遊戲外觀,這並不是指單純的遊戲畫面,而是指「感受層面的外觀」)
* key technology (關鍵技術)
* holistic game design (整體性的遊戲設計)

以現代的角度來說,所謂的「雛形製作階段」通常指的就是這個階段。

如果不經過決定遊戲設計的前期製作,一方面這會造成程式面在開發中後期頻繁的規格變更,另一種講法是幫設計師收爛攤子。我自己甚至經歷過在開發後期,直接砍掉大約70%的內容並延期重作的慘況。另一方面也會造成遊戲發布後,(設計面的)完成度不夠高的問題。(通常是由於經費與時間不允許繼續變更規格)

協助設計師創造「設計文件」

MYTH #7: DESIGN DOCUMENTS
“The more defined your initial vision, the better”
“I need a 100-page document describing my game”
迷思七:設計文件
「你的初步想法描述的越詳細越好」
「我需要寫一份100頁的文件來描述我的遊戲」

軟體工程有一句話,「你的程式碼就是你的技術文件」
我用類似的話來解釋遊戲設計文件,「你的初步可玩版本就是你的設計文件」
(初步可玩版本的對Mark Cerny定義並不是指第一雛形,詳見影片)

Blizzard的《爐石戰記》(Heartstone),這個遊戲的初步可玩版本,是設計師用Flash寫出來的。將之作為設計文件,交由技術人員來進行正式開發。

比較專業的設計師其實都有一定程度的編程能力,通常中低階的設計師沒辦法做這件事。因此,技術人員在這個階段的工作,就是協助設計師把「設計文件」創造出來。注意,你現在做的並不是開發遊戲,而是協助創造「遊戲設計」

混亂無序的時期

MYTH #1: PLANNING
“It is possible to plan and schedule the creation of your game”
迷思一:計畫
「你可以為你的遊戲創造做計劃與安排時程」

MYTH #2: PRODUCTIVITY
“Working productively means throwing out nothing”
迷思二:生產力
「高效率的工作代表不丟棄任何東西」

MYTH #3: TECHNOLOGY
“Cutting edge technology is very important, so build your technology first”
迷思三:技術
「尖端技術非常重要,所以先建造你的技術」

(古典與不太可行的)標準實踐:
製作遊戲設計文件
=> 製作遊戲技術文件
=> 開發技術(引擎、框架、開發工具等等…)
=> 開發遊戲

如果你有Game Jam的經驗,實際上你在Game Jam做的就是前期製作的過程。在這個階段,速度比程式碼的品質更加重要。你的速度越快,遊戲設計的創造與迭代時間就越短。

在這個階段,開發的過程是混亂無序的,但應該要容許並接受這些混亂無序。突然增加功能、砍掉功能,在這階段都是正常的事。這是為了產生更好的遊戲設計。

在這個階段,物件導向、重構、設計模式……等等,都不是重要的東西,因為這些是犧牲時間來獲得軟體品質與開發穩定性的工具。在這個階段,你可以使用各種骯髒的編程方法,大量使用singleton、資料型態、程序導向、500行的函式、3000行的類別,在這個階段都是可以允許的東西。

因為你寫的任何功能,可能都等一下就會被放棄掉。你可能會覺得,「什麼?你要浪費我之前付出的時間?」但你實際上為你的公司、團隊、甚至是你自己,省下了後期設計規格變更的時間、金錢以及風險。(實際上,你可能也沒有浪費自己的時間,你仍然獲得了付出時間的薪水)

另外,這些骯髒的程式碼不會進入正式製作階段,你需要重寫你的程式碼。如果把這些骯髒的程式碼帶進正式開發階段,那原本省下來的資源,就會被糟糕的軟體架構與多出來的debug時間浪費掉了。

不要忘記,技術人員在這個階段的目標是協助創造「設計文件」。

進入正式製作

初步可玩版本出現後,如果覺得遊戲設計沒有問題,那麼通常會進入正式製作階段。

程式碼在這個階段需要重寫,你可能可以從之前骯髒的程式碼拿一些東西回來,但請容許我使用「重寫」這個詞來強調重要性。這個階段的軟體開發,請使用我們的軟體工程教育的標準,以程式碼的品質為基本,當然速度仍然很重要,但你通常是利用程式碼的品質來維持你的編程速度

經過前期製作階段,有了設計文件,而且規格變更的頻率也大幅降低。因此技術人員可以知道如何編寫整合測試、單元測試,也避免了因高頻率的規格變更而重寫功能與測試碼的窘境。

在這之後的事情,我想大家都很熟悉了,就談到這裡為止。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。