在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ā)過程壓力強度非常的大。大部分的時間都是用來改進核心功能(因為也沒有其它的)。 另一方面，在長周期競賽項目里，人們最初只是關(guān)注一些無關(guān)緊要的功能。一旦你開始琢磨著添加一個界面組件，把它做成一個內(nèi)置的MP3播放器，或把界面弄的色彩斑斕，你的項目就開始失敗了。 這也許是我們得到的最重要的教訓。如果你需要很快的完成某項事情，代碼可能會寫的很差，但也會很短小、簡練和靈活。如果沒有時間的約束，程序的復雜度，功能項和缺陷率會上一個等級。給日后維護帶來的工作量并不體現(xiàn)在現(xiàn)在。 在4周的編程時間里，你可以進行數(shù)次的快速迭代編程，每一次都對游戲的核心功能進行改進。但如果一開始你就把一些以后未知的特征功能考慮進去，寫這 部分功能以及修改bug會耗去大部分的時間。誠然，你可以用這4周時間寫出大量的assets測試，但核心的游戲娛樂方式設(shè)計的足夠好嗎？ 最后，給你們一個絕對有價值的C(++)忠告：當增加新功能時，從最小的核心功能開始： 全局函數(shù) — 如果你需要去顯示分數(shù)，不要猶豫，立即寫出void DisplayScore()。如果你的游戲是單人玩的，把分數(shù)存成全局變量。看看，你至少節(jié)省了10分鐘的寫getter、setter和設(shè)計給模塊通 信的時間。不需要做這些。如果游戲是多人玩的，你需要為每個人記錄和顯示分數(shù)。但如果你的游戲不是多人玩的，你沒有任何理由實現(xiàn)能顯示任意多人的任意分數(shù) 的功能。相信我，你將會遇到比顯示分數(shù)復雜的多的多的問題。 如果你的函數(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)系意味這復雜。你的游戲設(shè)計會酷到留有大量的時間處理代碼的復雜嗎？ 只有當上面說的這些不夠好，設(shè)計模式或其他新奇的東西才能成為你的求助目標。永遠不要走到這一步。 |
