在Warsztat(一 個波蘭的游戲開發組織)工作的幾年中，我發現一個有趣的現象。經常我們會組織一些編程競賽，這些競賽通常分為兩種形式。一種是個人行動，一般只有2個小時的時間，另外一種是長時間的(數天/周)。作為一個額外的要求，前者通常限制只允許使用基本的API(SDL, OpenGL等)，而后者通常沒有限制(可以使用各種引擎，UDK/Unity等)。
結果有點讓人吃驚。很多人更愿意參加短競賽。但不管游戲是在2個小時里開發出來的，還是在4周內開發出來的，它們中優秀的部分的在水平上一樣的。為什么？ 4周的開發期并不意味著開發的時間是672或224小時。在一些極端的情況在，4周的競賽跟2個小時的競賽一樣，也就是這4周的最后2個小時在起作用。 很多的游戲體現出來的實際是一個創意。事實上：你4周內想出來的創意未必就比10分鐘內想出的好。 2小時競賽的開發過程壓力強度非常的大。大部分的時間都是用來改進核心功能(因為也沒有其它的)。 另一方面，在長周期競賽項目里，人們最初只是關注一些無關緊要的功能。一旦你開始琢磨著添加一個界面組件，把它做成一個內置的MP3播放器，或把界面弄的色彩斑斕，你的項目就開始失敗了。 這也許是我們得到的最重要的教訓。如果你需要很快的完成某項事情，代碼可能會寫的很差，但也會很短小、簡練和靈活。如果沒有時間的約束，程序的復雜度，功能項和缺陷率會上一個等級。給日后維護帶來的工作量并不體現在現在。 在4周的編程時間里，你可以進行數次的快速迭代編程，每一次都對游戲的核心功能進行改進。但如果一開始你就把一些以后未知的特征功能考慮進去，寫這 部分功能以及修改bug會耗去大部分的時間。誠然，你可以用這4周時間寫出大量的assets測試，但核心的游戲娛樂方式設計的足夠好嗎？ 最后，給你們一個絕對有價值的C(++)忠告：當增加新功能時，從最小的核心功能開始： 全局函數 — 如果你需要去顯示分數，不要猶豫，立即寫出void DisplayScore()。如果你的游戲是單人玩的，把分數存成全局變量。看看，你至少節省了10分鐘的寫getter、setter和設計給模塊通 信的時間。不需要做這些。如果游戲是多人玩的，你需要為每個人記錄和顯示分數。但如果你的游戲不是多人玩的，你沒有任何理由實現能顯示任意多人的任意分數 的功能。相信我，你將會遇到比顯示分數復雜的多的多的問題。 如果你的函數需要用到共用代碼或需要輔助函數，請把它們組織到一起，最好是放在一個單獨的文件里。時刻想著靜態函數和變量 — 跟“OO”的靜態相反，文件的靜態是可見的。這樣做很好，因為你可以把所有跟字體相關的操作都放在一個文件里，把把所有內部數據都放在靜態全局變量里。輔 助函數可以做成靜態的，通過共享的header對外開放(如果你寫出簡單的代碼，整理工作從來不會耗費你太多的時間)。 只有在必要的時候才把函數提升為類。記著，類意味著對象，對象意味這相互關系，而相互關系意味這復雜。你的游戲設計會酷到留有大量的時間處理代碼的復雜嗎？ 只有當上面說的這些不夠好，設計模式或其他新奇的東西才能成為你的求助目標。永遠不要走到這一步。 |
