為什麼遊戲開發沒有好的關於架構的書？

01-03

市面上幾乎所有的英文，中文的遊戲開發書籍都看過了，其它方面資料都蠻全，可是關於遊戲開發架構的書幾乎沒有，唯一一個擦邊的就是「遊戲引擎架構」。。。
請問想提高遊戲架構技術，除了自己悶頭苦幹，死命魯代碼之外，沒有其它資料可以參考么？大家是怎麼過來的？多謝～～
可能我說的不清楚，我對設計遊戲引擎沒興趣，簡單的說，我更喜歡設計gameplay,我想了解的是設計遊戲，而不是遊戲引擎，再次感謝大家的回答。

我個人覺得可能是遊戲架構過於依賴引擎的，原生的純代碼寫遊戲，已經有點不合時宜了？
而市面上關於用引擎寫遊戲的書，已經太多太多了。
我想起來了，國內有人寫過遊戲框架的書，作者叫免費打工仔，講的是他自己的orz框架，本人程度太低，基本沒看懂。。。
————————————————————————————————————
個人背景：已開發過5款單機上線遊戲，開發遊戲算比較熟練吧。
可能還是我的表達能力太差，我需要的不是教你做遊戲的書，我自己會做。我想要的是一本介紹，可以根據需求進行靈活更改的高度分離性的遊戲框架，哪怕是玩具框架，也好。

我想最主要的問題是, 講遊戲結構的書和資料, 很多都會著重在某個方向上發揮, 最有可能的是最後變成講渲染引擎, 講物理引擎或者泛泛的跟你介紹一遍其他東西. 市面上真正缺少的是認認真真講 3C 和 AI 的書. 如果你從 3C 和 AI 切入去設計遊戲的話, 你的所有"架構"才有意義. 我覺得知乎上有兩個關於這方面問題的答案, 非常值得答主參考:

- 像《無主之地》、《求生之路》這類遊戲，怪物的 AI 是怎麼做的？ - 知乎用戶的回答

- 遊戲邏輯程序員的未來在哪裡？ - Milo Yip 的回答

然後呢, 作為遊戲重要的一環 -- 工具開發的設計和架構也是資料最少, 最被忽略的. 至少不會有人告訴你 asset 的導入導出, 索引關係. 然而 asset 的索引關係關係到了你的 gameplay 初始化時該如何設計, 但有多少人把它當成一個泛化問題來看待和解決呢?

Game Programming Patterns

找不到參考資料正常，因為這方面第一代開發者還沒有退下來有時間寫書，不像已經發展很多年的其他領域，你應該感覺到興奮才對，說明這還是一個有待你探索，值得你摸索的方向。等到第一二代研發者都閑下來靠寫書培訓招搖撞騙才入行的人來發財的時候，這個方向就沒什麼值得你花時間去突破的地方了。

我來推薦一本你們也許都沒看過的良心書籍：

Real Time 3D Terrain Engines Using C++And DirectX 9
有中文版，好像叫《實時渲染地形》。

雖然名字是地形，主題也是地形。但是作者寫了一個基本渲染引擎框架GAIA來教學，包含基本的流水線，渲染隊列優化，場景管理，設計模式理念。演算法部分也很有用，雖然有些內容有些過時（ROAM等），但是這些仍然可以帶給你對細分演算法的深度理解和多樣性的思維方式。

如果你第一次寫3D圖形引擎，強烈推薦。

這個問題之前看過了，不敢回答。《ogre3d遊戲開發框架指南》這本書只能算是我個人的一些早期探索，不能算是什麼權威。但既然點名我了，那麼請允許我自作主張的把題主的架構在之後文章中等同於框架（framework）。

但對於 @Johnny Wu 的回答有一些不同的看法，AI發展的目標應該是引擎，而不是框架。之前有一個國外大牛曾經嘗試過做AI引擎，叫fear引擎，試圖把人工智慧統一成一個通用的結構，但是無疾而終。人工智慧太複雜，又多樣，但大家的目標還是做成類似圖形引擎的硬體（遊戲編程精粹裡面說過）。而不是框架。

正式討論這個問題之前，先要明確工具集（toolkits），引擎（engine）和框架（framework）之間的差異。

toolkits：是一系列關聯性小的工具集合，你用也行不用也行，隨時替換，用起來方便，偶合度最低。類似紅顏知己，在一起時候快樂，不在一起的時候也無所謂。

engine：是底層，比如圖形引擎，物理引擎，音頻引擎，人工智慧引擎，數學引擎，這個是你來用我做底層，我不限制你只給你提供服務，類似青樓美女，你用她很好，但她不要求你什麼，只要你按照固定介面來做，自然OK。在之前開發者希望能很容易的替換掉他們。做個中間層什麼的。

framework：是你大老婆，管你吃喝拉撒睡，她定義了所有的規則，你要按照他的方式提供工作，對你限制很多，不過你也省心，只要按章辦事，自然有個幸福的結果。

c++中的 boost 算是toolkits。而Ogre或者FMod或者Fear是引擎，而Unity是（以及UE）框架＋引擎＋工具。

起初，在我年輕的時候，我寫了Orz，後來改名叫geek（Game Engine Extendable Kits），希望做個純粹的框架（framework）+一大堆工具（toolkits），不涉及引擎（engine），只是找一個好的方式去組合他們。這其實不只是我做的事情，在Ogre流行的那幾年，大家都在做。這是因為Ogre的傲氣，她聲明，我只做引擎，不做一站式捆綁，給你自由的選擇，才是我對你的真愛。所以想用Ogre的任何人都需要做自己的框架，在那段時間我有幸看到了無數人的無數框架，只是他們沒有我這麼喜歡喧嘩而已。

可是，隨著技術的進步，大家開始離開青樓女子去找老婆了，Unity3D的價格不高，大家都娶得起，玩起來也挺爽，還不用提心弔膽所以大家就離開Ogre了，我離開Ogre的那幾年挺痛苦，畢竟十幾年的感情，但是看到他自己提供的調查問卷，明顯發現紅顏彈指老。

再掙扎了幾年之後，我開始嘗試使用Unity。

放棄了十年的Ogre，同時也放棄了七年的Orz（geek）。

然後做了一個不是很成功的遊戲。

但是幾年過去了，我竟然發現那個geek的心還沒有死掉。我把在Unity中開發中使用的工具和框架依舊總結出來，這次叫做GDGeek（Game Dev Game Engine Extendable Kits）。ok，你知道我新網名昵稱「遊戲開發極客」是什麼意思了吧。這裡面包括了幾個小的工具和一個建議。

因為Unity提供了太多東西了，GDGeek很小，小的沒有幾個東西，但這幾個東西都是很有用的。

通用的有限狀態機（從C++ Boost庫中抄來的）。

非同步任務管理器

插值工具（是NGUI和itween兩個庫的雜合）

還有後來加入的體素渲染系列工具

（以上是Toolkits）

還有一個MVC的建議

（以上是分Framework）

五年前，人家讓我寫OGRE 3D的書，我把Orz（Geek）藏在裡面。

今天，我又寫了《創遊記》，把GDGeek藏在裡面。

和之前不同的是，這次代碼很少，

但少，

豈不是更好。

以上，全是廢話，

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

以下，才是回答。

為什麼沒有框架的書？

框架和引擎不同，沒有統一的學問

一千個程序員有一千個框架。

如果說引擎是自然科學的話，

框架都是社會科學，

只要做到自洽，就是成功的框架。

而這框架，大多不是研究出來的。

是不斷的使用重構總結出來的。

一本框架的書，肯定是吃力不討好。

因為，這框架

是我的框架，

不是你的框架。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

最後一句，認真寫到半夜了，求贊。。

ps，補充一點，其實我本質是一個php程序員，你看看比如yii，zend framework等等，在後端屆不缺乏優良框架的實現，很多時候能帶來很多很好的靈感，畢竟php是最好的語言。

國內不斷堆砌代碼的多，先搭架構再用模式實現邏輯設計的少。說到這，突然想到星際爭霸1和魔獸爭霸3的地圖編輯器，那才是「先搭建框架和工具，然後你們設計師自己去玩吧」的典範。

遊戲引擎架構講c++的有點多，但是翻譯水平很高看著很舒服

遊戲編程精粹這個有六七本ψ(｀?′)ψ，我們主管看這個

引擎包含的東西太多，客戶端，伺服器端，不太可能一兩本書講清楚，還是從項目做起，最後選一個方向深入

題主說的gameplay部分，其實我覺得是沒有架構存在的。架構源於抽象，如果gameplay可以高度抽象，那所有的遊戲就會同質化，這個所謂的架構就只能產生換皮遊戲。這大概就是為什麼一直少有介紹遊戲架構的書，因為你實在很難用一個架構去框住大多數的遊戲。

如果遊戲開發有架構，那還真就是遊戲引擎的架構。因為遊戲引擎就是一個刨掉gameplay的通用部分。遊戲引擎可以進一步拆分成獨立的組件，而這些組件，是真正的可復用部分，比如渲染、音頻、物理等等。商業化的遊戲引擎則會提供更多更高級的常用的組件，比如第一人稱的角色控制器。

遊戲玩法一般都是源於具體的需求，抽象程度有限。比如一個棋牌遊戲和ARPG，這個你幾乎找不到什麼共同點。而針對不同的系統的設計，像是技能系統，你是可以找到一些文章的（因為還不至於複雜到要用一本書來講），絕大多數情況也是針對具體需求來闡述。但是對於代碼的組織上是一些模式的，除了經典的設計模式最常用的就是狀態機了。比如你的遊戲流程式控制制，角色AI都可以用狀態機組織。

知道為什麼很多人都吐槽，遊戲公司的程序員水平不行么，因為他們只注重實現主義，想要提高編程水平除了多看，多練，還要打好理論基礎，基礎都打不好就想建高樓畢竟不太實際。不要著急去看實現類方面的書，建議題主先沉下心打好基礎。

其實不是沒有、比如虛幻3國內使用的高手一大把，結果呢產品屎一樣！

工具就在哪裡！怎麼用如何用因人而異！

這個不是考試有絕對的答案！同樣的工具在公司手裡完全不能比！

有本書叫遊戲引擎架構啊.. @Milo Yip 翻譯的..