游戏引擎编程

     在开始构建一个游戏引擎时你需要先考虑哪些方面的问题呢？这是你必须认真考虑的问题，我的答案是首先必须考虑代码的可读性，尤其是在多人进行开发时更必须高度重视，如果你写的代码其他人需要花费非常大的精力进行阅读，那么根本谈不上提高工作效率，下面是提高代码可读性的一些良好建议：

1、建立一份简单明了的命名规则。一份良好的命名规则可以大幅提高代码的可读性，规则必须简单明了，通常只需要两三分钟的阅读应该可以让其他人掌握，例如在代码中直接使用匈牙利命名法这种大家熟知的规则，使用字母I作为接口类的首字母，使用C开头作为实现类的首字母，使用g_开头的变量名作为全局变量，s_开头作为静态变量名，m_开头作为内部变量名，使用_开头作为类内部使用的函数名等等，通过名字就可以使你大概了解对象的使用范围和基本功能。

2、不要讨厌写注释。一个编程者易犯的错误就是不写注释，认为它会增加自己的工作量，但是他没有考虑到相应的工作量已经转移到代码阅读者的身上，可能看代码的人会花费比写注释时间两倍或者三倍的时间来阅读代码，这是一种非常不负责任的行为，通过一段简短的注释可以使阅读者迅速的了解代码的功能，从而把时间更多的用到功能的扩展上。下面是一些良好的建议：尽量对每一个变量标明它的功能。对每一个函数声明的地方标明它的功能，对于复杂的函数还应当写清参数和返回值的作用，注意是在声明函数的头文件中。在关键的代码处写清它的作用，尤其是在进行复杂的运算时更应如此。在每一个类声明的地方简要的介绍它的功能。

3、减少类的继承层次。通常对于游戏编程来说每一个类的继承层次最好不要超过4层，因为过多的继承不仅会减少代码的可读性，同时使类表指针变长，代码体积增大，减低类的执行效率。还要注意要减少多重继承，因为不小心它会形成编程者非常讨厌的“钻石”形状。同时还要注意如果能使用类的组合的话那么就尽量减少使用类的继承，当然这是设计技巧的问题。

4、减少每行代码的长度。尽量不要在一行代码中完成一个复杂的运算，这样做会增加阅读难度，同时不符合现代CPU的执行，由于CPU现在都使用了超长流水线的设计，它非常适合执行那些每行代码非常短而行数非常多的代码，例如对一个复杂的数学运算，写成一行不如每一步骤写一行。

 

     如何组织一个引擎的架构。这是引擎最重要的部分，为什么重要呢？如果我们把引擎看作一间房子的话，那么架构可以看作是房子的框架，当你完成这个框架后就可以向框架内添砖加瓦盖房子了。下面让我们来看看如何构建这个框架，通常一个大型的软件工程是按照模块化的方式来构建的，编程之前要进行必要的需求分析，将软件工程根据不同的功能划分为几个较大的功能模块，对比较复杂的模块你可能还需要将它分为几个子模块，并需要给出各个模块之间的逻辑关系。当你编写一个引擎时也需要进行相应的功能分析，让我们看看如何来划分引擎的功能模块，如果按照上面的游戏无关性和相关性进行分析的话我们可以发现它可以分为游戏相关层和无关层两层，游戏相关层由于包含了游戏的逻辑性代码也被称为逻辑层。逻辑层应该位于引擎的最顶层，如果你在开发一个局域网或在线游戏的话，按照网络程序的C/S开发模式，这一层应该分为两个模块，服务器和客户端模块,它包含了和特定游戏相关的所有功能，如AI，游戏角色，游戏事件管理，网络管理等等。在它下面就是游戏无关层了，包括了引擎核心模块，GUI模块，文件系统管理模块等等，其中引擎的核心模块是最重要的部分，逻辑层主要通过它来和底层的模块打交道，它应该包含场景管理，特效管理，控制台管理，图形处理等等内容。在向下就是一些底层模块了，如图形渲染模块，输入设备模块，声音模块，网络模块，物理模块，角色模型模块等等，所有的这些底层模块必须通过核心模块来和逻辑层进行交互，因此核心模块是整个引擎的枢纽，所有的模块都通过它来进行交互。

下面看看应该如何来进行模块的设计，这里有一些通用的规则是你应当遵守的：

1、减少模块之间的关系复杂度。我们知道通常每一个模块内部都存在大量的对象需要在各个模块之间进行相互的调用，如果我们假设每一个模块内部对象的数量为N的话，那么每两个模块之间的关系复杂度为N*N，这样的复杂度是不可接受的，为什么呢？首先是它非常不利于管理，由于各个模块都存在大量的全局对象，并存在相互依存的关系，并且各自建立的时间各不相同，这就存在初始化顺序的矛盾，考虑这种情况，一个模块中存在一个对象需要另外一个模块中的对象才能进行初始化，当这个对象进行初始化时而另外的对象在之前并没有初始化就会引发程序的崩溃。其次，不利于多人进行同时的开发，由于各个模块存在相互依存的关系，当复杂度非常高时就会出现模块与模块的高度依存，也就是说一个模块没有完成下一个模块就无法完成，因此就需要一个模块一个模块按照它的依存关系进行编程，而无法同步进行。因此在设计模块时的第一件事情是减少模块之间的复杂度，为此你在设计模块时必须为模块设计一个交互接口，并约定所有模块之间的交互必须通过这个接口来进行，这样模块之间的关系复杂度就降低为1*1了，非常方便管理，同
时这非常利于多人之间进行开发，假如每个人负责一个模块的开发的话，那么你只需要先完成这个接口类，其他人就可以利用这个接口进行其他模块的开发，而不必等到你完成所有的类再进行，这样所有的模块都是同步进行，可以节省大量宝贵的开发时间。

2、对类的抽象接口而不是类的实现编程。这是《Design Patten》一书作者对所有软件编程者的建议，它也对游戏编程有很大的指导意义。对模块中所有被其它模块使用的类都要建立一个抽象接口，其它模块要使用这个抽象接口进行编程，这样其它模块就可以在不需要知道类是如何实现的情况下进行编程。这样做的好处是在接口不改变的情况下任意对类的实现进行改变而不必通知其它人，这对多人开发非常有用。

3、根据调用对象的不同对类进行分层。实际上本条还是对第2条的补充，分层还是为了更好隐藏底层的实现。通常一个类不仅被其它模块使用还要被自身模块所调用，而且它们需要的功能也不同，因此我们可以让一个类对外部显现一个接口而对内部也显现一个接口，这样做的好处和上面一样，因为一个复杂的模块也是多人在进行编程的。

4、通过让一个类对外显现多个接口来减少类的数量。减少关系复杂度的一个方法是减少类的数量，因此我们可以把完成不同功能的类合并成一个类，并让它对外表现为多个接口，也就是一个类的实现可以继承多个接口。

上面的建议只是起到参考作用，具体实现时你应该根据情况灵活使用，而不是任意乱用。

　　下面的内容涉及到具体的编程技巧，对于引擎中的全局对象你可以使用Singleton，如果你不了解它是什么可以阅读《Design Patten》，里面有对它的详细介绍，具体的使用可以通过OGRE引擎获得。

　　调用模块内的对象可以通过类厂来实现。COM可以看作是一种典型的类厂，DX就是使用它来进行设计的，而著名的开源引擎Crystle Space也是通过建立一个类似的COM物体来实现的，但是我并不对它很认可，首先构建一个类似COM的类厂非常复杂，开销有点大，其次COM的一个优点是可以对程序实现向下兼容，这也是DX使用它的重要原因，而一个游戏引擎并不需要。OGRE中也实现了一个类厂结构，这是一个比较通用的类厂，但是使用起来还是需要写一段代码。我比较欣赏VALVE的做法，它通过使用一个宏就解决了这个问题，非常高效，使用起来也非常方便。这个做法很简单，它把每个
模块中需要对外暴露的接口都连接到一个内部维护的链表上，每一个接口都和一个接口名相连，这样外部模块可以通过传入一个接口名给CreateInterface函数就可以获得这个接口的指针了，非常简单。下面看看它的具体实现。它内部保存的链表结构如下：

class InterfaceReg
{
public:
    InterfaceReg( InstantiateInterfaceFn fn , const char *pName );

public:
    InstantiateInterfaceFn m_CreateFn;
    const char *m_pName;

    InterfaceReg *m_pNext;
    static InterfaceReg *s_pInterfaceRegs;
};

并定义了两个函数指针和一个函数

#define CREATEINTERFACE_PROCNAME "CreateInterface"
typedef void *(CreateInterfaceFn)( const char *pName , int *pReturnCode );

typedef void *(InstantiateInterfaceFn)( void );
DLL_EXPORT void *CreateInterface( const char *pName , int *pReturnCode );

下面看看它如何通过宏来建立链表

#define EXPOSE_INTERFACE( className , interfaceName , versionName ) \
static void *__Create##className##_Interface() { return (interfaceName*) new className; } \
static InterfaceReg __g_Create##interfaceName##_Reg( __Create_##className##_Interface , versionName );

如果你有一个类CPlayer它想对外暴露接口IPlayer，那么很简单，可以这么做

#define PLAYER_VERSION_NAME "IPlayer001"
EXPOSE_INTERFACE( CPlayer , IPlayer , PALYER_VERSION_NAME );

如果在其他模块内你需要获得这个接口，可以这么做

CreateInterfaceFn factory = reinterpret_cast<CreateInterfaceFn> (GetProcAddress( hDLL , CREATEINTERFACE_PROCNAME ));
IPlayer player = factory( PLAYER_VERSION_NAME , 0 );

其中hDLL为模块的句柄。这里函数指针factory实际指向模块内部的CreateInterface函数，这个函数通过比较传入的接口名从链表找到指定类指针。

　　解决了类厂问题，下面让我们看看如何建立模块对外的接口，在Game Programming Gems3的《一个基于对象组合的游戏架构》一文提出了一种架构，Half Life2引擎中对这种架构进行了有效的扩展，你可以让所有的对外暴露的接口都使用这个架构，前提是模块只有一个接口对外暴露。

class IAppSystem
{
public:
    // Here's where the app systems get to learn about each other
    virtual bool Connect( CreateInterfaceFn factory ) = 0;
    virtual void Disconnect() = 0;

    // Here's where systems can access other interfaces implemented by this object
    // Returns NULL if it doesn't implement the requested interface
    virtual void *QueryInterface( const char *pInterfaceName ) = 0;

    // Init, shutdown
    virtual InitReturnVal_t Init() = 0;
    virtual void Shutdown() = 0;
};

　　通过Connect方法你可以将两个模块建立一个连接关系，通过QueryInterface方法你可以检索到其他需要暴露接口，这种方法很好的为所有的模块建立一个标准的对外接口，极大的减轻了编程的复杂性，遗憾的是在HL2引擎中只有部分模块使用了这个方法，可能是这个接口引入时间太晚的缘故。