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時間浪費掉了。
不要忘記，技術人員在這個階段的目標是協助創造「設計文件」。
進入正式製作
初步可玩版本出現後，如果覺得遊戲設計沒有問題，那麼通常會進入正式製作階段。
程式碼在這個階段需要重寫，你可能可以從之前骯髒的程式碼拿一些東西回來，但請容許我使用「重寫」這個詞來強調重要性。這個階段的軟體開發，請使用我們的軟體工程教育的標準，以程式碼的品質為基本，當然速度仍然很重要，但你通常是利用程式碼的品質來維持你的編程速度。
經過前期製作階段，有了設計文件，而且規格變更的頻率也大幅降低。因此技術人員可以知道如何編寫整合測試、單元測試，也避免了因高頻率的規格變更而重寫功能與測試碼的窘境。
在這之後的事情，我想大家都很熟悉了，就談到這裡為止。