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

本文是從 Simplicity Oriented Programming 這篇文章翻譯而來。

在Warsztat(一個波蘭的遊戲開發組織)工作的幾年中，我發現一個有趣的現象。經常我們會組織一些編程競賽，這些競賽通常分為兩種形式。一種是個人行動，一般只有2個小時的時間，另外一種是長時間的(數天/ 周)。作為一個額外的要求，前者通常限制只允許使用基本的API(SDL, OpenGL等)，而後者通常沒有限制(可以使用各種引擎，UDK/Unity等)。

結果有點讓人吃驚。很多人更願意參加短競賽。但不管遊戲是在2個小時裡開發出來的，還是在4周內開發出來的，它們中優秀的部分的在水平上一樣的。為什嗎？

1. 4周的開發期並不意味著開發的時間是672或224小時。在一些極端的情況在，4周的競賽跟2個小時的競賽一樣，也就是這4周的最後2個小時在起作用。
2. 很多的遊戲體現出來的實際是一個創意。事實上：你4周內想出來的創意未必就比10分鐘內想出的好。
3. 2小時競賽的開發過程壓力強度非常的大。大部分的時間都是用來改進核心功能(因為也沒有其它的)。
4. 另一方面，在長周期競賽項目裡，人們最初只是關注一些無關緊要的功能。一旦你開始琢磨著添加一個介面組件，把它做成一個內建的MP3播放器，或把介面弄的色彩斑斕，你的項目就開始失敗了。

這也許是我們得到的最重要的教訓。如果你需要很快的完成某項事情，代碼可能會寫的很差，但也會很短小、簡練和靈活。如果沒有時間的約束，程式的複雜度，功能項和缺陷率會上一個等級。給日後維護帶來的工作量並不體現在現在。

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

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

1. 全域函數 — 如果你需要去顯示分數，不要猶豫，立即寫出void DisplayScore()。如果你的遊戲是單人玩的，把分數存成全域變數。看看，你至少節省了10分鐘的寫getter、setter和設計給模組通訊的時間。不需要做這些。如果遊戲是多人玩的，你需要為每個人記錄和顯示分數。但如果你的遊戲不是多人玩的，你沒有任何理由實現能顯示任意多人的任意分數的功能。相信我，你將會遇到比顯示分數複雜的多的多的問題。
2. 如果你的函數需要用到共用代碼或需要輔助函數，請把它們組織到一起，最好是放在一個單獨的檔案裡。時刻想著靜態函數和變數 — 跟“OO”的靜態相反，檔案的靜態是可見的。這樣做很好，因為你可以把所有跟字型相關的操作都放在一個檔案裡，把把所有內部資料都放在靜態全域變數裡。輔助函數可以做成靜態，通過共用的header對外開放(如果你寫出簡單的代碼，整理工作從來不會耗費你太多的時間)。
3. 只有在必要的時候才把函數提升為類。記著，類意味著對象，對象意味這相互關係，而相互關係意味這複雜。你的遊戲設計會酷到留有大量的時間處理代碼的複雜嗎？
4. 只有當上面說的這些不夠好，設計模式或其他新奇的東西才能成為你的求助目標。永遠不要走到這一步。