游戲客戶端與編輯器代碼重用設(shè)計(jì)雜談
版本：0.1
最后修改：2010-12-10
撰寫：李現(xiàn)民
引言
很多游戲都有配套的編輯器，或通用或?qū)Ｓ?，這樣可以方便策劃及時(shí)設(shè)計(jì)、修改游戲數(shù)據(jù)。當(dāng)一個(gè)游戲方案確認(rèn)實(shí)施時(shí)，如果需要設(shè)計(jì)配套編輯器，那么它往往先于游戲本身而設(shè)計(jì)。出于代碼重用和方便維護(hù)的需要，大部分核心代碼會(huì)在游戲客戶端與編輯器中同時(shí)使用，因此有效提取這部分共用代碼并盡量減少與項(xiàng)目其它部分的耦合就成為設(shè)計(jì)的重點(diǎn)。
關(guān)于良好程序架構(gòu)設(shè)計(jì)的話題，比如設(shè)計(jì)模式、領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)等，相關(guān)論著恒河沙數(shù)。本文結(jié)合實(shí)踐中遇到的問題，從工具與技術(shù)相結(jié)合的角度來(lái)闡述相關(guān)問題的解決方案。
以下假定程序運(yùn)行環(huán)境為VC6+XP。從本文撰寫時(shí)間看（2010-12-10），VC6無(wú)論如何都不是一個(gè)好的選擇，但限于筆者所在公司環(huán)境如此，所以只好將就著來(lái)了╮(╯▽╰)╭。
使用宏控制代碼生成策略
盡管我們追求代碼的可重用性，但實(shí)際情況往往并不盡如人意，特別是在與特定于游戲客戶端（或編輯器）的功能相結(jié)合比較緊密的代碼部分。比如UI（界面），游戲客戶端中有獨(dú)立的界面模塊，而編輯器界面可能使用MFC制作。即使同一個(gè)函數(shù)接口，游戲客戶端與編輯器所需要的功能也可能是不一樣的，這是因?yàn)樗鼈儞碛懈髯圆煌膽?yīng)用傾向：游戲客戶端傾向于使游戲畫質(zhì)更加平滑，而編輯器則需要考慮策劃人員快速的編輯修改數(shù)據(jù)；再比如游戲客戶端可能需要網(wǎng)絡(luò)IO功能，而編輯器則一般不需要。
宏（具體的說(shuō)，C++中的宏），此時(shí)可能是一種比較合適的工具。比如，通過(guò)在游戲客戶端與編輯器中定義不同的宏變量，可以使游戲客戶端專用的網(wǎng)絡(luò)IO代碼在編輯器中根本不生成。
某些情況下可能需要在同一個(gè)項(xiàng)目下建立多個(gè)configurations（配置），通過(guò)定義不同的宏變量以控制生成不同版本的程序，比如：簡(jiǎn)化版、完整版、內(nèi)部版等。
宏在VC環(huán)境中有大量的應(yīng)用案例，比如windows.h頭文件中定義了大量的宏用于控制不同環(huán)境下的代碼生成策略。
使用函數(shù)控制代碼生成策略并信任編譯器優(yōu)化
宏控制的原理是將不需要的代碼當(dāng)作注釋直接移除，因此編譯器不會(huì)去審查該部分代碼的正確性。這在某些情況下是必須的，比如編輯器沒有網(wǎng)絡(luò)IO相關(guān)的代碼接口，因此相關(guān)代碼必須被清除，否則編輯器項(xiàng)目將無(wú)法正確編譯。
但宏控制有自己的問題：
宏變量通常定義在Project
Settings（工程設(shè)置）中，因此不容易記憶或查找；
IDE工具通常無(wú)法像支持代碼一樣支持此類宏變量的快速查找，特別是存在多個(gè)項(xiàng)目相互引用的復(fù)雜工程中（比如Visual
Assist X有Find
Reference功能，可以快速搜索到所有引用指定變量或函數(shù)的代碼，但此功能不支持在Project
Settings中定義的宏變量）；
編譯器無(wú)法審查被移除部分代碼的正確性，這可能導(dǎo)致一些代碼修改同步的問題。
針對(duì)這些問題，筆者的解決方案是：宏控制變量只使用一次，用于定義一個(gè)簡(jiǎn)單函數(shù)，而該函數(shù)返回當(dāng)前宏控制變量的存在情況，其它原本使用宏控制變量的地方都改為使用這個(gè)函數(shù)判斷。這樣間接的將宏變量控制轉(zhuǎn)換為函數(shù)控制，從而獲得IDE工具支持與編譯器代碼審查的雙重好處。
比如如下代碼：
namespace
edition
{
#ifdef
_EDITOR
inline
bool
IsEditor()
{ return
true;
}
#else
inline
bool
IsEditor()
{ return
false;
}
#endif
}
void
Print()
{
if
(edition::IsEditor())
{
puts("This
is editor");
}
else
{
puts("This
is not editor");
}
}
宏變量_EDITOR只使用一次，其余地方都使用edition::IsEditor()區(qū)分是編輯器代碼還是游戲客戶端代碼。
請(qǐng)注意，我們并不會(huì)有任何的運(yùn)行期性能損失，雖然看起來(lái)并非如此。由于在編譯期edition::IsEditor()的值是確定的，因此當(dāng)打開優(yōu)化時(shí)編譯器會(huì)移除不可達(dá)代碼，從而得到與宏控制情況下相同的可執(zhí)行文件。當(dāng)然，在Debug版本下（優(yōu)化關(guān)閉）所有的代碼都被編譯生成到最終可執(zhí)行文件中，但我猜您應(yīng)該不會(huì)將Debug版本給最終用戶使用對(duì)吧？
使用delegate解耦
在MVC架構(gòu)下，使用Observer（觀察者）模式將核心邏輯代碼與UI界面代碼分離似乎天經(jīng)地義的事，這樣做的好處是核心邏輯代碼可以獨(dú)立于UI代碼而存在，從而達(dá)到重用的目的。但不幸的是，從筆者經(jīng)手的代碼看，很多程序員并沒有注意到這一點(diǎn)。主要問題可能包括以下兩個(gè)方面：
第一是核心邏輯代碼與UI界面代碼相互調(diào)用關(guān)系錯(cuò)綜復(fù)雜。由于核心邏輯代碼不獨(dú)立，因而很難進(jìn)行提取復(fù)用。這種情況相對(duì)比較常見。
第二個(gè)問題解釋起來(lái)可能更復(fù)雜一些。由于缺乏從核心邏輯代碼到UI界面代碼的回調(diào)機(jī)制，程序員可能會(huì)被迫使用一些極端的手法來(lái)達(dá)到偵測(cè)指定事件是否發(fā)生的目的。比如，我們知道游戲客戶端都有一個(gè)主循環(huán)main_loop，方法名稱通常叫Update()或Tick()，用于更新每一幀的游戲動(dòng)畫。這時(shí)，程序員可能會(huì)在該循環(huán)中埋伏一些代碼以偵測(cè)核心邏輯狀態(tài)的變化情況，從而達(dá)到觸發(fā)事件的目的。這種手法實(shí)現(xiàn)了功能，保持了低耦合，卻降低了代碼執(zhí)行效率。
這兩個(gè)問題的解決之道在于觀察者模式。這個(gè)模式在實(shí)現(xiàn)上還是比較復(fù)雜的，對(duì)每一個(gè)要處理事件都需要定義對(duì)應(yīng)的觀察者與被觀察者接口。這種代碼復(fù)雜性曾使很多人望而卻步（包括本人-___-），為此java中內(nèi)置了java.util.Observer與java.util.Observable接口，以降低使用該模式的代價(jià)。
筆者建議的方案是使用delegate（委托）。沒錯(cuò)，就是那個(gè)C#中的delegate，它能夠極低的設(shè)計(jì)復(fù)雜度實(shí)現(xiàn)與觀察者模式相同的解耦效果。具體實(shí)例這里不再列舉，因?yàn)榫W(wǎng)上可以找到很多。如果你使用的是C#，那么你是幸運(yùn)的；如果你使用的是C++，那么網(wǎng)上同樣可以找到設(shè)計(jì)好的仿真類庫(kù)；如果你不幸使用了VC6，并且實(shí)在找到出路了，那么同學(xué)你也許可以去參考一下我的另一篇文章《VC6中簡(jiǎn)易delegate實(shí)現(xiàn)》，或許會(huì)有點(diǎn)幫助。
結(jié)語(yǔ)
本來(lái)還想加點(diǎn)靜態(tài)變量與通用工廠的話題的，但我發(fā)現(xiàn)meyers
singleton在VC6中的某種應(yīng)用模式下會(huì)問題（singleton對(duì)象的構(gòu)造函數(shù)會(huì)被調(diào)用兩次，T__T），因此先欠著賬，等待下次有成熟方案的時(shí)候再說(shuō)吧。不過(guò)對(duì)此問題諸位看官如果有相關(guān)寶貴經(jīng)驗(yàn)的話不妨提攜一二，感激不盡中。