業餘愛好者自創遊戲的經驗

　　前言

　　在過去三個月中，我都在致力於開發一款名為《Lunar Lander 3D》的小遊戲。我著手這個項目的主要原因是希望掌握創造遊戲所需了解的知識。除此之外，我還希望借此轉移自己在課業上的壓力。雖然這款遊戲很小很簡單，其開發過程卻讓我收獲了大量有用的知識。我將在本文列出自己在開發遊戲過程中學到的一些重要知識。

　　在進入正題之前，我想先說明一下，我並不是什麼專業人士。我隻是一個常坐在電腦前的呆子，本文內容麵向想自己試著創造一款遊戲的業餘程序員和愛好者。所以本文的重點是讓你如何完成一款遊戲，而非製作一款技術華麗的半成品遊戲。

　　你的理念並不罕見

　　如果你想完成一款遊戲，你就必須認識到這一點。無論你有多看重自己以及自己的想法，你都要勇於拋棄其中的多數想法。當我開始製作自己的遊戲時，滿腦子都是自己想用的理念。我想在遊戲世界中加入移動的平台的障礙，複雜的攝像係統以及一係列其他元素。但我知道如果我想完成遊戲，就得更改自己的多數理念。要記住當你是孤軍奮戰時，你就無法搞定一個專業團隊需要用一年以上時間才能完成的項目。雖然一年以上的時間對專業團隊來說並非很長的時間，但卻業餘愛好者來說卻是個大難題。要根據自己的想法合理安排開發時間，例如將其控製在6個月以內。

　　不要從頭做起

　　如果你並沒有什麼編碼基礎，那就無法一開始就編寫出一款遊戲。這聽起來難以讓人接受，但如果你確實沒有一係列持續使用的代碼，你可能就無法持續長時間地編程。如果你沒有那麼長久的編程經驗，那麼就不能幻想開發一款遊戲。我開始製作自己的遊戲時，已經有了一個很大的代碼庫。我針對一般窗口創造、輸入管理、粒子效果、運算以及各類用途的代碼。有了這些現成的代碼，我就能夠快速展開工作，製作與遊戲相關的內容。除此之外，我還不需要去測試這些代碼，因為我之前編寫的時候就已經測試過了。你在開始創造自己的遊戲之前，不需要逐個編寫每一節代碼。隻要花點時間先做一點基礎工作即可。如果你覺得自己還是得創建一個代碼庫，那就先編寫小型用來測試一下。我處理粒子效果、輸入管理和控製執行代碼時就是這麼做的。這可能不像製作遊戲一樣令人興奮，但對你卻有長期的幫助。

　　借鑒想法

　　我要再次強調這個環節的重要性。當你開始編寫一款遊戲時，不要害怕使用他人的理念，庫或工具。可以盡量借鑒，因為這可以讓你的工作更輕鬆。我在製作自己的遊戲時，借鑒了Conor Stoke的軸線對齊邊界框樹，Paul Nettle的碰撞檢測文件，id Software的Q3Radiant關卡編輯器。為什麼我要用其他人的想法和工具來解決自己本可以完成的問題呢？原因就在於，這樣更簡單——我使用這些不同的資源是因為節省時間。使用現成的方法進行碰撞檢測，這樣我就不需要將時間浪費在測試自己的碰撞係統上了。我根據自己的需求調整了id Software的地圖編輯器，就不需要再製作自己的編輯器了。除此之外，id地圖編輯器非常適合我，這又為我節省了不少功夫。不要執拗於自己的遊戲一定要有定製工具和解決方案。如果你夠精明，就會知道何時要采用新理念，何時可以使用現成的東西。

　　避免使用3D地形引擎

　　如果是為了創造遊戲而製作引擎，那就很可能被卡在半途。無論你多努力地嚐試，總會發現自己無所進展。根據我製作遊戲的經驗，你自己編寫遊戲時並不需要用到引擎。要記住，你是一個人而不是一家公司在編寫遊戲。你不需要一個反複重用的引擎。編寫引擎的一個理由就是代碼重用，但沒有引擎你也照樣可以做到這一點。隻要設計合理，你就能夠將自己其他項目的元素重用到遊戲上。例如，我編寫的遊戲所用的新代碼都不是特定的遊戲代碼，我可以將其重用於其他項目。編寫引擎以獲得引擎本身的知識及其背後的設計過程當然可以，像如果你是要製作一款遊戲那就要避免這種情況了。

　　不要在圖像上畫蛇添足

　　你製作自己的遊戲時，不要添加一些並不會讓遊戲更棒的圖像特點。不要使用GeForce20那種很棒的擴展功能，以及其他的逐象素、凹凸貼圖、紋理動畫、逐象素深度陰影等元素，因為你根本就不需要。如果你將自己的遊戲定義為靠圖像來撐場麵的那種，那你可能並不了解遊戲。你製作的隻是一個技術演示樣本。我在自己的遊戲中使用的最複雜的圖像功能就是多重紋理，但如果要遊戲正常運行也並不需要這種功能。我知道自己並非id Software成員，也並不需要很高端的硬件來支持我這款簡單的遊戲。如果你保持簡單性，不但可以擴大遊戲受眾，還能夠將自己的精力集中於更重要的環節，例如遊戲玩法。