在Warsztat(一個波蘭的游戲開發(fā)組織)工作的幾年中，我發(fā)現(xiàn)一個有趣的現(xiàn)象，

二小時與四周時間在編程上的差別

。經(jīng)常我們會組織一些編程競賽，這些競賽通常分為兩種形式。一種是個人行動，一般只有2個小時的時間，另外一種是長時間的(數(shù)天/周)。作為一個額外的要求，前者通常限制只允許使用基本的API(SDL, OpenGL等)，而后者通常沒有限制(可以使用各種引擎，UDK/Unity等)。

    結(jié)果有點讓人吃驚。很多人更愿意參加短競賽。但不管游戲是在2個小時里開發(fā)出來的，還是在4周內(nèi)開發(fā)出來的，它們中優(yōu)秀的部分的在水平上一樣的。為什么？

4周的開發(fā)期并不意味著開發(fā)的時間是672或224小時。在一些極端的情況在，4周的競賽跟2個小時的競賽一樣，也就是這4周的最后2個小時在起作用。

很多的游戲體現(xiàn)出來的實際是一個創(chuàng)意。事實上：你4周內(nèi)想出來的創(chuàng)意未必就比10分鐘內(nèi)想出的好。

2小時競賽的開發(fā)過程壓力強(qiáng)度非常的大。大部分的時間都是用來改進(jìn)核心功能(因為也沒有其它的)。

另一方面，在長周期競賽項目里，人們最初只是關(guān)注一些無關(guān)緊要的功能。一旦你開始琢磨著添加一個界面組件，把它做成一個內(nèi)置的MP3播放器，或把界面弄的色彩斑斕，你的項目就開始失敗了。

    這也許是我們得到的最重要的教訓(xùn)。如果你需要很快的完成某項事情，代碼可能會寫的很差，但也會很短小、簡練和靈活。如果沒有時間的約束，程序的復(fù)雜度，功能項和缺陷率會上一個等級，

管理資料

《二小時與四周時間在編程上的差別》(http://www.stanzs.com)。給日后維護(hù)帶來的工作量并不體現(xiàn)在現(xiàn)在。

    在4周的編程時間里，你可以進(jìn)行數(shù)次的快速迭代編程，每一次都對游戲的核心功能進(jìn)行改進(jìn)。但如果一開始你就把一些以后未知的特征功能考慮進(jìn)去，寫這部分功能以及修改bug會耗去大部分的時間。誠然，你可以用這4周時間寫出大量的assets測試，但核心的游戲娛樂方式設(shè)計的足夠好嗎？

    最后，給你們一個絕對有價值的C(++)忠告：當(dāng)增加新功能時，從最小的核心功能開始：

全局函數(shù) — 如果你需要去顯示分?jǐn)?shù)，不要猶豫，立即寫出void DisplayScore()。如果你的游戲是單人玩的，把分?jǐn)?shù)存成全局變量�？纯�，你至少節(jié)省了10分鐘的寫getter、setter和設(shè)計給模塊通信的時間。不需要做這些。如果游戲是多人玩的，你需要為每個人記錄和顯示分?jǐn)?shù)。但如果你的游戲不是多人玩的，你沒有任何理由實現(xiàn)能顯示任意多人的任意分?jǐn)?shù)的功能。相信我，你將會遇到比顯示分?jǐn)?shù)復(fù)雜的多的多的問題。

如果你的函數(shù)需要用到共用代碼或需要輔助函數(shù)，請把它們組織到一起，最好是放在一個單獨的文件里。時刻想著靜態(tài)函數(shù)和變量 — 跟“OO”的靜態(tài)相反，文件的靜態(tài)是可見的。這樣做很好，因為你可以把所有跟字體相關(guān)的操作都放在一個文件里，把把所有內(nèi)部數(shù)據(jù)都放在靜態(tài)全局變量里。輔助函數(shù)可以做成靜態(tài)的，通過共享的header對外開放(如果你寫出簡單的代碼，整理工作從來不會耗費你太多的時間)。

只有在必要的時候才把函數(shù)提升為類。記著，類意味著對象，對象意味這相互關(guān)系，而相互關(guān)系意味這復(fù)雜。你的游戲設(shè)計會酷到留有大量的時間處理代碼的復(fù)雜嗎？

只有當(dāng)上面說的這些不夠好，設(shè)計模式或其他新奇的東西才能成為你的求助目標(biāo)。永遠(yuǎn)不要走到這一步。