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