對基礎構思的完善和原型化

一款游戲從創(chuàng)意到開發(fā)，抽象來看可以分為兩大階段：基礎構思的階段，和迭代開發(fā)的階段。任何游戲在最早的時候都只是一個或者一組零散而不確定的構想，策劃人員將這組構想加以整理，抽取其中相互聯(lián)系的規(guī)則組成核心規(guī)則集，這就是產(chǎn)品最初的框架。譬如說俄羅斯方塊最初的規(guī)則可能包括：方塊連成一行就消除并加分；頭頂隨機掉落新的方塊；方塊可旋轉，等。

一般來說，在這個階段，游戲開發(fā)者會尋求利用這組核心規(guī)則建立一個簡單的DEMO，用來驗證游戲本身的可玩性。這個DEMO往往是缺乏美術效果和友好的UI的，但是其遵循的游戲主循環(huán)一般來說與后來的商業(yè)版本并沒有太大的不同。

譬如說如果你在做彈彈堂，你可能會先搞一個只有一種炮彈、一個怪一張地圖的演示版，雖然內(nèi)容簡單，但是回合規(guī)則與彈道公式是與后來的版本基本上一致的。

對于一個前期的產(chǎn)品構思來說，究竟要花多少時間和精力來做DEMO？又要花費多久來測試這個DEMO？不同的公司和團隊，對這個問題的回答往往大相徑庭。

在這里就出現(xiàn)了一個很有爭議性的問題：縝密的構思加上完善的策劃文檔，是否能夠替代對于DEMO的開發(fā)和評估？答案是否定的。

為什么要做原型呢？既然原型的代碼基本上不可能被用在商業(yè)化的成品里，既然這只是給一小部分人看的演示，跳過去有何不可？

核心原因在于，作為人，我們的能力和經(jīng)驗從本質上說，是有限且不完備的。而游戲又是一種體驗性的產(chǎn)品，一款游戲的可玩性，無法通過邏輯和數(shù)理的方式來驗證，而必須通過一部分人員通過實際的游戲過程，主觀的去感受和評判。而這也就是為什么說游戲設計是一門藝術的理由所在。

很多游戲策劃人員骨子里對市場和運營是持反感態(tài)度的，他們說，游戲是一種藝術，游戲性是我追求的靈魂，這比庸俗的充值要重要。在原型的設計和評估階段，他們是對的。

對于原型的評判，一般來說，是要看游戲的核心規(guī)則是否清晰容易掌握，同時根據(jù)用戶的操作又能夠得到各種不同的選擇結果，再就是技術角度的一些基礎性驗證。譬如說，一個游戲可能規(guī)則復雜變幻叵測，但是需要一個月的時間才能上手；又或者一個游戲3分鐘即可掌握，但是玩來玩去每一次的流程都差不多。這些，都是需要在原型化過程中去分析和判斷的問題。

如果一個原型做下來，大家不覺得這個東西好玩，接下來該怎么辦？

很簡單，放棄。扔掉一切，重新開始設計。這里有一個很大的誤區(qū)，一方面把游戲性不佳歸結于DEMO的內(nèi)容量不足，指望著內(nèi)容量增加之后可玩性變好；另一方面以DEMO早晚會放棄不應當投入太高成本為借口，認為“這么小的DEMO能達到這樣的水準，如果……的話，游戲肯定不錯”實際上這都是自己給自己挖坑跳的思想和行為。

一款游戲，小到俄羅斯方塊泡泡龍，大到魔獸世界天龍八部，本質上都是有自己的核心玩法的，大型產(chǎn)品的核心玩法構成可能更復雜，甚至是由一組相互關聯(lián)的子玩法相互配合所組成，但是無論大游戲小作品，都是由一個個獨立的玩法模塊搭建起來的，一個大型的MMO，可能其中很多玩法并不特別出色也能獲得成功；但是一個玩法模塊很多、但是每一個都不算出色的產(chǎn)品，是不可能僅僅憑借功能比別人多來贏得玩家的。

就是說，成功的游戲不見得每一個玩法都精彩，但是沒有至少一個比較精彩的玩法的游戲，一定會失敗，無論多久、無論成本多高、無論程序美術策劃多努力。實際上這是1和1后面的0的關系，沒有1，則再多的0加起來也是0。

我講過一個簡單的理論：游戲的核心玩法是一款游戲的縱軸，而內(nèi)容的增加是一款游戲的橫軸，一個好的縱軸，可以支撐很廣闊的橫軸，就像彈彈堂或者瘋狂的小鳥，基于自己的核心玩法，可以不斷設計推出新的地圖；而如果縱軸不夠強大，橫向的擴展越多，產(chǎn)品死亡的速度就會越快。這就像蓋房子沒有把房梁搭好就往上放磚，建的越快就塌陷越快。

所以，在游戲的初期，對于核心玩法和DEMO的反復修改不斷錘煉，是決定了這個產(chǎn)品能走多遠的基礎和地基，打個比方你能設計出瘋狂的小鳥或者植物大戰(zhàn)僵尸的核心玩法規(guī)則，那接下來要做的無非是找一堆美術和關卡外包干活罷了。這在網(wǎng)頁游戲和社交產(chǎn)品領域同樣是成立的，就像傲視天地的推圖和戰(zhàn)斗系統(tǒng)，都應該是在早期就開始勾勒并且貫穿了整個產(chǎn)品開發(fā)始終的東西。

迭代式開發(fā)的核心思想與理念

好了，接下來，把藝術的感性收起來，我們要進入迭代式開發(fā)的階段了。

何為迭代？盛大以前有一句很形象的形容，叫做小步快跑。

以下文本來自百度：迭代式開發(fā)。在軟件開發(fā)的早期階段就想完全、準確的捕獲用戶的需求幾乎是不可能的。實際上，我們經(jīng)常遇到的問題是需求在整個軟件開發(fā)工程中經(jīng)常會改變。迭代式開發(fā)允許在每次迭代過程中需求可能有變化，通過不斷細化來加深對問題的理解。迭代式開發(fā)不僅可以降低項目的風險，而且每個迭代過程以可以執(zhí)行版本結束，可以鼓舞開發(fā)人員。

其實中國還有一句老話，叫做走一步看一步。本質上，迭代式開發(fā)承認開發(fā)者當前對于用戶需求的了解和把握是欠完備的，開發(fā)者并不追求對產(chǎn)品需求進行一次性、全局的理解和把握，而是針對每一個產(chǎn)品細節(jié)，收集用戶行為和反饋，提出可能的解決方案，加以實現(xiàn)并驗證是否解決了問題，然后再邁向下一步的一種循環(huán)。

可以這么說，迭代式開發(fā)的起點，是從一個版本的發(fā)布開始：版本發(fā)布，通過數(shù)據(jù)統(tǒng)計和分析，以及直接的用戶調(diào)查和問詢，得到用戶行為的直接反饋；基于反饋分析原因并提出可能的解決方案及驗證方法，開發(fā)完成這一解決方案，觀察用戶的行為是否有所改善。如果沒有得到改善，那就去嘗試另一個解決方案，重復這個循環(huán)；如果經(jīng)過證實得以改善，那就繼續(xù)接下來的開發(fā)流程。

一個典型的迭代式開發(fā)過程中，有三個關鍵原則：盡可能短的迭代周期、明確的效果驗證方法、低成本的修正方案。

在不對用戶和運營產(chǎn)生過大困擾的情況下，迭代周期越短越好。這就要求把一個比較大的版本規(guī)劃切分成若干個小版本，分別針對某個特定的問題。本質上每一次的迭代循環(huán)，相當于開發(fā)人員與用戶/市場之間的一個對話周期，而對話進行的越頻繁，對市場的了解和把握就越深入。一對每年只通話一次的朋友，關系一定比不上每個禮拜都一起吃飯的朋友親密，而開發(fā)者和市場之間關系越疏離，距離成功的道路就越遙遠而不可見。

明確的效果驗證方法。這是絕大多數(shù)產(chǎn)品開發(fā)過程中會犯的錯，就是有意無意的省略了對效果的驗證。發(fā)現(xiàn)產(chǎn)品中的一個問題，譬如某個高流失率環(huán)節(jié)，討論，提出了某個改善方案，制作完成上線。然后……沒了。

實際上我一直在強調(diào)，迭代式開發(fā)的潛臺詞就是承認我們對用戶和市場的無知。只有經(jīng)過了驗證的方法，才能稱為一種“經(jīng)驗”，而這種經(jīng)驗的積累，代表了游戲團隊水平和競爭力的提升。僅僅滿足于提出或者完成某種改善方案，這本身沒有任何特別的意義。因為你壓根不知道，這個改善方案到底是對的，還是錯的？

標簽： 產(chǎn)品 ��

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。