對基礎構思的完善和原型化
一款游戲從創意到開發，抽象來看可以分為兩大階段：基礎構思的階段，和迭代開發的階段。任何游戲在最早的時候都只是一個或者一組零散而不確定的構想，策劃人員將這組構想加以整理，抽取其中相互聯系的規則組成核心規則集，這就是產品最初的框架。譬如說俄羅斯方塊最初的規則可能包括：方塊連成一行就消除並加分；頭頂隨機掉落新的方塊；方塊可旋轉，等。
一般來說，在這個階段，游戲開發者會尋求利用這組核心規則建立一個簡單的DEMO，用來驗證游戲本身的可玩性。這個DEMO往往是缺乏美術效果和友好的UI的，但是其遵循的游戲主循環一般來說與後來的商業版本並沒有太大的不同。
譬如說如果你在做彈彈堂，你可能會先搞一個只有一種炮彈、一個怪一張地圖的演示版，雖然內容簡單，但是回合規則與彈道公式是與後來的版本基本上一致的。
對於一個前期的產品構思來說，究竟要花多少時間和精力來做DEMO？又要花費多久來測試這個DEMO？不同的公司和團隊，對這個問題的回答往往大相徑庭。
在這裡就出現了一個很有爭議性的問題：缜密的構思加上完善的策劃文檔，是否能夠替代對於DEMO的開發和評估？答案是否定的。
為什麼要做原型呢？既然原型的代碼基本上不可能被用在商業化的成品裡，既然這只是給一小部分人看的演示，跳過去有何不可？
核心原因在於，作為人，我們的能力和經驗從本質上說，是有限且不完備的。而游戲又是一種體驗性的產品，一款游戲的可玩性，無法通過邏輯和數理的方式來驗證，而必須通過一部分人員通過實際的游戲過程，主觀的去感受和評判。而這也就是為什麼說游戲設計是一門藝術的理由所在。
很多游戲策劃人員骨子裡對市場和運營是持反感態度的，他們說，游戲是一種藝術，游戲性是我追求的靈魂，這比庸俗的充值要重要。在原型的設計和評估階段，他們是對的。
對於原型的評判，一般來說，是要看游戲的核心規則是否清晰容易掌握，同時根據用戶的操作又能夠得到各種不同的選擇結果，再就是技術角度的一些基礎性驗證。譬如說，一個游戲可能規則復雜變幻叵測，但是需要一個月的時間才能上手；又或者一個游戲3分鐘即可掌握，但是玩來玩去每一次的流程都差不多。這些，都是需要在原型化過程中去分析和判斷的問題。
如果一個原型做下來，大家不覺得這個東西好玩，接下來該怎麼辦？
很簡單，放棄。扔掉一切，重新開始設計。這裡有一個很大的誤區，一方面把游戲性不佳歸結於DEMO的內容量不足，指望著內容量增加之後可玩性變好；另一方面以DEMO早晚會放棄不應當投入太高成本為借口，認為“這麼小的DEMO能達到這樣的水准，如果……的話，游戲肯定不錯”實際上這都是自己給自己挖坑跳的思想和行為。
一款游戲，小到俄羅斯方塊泡泡龍，大到魔獸世界天龍八部，本質上都是有自己的核心玩法的，大型產品的核心玩法構成可能更復雜，甚至是由一組相互關聯的子玩法相互配合所組成，但是無論大游戲小作品，都是由一個個獨立的玩法模塊搭建起來的，一個大型的MMO，可能其中很多玩法並不特別出色也能獲得成功；但是一個玩法模塊很多、但是每一個都不算出色的產品，是不可能僅僅憑借功能比別人多來贏得玩家的。
就是說，成功的游戲不見得每一個玩法都精彩，但是沒有至少一個比較精彩的玩法的游戲，一定會失敗，無論多久、無論成本多高、無論程序美術策劃多努力。實際上這是1和1後面的0的關系，沒有1，則再多的0加起來也是0。
我講過一個簡單的理論：游戲的核心玩法是一款游戲的縱軸，而內容的增加是一款游戲的橫軸，一個好的縱軸，可以支撐很廣闊的橫軸，就像彈彈堂或者瘋狂的小鳥，基於自己的核心玩法，可以不斷設計推出新的地圖；而如果縱軸不夠強大，橫向的擴展越多，產品死亡的速度就會越快。這就像蓋房子沒有把房梁搭好就往上放磚，建的越快就塌陷越快。
所以，在游戲的初期，對於核心玩法和DEMO的反復修改不斷錘煉，是決定了這個產品能走多遠的基礎和地基，打個比方你能設計出瘋狂的小鳥或者植物大戰僵屍的核心玩法規則，那接下來要做的無非是找一堆美術和關卡外包干活罷了。這在網頁游戲和社交產品領域同樣是成立的，就像傲視天地的推圖和戰斗系統，都應該是在早期就開始勾勒並且貫穿了整個產品開發始終的東西。
迭代式開發的核心思想與理念
好了，接下來，把藝術的感性收起來，我們要進入迭代式開發的階段了。
何為迭代？盛大以前有一句很形象的形容，叫做小步快跑。
以下文本來自百度：迭代式開發。在軟件開發的早期階段就想完全、准確的捕獲用戶的需求幾乎是不可能的。實際上，我們經常遇到的問題是需求在整個軟件開發工程中經常會改變。迭代式開發允許在每次迭代過程中需求可能有變化，通過不斷細化來加深對問題的理解。迭代式開發不僅可以降低項目的風險，而且每個迭代過程以可以執行版本結束，可以鼓舞開發人員。
其實中國還有一句老話，叫做走一步看一步。本質上，迭代式開發承認開發者當前對於用戶需求的了解和把握是欠完備的，開發者並不追求對產品需求進行一次性、全局的理解和把握，而是針對每一個產品細節，收集用戶行為和反饋，提出可能的解決方案，加以實現並驗證是否解決了問題，然後再邁向下一步的一種循環。
可以這麼說，迭代式開發的起點，是從一個版本的發布開始：版本發布，通過數據統計和分析，以及直接的用戶調查和問詢，得到用戶行為的直接反饋；基於反饋分析原因並提出可能的解決方案及驗證方法，開發完成這一解決方案，觀察用戶的行為是否有所改善。如果沒有得到改善，那就去嘗試另一個解決方案，重復這個循環；如果經過證實得以改善，那就繼續接下來的開發流程。
一個典型的迭代式開發過程中，有三個關鍵原則：盡可能短的迭代周期、明確的效果驗證方法、低成本的修正方案。
在不對用戶和運營產生過大困擾的情況下，迭代周期越短越好。這就要求把一個比較大的版本規劃切分成若干個小版本，分別針對某個特定的問題。本質上每一次的迭代循環，相當於開發人員與用戶/市場之間的一個對話周期，而對話進行的越頻繁，對市場的了解和把握就越深入。一對每年只通話一次的朋友，關系一定比不上每個禮拜都一起吃飯的朋友親密，而開發者和市場之間關系越疏離，距離成功的道路就越遙遠而不可見。
明確的效果驗證方法。這是絕大多數產品開發過程中會犯的錯，就是有意無意的省略了對效果的驗證。發現產品中的一個問題，譬如某個高流失率環節，討論，提出了某個改善方案，制作完成上線。然後……沒了。
實際上我一直在強調，迭代式開發的潛台詞就是承認我們對用戶和市場的無知。只有經過了驗證的方法，才能稱為一種“經驗”，而這種經驗的積累，代表了游戲團隊水平和競爭力的提升。僅僅滿足於提出或者完成某種改善方案，這本身沒有任何特別的意義。因為你壓根不知道，這個改善方案到底是對的，還是錯的？
我們往往以成本和工期為理由，用自己或者領導的想當然，來替代繁雜但卻可靠的運營數據和用戶行為分析，並且振振有詞說這就是我的水平，其實這只導致了一個結果，就是曾經犯下的錯誤，必然在未來某個時間點重復再犯一次。工期越長、時間越久，這種差距就越來越大。就像同樣是成立5年的公司，zynga真正比我們強悍的地方，其實在於每過一年，他們做一個新產品的時候所需要犯的錯誤就少一些，而我們5年前犯的錯和今天做一個產品犯的錯有可能是一樣多的。
低成本的解決方案設計。這意味著當我們發現某個環節有待改善時，應當首先評估那些實施成本最低的方案。因為每一次方案的提出和實施都是一次風險投資，在目標明確的前提下，投入越少，性價比越高。低成本的方案往往也意味著更迅速的開發時間和更短的迭代周期。有趣的是，雖然理智上我們很容易支持這一點，但是許多時候這樣的要求，和作為開發者本身的人性是相違背的。
作為產品的創造者，我們經常會在發現產品的種種不足之處時，提出一個“全新的、更好的、一攬子的”解決方案，並且認為那就是完美的答案。這可以稱之為一種“創新沖動”，但也可以叫做“創新性的陷阱”。實踐證明，這種看起來很完美的方案，經常只是因為其細節沒有被考慮充分罷了。大多數時候，在現有的方案上稍加調整，就可以解決問題的90%，這時候優先選擇的一定是成本更低的解決方式。
有人會問為什麼不投入更大的精力，追求產品的完美？這經常是一種很有沖擊性的提問方式，就好像我們是在裹著裹腳布走路的小老太太，被五四青年當街質問一般。
其實答案很簡單，因為你我這一刻所認為的完美方案，往往一點都不完美。人經常陷入一個思維誤區，就是對某個特定方式的非理性推崇和崇拜。進而認為所有不同意這個方式的人都是品味或者能力有問題。然而一兩個禮拜之後，就發現其實全然不是如此這般。之前的完美方案之所以看起來如此誘人，只是因為我們只是一廂情願的看到了其優點，而不願意面對其不足。
當一個方案真的在各方面都遠勝從前的時候，我們自然應當勇往直前將其付諸實施，據我的經驗，這種情況一般來說只占十分之一的比例。一段時間的沉澱、替代方案的討論以及廣泛聽取周圍人的意見，有助於我們去判斷哪些東西是真金，哪些東西是空包彈。
一句話：為解決問題而提出、並且經過了事實的驗證被證明有用的創新，才是有效性的創新，而一系列有效性的創新的累加，就是一款成功的商業化產品。
所以總體上，當我們面對一堆版本反饋和數據的時候：1、首先要做的，是提取其中對產品的進一步改善有顯著標示性的片段；2、針對這些片段，提出關於其原因的假設和潛在的修改方案；3、通過邏輯性和既往經驗，去掉部分可能性和可實施性較低的方案；4、然後，針對剩下來的方案，設計對其調整的有效性的驗證方法；5、在成本允許的情況下，盡可能嘗試所有的方案，尋找效果最好的一種，固定下來。
相對於拍腦袋，這是個辛苦得多的過程。而這個辛苦的過程所帶來的，就是我們和真正一流的研發公司之間的巨大鴻溝。
另外一個很現實的問題是，當一款產品還沒有推出到市場上的時候，應當如何實現有效的需求迭代？目前來看，有幾個方法可以參考：首先，盡量壓短前期開發時長，讓產品可以更早的面向至少一部分的用戶群；其次，在有限范圍內尋找參與者，典型的譬如公司內的自發性組織和測試，也包括受控制的小范圍封閉測試（這幾乎是最常見的做法之一）；最後，記住一件事：對於開發團隊來說，真正的開發周期是從產品上線那天開始算起。這可說是一種超越了具體方法本身的價值觀。
我認為，豐富的原始創意/敏銳的市場嗅覺、對既往成功產品（包括市場上的流行產品）成功做法的分析和總結/模板化、迭代化的開發思想/強大而迅速的執行能力，這若干項的合理組合，就是一家成功的游戲開發公司內在的基因所在。誠然，對今天的我們，這些要求很遙遠也很難達到，但，這起碼告訴了我們未來的方向。
一些哲學層面的提升
如果我們仔細研究人類的思維方式，你會發現，任何創新的點子在被醞釀出的一瞬間，都是基於一個特定的市場假設模型的。這個模型存在於我們的腦海裡，且相互之間不可復制。譬如說我腦子裡可能出現一個點子：加了芥末的酸辣黃瓜會大賣。這裡的大賣，就是我基於我腦子裡對顧客的理解和認知，模擬出來的一個餐飲市場的模型，我把自己的主意放到這個模型裡，然後發現計算結果是“十分樂觀”，接下來該怎麼做？馬上改行當廚子去？
且慢。首先我必須問自己一個問題，我了解餐飲業麼？作為一個從來不做飯的人，我是否可以僅僅憑借自己腦子裡的臆測，就認定一種產品會成功與否呢？
如果你仔細閱讀了之前的文字，這裡你就會明白，實際上我頭腦中的市場模型並不完備。順帶你也可以懂得，其實沒有任何人腦子裡的模型，是與市場完全等價的。本質上，我們對於現實世界的了解，永遠是局部、片面並且帶有主觀傾向的，這是一種常態。當然，經常去了解和分析市場的人，其模型的偏差程度，會比我這種外行要小，所以他們的判斷相對更可靠一些；而我們基於對市場的不完備理解，所設計出來的解決方案，本質上也必然是有欠完美的。這是一種非常哲學化的思辨，但在產品開發過程裡，這幾乎可以當成警句來使用。
我們對用戶的需求不夠了解 >> 我們設計出來的方案充滿缺陷 >> 缺陷的方案提交給不夠了解的用戶，必然會產生意料不到的偏差
這幾乎是一種宿命的悲觀論調。如果我們推演下去，不完備的方案進而會影響和改變用戶原有的需求，那這基本上是喬治索羅斯著名的“反身性原理”的游戲開發版。
可是另一方面來說，正因為缺乏完美的解決方案，才導致了市場上各種游戲設計思路都有其機會，沒有完美答案所以每個人都可以提出自己的方案，然後在市場中競爭並測試其有效性。生產鋼材的完美方案只有一種或者幾種，所以新的創業者基本上無法去開個煉鋼廠。做出好游戲的思路千變萬化，所以我們每個人就都有了自己的機會。