文章內容不涉及程式碼，儘量用最簡單的語言來講程式設計師敲的一行行程式碼怎麼變成遊戲的。

做一個遊戲，就像建一個房子。

本來想要什麼「面向物件」之類的語言來描述的，但想到讀者可能不懂程式設計，那麼找個比喻吧。建房子應該很多人知道吧，就算沒動手建過也看別人建過，畢竟走出去，哪裡不是在施工？

假設你現在建房子，有6個步驟：

1. 選址

你要找個風水好的地方，坐北朝南，這樣你的房子才更舒適。

換成遊戲，就是你要選個玩家喜歡玩的，做好市場調研。當然，這一步還沒涉及程式碼。

2.設計方案

你要建房子，那麼你得確定：你是用什麼結構，做複式還是多層，用什麼磚塊，請多少人。

換成遊戲，就是你要做什麼功能和玩法，用什麼遊戲引擎，什麼語言，等等。

3. 施工隊打地基

建房子當然免不了打地基，這樣房子才能穩固。

而對於遊戲而言，就是底層程式碼。

什麼是程式碼？程式碼就是告訴計算機如何做的指令。高層程式碼和底層程式碼有啥不同？高層程式碼更直觀，且高層程式碼的實現依賴底層程式碼。

這裡再舉一個例子。例如某個公司需要完成一個任務，老闆吩咐銷售部總監，這個月完成500萬的銷售額，這就是「高層程式碼」；而銷售部總監把銷售額分給小黃150萬、小李200萬、小趙200萬，這就是「中間層程式碼」，而小黃計算手上有幾個在談的客戶，每個客戶預計成交額多少，還需要發展多少個新客戶才能目標，這就是「底層程式碼」。甚至還可以計算今天工作8小時，能拜訪到幾個客戶，怎麼走能拜訪最多客戶（更底層演算法，我們可以稱之為路徑最佳化演算法）。

換成遊戲，就是這樣的：你需要確定物理效果（例如計算拋物線路徑），渲染（透過計算，例如計算光的入射角出射角，確定在xx位置畫xx）這種最底層的東西，確定怎麼收發訊息（如何加密，什麼傳送格式）等等。當然，多數遊戲引擎都已經幫你做好這些了，例如Unity，你可以直接拖拽已經寫好的物理元件到某個物體上，當你給這個物體一個初速度，他就按照物理規律運動，沒啥難的，就是把中學時各種 等應用上去就是了。

這裡嘗試用虛擬碼來講解下高層和底層程式碼：

高層程式碼：這裡寫了一個「高層程式碼」，我相信你沒程式設計經驗也能懂吧，這裡實現了跳到下一關的功能，就是移除當前場景，然後載入新場景。

Function JumpToNextLevel():

remove(scene)

load(newscene)

底層程式碼：載入新場景這個功能怎麼實現了，這就需要再往下一層了。

Function load(resource):

try:

f = file.open(resource)

while f.notEnd():

encoder.encode(f.readNextline())

catch FileNotFoundError:

f = file.open(backup_resource)

可以看到，載入場景的「底層程式碼」就可讀性變差了，這段程式碼想表達的是，載入場景需要逐行載入配置檔案，直到最後一行，每一行再透過轉碼器，轉成場景的效果。如果找不到資源，就讀備用資源。

懂程式設計的不用糾結這是什麼語言，我為了好懂，揉和了幾個程式語言的關鍵詞。

4. 鋼筋水泥框架

有了地基，我們就可以在這基礎上開始蓋房子了。我們會建起柱和梁，這時候還沒外牆和爛尾樓差不多。

同理，在開發遊戲時，我們需要建立一個開發框架。遊戲引擎不是開發框架，開發框架包括程式碼規範，思想架構（例如Model View Controller）。

為什麼要統一開發框架？你想想，建房子時，一個柱子長，一個柱子短，是不是會出現隱患？

統一標準，是為了讓任務能讓任意一個人快速上手。開發遊戲多數情況下，都是多人合作的。

再具體點，就是根據業務，定義基類，介面等等。什麼是基類，介面？基類就大概是預先備好的菜，你只需要直接用，就能實現新的菜式，例如你買了已經切好快的雞肉，你可以用雞肉做姜蔥雞，也可以做豉油雞。

而介面，就是定義了一些步驟，但步驟的實現需要自定義。大概就是給了你個菜譜，告訴你步驟，例如做姜蔥雞，你需要買雞，姜蔥，但你買清遠雞還是海南雞，山東大蔥還是東北大蔥， 你自己決定。

5. 砌牆

就好像建房子時砌牆的任務比較枯燥但有章可循，寫遊戲程式碼時也一樣。根據上一個步驟定義好的框架，往裡面填充內容。

例如在上一個步驟裡，我們定義了一些基類，介面，那麼我們得用起來。又如遊戲裡的角色，我們可以根據其共性，可以在基類裡定義一些功能，如walk, run等等。

然後我們建立新角色時，就不需要再每次都寫walk,run功能，而且還能新增新功能。例如建立一個英雄角色，這個英雄不僅能走能跑，還能飛，而我僅僅需要給英雄寫一個飛的功能，走和跑的功能直接用基類定義好的。

6.貼瓷磚

這個就很直觀了，就是給遊戲換上好看的UI。

我們做遊戲時，技術組和美術組是平行工作的，我們不可能等到美術把UI畫好了才開始開發，但有時候我們需要UI才能測試功能。因此我們一般會自己隨便繪製一個線框圖一樣的UI，等美術畫了個好看的，再換上去。

例如，我們開發時可能用這種的UI：

等美術資源畫好了，我們就用這種UI：

這個過程和貼瓷磚很像吧。

結合建房子流程，總結一下游戲開發流程。

寫程式碼和建房子的不同點：

畢竟要找個完全符合遊戲開發的比喻不容易，所以用了房子的比喻。但這裡必須指出，寫程式碼和建房子還是有不同之處的。

建房子時，步驟1-6必須按順序。你發現地基有問題，糟糕，得推到重來。

在寫遊戲程式碼時，步驟1-6總體來說是按順序，但並不是嚴格按順序的。

例如我在第5步砌牆（也就是開發具體功能時），發現某個角色動作不自然，然後查到是物理引擎計算問題，還可以返回第3步修改，並不需要推到重來。遊戲是軟資產，可以「迭代」。

寫程式碼的難度在哪裡呢？

複雜度。前面的虛擬碼才幾行，就略顯複雜了，而我們做一個MOBA遊戲，大概寫了幾十萬行吧程式碼。這個複雜度沒有很好的工程實踐，會失控的。

層級依賴性。有時候你寫的程式碼不行，並不是你的邏輯不對，而是你用的「基類」出問題。就好像你煮了姜蔥雞吃了拉肚子，並不一定是你煮得不好，可能是雞本身變質了。

需求變更。這是我認為最大的挑戰。需求變更可能會導致之前設計的功能，框架不好用，所以在設計框架程式碼之初，需要考慮到未來可能的需求變更。這就是為啥有經驗的遊戲主程如此高薪，因為他們見過太多變更，能設計出相容性強的邏輯。