《XNA進階編程：Xbox 360和Windows》2-2

2.2遊戲構思

     討論類似Pong這樣的遊戲的遊戲構思聽起來有些可笑，不過我會盡量將事情一般化來處理。在您開始編碼之前有一件事非常重要，那就是您要仔細考慮您的遊戲外觀是什麼樣子，以及玩起來會有什麼感受。遊戲項目越大，設計過程就越重要。但我不是說如果您沒有任何想法就不能寫遊戲或者應用程式，實際上，很多初學者都是以寫東西開始，然後再一步一步地改進直到它看起來非常棒。問題在於，在第一次嘗試的時候很難找到一個最好的解決方案。

     Pong遊戲邏輯很簡單，也不需要太多的文字內容或者映像（2-1所示），這使得編寫代碼以及寫遊戲構思變得很簡單。寫下該遊戲需要的所有組件（比如球、球拍和螢幕邊框等）以及您的最初想法。

圖2-1

寫下您的想法！

     寫下您的想法並不是說您必須很瘋狂地寫下所有想法、畫UML圖，直到所有東西都準備好了才開始工作，我很反對這種方式，因為您不可能把所有東西都想到。而且，初學者一般都不知道以怎樣最好的方式預先設計整個遊戲。然而，您可以在您的腦海中對您的遊戲有一個非常清晰的畫面，當您在腦海中花了足夠多的時間來設計之後就可以開工了。

     如果您的項目中還有其他人和您一起工作，那麼解釋遊戲的構思以及讓每個人的工作都保持同步將變得更加困難。僅僅因為這個原因您就得養成一個習慣，只用一頁紙寫下您的遊戲構思。您不能只把這個展示給其他人看，您還得考慮其他的東西——當您把想法寫下來的時候您會發現它比您腦海中想的更加複雜，而且您不得不考慮很多相關的東西。

     比如，在Pong遊戲中您知道您需要兩個球拍和一個在球拍之間運動的球。但或許只有當您寫下最初的構思以及要使用的紋理素材之後，您才會想到更加詳細的遊戲玩法——每個玩家有幾條命？怎樣檢測球碰到了球拍的邊緣以及如何處理它？球拍的速度會影響球的速度和運動方向嗎？當玩家覺得無聊的時候是不是要每隔一段時間就增加遊戲的速度呢？當然，當您完成第一個版本之後這些方面都可以改進，不過在您開始編寫複雜的代碼之前把所有這些都考慮進去了會更加容易。

     作為一個例子，我會寫下本章中您將開發的Pong遊戲的設計構思。您可能會用5到10頁的篇幅來寫更加複雜的遊戲，但是不要一行代碼都沒有寫就寫了100頁的想法，這會花很多時間而且很難管理這些想法。使用“敏捷方法學”您將經常更新想法並修改一些細節，我一般都是在代碼至少完成了50%之後才開始畫UML圖，而像概覽圖和文檔直到項目快結束的時候才進行更新。

Pong遊戲構思

     這個遊戲是Pong遊戲的一個簡單的複製版本，支援一個或兩個玩家。在單人模式中電腦會控制另一個球拍；在雙人模式中，兩個玩家可以使用GamePad玩，也可以在個人電腦上使用同一個鍵盤來操作，還可以在Xbox 360上來玩。

     遊戲會為球和球拍使用一些2D圖片，以及一些音效檔來支援當球撞倒球拍或者死了一次的特效，還有一個非常簡單的遊戲菜單供選擇：

• 單人模式
• 雙人模式
• 離開遊戲

這個菜單使用一個簡單的紋理圖片，背景就是一塊黑暗地區，而大多數的圖片都是明亮的。您要試著把遊戲做得足夠有趣。

遊戲特點及玩法

     遊戲有兩個螢幕介面：菜單和遊戲。菜單就是之前提到的包含幾個菜單選項，遊戲主要包含基本的球、兩個球拍以及一個簡單的計分系統。看一張簡單的草圖明白您將完成的任務（圖2-2）：
圖2-2

使用的技術

     很明顯，您要使用XNA Game Studio Express，不需要使用其它的類庫，因為只是渲染簡單的Sprites，所以也不需要3D模型和Shaders，而且遊戲要在Windows和Xbox 360平台上都可以運行。

     正如您所看到的，我設法將所有東西都放到一頁紙的篇幅內，這是我在寫遊戲構思的時候的一個慣例：首先把所有東西都放在一頁篇幅內，然後寫一些代碼，如果您的小組或者外部夥伴（比如，如果您想把您的遊戲想法展示給一個遊戲出版商）需要的話，可以寫一份5到10頁的白皮書，包含一些最初的想法和草圖。

     我從來不會在遊戲構思的階段談論編碼，我只要確定要使用什麼技術。現在是時候考慮具體實現的問題了。不要在遊戲構思的時候考慮您的實際能力，因為這會限制您，儘管把它們拋之腦後吧！

     有關遊戲構思的一個完整的例子是Rocket Commander遊戲的構思（參見圖2-3），您可以查看本章檔案夾中的相關PDF檔案。它有4頁內容和一個封面，它包含了Rocket Commander的所有構想。從封面您可以看到，它和遊戲的構思很不同，不過基本的遊戲想法都體現出來了。
圖2-3

敏捷方法學

     對軟體開發來說敏捷方法學（Rocket Commander）是個概念範疇，它的主要思想是避免大的計劃階段，因為這會帶來很多危險，而且很難遵從不切實際的項目進度表。對於小的項目，您可能只要短時間的反反覆複，但隨著項目的增大，您會發現您總是在不停地解決問題，而這些問題可能要花費幾個月甚至幾年才能搞定，所有這些都是很難計劃的。

     實際上不要把所有東西都盡量設計得特別詳細，只要一些粗略的構思就可以了。在整個敏捷開發過程中構思的每個部分都會反覆很多次，把它設計的更詳細，藉助單元測試來設計代碼，然後編寫實際的代碼來實現，最後測試並寫文檔。這樣的反覆不應該超過幾個星期，而且大項目的所有部分都會重複這樣的過程。

     敏捷方法還包含其它的一些思想，比如如何讓開發人員和客戶、測試人員、專案管理人員以及設計人員更好地協作等等。有幾條規則可以用到敏捷架構中來避免整體的混亂。因為設計階段被縮短了，所以看起來好像沒有為項目進行詳細的設計，很像混亂的強力編碼。但實際上設計過程貫穿於更個項目，而且比在開始就設計好一切並解決那個階段產生的所有錯誤更有用。

     本書中我不會過多地討論敏捷方法學，不過我會使用單元測試以及簡略的概念，單元測試設計，然後反覆地編碼將貫穿本書的所有項目。如果您想瞭解單元測試的更多資訊我推薦您訪問Martin Fowler的網站：http://martinfowler.com 。

     Martin也寫了好幾本書，我推薦《重構：改善既有代碼的設計》（Refactoring: Improving the Design of Existing Code）這本書，您也可以在網站上找到它，您還可以在他的網站上找到更多的有關敏捷式軟體開發 (Agile Software Development)過程的連結及資訊。

解決一開始的難題

     好了，遊戲的構思您已經有了，但您還沒有花時間在找圖片和音效檔上，以及如何?它們，球撞擊球拍的問題又如何處理呢？您是否需要為球而設計一個簡單的物理引擎呢？

     在設計階段之後，所有這些問題都會冒出來，而對於更加複雜的項目來說，可能要花幾個星期甚至幾個月的時間來解決一些基本問題。比如，我做的第一個.Net 2.0遊戲Rocket Commander，我想在螢幕上顯示上千顆小行星，總體上有數百萬個，我還想讓它們相互碰撞並相互探測，但如何最佳化地實現它並不是很清楚。經過最初的測試我發現，我甚至不能在不明顯降低效能的前提下渲染超過100個小行星。此時我並沒有重寫我的遊戲構思，也沒有做一個小行星少得可憐令人厭煩的遊戲（如果沒有很多小行星那它就不是一個真正的遊戲——這就是Rocket Commander這款遊戲的原則），而是試著來解決這個問題，我把小行星按照Shaders和素材設定（Material Settings）分類，然後渲染它們，如果小行星不可見的話就儘早把它們清空，而且只把物理過程的處理應用於相鄰的小行星上。

     雖然經過一周的努力和最佳化處理，小行星可以渲染出來了，而且效能還不錯，但是物理過程的處理仍然很慢。即使應用最好的最佳化處理，在每一幀的可視範圍內更新5000到10000個小行星來查看它們相互碰撞仍然顯得太多，但我依然想讓小行星相互撞擊並在碰撞後仍能運行正常。如果每一幀我只檢查一定數量的小行星，演算法經常會沒有碰撞效果，而且只有當一個小行星進入滲透到另一個裡面的時候才出現碰撞，帶來的麻煩比移除物理過程還多。我幾乎快要放棄了，因為我已經花了整個項目的50%的時間來解決這一個問題。但後來我又有了一個想法，把整個空間分割成若干個地區，每個地區都有特定數量的小行星，每當一個小行星離開一個地區的時候就把它從這個地區移除，並添加到新的地區中，這樣小行星只需要檢測它們自己的以及鄰近的地區中的碰撞。這聽起來好像還有很多碰撞檢測，但是使用“地區邏輯（sector logic）”的確把物理過程的效能提高了100倍之多，而且經過最佳化處理效果還會更明顯。

     現在，在我參與的大多數遊戲項目中我會花一半還多的時間來處理最初的難題，然後把它們分割成更小的問題來解決，稍後把這些小的片段再重新組合起來，很快地過一些天之後整個遊戲就完成了。雖然這是一個儘可能快的方式來完成一個遊戲，但是很長一段時間看不到遊戲啟動並執行結果也會有一種挫敗感。在過去，我總是反反覆複地修改我的遊戲直到我對結果滿意為止，這也的確會花很長時間。多虧了敏捷開發過程，現在我可以解決這些問題並且再也不用重複幾乎沒有止境的改進迴圈了。

     這對您的Pong遊戲意味著什麼呢？遊戲很簡單，您不需要花很多時間對它不斷地改進100次，只要實現一個基礎版本的Pong遊戲，為電腦寫入程式碼（hard-coded）一個球拍，在螢幕左邊隨著球的位置來回上下移動，並且還要控制右邊的球拍。經過改進並測試單人模式的遊戲之後，您或許想支援雙人對戰的模式，但這非常難，因為您寫入程式碼了電腦球拍的實現部分。您可能會把這部分代碼注釋掉或者乾脆刪掉，並重新修改玩法部分的代碼。等測試了雙人對戰模式之後，您可能又想添加一個菜單，您又再一次調整修改代碼，這樣不斷地進行下去。

     雖然這是一個好的實踐方式，並迫使您不斷地重構您的代碼（重構的意思是在不改變功能的前提下修改代碼的設計使得更容易維護，可以參考前面推薦的Martin Fowler寫的有關重構的書），不過如果每次只把重點放在遊戲的一個部分上，並且同時使用幾個版本進行測試會更加容易。在本章接下來的部分您將要這麼做，希望您能領會我的意思。藉助單元測試，代碼重構會更自然，並讓您的代碼更易使用，還能讓您更快地看到運行結果。

     接下來您要解決的一個問題是，怎麼處理球的物理運動，並且如何檢測球撞擊了球拍的哪個部位。

建立紋理

     在您開始編碼之前，您需要紋理素材在螢幕上顯示遊戲元素的材質。即使這裡您使用虛擬位元影像（dummy bitmap）或者從其他地方得到的圖片，考慮最終的映像效果還是很重要的，比如球和球拍的尺寸等等諸如此類的東西。

     再說一次，您的Pong遊戲相當地簡單，但更加複雜的遊戲可能需要一個美術創意、很多草圖以及一個能管理這些設計作品並能及時地完成它們以便遊戲編程人員實現它們的人。回顧電腦遊戲早期，幾乎所有的遊戲都是靠一個人來完成的，雖然這是最容易的方式，但今天沒有一個正規的遊戲可以只靠一個人來開發。大多數優秀的美術設計人員都不是編程人員，大多數編程人員又不是好的美術設計。如果您只做一個簡單的遊戲這倒無所謂，但是您的項目越大，您就需要更多的時間來找夥伴、有經驗的美術設計人員和模型製作人員，並把他們有效地組織起來。

     看一2-4的遊戲圖片，您需要三個紋理檔案：（1）SpaceBackground.dds 作為背景；（2）PongMenu.png，它包含了Logo，功能表項目以及其他遊戲需要的文本資訊；（3）PongGame.png，用來修飾球拍和球。
圖2-4

     另外您還要匯入兩個音效檔（PongBallHit.wav和PongBallLost.wav）到您的項目中，並添加一個簡單的XACT項目來播放聲音。更多關於聲音處理和XACT的內容請參考第九章。