電子遊戲設計/章節/實施

實施

設計實施

在考慮實施你的設計之前，你應該思考一下實施的成本，包括時間和金錢。你可以透過將你的遊戲設計（概念）出售給遊戲製作工作室來將其貨幣化，或者你可以為開放式實施建立一個開源專案。

在考慮做什麼時，也請考慮你建立的遊戲的可營銷性以及你的目標。它將是免費的嗎？還是你要出售它？如果你要出售它，人們會想要購買它嗎？人們將如何聽到關於它的訊息？你願意在營銷這款遊戲上花多少錢和多少資源？你有嗎？它們值得嗎？

實施也應該被視為一個沙盒，在那裡將嘗試和修剪事物以滿足所需的目標。你只應該在實施的後期階段感到擔憂，因為在某個時候，人們必須接受過多的更改可能會破壞專案。

如果你的實施過程在某個部分停滯，請回到你的設計參考，看看以前的人如何處理這些問題。你可以，也應該，有創造力，但你應該期望有人已經找到至少一個可行的解決方案來解決每個問題，使用你的創造性資源來建立在這個解決方案的基礎上，而不是重新建立與以前已經完成的事情相等的東西。

概念與能力

在你開始開發之前，請記住要區分你想要做什麼和你能做什麼。弄清楚你擁有的資源，並將它們與專案所需的資源進行比較，並相應地進行調整。如果你擁有大量資源，但你的概念很簡單，也許你可以擴充套件它。如果你有一個複雜的概念，但資源很簡單，也許你需要擴充套件你的資源。

在你完成了所有這些考慮之後，概述專案，首先是如何遊戲的工作方式以及它的排列方式，然後按時間順序排列你將如何完成這些事情 - 為自己設定一個截止日期可能會有所幫助。

資源

考慮你的資源，你個人有哪些能力？你會程式設計、畫畫、渲染多邊形嗎？你有多少錢，你打算花多少時間在這上面？你是否有開發遊戲的技術，還是需要去獲取？你知道你需要什麼嗎？

程式語言

圖形設計

音樂創作

團隊合作

開發一款影片遊戲對於一個人來說是一個非常大的專案，尤其是一個人獨自完成。將專案作為一個團隊來做，將所有需要的資源整合在一起，共同打造一款優秀的影片遊戲，或許是一個更好的主意。僅僅靠一個人幾乎不可能創作出人們真正喜歡的遊戲。遊戲開發需要良好的社交技能，因為 99% 的時間你都將與一個設計師團隊一起工作。與你的遊戲設計同事建立良好的關係非常重要，這樣才能取得專案最佳效果。

團隊合作

開發階段

測試和開發階段是遊戲真正被創建出來的階段。當你進行程式設計、製作圖形、作曲並協作這些資源時，你會進行大量的測試和除錯工作。請考慮以下部分。

除錯

概念藝術

在遊戲實施的早期階段擁有良好的概念藝術作品集非常重要，這不僅可以使概念更加直觀，還可以協調整個開發團隊的開發工作。

概念藝術在實施之前就提高了遊戲設計本身的價值。

內容創作

遊戲內容可以是靜態的，也可以是動態的，與移動有關，並取決於它是如何建立的（設定或程式化），甚至兩者兼而有之，生成也可以是即時進行的，也可以來自儲存資料，這主要取決於互動程度或硬體能力。

演示

演示在遊戲中，就像在現實生活中的大多數事物中一樣，非常重要。震撼效果、將簡單平庸的事物以創意的方式改變，讓玩家沉浸在作品中，是遊戲成功的關鍵因素之一。

演示涵蓋了遊戲中所有視覺元素的利用方式，從在2D 或 3D實現之間進行選擇，到所有遊戲藝術作品的質量，從遊戲內物品到現實生活中的營銷宣傳、曝光和遊戲盒設計。

有許多免費許可內容的資源庫，不僅可以用於遊戲原型設計，甚至可以用來構建完整的成熟遊戲實現。

• OpenGameArt.org (http://opengameart.org/) - 一個包含各種型別媒體的資源庫，具有不同的版權許可狀態，旨在用於自由軟體遊戲專案。
• ccMixter (http://ccmixter.org/) - 一個促進混音文化的社群音樂網站，提供 Creative Commons 許可的樣本、混音和人聲伴奏軌道供下載和在創意作品中重複使用。
• The Freesound Project (http://www.freesound.org/) - 一個 Creative Commons 許可的音訊樣本資源庫。該網站的使用者上傳的聲音涵蓋了廣泛的主題，從實地錄音到合成音效。

構圖

遊戲構圖與電影攝影和動畫有很多共同點。就像電影一樣，大多數遊戲都傾向於講述一個故事，即使是以互動的方式。如今，任何製作 3D 遊戲的人都應該學習如何正確地進行鏡頭切換、廣角鏡頭和蒙太奇。理解焦點與零平面之間的關係。

藝術作品

遊戲的每一個視覺方面都需要某種形式的藝術作品。

動畫

動畫是動態內容的一個例子，它們可能在遊戲中是必要的，用於情節推進或提供背景資訊。製作的複雜程度也可能需要更復雜的員工，作家、導演和動畫師經常被使用。由於電影的使用，使用電影技巧；製作出能夠有效地進行電影觀看的素材將非常重要。

在任何型別的動畫場景中，理解物體是如何移動的，每個身體如何行動以及如何與周圍環境互動都非常重要。

動作捕捉

動作捕捉演員的表演正在成為近年來遊戲中逼真角色動畫的要求，尤其是如果現實主義確實是需求的話。

捕捉演員的互動最好是在即時互動中進行，而不是作為個人表演的整合，這樣互動會更加真實，因為這允許演員以指令碼無法規劃的方式進行創新。通常只有潛意識感知到的自然互動將有助於使場景對玩家更真實。

聲音能力

能夠即時捕捉對話對於賦予場景真實感非常重要，因為語音會根據身體位置以及演員在表演過程中的位置和移動而改變。它還有助於演員充分地進行必要的表演。

多次拍攝

對於動作捕捉表演的導演來說，重要的是讓演員能夠發揮自己的主動性，允許多次拍攝，並且可以自由地超出劇本範圍。這通常會帶來更好、更豐富的解決方案。這可能取決於可用時間和處理材料所需的資源，但在當今的數字世界中，這通常可以在不產生過高成本增加的情況下實現。

3D 圖形

有幾種方法可以生成 3D 計算機圖形來表示 3D 環境中的形狀。瞭解物體將如何被利用以及技術特性和所需的細節水平非常重要。藝術家必須意識到可能存在的任何限制，例如，可能需要降低細節級別以保留資源或僅僅因為它們不需要，每個需求都需要一種獨特的藝術方法。

觀察
在開始對物體進行建模之前，首先需要觀察要建立的物件。必須仔細記錄細節以及如何在軟體中重現這些細節。必須記錄在藝術作品中計劃建立的所有內容。每個部分的重建將是任何軟體中的主要任務。現在記下（在紙上）所需的所有細節將加快在開始使用軟體時的工作速度。

具有 90 度角的事物的表面和角很容易記住，但是近距離觀察可能會有更多細節。對於更復雜的事物，請書寫或繪製有關主題的具體內容。如果你不知道輻條與軸連線相切並在另一側朝相反方向延伸，那麼試圖在不檢視的情況下對腳踏車輪進行建模幾乎是不可能的。

有機物件的曲線通常具有不同程度的銳度。在曲線更銳利的地方，可能需要在建模階段在該區域新增更多細節。曲線的 位置和方向在建模階段也至關重要。

主題的比例對於確認模型看起來準確和真實很重要。它們可以在建模過程中使用，也可以在最終校正後使用。

每個表面/材料都有幾個不同的內在特徵（不依賴於環境），例如

• 顏色
• 紋理
• 反射率
• 透明度

如果在 3D 中複製或建立複雜的場景，正確且一致地使用燈光很重要，請注意

• 光源
• 位置
• 方向
• 擴散

建模
在很好地瞭解如何以及從物件中表示什麼之後，下一步是生成要顯示的物件模型。建立模型有很多不同的方法，每種方法都有其優缺點。為了讓藝術家在這一步驟中更加高效，他們需要了解不同方法及其優缺點。

考慮你的主題，哪種方法最適合這種情況。

多邊形和網格建模理論

在現實生活中，物體是由難以想象數量的原子組成的。計算機難以處理現實生活的複雜性，因此我們需要使用更簡單的東西來對其進行建模。

我們在計算機上可以定義的最簡單的東西是空間中的一個點。（類似地，如果我面前有一張紙，我在上面最容易畫的就是一個點，我只需用鉛筆輕觸紙張即可。）空間中的一個點稱為頂點。

現在考慮這一點。紙上的每個點（或頂點）都有一個編號。我們將我繪製的第一個點稱為頂點 1。如果我繼續繪製更多頂點，我繪製的第二個頂點將被稱為頂點 2，第三個將被稱為頂點 3，依此類推。

一堆點本身對我們來說並沒有什麼用。所以我們將它們連線起來，就像一個連點遊戲。如果我們將其中三個連線起來，並填充中心，我們將得到一個三角形，這是我們可以用頂點建立的最簡單的表面。

如果我們建立額外的三角形（從第一個三角形擴充套件），我們可以建立更復雜的表面。如果我們使用足夠的三角形，可以建立任何表面！

如果兩個三角形彼此相鄰，並且似乎構成物體的側面，我們通常稱它們為多邊形，並將它們視為多邊形，而不是稱它們為兩個三角形。它仍然由兩個三角形組成，但我們只稱它們為多邊形，以使其更容易。

三角形有一些特性，使其易於計算機處理

• 它們由直角構成。三角形由直邊構成，沒有曲線。計算機處理直線很好。它們不輕易處理曲線。這樣想，如果我給你一張紙，上面有兩個點，並說，“在這兩個點之間畫一條直線”，你會確切地知道我的意思。我給的每個人如果按照指示都會畫出相同的線。現在假設我給你同樣的紙，並說，在這兩點之間畫一條彎曲的圓形線。這些都是含糊不清的指示。你不知道我到底想讓你畫什麼。我給每個人的作業都會畫出稍微不同的曲線。為了確保每個人在兩點之間畫出相同的曲線，我需要給出更復雜的指示。

• 它們是平坦的。

• 它們不能自相交。如果你有兩個多邊形，它們可以彼此相交（穿過）。計算機難以處理交點。因此，三角形更容易處理，因為它們不能穿過自身。

多邊形是下一個最簡單的表面。

多邊形就像三角形，但邊數比三條邊多。正方形是一個多邊形。任何多邊形都可以很容易地分解成三角形，所以它仍然相當簡單。多邊形通常是平坦的，或接近平坦。如果兩個三角形形成一個極端的角度（不平坦），那麼我們通常不會稱它們為多邊形。法線的概念

動畫軟體中的每個三角形或多邊形都有一個“法線”。如果一個三角形是一個桌面，它的法線將直接向上指向，遠離表面。法線始終垂直於表面。為了簡化計算機需要完成的工作量，3D 軟體可以執行一種稱為“背面剔除”的操作。剔除表示“不顯示”、“修剪掉”、“忽略”，背面表示面的背面，或多邊形的背面。背面剔除表示不顯示多邊形的背面，只顯示正面，或者更準確地說，法線指向的一側。

示例：普通球體上的法線指向遠離球體中心的點。如果你站在一個巨大的球體外面，看著它，你會看到它。但是，如果你站在球體裡面，你就看不到它。背面剔除將消除球體的內部，因為它的法線不朝向你。

法線由在定義多邊形時對頂點進行計數的順序來定義。無論你在繪製原始三角形或多邊形時是按一個方向繞行還是另一個方向繞行。你不應該擔心這個問題。只需要知道你經常需要“翻轉法線”，這是一個在每個值得信賴的建模軟體包中都可以找到的命令。元素（連續網格）

元素是一個獨特的表面。如果兩個多邊形並排建立，每個多邊形都是用與最後一個不同的頂點建立的，那麼它們被認為是獨立的元素（或不是連續網格）。假設我們有兩個三角形。（圖 1）它們是兩個元素。現在假設我們將它們移到一起，使它們接觸。即使它們看起來像一個，它們仍然被認為是兩個元素。區別在於它們是由不同的頂點定義的。它們不共享任何頂點。為了使它們成為一個元素，我們需要“合併”（或焊接，或摺疊，有時也稱為）這兩個頂點。在三角形看起來相互接觸的每個地方，我們都要確保只有一個頂點。然後這兩個三角形將共享頂點，它們將成為一個元素。通常，建模軟體會在大多數情況下將你的物件保留為一個元素，並在你擴充套件模型表面時自動共享頂點。

與元素沒有連線的多邊形不與其“連續”。這在紙上很難理解。在軟體中工作。

元素在物件中一次選擇多個多邊形組很有用，這些物件中存在多個不同的表面。在 3DSMAX 中，你可以在可編輯網格中選擇元素模式，並選擇元素。在 Maya 中，你可以透過將選擇擴充套件到最遠的地方來選擇元素。

• 頂點 - 一個點，在一個地方。一個頂點非常小。它沒有寬度、長度或高度。它只有一個位置。頂點本身沒有用。與其他東西結合起來才有用。如果我們建立多個頂點，我們可以開始將它們連線起來以建立可見的表面。

• 邊 - 多邊形或三角形的一側。如果你移動一條邊，定義該多邊形或三角形該邊的兩個頂點實際上將被移動。

• 三角形 - 它由 3 個頂點定義。我可以說頂點 1、頂點 2 和頂點 3 構成一個三角形。這將給我一個表面。三角形邊框內的區域也是三角形的一部分。三角形是一個表面。三角形可以渲染，並且會顯示為實體。

• 多邊形 - 多邊形就像三角形，但邊數比三條邊多。多邊形實際上是由多個三角形組成的。通常軟體允許你處理多邊形，而不必擔心三角形。它會自己擔心三角形。你不必單獨定義每個三角形。你只需處理多邊形，通常軟體會自己弄清楚如何處理三角形。對於一些高階建模目的，你可能有一天需要擔心單個三角形，但這並不常見。
  一個三邊多邊形是一個“三角形”，一個四邊多邊形是一個四邊形。結構良好的模型通常應該主要由四邊形組成，幷包含幾個三角形。如果該模型旨在用於細分曲面（一種對模型進行圓角的方法），則它不應包含超過 4 條邊的多邊形。

• 元素（或“連續網格”）- 元素是焊接在一起的多邊形集合。它們彼此共享頂點。

• 法線 - 用於指示多邊形的哪一面是可見的。當背面剔除開啟時，你只能看到法線朝向你的三角形。本質上，三角形的只有一側是可見的。

這些多邊形（或“網格”）模型的元件也定義為 3DSMAX 中的“子物件”和 Maya 中的“元件”。

次表面建模

對於具有對稱細節級別的主題，使用次表面建模是理想的選擇。相反，人臉需要在臉部和耳朵上擁有更多的細節，而在其他地方則需要很少的細節。這種不均勻的細節會使模型的線框看起來雜亂，並使用三角形來彌補面積差異處的接縫。雖然可用，但繼續深入的次表面建模會使模型過於複雜。因此，對臉部的動畫可能會因為所有不可預測的三角形而變得很痛苦。

盒子建模

這種建模過程被認為是最常見的建模新物件的方法之一。在這裡，我們將盒子作為基礎物件，並使用建模工具和技術對形狀進行更改，以完成模型。

細微細節的力量

考慮到對細節的額外關注所蘊藏的力量，它可能讓玩家感到驚歎，這將提高滿意度，並等同於對製作投入的努力的感知。

人類的心智是一件了不起的事情，如果考慮到捕捉它的想象力，一個良好且詳細的環境通常會掩蓋實現中的一些小錯誤。

語音

遊戲中的語音對於推進劇情、介紹新元素甚至作為遊戲玩法的一部分都很重要。大多數遊戲使用數字化語音，如果遊戲模擬現實，則聲音的質量以及與動作的協調性至關重要。一些遊戲未能取悅玩家僅僅是因為配音的質量很差或表現不佳，或者即使同一個配音演員為太多角色配音也是如此。

情緒對人聲的影響

	快樂	悲傷	憤怒	恐懼	厭惡	驚訝
音質	氣聲和沙啞	渾厚	氣聲，帶有胸腔音	不規則和沙啞	咕噥，帶有胸腔音	氣聲和沙啞
發音	正常	含糊不清	緊張	清晰	正常	緊張而清晰
語速	更快或更慢	稍微慢一點	稍微快一點	快得多	慢得多	快得多
強度	更高	更低	更高	正常	更低	更高
音域	寬得多	稍微窄一點	寬得多	寬得多	稍微寬一點	寬得多
音高平均值	高得多	稍微低一點	高得多	高得多	低得多	高得多
音高變化	平滑，向上拐彎	向下拐彎	在重讀音節上突然變化	正常	在結尾拐彎處大幅向下	上升的輪廓

由於遊戲可以面向國際公眾，並且作為減少任何缺陷（如糟糕的聲音再現）的一種方式，字幕在遊戲中也變得很重要。

合成語音

旁註

DECTalk 在 YouTube 上的示例 (計算機演唱“溫柔的謊言” 或 語音合成很棒)。DECTalk 最初是合成語音的硬體實現，後來演變成僅軟體解決方案，其多功能性仍然無與倫比。

合成語音尚未在遊戲中獲得發展動力，主要是因為該領域的質量低和技術進步緩慢。隨著技術的進步，對話可能會變得更加動態，並且更容易適應國際受眾。將這種能力新增到人工智慧角色中也很有趣。

大多數合成語音不會直接落到遊戲美術部門，而是落到程式設計師手中，但任何遊戲的文字或語音部分的指令碼始終需要創意作家。

過程生成

由於大多數過程生成的內容依賴於演算法實現，因此這些例程通常是 遊戲框架 的一部分，這使得它易於在多個遊戲作品中使用。

程式設計

程式設計是將你的概念付諸實踐的方式，是構建遊戲的過程。有各種各樣的 程式語言。這些語言將在後面詳細介紹。

遊戲程式設計師或遊戲開發者負責實現遊戲設計，影片遊戲程式設計的大部分工作都枯燥無味，缺乏創意，除非遊戲設計需要一些創新或更新。但需要注意的是，對於任何開發者來說，特別是那些實現影片遊戲的開發者來說，最糟糕的情況是，從一開始就擁有糟糕的遊戲設計，無法做出決定或對選擇猶豫不決會導致開發者不得不實現糟糕的概念，直到遊戲設計師接受結果（或由於時間/成本限制被迫同意），從而導致產品質量低下。

並非所有開發工作都具有吸引力，在遊戲中，大多數工作都不是，例如，遊戲的正面在大多數遊戲設計中都是很常見的，做一個更多隻是在跳躍。現在，我們以支援顯示卡硬體更改的任務或甚至低階最佳化任務為例，這將是創造性程式設計師的最佳選擇。

學習程式設計

因為這可以說是遊戲設計中最困難的部分，所以我們將花相當多的時間來學習它。如果你對想學習哪種語言有一些想法，並且已經閱讀過各種語言，你應該開始學習。如果你能上一些課程，那就太好了，如果沒有，還有很多其他選擇。購買一些程式設計書籍，在網際網路或華夏公益教科書上查詢一些教程，並檢視開源程式的原始碼。不要以為這會很容易，它並不容易；但要嘗試享受其中。如果你不享受其中，那豈不是失去了整個目的嗎？

一些資源：Google 程式碼，Sourceforge

選擇程式語言

在開始程式設計之前，選擇一種適合您需求的程式語言非常重要。請記住，沒有一種語言適合所有人或所有情況。有如此多的語言可供選擇，以至於選擇一種幾乎是不可能的。在決定學習 Java 或組合語言之前，請確保您知道您要做什麼。遊戲的複雜程度如何？花大量時間和精力學習一種沒有能力製作您計劃的語言將是得不償失的，就像學習一種對您的需求過於複雜的語言一樣。當您開始閱讀有關各種語言的資訊時，您將不可避免地讀到“低階”和“高階”語言。在這個階段，這並不那麼重要，但在以後會非常重要。本質上，低階語言（例如：C++、C、Asm）功能更強大、速度更快，讓您可以控制計算機的內部工作機制。但是，它們通常更難學習。高階語言（例如：BASIC）更容易學習和使用，但缺乏低階語言的功能和靈活性。

聲音

聲音在任何遊戲中都起著不可或缺的作用，因為它在意識和潛意識層面上影響著玩家的情緒！你能想象在沒有聲音的情況下玩 UT 或 Quake 嗎？那將是無法忍受的！遊戲中的聲音（當然取決於遊戲本身）通常包括背景音樂、事件音效（汽車喇叭、槍聲等）和環境音效（腳步聲、風聲、鳥鳴、海浪、蟲鳴、回聲等）。

背景音樂，根據遊戲的不同，可以一直播放，也可以像電影一樣完全停止並改變以適應某些情緒，例如，如果你進入戰鬥，音樂可能會變成節奏更快或更不穩定的曲目。

另一方面，音效會在某些事件觸發時播放。如果玩家要開啟一扇門，可能會發出門吱呀作響的聲音。音效可以為遊戲增添不少真實感，選擇合適的音效可以真正讓遊戲活起來。但是請注意，音效過多，或者音效具有不真實的屬性，會損害遊戲體驗，或者讓玩家感到厭煩。例如，有一個遊戲包含一個噴氣揹包。這個噴氣揹包有無限燃料，所以玩家可以無限期地在空中漂浮。噴氣揹包執行時，會發出像呼嘯的空氣的聲音。隨著時間的推移，這種聲音會變得非常煩人，因為它在遊戲過程中經常被聽到。此外，如果一種聲音具有奇怪的屬性，它可能會減損真實感。例如，發出嘎嘎聲的機槍，或者射擊速度快於實際射擊速度的機槍。

環境音效在玩家進入環境時觸發，並迴圈播放，直到玩家離開。請注意，這些聲音檔案數量最多，有時多個聲音以隨機順序迴圈播放，以營造出環境的多樣感（例如，兩隻唱著完全不同的歌的鳥，或者兩個角色走路時，每個角色的鞋子發出不同的“咔嗒”聲）。

輸入

遊戲通常為玩家提供許多關於輸入的選項。常見的輸入方式包括滑鼠、鍵盤、操縱桿和遊戲手柄。理想情況下，遊戲引擎應該抽象化輸入，以便使用者可以選擇上述任何一種。此外，要記住的一件重要的事情是，所有玩家在按鍵或按鈕放置方面都有不同的偏好，並且通常希望獲得特定的配置。這意味著輸入也應該被抽象化，以允許按鈕或按鍵在遊戲中執行不同的操作。

鍵盤

首先要了解程式解釋鍵盤事件的不同方式。接收鍵盤事件的最常見方式是透過回撥和輪詢。

• 回撥 - 通常由使用 GLUT 庫的遊戲使用，函式指標傳遞給 GLUT，它將該函式“註冊”為鍵盤事件回撥。這意味著，每當按下或釋放一個鍵時，GLUT 都會呼叫相應的函式，傳遞鍵資料，並允許程式做出相應的響應。
• 輪詢 - 更常被使用 SDL 的遊戲使用，如果回撥函式在引擎中破壞了抽象，則輪詢會很有幫助。輪詢是一個過程，遊戲在空閒時間檢查一組鍵盤事件。因此，在遊戲迴圈的每次透過中，您的遊戲都可以輪詢該集合，從而快速響應按鍵事件，並且不會丟失資料。

網路

每個作業系統都有自己的 TCP/IP API，因此，如果您計劃為特定平臺開發遊戲，那麼您必須研究該作業系統的 SDK（例如，Windows API 的 WinSock）。如果您要編寫可移植到多個平臺的遊戲，一個不錯的選擇是SDL_net.

選擇好網路 API 後，應該為遊戲引擎構建封裝套接字的類。您還必須決定使用哪種網路協議，TCP 和 UDP（儘管透過抽象，可以使用任何一種）。

• TCP - 此協議在兩臺計算機之間建立連線。如果存在任何錯誤，在計算機之間傳送的資料會被重新發送。此協議的缺點是，它的整體速度不如 UDP 快。
• UDP - 此協議不建立連線。資料包被髮送到一個地址，傳送方不知道它是否已正確無誤地到達。可以使用 UDP 編寫一個協議來提供錯誤檢查和重新發送。

最終的決定取決於程式設計師，以及什麼最適合遊戲。如果主題是網路象棋遊戲，速度不是主要問題，可以使用 TCP 來避免一些麻煩。但是，對於大型團隊在 FPS 中玩遊戲，UDP 由於速度更快，將是一個更好的選擇。

《Free Fire》是一款非常酷的遊戲，約有 4100 萬人玩這款遊戲。Sea Limited 由 Forrest Li 於 2009 年在新加坡成立，他畢業於上海交通大學和斯坦福商學院。Garena 最初的目標是一家遊戲開發和發行公司，但後來擴充套件成為一家科技巨頭，還提供金融服務和電子商務。2017 年更名為 Sea 後，數字娛樂部門保留了 Garena 的名稱。

同年，《Free Fire》作為一款大逃殺多人遊戲釋出，並迅速獲得了國際上的成功。它是 2019 年全球下載量最高的移動遊戲，並已成為 Garena 的重要收入來源。

2021 年，Garena 釋出了一個圖形增強版《Free Fire Max》，但其收入尚未超過原始版本。根據 AppMagic 的資料，這兩款應用程式是 2022 年下載量最高的射擊遊戲，每款下載量超過 1 億次。

《Free Fire》已成為三大射擊手機遊戲之一，另外兩款是《PUBG Mobile》和《使命召喚：手遊》，此前《堡壘之夜》已於 2020 年 8 月從 App Store 和 Google Play 下架。這三款遊戲在該型別遊戲中獲得了大部分收入，而該型別遊戲的受歡迎程度比其他遊戲子類別下降得更快。

2022 年初，印度禁止了《Free Fire》和其他 53 款被認為對國家安全構成威脅的應用程式；《Free Fire Max》仍然可以在 Google Play 商店中使用。根據 data.ai 的資料，《Free Fire》曾是印度下載量第二高的應用程式，並且擁有最高的消費者支出。雖然 Sea 總部位於新加坡，但其最大股東是中國社交媒體公司騰訊控股。2022 年，《Free Fire》和 Sea 的年收入大幅下降，這在一定程度上歸因於印度的禁令。

自 2019 年以來，《Free Fire》還舉辦了電子競技比賽，其世界系列賽已成為歷史上觀看人數最多的電子競技賽事，2021 年的直播觀看人數達到 540 萬。這些區域賽事在全球範圍內舉行，並提供數百萬美元的獎金。

《Free Fire》被《PUBG Mobile》的開發商 Krafton 指控侵犯版權，該公司於 2022 年 1 月對 Garena 提起訴訟，指控其遊戲道具、機制和外觀存在相似之處。蘋果和谷歌也被列入訴訟中，原因是它們分發了這款遊戲，該訴訟尚未得到解決。

我們收集了關於《Free Fire》的資料和統計資訊。閱讀以下內容以瞭解更多資訊指令碼

以下是遊戲開發中使用的一些免費指令碼引擎

• KonsolScript - 一種免費軟體遊戲指令碼語言
• Lua - Lua 指令碼語言

遊戲工具

這裡列出了一些可用於遊戲開發的免費軟體工具。

• Blender3D - 一個免費且非常先進的建模程式，雖然有點難上手，但功能與任何其他商業建模程式一樣強大。
• OGRE - 一個免費的軟體圖形引擎。頂尖水平。
• Terragen - 一個免費用於非商業用途的地形生成器
• TrueSpace - 專業級 3D 建模、動畫和渲染軟體包，之前售價高達 700 美元，現在微軟收購 Caligari 後可免費下載。

組建和協調團隊

其他

• 計算機遊戲設計藝術
• Sloperama 的遊戲行業建議頁面
• 遊戲設計 Wiki 列表 在 FreeGameDevWiki

選擇硬體

要開發遊戲，您可能不僅需要為特殊任務（如圖形設計師）配備合格的專業人員，還需要考慮編輯軟體（用於建立角色、物品、場景等），以及支援這些任務的物理硬體。例如，圖形設計師可能需要圖形板，您可能還需要掃描器來輸入藝術家手繪的圖片，以及相機。相機可用於拍攝繪製的藝術作品的照片。所有這些額外成本都需要仔細考慮，並且僅取決於專案的級別。

但是，硬體考慮因素不僅限於您將使用的工具，最重要的是執行已完成產品的需求，這不僅會影響目標受眾，還會影響專案的開發。實現遊戲設計的軟體需求可能需要訪問大量記憶體，但每次只能使用有限的記憶體。也可能存在其他限制，例如較弱的 CPU、較弱的處理器快取或非預設記憶體對齊要求。

簡單的解決方法...

沒有花哨的功能，沒有額外成本。如果您選擇一個虛擬框架，例如使用 Flash 作為開發框架，您將無需考慮和支援特殊的硬體或設定，您還將獲得一個 RAD 工具來將您的概念付諸行動。

發行媒介

發行媒介對於確定可以打包多少資源以及如何打包至關重要。

選擇程式語言

原型設計

原型旨在進行探索，探索想法一旦融入完整的程式會如何發揮作用。它是對之前從未見過的全新概念進行測試，因此必須在其實現中具有最大的靈活性，以便於改進，因為原型的建立會激發全新的想法。如果在原型設計階段沒有探索新概念，那麼原型本身還有什麼意義呢？

原型設計應該快速完成，然後需要更快地進行更改。要做到這一點，原型設計必須可維護，並且使用靈活且編寫良好的程式碼庫。但請記住，原型只有在足夠好以證明您的願景正確並被真正的實現所取代時才有用；如果您在原型上花費了太多時間，以至於您開始質疑它的替代，那麼您走錯了路或在應該保持為總體規劃的第一次嘗試上花費了太多精力。

閉源或開源

通用架構問題

遊戲的框架基本上是所有用於建立遊戲但並未直接實現任何遊戲玩法的程式設計。這可以是管理顯示、檔案訪問、聲音和其他外圍裝置的程式碼。

沒有適用於所有影片遊戲的框架。每個遊戲都需要選擇元件以及將它們連結在一起的策略。使用免費提供的框架甚至授權流行的框架的好處是，您無需“重新發明輪子”，並獲得支援和協作來解決問題並擴充套件功能。事實上，建立自己的框架的唯一優勢是能夠對其進行控制，這可能是由於需要實現其他人反對的東西，或者只是為了從這項特定工作中獲得經濟補償並將其授權給其他人。

選擇 API（應用程式程式設計介面）

有許多適用於遊戲程式設計的 API。API 的範圍從專門（僅限圖形，如 OpenGL）到非常非常廣泛（視窗、圖形、網路等在 ClanLib 中可用）

• OpenGL -- 具體來說，這是一個圖形庫。一些其他 API 可以很好地與 OpenGL 整合（例如 SDL）。它也是跨平臺的。

• DirectX -- 一組由 Microsoft 提供的 API，專門用於執行 Windows 的機器，儘管它也存在於其他 Microsoft 平臺上（xbox 1 使用了修改後的 DirectX API 版本）。它們包括聲音、音樂、圖形、輸入和網路。

• SDL（簡單直接媒體層） -- 一個基於 C 的良好庫，可移植性非常高，雖然非常底層，但它已經足夠完整，可以控制聲音、圖形和輸入（來自操縱桿、鍵盤、滑鼠和 CD-ROM）。zlib/png 許可證。

• SFML -- 支援音訊、圖形、視窗處理、多執行緒、網路和輸入（來自滑鼠、鍵盤和操縱桿）的面向物件的 C/C++/.Net API。

• Allegro -- 一個易於使用的 C/C++ 程式庫。跨平臺（支援 Windows、DOS、Mac OS X、UNIX 和 BeOS）。提供用於圖形、聲音、輸入和計時器的函式。

• ClanLib -- 一個 C++ 工具包和 OpenGL 2.0 包裝器。

圖形

圖形是遊戲環境及其元件的視覺呈現的常用名稱。 建立視覺環境通常從概念藝術家開始，根據遊戲概念建立視覺表示，不僅包括遊戲角色和物體，還包括環境的外觀，甚至擴充套件遊戲創造者想象的視覺效果。 這部分工作主要在遊戲之外完成，使用專門用於這些不同任務和資料的第三方軟體。

遊戲的圖形不僅限於遊戲內藝術，還包括字型設計、標誌和營銷目的的廣告。 它們也會對其他型別的商品產生重大影響，例如 T 恤、玩具或其他衍生產品，例如基於遊戲概念的動畫系列甚至真人電影。

視覺

視覺是人類最重要的感官。 展示一款視覺上令人驚歎的產品將勝過吸引玩家和保證初始銷售的大多數其他方面。 我們已經討論過 為什麼有吸引力的展示很重要。

多檢視顯示
由於如今擁有多顯示器設定並不罕見，隨著價格持續下降和影像技術提升，遊戲中的多顯示器支援也將變得普遍。 多顯示器設定也可以輕鬆地將普通檢視擴充套件成馬賽克，而無需遊戲建立者特別考慮，但擁有不同的螢幕對於策略遊戲和模擬遊戲來說非常有趣，因為遊戲玩法通常允許玩家視覺化大量不同的資料。

2D 或 3D

直到最近，大多數現代遊戲似乎都沉浸在 3D 狂潮中，直到手機重新帶來了對更簡單的視覺效果和傳統的 2D 創意和創新的市場。 2D 主要被降級為模擬器和舊遊戲模型的重新實現。

在 3D 的初始進步和良好 3D 硬體的開發之後，3D 很快開始成為一種主要用於營銷噱頭、賣點以及用良好的視覺效果隱藏遊戲概念的脆弱性的一種方式，其中效能或視覺真實感取得的每一寸進步都被吹捧為一項革命性的必須看到的發現。 請記住我們之前關於展示的內容，這主要是它的使用方法。 大多數遊戲不知道如何以補充遊戲玩法和遊戲設計的方式使用它。

一款優秀的 3D 遊戲使用動態的場景和環境組合，就像電影一樣，其目的是展示遊戲設計並激發玩家的想象力，但對遊戲玩法始終保持敬畏。

圖形引擎

遊戲引擎應該使用更原始的環境和模型進行除錯和測試，特別是對於遊戲機。 遊戲稱為圖形引擎的東西用於操縱遊戲動畫指令碼、角色在環境中的位置以及圖形渲染的記憶體分配。 其他資料，例如物理、AI 和遊戲指令碼，由其他引擎處理。 公眾普遍存在一個誤解，即遊戲僅使用一個“引擎”製作而成。

3D 圖形

超越 3D

立體檢視
雖然大多數遊戲引擎僅打算模擬深度和與其他圖形偽影不同的深度環境，但真正的 3D 直到最近才在遊戲中流行起來。 有一些技術可以生成和顯示 3D 動態影像。 核心要求是顯示分別過濾到左眼和右眼的偏移影像，從而為觀察到的場景提供獨立的焦點，從而提供深度。 已經使用了兩種策略來實現這一點：讓觀看者戴上眼鏡來分別過濾偏移影像到每隻眼睛，或者讓光源將影像方向性地分成觀看者的眼睛（不需要眼鏡）。 到目前為止，問題在於 CPU 或顯示卡生成所需的類似但不同的影像，以及生成這些檢視的軟體，GPU 的興起以及 3D 電視的採用最終允許普遍使用這種 3D 檢視，即使沒有大量的遊戲實現。

超越多邊形
在科學和醫學領域，由於其允許使用成像裝置（磁性、雷射）獲得高細節，點雲資料的概念開始變得重要。 一家澳大利亞公司 Euclideon 聲稱使用點而不是多邊形來渲染 3D 場景，從而在基於稀疏體素八叉樹圖形的基礎上提高了可能的細節水平。 其他一些公司也在研究這種技術，例如 Atomontage Engine（混合方法）或 Ken Silverman（他還編寫了 Build 引擎，用於 Duke Nukem 3D）的 Voxlap 引擎。

使用者介面

使用者介面 (UI) 是任何遊戲的非常重要的組成部分，因為這通常是新玩家在啟動你的遊戲時看到的第一件事。 它也（在大多數遊戲中）始終對玩家可見，因此明智的做法是花一些時間建立一個直觀、易於使用且外觀良好的介面！ 沒有什麼比設計糟糕的介面更能讓人對一款潛在的優秀遊戲感到厭煩了。

使用者介面包含

• 圖形 - 按鈕、資訊面板、地圖等）
• 佈局 - 這些內容在螢幕上的位置
• 互動 - 這些內容如何響應使用者輸入；它們會調出地圖嗎？你的庫存？訪問設定？

2D 和 3D

UI 可以以 2D 或 3D 方式渲染，介面本身在大多數情況下獨立於遊戲引擎，充其量它充當玩家與遊戲世界的 I/O 介面。 UI 上渲染的許多基元不會出現在遊戲引擎中，特別是如果你依賴打包的引擎。

2D 遊戲可以有 3D UI，3D 遊戲也可以有 2D UI。選擇取決於設計和呈現方式。需要注意的是，從計算角度來看，3D UI 會佔用更多遊戲資源，而且花哨的 UI 往往只對初次接觸遊戲的人有影響，如果 UI 與遊戲玩法沒有更深入的整合，這種影響很快就會消失。UI 不應該喧賓奪主，最好是實用且資訊豐富。

打包解決方案

商業

• Autodesk Scaleform (http://www.scaleform.com/) - 一個向量圖形渲染引擎，用於在影片遊戲行業中作為中介軟體顯示基於 Adobe Flash 的使用者介面。HUD 和動畫紋理，適用於 Microsoft Windows、Mac OS X、Linux 以及 Xbox 360、PlayStation 2、PlayStation Portable、PlayStation 3、PSVITA、3DS、Wii、iOS 和 Android 平臺。

人工智慧 (AI)

人工智慧讓你的遊戲世界變得生動起來，讓遊戲中的生物擁有自己的思維。AI 還允許遊戲難度發生變化，可以由使用者選擇自己的難度級別，也可以由遊戲根據玩家的技能水平自動調整。在遊戲中實現 AI 的方法有很多。

• 人工智慧

有限狀態機

《毀滅戰士》中使用了一種非常簡單的 AI 型別。有限狀態機包含一個可能狀態（或“情緒”）列表。假設有一個遊戲中有警衛在房間裡巡邏，尋找入侵者。
假設這些警衛有五個狀態

• 巡邏 - 警衛沿著分配給他的路線行走
• 等待或閒置 - 警衛站在某個地方，可能在和附近另一個警衛聊天，抽菸等。
• 可疑 - 警衛聽到了一些聲音，認為附近有什麼東西（例如：警衛聽到玩家從懸崖上踢下了一塊石頭）。
• 警覺 - 警衛明顯地看到了你，正在攻擊你，或者可能正在呼喊求救。
• 受傷/遇險 - 你傷到了警衛，但警衛還活著，正在逃跑求救。

這些狀態將有與警衛的“情緒”相一致的特定動作。巡邏將啟用航點系統，警覺將意味著你激活了 AI 的目標系統。

程式內容生成

這個概念被定義為以程式方式生成任何型別的 2D/3D 幾何圖形、紋理、指令碼或聲音的過程，甚至可以使用隨機種子。迄今為止，這種技術主要用於建立環境、簡單的世界或結構。這種方法也可以應用於許多其他內容，使用嚴格的定義，它可以與 AI 協同工作（動態環境、物體和生物），但它仍然難以像傳統動畫一樣可靠且逼真，即使它可以提供更大的可變性和複製人聲，它仍然處於起步階段。

除非為了互動性或隨機化而存在好處，否則應該避免程式內容生成，因為它在 CPU 週期方面很昂貴，並且通常實施起來很複雜。例外情況是重複但簡單的模式，即使沒有互動性也可以，例如在模擬水、雨的效應，甚至顯示雲、煙霧、火焰或爆炸時。程式內容生成的另一個不太重要的因素是最終產品中的空間（大小）限制，由於要使用的媒體或下載的大小。

物理

在建立遊戲時，有一些功能可以幫助玩家輕鬆地與建立的虛擬環境進行互動。如果模擬真實的環境，這一點非常重要，因為人們期望遊戲是真實的，從物體的軌跡到它們的碰撞方式、質量的感覺以及流體的行為方式以及其他類似的行為，所有這些都可以根據現實世界中也有效的公認公式進行建模。

液體

• 表面張力
• 粘度

現實主義（現實模擬）

動畫

新增細節

讓遊戲包含小的，即使是重複的細節，也會提供更豐富的體驗，無論是陣陣風聲，一粒塵埃，垃圾桶上的蒼蠅，一片隨風飄落的樹葉，都能像動態光照那樣強大，甚至更強大。

水

水可能是遊戲中最難再現的效果，它包含反射、透明和扭曲，像波浪、泡沫一樣的高細節，而且是一種流體，表現得像固體和液體一樣，所以根據想要達到的細節程度，這將不僅僅是一項艱鉅的任務，如果即時完成，還會消耗大量的計算能力。

聲音

對於我們引擎的這部分，我們將使用 OpenAL API。為什麼？因為在選擇 API 時，我們已經概述了以下簡單的原因：它是開源的、跨平臺的、功能強大的，同時仍然相對易於使用。所以讓我們開始吧……

在我們的遊戲世界中，所有可以發出聲音的物件都有一個位置（背景音樂除外）。聲音還與某種觸發事件相關聯，因此當玩家執行某些操作來啟用觸發器時，聲音就會開始播放。很簡單吧！那麼我們現在究竟如何實現這一點呢？

OpenAL 基於擁有一個源（播放的聲音）和一個監聽器（聆聽的人）的概念，這兩個物件可以放置在我們 3D 環境中的任何地方，並賦予某些屬性，例如使用哪種衰減模型、源的移動速度等，但我們稍後會講到這些。你還可以擁有許多源（這是有道理的），但只有一個監聽器（這也是有道理的）。當你新增一個聲音供 OpenAL 播放時，你首先需要做三件事：建立一個緩衝區，用來載入音訊資料到其中，然後建立一個源，然後將源與緩衝區關聯起來，這樣 OpenAL 就能知道從哪個源播放哪個音訊。因此，考慮到所有這些因素，我們將把每個源封裝到一個 C++ 結構體中。這個結構體，我們將其命名為 newSource，將儲存源的位置資訊作為 sourcePos[3]，一個 sourceID 和一個 bufferID，以便我們可以唯一地定址每個源。

我們還需要考慮的是，由於 OpenAL 很樂意根據距離為我們衰減聲音，我們需要在玩家到達源的“外邊界”（你不再能聽到聲音播放的點）時開始播放聲音。因此，我們還會在結構體中新增一個 activateDistance 值。

此外，我們需要考慮到，由於聲音資料無法從硬碟中立即載入，因為與記憶體相比，硬碟的速度非常慢。因此，我們還會在結構體中新增一個 preloadDistance 值，這樣當我們移動到該值的範圍內時，聲音就會載入到緩衝區中，當我們移動到 activateDistance 值的範圍內時，聲音就會開始播放。真棒吧！

最後，由於我們很有可能會有不止一個源（如果沒有的話遊戲會很無聊），我們將把我們的結構體塞進一個 C++ 向量中（如果你不知道什麼是向量，它只是一個數組，但功能更多），我們將將其命名為 pipeline。我們還需要新增一些功能來從管道中刪除“死”源並釋放記憶體，但我們稍後會講到這一點。

為了說明所有這些是如何組合在一起的。

這個示例說明了 preloadDistance、activateDistance 和 sourcePos 在“遊戲內”檢視中的位置。

因此，概述一下這個過程：

• 當玩家移動到紅色外球的範圍內時，就會建立一個新的 newSource 結構體，聲音載入到緩衝區中並被推送到 pipeline 中。

• 當玩家移動到黃色球的範圍內時，聲音就會開始播放，當玩家向白色內球靠近時，聲音會越來越大，直到在白色球處達到最大音量。

• 反之，當玩家離開白色球時，聲音的音量會降低，直到你移動到黃色球的外面，此時聲音會關閉，但仍然保留在 pipeline 中。

• 當玩家離開紅色球時，源就會從 pipeline 中刪除並銷燬（剔除），這樣我們就可以避免佔用不必要的記憶體。

雖然存在多種型別的電子遊戲，但有一些屬性是恆定不變的：每個遊戲都需要至少一名玩家，每個遊戲都會給玩家至少一項挑戰，每個遊戲都使用顯示器，每個遊戲都至少有一種輸入/控制方法。

使用者介面

正如本章開頭所述，使用者介面由精靈、選單等組成。它是提供給使用者用來控制遊戲內操作的東西。這些圖形被定義為按鈕，可以被按下，或者是一個角色，可以用箭頭鍵移動。所有這些元素都是使用者介面的一部分。

主選單

首先，幾乎所有電子遊戲都會啟動到主選單。這通常是一個帶有某種背景的螢幕，上面排列著一些按鈕，用於執行諸如新遊戲或開始遊戲、選項、載入遊戲和退出遊戲之類的操作。

此螢幕充當遊戲的控制面板，允許玩家更改設定、選擇模式或訪問實際遊戲。

有時，遊戲會使用主選單作為遊戲內選單。遊戲內選單通常在遊戲過程中透過Esc 鍵或開始按鈕訪問。遊戲內選單允許玩家訪問大多數主選單操作，並提供其他操作，例如顯示角色屬性、點數、庫存等。不過，並非所有選單都必須是帶有文字的正方形。遊戲 聖劍傳說 使用了一個創造性的選單，在該選單中，關卡保持在焦點位置，而選擇項圍繞著玩家形成一個圓圈。

這些選單不是必需的，但傳統上會包含它們。

開始遊戲

當你第一次啟動遊戲時，會顯示一系列啟動畫面。啟動畫面包含諸如徽標、電影等元素。這通常用於告訴玩家哪些公司直接參與了遊戲，有時還會部分或全部介紹遊戲劇情。

當實際遊戲開始時，通常會播放一個介紹性的電影，介紹劇情的序幕。這不是你在電影院看到的電影，而是通常是使用遊戲自身圖形和聲音製作的更精美渲染。

在大多數遊戲中，你接下來會被要求輸入你的名字，在某些遊戲中，你可以自定義角色、設定等。

遊戲的這個階段被稱為教程。它並不總是被認為是遊戲劇情的一部分，但在某些遊戲中，它被整合到遊戲中，即使是教程階段，它也是遊戲劇情的一部分。我們將稱之為教程整合。它廣泛用於諸如 塞爾達傳說 和 超級馬里奧 64 等遊戲中。

玩遊戲

在遊戲過程中，幾乎所有遊戲都會使用一些基本概念。它們列在下面。

玩家與角色的關係

玩家在角色中的作用。玩家如何控制角色？通常有 3 種 PCR，第 3 人稱、第 1 人稱和影響。

第 3 人稱：玩家不是角色，而是以非人物化的方式控制角色/角色。

第 1 人稱：玩家就是角色/角色，並從角色的角度以個人和視覺方式看待事物。

影響：玩家不受限於任何角色/角色，而只是在遊戲中發揮影響力。這在像俄羅斯方塊這樣的益智遊戲中很常見，在 RTS 遊戲中也很常見。

遊戲世界

遊戲描繪的“世界”是什麼？這裡有兩個需要考慮的問題。

角色作用：角色在遊戲本身中扮演什麼角色也是一個問題，從這個意義上講，有三種類型。

主角：一切都圍繞著角色/角色，拯救世界的型別。在《塞爾達傳說》、《馬里奧》、《最終幻想》等遊戲中可見。

街機傳統：一個非人物化的街機角色。

影響力：角色是遊戲中一個無名的影響力。

---

法則 定義領域的法律、概念、規則等是什麼？

圖形 什麼是可見的以及風格法則

聲音 什麼是可聽見的以及風格法則

遊戲性 如何玩遊戲

儲存/載入

考慮到遊戲的儲存和載入，通常這可以是一個基本的選單操作，玩家在其中輸入儲存名稱，然後遊戲就會儲存。但在某些遊戲中，採用了更具創意的方法，這樣玩家就不會被從遊戲體驗中拉出來。《銀河戰士》就是用它的存檔點來實現這一點。

然而，載入通常是一個選單操作。

主迴圈

我們遊戲的核心是主迴圈（或遊戲迴圈）。與大多數互動式程式一樣，我們的遊戲會一直執行，直到我們告訴它停止。每次迴圈就像遊戲的心跳。即時遊戲的迴圈通常與影片更新（垂直同步）繫結。如果我們的主迴圈與固定時間硬體事件（如垂直同步）同步，那麼我們必須將每次更新呼叫的總處理時間控制在該時間間隔內，否則遊戲將“卡頓”。

// a simple game loop in C++

int main( int argc, char* argv[] )
{
    game our_game;
    while ( our_game.is_running())
    {
        our_game.update();
    }
    return our_game.exit_code();
}

每個主機制造商都有自己的影片遊戲釋出標準，但大多數要求遊戲在啟動後的幾秒鐘內提供視覺反饋。作為一般設計準則，最好儘快為玩家提供反饋。

因此，大多數啟動和關閉程式碼通常從主迴圈中處理。冗長的啟動和關閉程式碼可以在從主 update() 函式監控的子執行緒中執行，或者切分成小塊，並按照順序從 update() 函式本身執行。

狀態機

即使不考慮遊戲本身的各種遊戲模式，大多數遊戲程式碼也屬於幾種狀態之一。遊戲可能包含以下狀態和子狀態

• 啟動
• 許可證
• 開場動畫
• 前端
  • 遊戲選項
  • 聲音選項
  • 影片選項
• 載入螢幕
• 主遊戲
  • 簡介
  • 遊戲
    • 遊戲模式
  • 暫停選項
• 結束遊戲動畫
• 片尾
• 關閉

在程式碼中對這種模型的一種方法是使用狀態機

class state
{
public:
    virtual void enter( void )= 0;
    virtual void update( void )= 0;
    virtual void leave( void )= 0;
};

派生類可以覆蓋這些虛擬函式，以提供特定於狀態的程式碼。然後，主遊戲物件可以儲存一個指向當前狀態的指標，並允許遊戲從一個狀態流向另一個狀態。

extern state* shut_down;

class game
{
    state* current_state;
public:
    game( state* initial_state ): current_state( initial_state )
    {
        current_state->enter();
    }

    ~game()
    {
        current_state->leave();
    }

    void change_state( state* new_state )
    {
        current_state->leave();
        current_state= new_state;
        current_state->enter();
    }

    void update( void )
    {
        current_state->update();
    }

    bool is_running( void ) const
    {
        return current_state != shut_down;
    }
};

時間

遊戲迴圈必須同時考慮實際時間和遊戲時間的流逝。將兩者分開可以使慢動作（即子彈時間）效果、暫停狀態和除錯變得更加容易。如果你打算製作一款可以倒流時間的遊戲，比如《布林克斯》或《時間沙漏》，你需要能夠在遊戲時間倒流的同時，讓遊戲迴圈向前執行。

圍繞時間的另一個考慮因素取決於你是否要採用固定幀率或可變幀率。固定幀率可以簡化遊戲中的許多數學運算和時間計算，但它們會使遊戲更難移植到其他地區（例如，從美國 60 Hz 電視機移植到歐洲 50 Hz 電視機）。因此，建議將幀時間作為變數傳遞，即使該值從未改變。當每幀的工作負載達到極限時，固定幀率會受到卡頓的影響，這比較低的幀率感覺更差。

另一方面，可變幀率會自動補償不同的電視重新整理率。但與固定幀率遊戲相比，可變幀率往往感覺很卡。除錯，特別是除錯時間和物理問題，在可變時間下通常更困難。在程式碼中實現時間計時時，給定平臺上通常有幾種可用的硬體計時器，它們通常具有不同的解析度、訪問它們的開銷和延遲。請特別注意可用的即時時鐘。你必須使用解析度足夠高的時鐘，同時不要使用過高的精度。你可能需要處理時鐘迴繞的情況（例如，一個 32 位納秒計時器將在 2^32 納秒後溢位回零，這隻有 4.2949673 秒）。

const float game::NTSC_interval= 1.f / 59.94f;
const float game::PAL_interval=  1.f / 50.f;

float game::frame_interval( void )
{
    if ( time_system() == FIXED_RATE )
    {
        if ( region() == NTSC )
        {
            return NTSC_interval;
        }
        else
        {
            return PAL_interval;
        }
    }
    else
    {
        float current_time= get_system_time();
        float interval= current_time - last_time;
        last_time= current_time;
        if ( interval < 0.f || interval > MAX_interval )
        {
            return MAX_interval;
        }
        else
        {
            return interval;
        }
    }
}

void game::update( void )
{
    current_state->update( frame_interval());
}

載入

現代遊戲通常直接從 CD 載入，或者間接從硬碟載入。無論哪種方式，你的遊戲都可能花費大量時間進行 I/O 訪問。磁碟訪問，尤其是 CD 和 DVD 訪問，比遊戲的其他部分慢得多。許多主機制造商將其作為一項標準，即所有磁碟訪問必須以視覺方式指示；而無論如何，這也不失為一個好的設計選擇。

但是，大多數磁碟訪問 API 函式（特別是那些透過 C 執行時庫的標準 I/O 對映的函式）會使處理器停滯，直到傳輸完成。這被稱為同步訪問。

多執行緒磁碟訪問

在訪問磁碟時獲得反饋的一種方法是在單獨的執行緒中執行磁碟操作。這具有允許其他處理繼續進行的優點，包括繪製磁碟操作的一些視覺反饋。但代價是需要編寫更多程式碼，並且需要同步對資源的訪問。

非同步磁碟訪問

一些主機作業系統 API 透過允許使用非同步讀取操作來排程磁碟訪問，從而為你處理了一些多執行緒程式碼。非同步讀取可以透過輪詢檔案控制代碼或使用回撥來確定它們是否已完成。

可渲染物件

無論遊戲使用 2D 圖形、3D 圖形還是兩者的組合，引擎都應該以類似的方式處理它們。需要考慮三個主要方面。

1. 某些物件可能需要一段時間才能載入，並且可能會暫時凍結遊戲。
2. 有些機器比其他機器執行速度更慢，遊戲必須以低幀率繼續進行。
3. 有些機器執行速度更快，動畫可能會比具有較高幀率的時間間隔更流暢。

因此，建立一個作為介面的基類是一個好主意，它將這些函式分開。這樣，每個可繪製物件都可以以相同的方式處理，所有載入都可以同時進行（用於載入螢幕），所有繪製都可以獨立於時間間隔進行。OpenGL 還要求物件顯示列表具有唯一的整數識別符號，因此我們還需要支援分配該值。

class IDrawable
{
public:
    virtual void load( void ) {};
    virtual void draw( void ) {};
    virtual void step( void ) {};

    int listID()            {return m_list_id;}
    void setListID(int id)  {m_list_id = id;}
protected:
    int m_list_id;
};

包圍盒

一種常見的碰撞檢測方法是使用軸對齊邊界框。為了實現這一點，我們將基於我們之前的介面 IDrawable。它應該與 IDrawable 保持分離，因為畢竟，並非螢幕上繪製的每個物件都需要碰撞檢測。一個 3D 框應該由六個值定義：x、y、z、寬度、高度和深度。該框還應該返回物件在空間中的當前最小值和最大值。這是一個示例 3D 邊界框類

class IBox : public IDrawable {
    public:
        IBox();
        IBox(CVector loc, CVector size);
        ~IBox();
        float X()	{return m_loc.X();}
        float XMin()	{return m_loc.X() - m_width / 2.;}
        float XMax()	{return m_loc.X() + m_width / 2.;}
        float Y()	{return m_loc.Y();}
        float YMin()	{return m_loc.Y() - m_height / 2.;}
        float YMax()	{return m_loc.Y() + m_height / 2.;}
        float Z()	{return m_loc.Z();}
        float ZMin()	{return m_loc.Z() - m_depth / 2.;}
        float ZMax()	{return m_loc.Z() + m_depth / 2.;}
    protected:
        float m_x, m_y, m_z;
        float m_width, m_height, m_depth;
};

IBox::IBox() {
	m_x = m_y = m_z = 0;
	m_width = m_height = m_depth = 0;
}

IBox::IBox(CVector loc, CVector size) {
	m_x      = loc.X();
	m_y      = loc.Y();
	m_z      = loc.Z();
	m_width  = size.X();
	m_height = size.Y();
	m_depth  = size.Z();
}

製作你自己的遊戲引擎

複雜性

雖然在大多數 API 中顯示影像或紋理立方體很簡單，但隨著你開始為你的遊戲新增更多複雜性，任務自然會變得稍微困難一些。對於結構不良的引擎，這種複雜性會隨著你的引擎變大而變得越來越明顯。它可能變得不清楚需要哪些更改，你可能會最終得到巨大的特殊情況 switch 塊，而一些簡單的抽象可能會簡化問題。

可擴充套件性

這與上面的觀點相關聯 - 隨著你的遊戲引擎發展，你將希望新增新功能。對於無結構的引擎，這些新功能很難新增，並且可能花費大量時間來找出為什麼該功能無法按預期工作。也許是某些奇怪的函式正在中斷它。精心設計的引擎將任務分開，以便擴充套件特定區域就是那樣 - 而不是必須修改之前的程式碼。

瞭解你的程式碼

透過精心設計的遊戲引擎設計，你將開始瞭解你的程式碼。你會發現自己花更少的時間盯著（或者可能詛咒）空白螢幕，想知道為什麼你的程式碼沒有做你認為你告訴它的。

DRY 程式碼

DRY 是一個經常使用（尤其是在極限程式設計環境中）的縮寫詞，它代表*不要重複自己*。聽起來很簡單，但可以為你節省更多時間去做其他事情。此外，執行特定任務的程式碼位於一箇中心位置，這樣你就可以修改該小部分並看到你的更改在所有地方生效。

事實上，這是常識

上面的觀點可能對你來說並不那麼令人難以置信 - 它們確實是常識。但如果沒有設計遊戲引擎時的思考和規劃，你會發現實現這些目標會困難得多。