【程式設計師的遊戲開發之路】 遊戲架構

啊啊啊啊今天去面了鵝廠，結果在實習公司Unity用得太多了，好多基礎都忘得差不多了，看起來要撿起來好好再學習一下O(∩_∩)O莫要放棄，就從遊戲架構開始學起哈。
參考的書是《 遊戲程式設計權威指南 》

遊戲整體架構

總體來說，遊戲中的所有子系統屬於以下的3個主要類別之一：
1.應用層
應用層關注的是遊戲執行的機器，如果將遊戲移植到別的平臺，則需要重新寫很多應用層的程式碼，但不需要修改其他的部分。這個模組中包含處理硬體裝置的程式碼、操作體統服務（網路通訊或執行緒）和操作（如遊戲的初始化和關閉）

2.遊戲邏輯
遊戲邏輯層就是遊戲，他與遊戲執行的機器和顯示方式完全無關。在理想情況下，修改遊戲邏輯相關程式碼，它依然可以在所有之前支援的平臺或作業系統中執行。在這個模組中，你會發現管理遊戲狀態的子系統，將狀態變化傳送給其他系統的子系統和從其他系統中接受輸入命令的子系統。還包括執行遊戲世界規則的系統。其中一個示例是物理系統，它用於管理遊戲物件互動和互動的過程。

3.遊戲檢視
該系統負責顯示遊戲的狀態，並將輸入轉換為可以傳送給遊戲邏輯的遊戲命令。它可以擁有不同的實現，連線到遊戲中的檢視數可能與電腦處理的檢視數相同。有多種遊戲試圖①針對玩家的，它會繪製螢幕上的遊戲狀態，將音訊傳送到聲音輸出裝置 ②針對人工智慧代理的 ③針對網路中的遠端玩家。
（其實我看到遊戲檢視這裡沒懂，看後面的吧）

舉例：
假設我們需要做一個賽車遊戲：
對於遊戲邏輯來說：①輸入就是轉向、加速度、制動、緊急制動等 ②輸出則是狀態變化和事件，包括車的位置和方向等等。 事件和狀態將被髮送到遊戲檢視。

遊戲檢視則要做很多工作來傳遞給玩家很多資訊，比如說影像、聲音、粒子效果等。同時它還要讀取遊戲控制器的狀態，並將其轉換為邏輯命令，然後傳送給遊戲邏輯。

應用層見下面

應用層

1.讀取輸入

多種使用者輸入裝置，例如鍵盤、滑鼠、遊戲手柄等，讀取這些裝置基本完全依賴於對作業系統和裝置驅動的呼叫。總是將這些裝置的狀態轉化為遊戲命令，其中一些會發給遊戲邏輯，而另一些會給遊戲檢視。在讀取使用者輸入時，最好不要直接修改遊戲資料，這樣系統的可維護性是很差的，會成為系統的負擔。

2.檔案系統和資源快取

檔案系統是從儲存系統中讀取資料，並將資料寫入儲存系統中。該之系統常常負責管理遊戲原始檔、載入和儲存遊戲狀態。
資源快取是以某種方式管理素材，讓遊戲誤以為它們一直存在於記憶體中，如果一切順利的話，遊戲永遠無需等待，因為資源快取能足夠聰明能預測出將使用哪些素材並提前載入他們。但是它時常會算錯，導致快取未命中，可能會導致遊戲的卡頓等。

3.記憶體管理

記憶體管理是遊戲中很重要的系統。遊戲中的很多資料結構都是相對較小的內容，並且他們屬於不同的區域，例如RAM或視訊記憶體。所以要儘量使記憶體管理器面面俱到，讓你知道遊戲需要和使用的記憶體的所有細節。

4.初始化、主迴圈和關閉

主迴圈基本是用來控制系統的主體行為，主要由三個部分組成：①獲取並對玩家輸入排序 ②標記遊戲邏輯 ③在所有遊戲檢視中顯示邏輯狀態（渲染影像、播放聲音、或者通過網際網路傳送遊戲狀態的變化）。

遊戲邏輯

遊戲邏輯是遊戲的核心。它定義了遊戲世界、其內容和其互動方式。包絡遊戲狀態和資料結構、物理層、事件、程式管理器、命令直譯器這機種元件：

1.遊戲狀態&資料結構

每個容器物件都具有容器，並且需要合理的資料結構來儲存它

2.物理學和碰撞

3.事件

當遊戲邏輯讓遊戲狀態發生變化時，遊戲系統就會作出響應

4.程式管理器

儲存程式列表

5.命令直譯器

遊戲邏輯需要對外部命令做出響應。

其實我也不知道這是不是現在流行的架構了，看了很多資料，各有不同，僅供參考吧