這里的“游戲”我只討論一般的小游戲，這里的渲染器也特指游戲中負(fù)責(zé)所有（或者說大部分）渲染工作的那個(gè)對象。而我這里說所的“架構(gòu)”則是指如何安排這個(gè) “渲染器”與游戲中其他對象（類）的關(guān)系，之所以要討論這種關(guān)系，是因?yàn)楹芏鄷r(shí)候我們都需要改善游戲中邏輯部分和渲染部分之間的關(guān)系。如果這種關(guān)系藕荷度太高，最直接的問題就是導(dǎo)致代碼可擴(kuò)展性不高。
渲染代碼往往依賴于開發(fā)所使用的開發(fā)包。假使你直接使用DirectX或者OpenGL，你的渲染代碼很有可能會(huì)直接涉及到各種DirectX或OpenGL中的概念。在代碼級別，就是會(huì)牽扯進(jìn)很多跟開發(fā)包相關(guān)的類，函數(shù)，結(jié)構(gòu)體等等之類。
也許你會(huì)對DirectX或OpenGL做二次封裝，開發(fā)出一些游戲引擎（或者只是單純的圖形引擎）。于是，現(xiàn)在的渲染代碼就可以只跟你的游戲引擎相關(guān)（代碼級別）。
無論如何，如果直接使用DirectX或OpenGL（一次封裝都沒做這是很爛的方式），當(dāng)你移植游戲時(shí)你很有可能就會(huì)面臨從DirectX到 OpenGL代碼轉(zhuǎn)化的問題（反之亦然）。而使用游戲引擎呢？游戲引擎隔離了底層具體的開發(fā)包（DirectX或OpenGL），但是如果要換引擎呢？換引擎這樣的情況我認(rèn)為是完全存在的，例如現(xiàn)在在Windows下開發(fā)了一個(gè)基于HGE的游戲，現(xiàn)在我想把這個(gè)游戲移植到Linux 下。而HGE是基于DirectX的，要移植到Linux下，你當(dāng)然可以保持HGE的接口不變，而使用OpenGL重寫HGE。這里，你就需要重新開發(fā)一個(gè)引擎！這很浪費(fèi)時(shí)間！所以你可能會(huì)使用另一個(gè)在Linux 下運(yùn)行的引擎（跨平臺(tái)的引擎也可以），例如ClanLib，于是，這里就涉及到了“換引擎”的問題。
從上文我們可以看出，基于很多原因（不僅僅是要把代碼做移植，好的架構(gòu)還利于代碼的擴(kuò)展，利于開發(fā)過程---特指編碼過程----的平穩(wěn)進(jìn)行等等之類），游戲中渲染器的架構(gòu)需要得到關(guān)注。
接下來我將討論幾種不同的架構(gòu)：
一．這也是最爛的方式，游戲中無論在什么地方，只要需要渲染了，就加渲染代碼。其結(jié)果就是各種與圖形開發(fā)包相關(guān)的東西鋪天蓋地。這樣的代碼根本沒任何幽雅性可討論。事實(shí)上，在很多游戲開發(fā)相關(guān)的書籍中早就提到過類似“將游戲邏輯和渲染分離開來”的觀點(diǎn)。
二．這是我使用了很多次的架構(gòu)方式，類圖為：
Game類是一個(gè)Manager類，Renderer類里包含了游戲中所有的渲染代碼，Monster是一個(gè)具體的怪物類，它沒有類似于Render或者 Draw之類的接口，這些接口都被放在Renderer類里，例如RenderMonster()。當(dāng)游戲需要渲染這個(gè)Monster對象時(shí)，Game對象就調(diào)用Renderer類的RenderMonster接口。
于是，現(xiàn)在Monster類里（基于這種架構(gòu)，其他所有的精靈類以及各種需要渲染的非精靈類）就沒有任何與圖形開發(fā)包相關(guān)的東西。而與圖形開發(fā)包相關(guān)的東西則都集中到了Renderer類里。當(dāng)你要移植代碼時(shí)，只需要重寫Renderer類即可。
但是這種架構(gòu)還是有很多問題：
1．隨著游戲越做越大，游戲中需要得到渲染的物體就會(huì)越來越多。這樣，每次都給Renderer類添加一個(gè)RenderSomething之類的接口（注意，除了添加接口外很有可能還要添加一些渲染所需要的對象，例如Surface之類的）。Renderer類最終將成為一個(gè)非常巨大的類，這違背了面向?qū)ο笤O(shè)計(jì)的原則（巨類導(dǎo)致的最直接的壞處就是改代碼痛苦-----鼠標(biāo)滾輪滾半天才找到目標(biāo)代碼。just a joke。）
2．事實(shí)上，Renderer類的RenderSomething 之類的接口在被調(diào)用時(shí)還需要一些渲染參數(shù)。例如渲染一個(gè)精靈類的話，就需要知道要渲染哪一幀，以及渲染到哪里之類的信息。在某些時(shí)候，這些參數(shù)會(huì)讓這些接口的declaration 變的很惡心?。ùa要幽雅，先把格式寫好看點(diǎn)------當(dāng)然你愿意去參加“混亂代碼大賽”的話倒可以朝這個(gè)方向發(fā)展，another joke）
三．我始終記得一句關(guān)于面向?qū)ο笤O(shè)計(jì)的話：“面向?qū)ο笫怯脕砟M世界的”（大致是這樣的）。這句話其實(shí)真的可以作為面向?qū)ο箝_發(fā)的一個(gè)指導(dǎo)性原則，它會(huì)讓你在架構(gòu)系統(tǒng)時(shí)變得很容易。因此，套用這句話的話，上面那種架構(gòu)方式就出現(xiàn)一些讓人覺得別扭的地方了。怪物對象為什么不能自己渲染自己？（難道一個(gè)人表現(xiàn)自己的能力都沒有？爛比喻！）按照那條原則，怪物類理所應(yīng)該擁有一個(gè)Render之類的接口！
于是，架構(gòu)二稍微做了些變化：
我們讓每個(gè)需要渲染的物體，這里是Monster，都有一個(gè)Render接口以及一個(gè)Renderer對象指針。在創(chuàng)建該精靈對象時(shí)，Game類把自己創(chuàng)建的Renderer對象指針傳給該精靈對象。該精靈對象再保存該指針到mRender成員。當(dāng)渲染時(shí)，Game類不再直接調(diào)用Renderer對象里的 RenderSomething之類的接口，而是很自然地調(diào)用Monster的Render接口。然后Monster的Render接口再通過自己保存的 Renderer對象指針調(diào)用其RenderMonster接口。
這里，我們?yōu)榱俗屧O(shè)計(jì)更貼近真實(shí)世界，就多加了一條依賴關(guān)系。（這其實(shí)純碎是某些完美主義程序員的癖好-----for instance, me :D）
四．這可能是種被普遍使用的方式：
類圖為：
這里不再有Renderer類了，精靈也不再象方式三中的那種“虛假”的Render了。取而代之的是，精靈類（以及其他需要渲染對象）自己直接使用圖形引擎來渲染自己，自己也保存渲染所需要的信息，例如那個(gè)mImage。
這種方式的缺點(diǎn)在于：每個(gè)需要渲染的物體就都會(huì)與圖形開發(fā)包相關(guān)。當(dāng)然如果代碼組織得當(dāng)，在移植時(shí)也不是很費(fèi)勁。但是它造成了代碼層次上的相關(guān)性，讓我覺得不是很好。（代碼相關(guān)性：例如要涉及到圖形引擎的類（例如Image ），還要包含一些圖形引擎頭文件，這樣一折騰就讓我覺得很不爽）
總結(jié)了以上四種方式，我在這里試著提出一種個(gè)人覺得更為好的架構(gòu)方式（因?yàn)檫€沒在實(shí)際的項(xiàng)目中實(shí)驗(yàn)過，所以只能說“試著”）。
關(guān)于渲染所需要的渲染信息，其最基本的信息就是類似于Surface，Image之類的用來代表該物體外觀圖片的對象。又由于圖片資源的一些屬性，很有可能還會(huì)涉及到一些輔助加工資源的變量（例如對于一個(gè)精靈，某一幀對應(yīng)于圖片上的矩形區(qū)域）。
這里涉及的問題就變?yōu)椋阂粋€(gè)需要被渲染的物體，除了其渲染代碼與特定的圖形開發(fā)包相關(guān)外，其渲染信息數(shù)據(jù)也與圖形開發(fā)包相關(guān)。如何盡可能地把這些代碼與邏輯部分代碼分離？
于是我得到了如下的架構(gòu)形式：
每一個(gè)需要渲染的物體都擁有一個(gè)其自己的渲染器，然后每個(gè)特定的渲染器還有一個(gè)其特有的資源管理器（這里主要管理圖片資源-----事實(shí)上只是作為一種資源加工器而已）。
這種方式其實(shí)就是上面提到的方式二的改進(jìn)版本，把方式二中的那個(gè)巨類分割開來。而為了更方便地進(jìn)行渲染，Monster在創(chuàng)建MonsterRenderer對象時(shí)可以把自身作為參數(shù)傳給MonsterRenderer并讓其保存。這樣，又多了條依賴關(guān)系：
有時(shí)候，對于一個(gè)精靈而言，為了靈活地配置其部分屬性（這部分屬性如果硬編碼的話很有可能就是一些常量或者宏），我們還要為精靈增加一個(gè)屬性讀取器，它會(huì)從外部配置文件讀入屬性-----事實(shí)上這不是本文討論的范圍-----例如使用一種XML解析庫來從XML配置文件中讀取數(shù)據(jù)，可以這樣設(shè)計(jì)：
如果精靈渲染信息數(shù)據(jù)也需要由外部文件配置，并且與那些屬性被放在同一個(gè)配置文件中（這可能不是種好的習(xí)慣），這樣，PropertiesReader和MonsterResMgr就會(huì)從同一個(gè)XML配置文件中讀取數(shù)據(jù)。我們可以這樣解決這個(gè)問題：
所有配置數(shù)據(jù)都由PropertiesReader讀取，Monster負(fù)責(zé)創(chuàng)建PropertiesReader對象，然后把該對象指針傳給 MonsterRenderer對象。事實(shí)上，因?yàn)镸onsterRenderer對象保存有Monster對象指針，所以完全可以訪問到 PropertiesReader對象