建議讀者對(duì)應(yīng) HGE 的官方的例子：Tutorial 02 - Using input, sound and rendering 來(lái)閱讀本文

渲染：

在 HGE 中，四邊形是一種圖元，對(duì)應(yīng)了結(jié)構(gòu)體 hgeQuad，另外還有三角形圖元，對(duì)應(yīng) hgeTriple，為了渲染，我們現(xiàn)在需要使用 hgeQuad 結(jié)構(gòu)體，這個(gè)結(jié)構(gòu)體如下：

struct hgeQuad
{
  hgeVertex  v[4];   // 頂點(diǎn)描述了這個(gè)四邊形
  HTEXTURE   tex;   // 紋理的句柄或者為0
  int        blend;   // 混合模式（blending mode）
};

HGE 中圖元對(duì)應(yīng)的結(jié)構(gòu)體總含有這3個(gè)部分：頂點(diǎn)，紋理句柄，混合模式

struct hgeVertex

{

    float x, y;   // 屏幕的 x，y 坐標(biāo)

    float z;   // Z-order，范圍 [0, 1]

    DWORD col;   // 頂點(diǎn)的顏色

    float tx, ty;   // 紋理的 x，y 坐標(biāo)（賦值前需要規(guī)格化坐標(biāo)間隔，使得 tx，ty 取值范圍在[0,1]）

};

規(guī)格化坐標(biāo)間隔在后面的例子中會(huì)談到。不過(guò)先要談到的一點(diǎn)是 tx，ty 的值超過(guò) 1 也是合法的

1. 顏色的表示：

顏色使用32位表示，從左開(kāi)始，8位為 Alpha 通道，8位紅色，8位綠色，8位藍(lán)色

對(duì)于后24位，如果全部為0，表示黑色，如果全部為1，表示白色

2. 定義顏色的運(yùn)算：

我們把顏色看成一個(gè)四維向量，即 alpha 通道，紅色，綠色，藍(lán)色這四個(gè)分量

    <1> 顏色是可以相乘的

    顏色的相乘是對(duì)應(yīng)的四個(gè)分量分別相乘的結(jié)果，即：alpha 通道的值與 alpha 通道的值相乘，紅色的值與紅色的值相乘，綠色的值與綠色的值相乘，藍(lán)色的值與藍(lán)色的值相乘。

    <2> 顏色是可以相加的

    同上，對(duì)應(yīng)分量相加。

顏色的每個(gè)分量使用浮點(diǎn)數(shù)表示，范圍是[0-1]，相加操作可能導(dǎo)致溢出，一種處理的方式就是，如果溢出，則設(shè)定值為1。

3. 混合模式：

1）BLEND_COLORADD

表示頂點(diǎn)的顏色與紋理的紋元（texel）顏色相加，這使得紋理變亮，可見(jiàn)頂點(diǎn)顏色為 0x00000000 將不造成任何影響。

2）BLEND_COLORMUL

表示頂點(diǎn)的顏色與紋理的紋元顏色相乘，這使得紋理變暗，可見(jiàn)頂點(diǎn)顏色為 0xFFFFFFFF 將不造成任何影響。

注意：必須在1），2）中做一個(gè)選擇，且只能選擇1），2）中的一個(gè)。處理的對(duì)象是紋理顏色和頂點(diǎn)顏色。

這里有一個(gè)技巧：

如果我們需要在程序中顯示一個(gè)氣球，這個(gè)氣球的顏色不斷變化，這時(shí)候我們并不需要準(zhǔn)備多張不同顏色的氣球紋理，而只需要一張白色的氣球紋理，設(shè)置 blend 為 BLEND_COLORMUL，白色的R,G,B值被表示成 1.0，也就是說(shuō)，紋理顏色和頂點(diǎn)顏色相乘的結(jié)果是頂點(diǎn)的顏色，那么就可以通過(guò)修改頂點(diǎn)顏色，得到任意顏色的氣球了。

3）BLEND_ALPHABLEND

渲染時(shí)，將對(duì)象的像素顏色（而非頂點(diǎn)的顏色）與當(dāng)前屏幕的對(duì)應(yīng)像素顏色進(jìn)行 alpha 混合。alpha 混合使用到 alpha 通道，對(duì)于兩個(gè)像素顏色進(jìn)行如下操作，得到一個(gè)顏色：

R(C)=alpha*R(B)+(1-alpha)*R(A)
G(C)=alpha*G(B)+(1-alpha)*G(A)
B(C)=alpha*B(B)+(1-alpha)*B(A)

這里的BLEND_ALPHABLEND使用的是對(duì)象像素的顏色的 alpha 通道。可見(jiàn)如果對(duì)象像素顏色 alpha 通道為 0，那么結(jié)果就是只有當(dāng)前屏幕的像素顏色，也就是常常說(shuō)的 100% 透明，因此，我們可以理解 alpha 混合就是一個(gè)是圖像透明的操作，0 表示完全透明，255 表示完全不透明。

4）BLEND_ALPHAADD

渲染時(shí)，將對(duì)象的像素顏色與當(dāng)前屏幕的對(duì)應(yīng)像素顏色相加，結(jié)果是有了變亮的效果。

注意：這里的3），4）必選其一，且只能選其一。處理的對(duì)象是對(duì)象像素顏色和屏幕像素顏色。選擇 BLEND_ALPHABLEND 并且設(shè)定對(duì)象的 alpha 通道為 FF，可使此組參數(shù)無(wú)效。

5）BLEND_ZWRITE

渲染時(shí)，寫(xiě)像素的 Z-order 到 Z-buffer

6）BLEND_NOZWRITE

渲染時(shí)，不寫(xiě)像素的 Z-order 到 Z-buffer

這里一樣是二者選一

設(shè)置舉例：

quad.blend=BLEND_ALPHAADD | BLEND_COLORMUL | BLEND_ZWRITE;   // quad 為 hgeQuad 變量

4. HGE 渲染

1）定義和初始化 hgeQuad 結(jié)構(gòu)體：

hgeQuad quad;   // 定義四邊形

2）初始化 hgeQuad 變量：

// 設(shè)置混合模式

quad.blend=BLEND_ALPHAADD | BLEND_COLORMUL | BLEND_ZWRITE;

// 加載紋理

quad.tex = pHGE->Texture_Load("particles.png");

注意，讀取硬盤(pán)上資源的時(shí)候，可能會(huì)失敗，因此通常都需要檢查，例如：

if (!quad.tex)

{

    MessageBox(NULL, "Load particles.png", "Error", 0);

}

// 初始化頂點(diǎn)

for(int i=0;i<4;i++)
{
    // 設(shè)置頂點(diǎn)的 z 坐標(biāo)
    quad.v[i].z=0.5f;
    // 設(shè)置頂點(diǎn)的顏色，顏色的格式為 0xAARRGGBB
    quad.v[i].col=0xFFFFA000;
}

// 這里假定載入的紋理大小為 128*128，現(xiàn)在截取由點(diǎn)（96，64），（128，64），（128，96），（96，96）這四個(gè)點(diǎn)圍成的圖形。

quad.v[0].tx=96.0/128.0; quad.v[0].ty=64.0/128.0;   // 規(guī)格化坐標(biāo)間隔
quad.v[1].tx=128.0/128.0; quad.v[1].ty=64.0/128.0;
quad.v[2].tx=128.0/128.0; quad.v[2].ty=96.0/128.0;
quad.v[3].tx=96.0/128.0; quad.v[3].ty=96.0/128.0;

注意，對(duì)于 hgeQuad 結(jié)構(gòu)體，頂點(diǎn) quad.v[0] 表示左上那個(gè)點(diǎn)，quad.v[1] 表示右上的點(diǎn)，quad.v[2] 表示右下的點(diǎn)，quad.v[3] 表示左下的點(diǎn)。

// 設(shè)置 hgeQuad 在屏幕中的位置

float x=100.0f, y=100.0f;

quad.v[0].x=x-16; quad.v[0].y=y-16;
quad.v[1].x=x+16; quad.v[1].y=y-16;
quad.v[2].x=x+16; quad.v[2].y=y+16;

quad.v[3].x=x-16; quad.v[3].y=y+16;

3）設(shè)置渲染函數(shù)（render function）：

System_SetState(HGE_RENDERFUNC,RenderFunc);

RenderFunc 原型和幀函數(shù)一樣：

bool RenderFunc();

4）編寫(xiě) RenderFunc 函數(shù)：

bool RenderFunc()
{
    pHGE->Gfx_BeginScene();   // 在如何渲染之前，必須調(diào)用這個(gè)函數(shù)
    pHGE->Gfx_Clear(0);   // 清屏，使用黑色，即顏色為 0
    pHGE->Gfx_RenderQuad(&quad);   // 渲染
    pHGE->Gfx_EndScene();   // 結(jié)束渲染，并且更新窗口
    return false;   // 必須返回 false
}

補(bǔ)充：Load 函數(shù)是和 Free 函數(shù)成對(duì)出現(xiàn)的，即在硬盤(pán)上加載了資源之后，需要 Free 它們，例如：

quad.tex = pHGE->Texture_Load("particles");

// ...

pHGE->Texture_Free(quad.tex);

這里不得不談一下規(guī)格化坐標(biāo)間隔，而這之前，需要說(shuō)說(shuō) Texture_GetWidth(xxx) 和 Texture_GetHeight(xxx) 函數(shù)，如果這樣調(diào)用：Texture_GetWidth(xxx) 獲取的是處于顯存中的紋理寬度，而 Texture_GetWidth(xxx, true) 獲取到的是圖像文件的寬度，需要特別主義的是，對(duì)于同一張紋理來(lái)說(shuō)，這兩個(gè)值可能是不一樣的，那么在規(guī)格化坐標(biāo)間隔的時(shí)候，應(yīng)該明確的是，對(duì)于一個(gè) w*h 圖像的圖片，那么對(duì)于圖中點(diǎn)（x,y）應(yīng)該轉(zhuǎn)換成為：

tx = x / pHGE->GetWidth(xxx);
ty = y / pHGE->GetHeight(xxx);

而不能寫(xiě)成：

tx = x / pHGE->GetWidth(xxx, true);

ty = y / pHGE->GetHeight(xxx, true);

這里要注意一下 x，y 的含義

最后再談一下 tx 和 ty，實(shí)際上 tx，ty 大于 1 也是合法的，例如：

tx = 800 / 64;

ty = 600 / 64;

這會(huì)使得圖片重復(fù)，而具體的含義，可以通過(guò)實(shí)現(xiàn)來(lái)體會(huì)

音效：

使用音效是很簡(jiǎn)單的

1. 載入音效：

HEFFECT hEffect = pHGE->Effect_Load("sound.mp3");

2. 播放：

pHGE->Effect_PlayEx(hEffect);

或者 pHGE->Effect_Play(hEffect);

1）Effect_Play 函數(shù)只接受一個(gè)參數(shù)就是音效的句柄 HEFFECT xx;

2）Effect_PlayEx 函數(shù)較為強(qiáng)大，一共有四個(gè)參數(shù)：

HCHANNEL Effect_PlayEx(
                       HEFFECT effect,   // 音效的句柄
                       int volume = 100,   // 音量，100為最大，范圍是[0, 100]
                       int pan = 0,   // 范圍是[-100, 100]，-100表示只使用左聲道，100表示只使用右聲道
                       float pitch = 1.0,   // 播放速度，1.0 表示正常速度，值越大播放速度越快，值越小播放越慢。這個(gè)值要大于0才有效（不可以等于0）
                       bool loop = false   // 是否循環(huán)播放，false表示不循環(huán)
                       );

輸入：

僅僅需要調(diào)用函數(shù) pHGE->Input_GetKeyState(HGEK_xxx); 來(lái)判斷輸入，應(yīng)該在幀函數(shù)中調(diào)用它，例如：

bool FrameFunc()

{

    if (pHGE->Input_GetKeyState(HGEK_LBUTTOM))

       // ...

    if (pHGE->Input_GetKeyState(HGEK_UP))

       // ...

}

在ubuntu下安裝subversion服務(wù)器

Tuesday, 6. March 2007, 13:29:44

subversion, ubuntu

$ sudo apt-get install subversion
$ sudo apt-get install libapache2-svn

sudo addgroup subversion
sudo usermod -G subversion -a www-data

$ sudo vi /etc/group

$ cat /etc/group|grep subversion
subversion:x:1001:www-data,exp

$ sudo mkdir /home/svn
$ cd /home/svn
$ sudo mkdir myproject
$ sudo chown -R root:subversion myproject

$ sudo svnadmin create /home/svn/myproject

$ sudo chmod -R g+rws myproject

Can't open '/home/svn/myproject/db/txn-current-lock': Permission denied

$ ls -l /home/svn/myproject/db/txn-current-lock
-rw-rwSr-- 1 root subversion  0  2009-06-18  15:33  txn-current-lock

$ sudo chown -R root:subversion myproject

$ svn co file:///home/svn/myproject
或者
$ svn co file://localhost/home/svn/myproject

<Location /svn/myproject>
DAV svn
SVNPath /home/svn/myproject
AuthType Basic
AuthName "myproject subversion repository"
AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>

sudo /etc/init.d/apache2 restart

sudo htpasswd -c /etc/subversion/passwd user_name

sudo htpasswd /etc/subversion/passwd other_user_name

$ svn co http://hostname/svn/myproject myproject --username user_name

# [general]
# password-db = passwd

username = password
＃(注意行開(kāi)始不要有多余空格)

$ svnserve -d --foreground -r /home/svn
# -d -- daemon mode
# --foreground -- run in foreground (useful for debugging)
# -r -- root of directory to serve
要了解更多信息，請(qǐng)輸入：
$ svnserve --help

$ svn co svn://hostname/myproject myproject --username user_name

$ cd project_dir
$ svn update

$ svn co --help
或者這樣
$ svn --help commit
或者直接
? svn help co
checkout (co): 從版本庫(kù)簽出工作副本。
使用: checkout URL[@REV]... [PATH]
。。。。。

? killall svnserve; svnserve -d -r /home/svn/

/home/svn/lj12-source/conf ? dog *
authz:[groups]
authz:lj12 = veexp
authz:[lj12-source:/] <-注意寫(xiě)法。
authz:veexp = rw
authz:@lj12 = rw
authz:* = passwd:[users] <-2個(gè)用戶和密碼。
passwd:veexp = icep
passwd:test = test 
svnserve.conf:[general]
svnserve.conf:anon-access = none
svnserve.conf:auth-access = write
svnserve.conf:password-db = passwd
svnserve.conf:authz-db = authz <-如果不啟用authz，則test也可以取出。

? svn co svn://localhost/lj12-source --username veexp
認(rèn)證領(lǐng)域: <svn://localhost:3690> a712643f-661e-0410-8ad4-f0554cd88977
用戶名: veexp “veexp”的密碼:
A lj12-source/tim.h A lj12-source/en.c
......

eea34a6f7baa67a3639cacd6a428dba4

$ svn co svn+ssh://hostname/home/svn/myproject myproject --username user_name

（呵）近一段時(shí)間由于工作需要，終于開(kāi)始玩Linux了，今天搞了一天的MySQL編譯安裝，記錄下來(lái)，備忘吧?。?/p>

（卡）安裝環(huán)境：VmWare5(橋接模式) + RedHat E AS 4 + 已安裝了開(kāi)發(fā)工具以及相關(guān)開(kāi)發(fā)包(安裝Linux系統(tǒng)時(shí)自己要定制的)，并測(cè)試成功

（！）先給出MySQL For Linux 源碼下載地址，是xx.tar.zg格式的

http://www.filewatcher.com/m/mysql-5.0.45.tar.gz.24433261.0.0.html

（1）

      -------------預(yù)備工作----------

      1：假如下載的文件名為：mysql-5.0.45.tar.gz

      2：假如copy到 /home下

      3：groupadd mysql #添加mysql組

      4：useradd -g mysql mysql #添加一個(gè)mysql用戶

      5：cd /home #進(jìn)入到該目錄

      -----------------------編譯過(guò)程-----------------------

      6：tar zxvf mysql-5.0.45.tar.gz #解壓后，在該目錄下會(huì)出現(xiàn)一個(gè)同名的文件夾

      7：cd /home/mysql-5.0.45

      8：./configure --prefix=/usr/local/mysql --with-charset=utf8 --with-collation=utf8_general_ci --with-extra-charsets=latin1 #參數(shù)設(shè)置，可以先不明白，以后再修改配置

      9：make

      10：make install

      11：cp support-files/my-medium.cnf /etc/my.cnf #如果/etc/my.cnf已存在，則先備份，再刪除

      12：vi /etc/my.cnf #將log-bin=mysql-bin注釋掉

      ----------------------------安裝并初步配置mysql--------------------------

      13：cd /usr/local/mysql

      14：bin/mysql_install_db --user=mysql #初始化mysql

      15：chown -R root . #改當(dāng)前目錄的捅有者為root。注意，最后有個(gè) . 啊，表示當(dāng)前目錄

      16：chown -R mysql /usr/local/mysql/var #-R表示遞歸之下的所有目錄

      17：chgrp -R mysql /usr/local/mysql #改變目錄所屬為mysql

      18：bin/mysqld_safe --user=mysql & #啟動(dòng)mysql

      -----------------------------------------更改mysql的root用戶密碼----------------------------

      19：bin/mysqladmin -uroot password 123456 #在mysql政黨啟動(dòng)的情況下，更改root用戶的登錄密碼

      20：bin/mysql -uroot -p #輸入此命令后，會(huì)提示你輸入root用戶密碼123456，

      21：show databases; #如果查出所有數(shù)據(jù)庫(kù)，就恭喜你了

      ------------------------------------------------------把mysql加入到系統(tǒng)服務(wù)中-------------------------------------

      22：cp  /usr/local/mysql/share/mysql/mysql.server  /etc/init.d/mysqld      

             chkconfig --add  mysqld #加入到系統(tǒng)服務(wù)中，就可以通過(guò)service mysqld start|stop|status|restart等進(jìn)行管理，很是方便，就不用再到/usr/local/mysql5.0.45/bin/啟動(dòng)mysql了

      ------------------------------------------------------------------配置mysql環(huán)境變量------------------------------------------------

      23：cd /root #回到你的個(gè)人主目錄，我這里是用root登陸的

             cp .bashrc .bashrc.bak #備份一下吧

             vi .bashrc

             在最后加入：export PATH=/usr/local/mysql/bin:$PATH:.
             source ~/.bashrc #回到終端再輸入此命令，以使剛修改的起作用，~代表用戶主目錄

             env #查看一下是否生效

      24：此是用來(lái)替換23步的一種方法

             cp /usr/local/mysql/bin/mysql   /usr/bin/mysql #把mysql常用的工具目錄加入到系統(tǒng)變量目錄中去，自己選擇性加，這樣做主要是可以直接運(yùn)行該工具，而不需要切換到該目錄下，類似于添加環(huán)境變量了

      -------------------------------------------------------------------------------讓Linux開(kāi)放3306端口-------------------------------------------

      25：service iptables stop

             vi /etc/sysconfig/iptables

             -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT

             service iptables start

      -------------------------------------------------------------------------------給root用戶開(kāi)啟mysql遠(yuǎn)程訪問(wèn)權(quán)限--------------------------------------------

      26：shutdown -hr now #重啟

             ps -e | grep mysql #查看mysql是否已隨開(kāi)機(jī)啟動(dòng)，或者輸入：service mysqld status

             mysql -uroot -p #進(jìn)入mysql

             輸入root用戶的密碼

             grant all on *.* to root@'%' identified by '123456';

             #grant 權(quán)限 on 數(shù)據(jù)庫(kù)名.表名 to 用戶@登錄主機(jī) identified by "用戶密碼";

             flush privileges; #為了開(kāi)發(fā)方便,可以讓root用戶具有遠(yuǎn)程訪問(wèn)的權(quán)限

             #最后，再附上一個(gè)很好用的mysql客戶端，http://download.csdn.net/source/924456

（2）默認(rèn)的mysql數(shù)據(jù)庫(kù)目錄是 /usr/local/mysql-5.0.45/var

        我們?cè)诎惭b時(shí)指定了安裝目錄為/usr/local/mysql-5.0.45，除了在這里安裝所要的文件外，還有一部分用戶常用的，可執(zhí)行二進(jìn)制文件被放到了/usr/bin中，其實(shí)，在/usr/local/mysql-5.0.45/bin下，全都有這些命令了，之所以要在/usr/bin中把那幾個(gè)命令考過(guò)來(lái)，就是為了方便，相當(dāng)于設(shè)置環(huán)境變量了，你可以echo $PATH一下，里面一定有/usr/bin這個(gè)值的。

         明白了安裝過(guò)程，刪除mysql也就不足為難了

 （3）通過(guò)一個(gè)完整的例子，自己會(huì)學(xué)到很多東西，linux常用命令還真需要自己來(lái)，整理記錄

　　談這個(gè)話題之前，首先要讓大家知道，什么是服務(wù)器。在網(wǎng)絡(luò)游戲中，服務(wù)器所扮演的角色是同步，廣播和服務(wù)器主動(dòng)的一些行為，比如說(shuō)天氣，NPC AI之類的，之所以現(xiàn)在的很多網(wǎng)絡(luò)游戲服務(wù)器都需要負(fù)擔(dān)一些游戲邏輯上的運(yùn)算是因?yàn)闉榱朔乐箍蛻舳说淖鞅仔袨?。了解到這一點(diǎn)，那么本系列的文章將分為兩部分來(lái)談?wù)劸W(wǎng)絡(luò)游戲服務(wù)器的設(shè)計(jì)，一部分是講如何做好服務(wù)器的網(wǎng)絡(luò)連接，同步，廣播以及NPC的設(shè)置，另一部分則將著重談?wù)勀男┻壿嫹旁诜?wù)器比較合適，并且用什么樣的結(jié)構(gòu)來(lái)安排這些邏輯。


服務(wù)器的網(wǎng)絡(luò)連接

　　大多數(shù)的網(wǎng)絡(luò)游戲的服務(wù)器都會(huì)選擇非阻塞select這種結(jié)構(gòu)，為什么呢？因?yàn)榫W(wǎng)絡(luò)游戲的服務(wù)器需要處理的連接非常之多，并且大部分會(huì)選擇在Linux/Unix下運(yùn)行，那么為每個(gè)用戶開(kāi)一個(gè)線程實(shí)際上是很不劃算的，一方面因?yàn)樵贚inux/Unix下的線程是用進(jìn)程這么一個(gè)概念模擬出來(lái)的，比較消耗系統(tǒng)資源，另外除了I/O之外，每個(gè)線程基本上沒(méi)有什么多余的需要并行的任務(wù)，而且網(wǎng)絡(luò)游戲是互交性非常強(qiáng)的，所以線程間的同步會(huì)成為很麻煩的問(wèn)題。由此一來(lái)，對(duì)于這種含有大量網(wǎng)絡(luò)連接的單線程服務(wù)器，用阻塞顯然是不現(xiàn)實(shí)的。對(duì)于網(wǎng)絡(luò)連接，需要用一個(gè)結(jié)構(gòu)來(lái)儲(chǔ)存，其中需要包含一個(gè)向客戶端寫(xiě)消息的緩沖，還需要一個(gè)從客戶端讀消息的緩沖，具體的大小根據(jù)具體的消息結(jié)構(gòu)來(lái)定了。另外對(duì)于同步，需要一些時(shí)間校對(duì)的值，還需要一些各種不同的值來(lái)記錄當(dāng)前狀態(tài)，下面給出一個(gè)初步的連接的結(jié)構(gòu)：

typedef connection_s {

    user_t *ob; /* 指向處理服務(wù)器端邏輯的結(jié)構(gòu) */

    int fd; /* socket連接 */

    struct sockaddr_in addr; /* 連接的地址信息 */

    char text[MAX_TEXT]; /* 接收的消息緩沖 */

    int text_end; /* 接收消息緩沖的尾指針 */

    int text_start; /* 接收消息緩沖的頭指針 */

    int last_time; /* 上一條消息是什么時(shí)候接收到的 */

    struct timeval latency; /* 客戶端本地時(shí)間和服務(wù)器本地時(shí)間的差值 */

    struct timeval last_confirm_time; /* 上一次驗(yàn)證的時(shí)間 */

    short is_confirmed; /* 該連接是否通過(guò)驗(yàn)證過(guò) */

    int ping_num; /* 該客戶端到服務(wù)器端的ping值 */

    int ping_ticker; /* 多少個(gè)IO周期處理更新一次ping值 */

    int message_length; /* 發(fā)送緩沖消息長(zhǎng)度 */

    char message_buf[MAX_TEXT]; /* 發(fā)送緩沖區(qū) */

    int iflags; /* 該連接的狀態(tài) */

} connection_t;

　　服務(wù)器循環(huán)的處理所有連接，是一個(gè)死循環(huán)過(guò)程，每次循環(huán)都用select檢查是否有新連接到達(dá)，然后循環(huán)所有連接，看哪個(gè)連接可以寫(xiě)或者可以讀，就處理該連接的讀寫(xiě)。由于所有的處理都是非阻塞的，所以所有的Socket IO都可以用一個(gè)線程來(lái)完成。

　　由于網(wǎng)絡(luò)傳輸?shù)年P(guān)系，每次recv()到的數(shù)據(jù)可能不止包含一條消息，或者不到一條消息，那么怎么處理呢？所以對(duì)于接收消息緩沖用了兩個(gè)指針，每次接收都從text_start開(kāi)始讀起，因?yàn)槔锩鏆埩舻目赡苁巧洗谓邮盏降亩嘤嗟陌霔l消息，然后text_end指向消息緩沖的結(jié)尾。這樣用兩個(gè)指針就可以很方便的處理這種情況，另外有一點(diǎn)值得注意的是：解析消息的過(guò)程是一個(gè)循環(huán)的過(guò)程，可能一次接收到兩條以上的消息在消息緩沖里面，這個(gè)時(shí)候就應(yīng)該執(zhí)行到消息緩沖里面只有一條都不到的消息為止，大體流程如下：

while ( text_end – text_start > 一條完整的消息長(zhǎng)度 )

{

    從text_start處開(kāi)始處理;

    text_start += 該消息長(zhǎng)度;

}

memcpy ( text, text + text_start, text_end – text_start );

　　對(duì)于消息的處理，這里首先就需要知道你的游戲總共有哪些消息，所有的消息都有哪些，才能設(shè)計(jì)出比較合理的消息頭。一般來(lái)說(shuō)，消息大概可分為主角消息，場(chǎng)景消息，同步消息和界面消息四個(gè)部分。其中主角消息包括客戶端所控制的角色的所有動(dòng)作，包括走路，跑步，戰(zhàn)斗之類的。場(chǎng)景消息包括天氣變化，一定的時(shí)間在場(chǎng)景里出現(xiàn)一些東西等等之類的，這類消息的特點(diǎn)是所有消息的發(fā)起者都是服務(wù)器，廣播對(duì)象則是場(chǎng)景里的所有玩家。而同步消息則是針對(duì)發(fā)起對(duì)象是某個(gè)玩家，經(jīng)過(guò)服務(wù)器廣播給所有看得見(jiàn)他的玩家，該消息也是包括所有的動(dòng)作，和主角消息不同的是該種消息是服務(wù)器廣播給客戶端的，而主角消息一般是客戶端主動(dòng)發(fā)給服務(wù)器的。最后是界面消息，界面消息包括是服務(wù)器發(fā)給客戶端的聊天消息和各種屬性及狀態(tài)信息。

　　下面來(lái)談?wù)勏⒌慕M成。一般來(lái)說(shuō)，一個(gè)消息由消息頭和消息體兩部分組成，其中消息頭的長(zhǎng)度是不變的，而消息體的長(zhǎng)度是可變的，在消息體中需要保存消息體的長(zhǎng)度。由于要給每條消息一個(gè)很明顯的區(qū)分，所以需要定義一個(gè)消息頭特有的標(biāo)志，然后需要消息的類型以及消息ID。消息頭大體結(jié)構(gòu)如下：

type struct message_s {

    unsigned short message_sign;

    unsigned char message_type;

    unsigned short message_id

    unsigned char message_len

}message_t;


服務(wù)器的廣播

　　服務(wù)器的廣播的重點(diǎn)就在于如何計(jì)算出廣播的對(duì)象。很顯然，在一張很大的地圖里面，某個(gè)玩家在最東邊的一個(gè)動(dòng)作，一個(gè)在最西邊的玩家是應(yīng)該看不到的，那么怎么來(lái)計(jì)算廣播的對(duì)象呢？最簡(jiǎn)單的辦法，就是把地圖分塊，分成大小合適的小塊，然后每次只象周圍幾個(gè)小塊的玩家進(jìn)行廣播。那么究竟切到多大比較合適呢？一般來(lái)說(shuō)，切得塊大了，內(nèi)存的消耗會(huì)增大，切得塊小了，CPU的消耗會(huì)增大（原因會(huì)在后面提到）。個(gè)人覺(jué)得切成一屏左右的小塊比較合適，每次廣播廣播周圍九個(gè)小塊的玩家，由于廣播的操作非常頻繁，那么遍利周圍九塊的操作就會(huì)變得相當(dāng)?shù)念l繁，所以如果塊分得小了，那么遍利的范圍就會(huì)擴(kuò)大，CPU的資源會(huì)很快的被吃完。

　　切好塊以后，怎么讓玩家在各個(gè)塊之間走來(lái)走去呢？讓我們來(lái)想想在切換一次塊的時(shí)候要做哪些工作。首先，要算出下個(gè)塊的周圍九塊的玩家有哪些是現(xiàn)在當(dāng)前塊沒(méi)有的，把自己的信息廣播給那些玩家，同時(shí)也要算出下個(gè)塊周圍九塊里面有哪些物件是現(xiàn)在沒(méi)有的，把那些物件的信息廣播給自己，然后把下個(gè)塊的周圍九快里沒(méi)有的，而現(xiàn)在的塊周圍九塊里面有的物件的消失信息廣播給自己，同時(shí)也把自己消失的消息廣播給那些物件。這個(gè)操作不僅煩瑣而且會(huì)吃掉不少CPU資源，那么有什么辦法可以很快的算出這些物件呢？一個(gè)個(gè)做比較？顯然看起來(lái)就不是個(gè)好辦法，這里可以參照二維矩陣碰撞檢測(cè)的一些思路，以自己周圍九塊為一個(gè)矩陣，目標(biāo)塊周圍九塊為另一個(gè)矩陣，檢測(cè)這兩個(gè)矩陣是否碰撞，如果兩個(gè)矩陣相交，那么沒(méi)相交的那些塊怎么算。這里可以把相交的塊的坐標(biāo)轉(zhuǎn)換成內(nèi)部坐標(biāo)，然后再進(jìn)行運(yùn)算。

　　對(duì)于廣播還有另外一種解決方法，實(shí)施起來(lái)不如切塊來(lái)的簡(jiǎn)單，這種方法需要客戶端來(lái)協(xié)助進(jìn)行運(yùn)算。首先在服務(wù)器端的連接結(jié)構(gòu)里面需要增加一個(gè)廣播對(duì)象的隊(duì)列，該隊(duì)列在客戶端登陸服務(wù)器的時(shí)候由服務(wù)器傳給客戶端，然后客戶端自己來(lái)維護(hù)這個(gè)隊(duì)列，當(dāng)有人走出客戶端視野的時(shí)候，由客戶端主動(dòng)要求服務(wù)器給那個(gè)物件發(fā)送消失的消息。而對(duì)于有人總進(jìn)視野的情況，則比較麻煩了。

　　首先需要客戶端在每次給服務(wù)器發(fā)送update position的消息的時(shí)候，服務(wù)器都給該連接算出一個(gè)視野范圍，然后在需要廣播的時(shí)候，循環(huán)整張地圖上的玩家，找到坐標(biāo)在其視野范圍內(nèi)的玩家。使用這種方法的好處在于不存在轉(zhuǎn)換塊的時(shí)候需要一次性廣播大量的消息，缺點(diǎn)就是在計(jì)算廣播對(duì)象的時(shí)候需要遍歷整個(gè)地圖上的玩家，如果當(dāng)一個(gè)地圖上的玩家多得比較離譜的時(shí)候，該操作就會(huì)比較的慢。


服務(wù)器的同步

　　同步在網(wǎng)絡(luò)游戲中是非常重要的，它保證了每個(gè)玩家在屏幕上看到的東西大體是一樣的。其實(shí)呢，解決同步問(wèn)題的最簡(jiǎn)單的方法就是把每個(gè)玩家的動(dòng)作都向其他玩家廣播一遍，這里其實(shí)就存在兩個(gè)問(wèn)題：1，向哪些玩家廣播，廣播哪些消息。2，如果網(wǎng)絡(luò)延遲怎么辦。事實(shí)上呢，第一個(gè)問(wèn)題是個(gè)非常簡(jiǎn)單的問(wèn)題，不過(guò)之所以我提出這個(gè)問(wèn)題來(lái)，是提醒大家在設(shè)計(jì)自己的消息結(jié)構(gòu)的時(shí)候，需要把這個(gè)因素考慮進(jìn)去。而對(duì)于第二個(gè)問(wèn)題，則是一個(gè)挺麻煩的問(wèn)題，大家可以來(lái)看這么個(gè)例子：

　　比如有一個(gè)玩家A向服務(wù)器發(fā)了條指令，說(shuō)我現(xiàn)在在P1點(diǎn)，要去P2點(diǎn)。指令發(fā)出的時(shí)間是T0，服務(wù)器收到指令的時(shí)間是T1，然后向周圍的玩家廣播這條消息，消息的內(nèi)容是“玩家A從P1到P2”有一個(gè)在A附近的玩家B，收到服務(wù)器的這則廣播的消息的時(shí)間是T2，然后開(kāi)始在客戶端上畫(huà)圖，A從P1到P2點(diǎn)。這個(gè)時(shí)候就存在一個(gè)不同步的問(wèn)題，玩家A和玩家B的屏幕上顯示的畫(huà)面相差了T2-T1的時(shí)間。這個(gè)時(shí)候怎么辦呢？



　　有個(gè)解決方案，我給它取名叫 預(yù)測(cè)拉扯，雖然有些怪異了點(diǎn)，不過(guò)基本上大家也能從字面上來(lái)理解它的意思。要解決這個(gè)問(wèn)題，首先要定義一個(gè)值叫：預(yù)測(cè)誤差。然后需要在服務(wù)器端每個(gè)玩家連接的類里面加一項(xiàng)屬性，叫l(wèi)atency，然后在玩家登陸的時(shí)候，對(duì)客戶端的時(shí)間和服務(wù)器的時(shí)間進(jìn)行比較，得出來(lái)的差值保存在latency里面。還是上面的那個(gè)例子，服務(wù)器廣播消息的時(shí)候，就根據(jù)要廣播對(duì)象的latency，計(jì)算出一個(gè)客戶端的CurrentTime，然后在消息頭里面包含這個(gè)CurrentTime，然后再進(jìn)行廣播。并且同時(shí)在玩家A的客戶端本地建立一個(gè)隊(duì)列，保存該條消息，只到獲得服務(wù)器驗(yàn)證就從未被驗(yàn)證的消息隊(duì)列里面將該消息刪除，如果驗(yàn)證失敗，則會(huì)被拉扯回P1點(diǎn)。然后當(dāng)玩家B收到了服務(wù)器發(fā)過(guò)來(lái)的消息“玩家A從P1到P2”這個(gè)時(shí)候就檢查消息里面服務(wù)器發(fā)出的時(shí)間和本地時(shí)間做比較，如果大于定義的預(yù)測(cè)誤差，就算出在T2這個(gè)時(shí)間，玩家A的屏幕上走到的地點(diǎn)P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再繼續(xù)走下去，這樣就能保證同步。更進(jìn)一步，為了保證客戶端運(yùn)行起來(lái)更加smooth，我并不推薦直接把玩家拉扯過(guò)去，而是算出P3偏后的一點(diǎn)P4，然后用(P4-P1)/T(P4-P3)來(lái)算出一個(gè)很快的速度S，然后讓玩家A用速度S快速移動(dòng)到P4，這樣的處理方法是比較合理的，這種解決方案的原形在國(guó)際上被稱為（Full plesiochronous），當(dāng)然，該原形被我篡改了很多來(lái)適應(yīng)網(wǎng)絡(luò)游戲的同步，所以而變成所謂的：預(yù)測(cè)拉扯。

　　另外一個(gè)解決方案，我給它取名叫 驗(yàn)證同步，聽(tīng)名字也知道，大體的意思就是每條指令在經(jīng)過(guò)服務(wù)器驗(yàn)證通過(guò)了以后再執(zhí)行動(dòng)作。具體的思路如下：首先也需要在每個(gè)玩家連接類型里面定義一個(gè)latency，然后在客戶端響應(yīng)玩家鼠標(biāo)行走的同時(shí)，客戶端并不會(huì)先行走動(dòng)，而是發(fā)一條走路的指令給服務(wù)器，然后等待服務(wù)器的驗(yàn)證。服務(wù)器接受到這條消息以后，進(jìn)行邏輯層的驗(yàn)證，然后計(jì)算出需要廣播的范圍，包括玩家A在內(nèi)，根據(jù)各個(gè)客戶端不同的latency生成不同的消息頭，開(kāi)始廣播，這個(gè)時(shí)候這個(gè)玩家的走路信息就是完全同步的了。這個(gè)方法的優(yōu)點(diǎn)是能保證各個(gè)客戶端之間絕對(duì)的同步，缺點(diǎn)是當(dāng)網(wǎng)絡(luò)延遲比較大的時(shí)候，玩家的客戶端的行為會(huì)變得比較不流暢，給玩家?guī)?lái)很不爽的感覺(jué)。該種解決方案的原形在國(guó)際上被稱為（Hierarchical master-slave synchronization），80年代以后被廣泛應(yīng)用于網(wǎng)絡(luò)的各個(gè)領(lǐng)域。

　　最后一種解決方案是一種理想化的解決方案，在國(guó)際上被稱為Mutual synchronization，是一種對(duì)未來(lái)網(wǎng)絡(luò)的前景的良好預(yù)測(cè)出來(lái)的解決方案。這里之所以要提這個(gè)方案，并不是說(shuō)我們已經(jīng)完全的實(shí)現(xiàn)了這種方案，而只是在網(wǎng)絡(luò)游戲領(lǐng)域的某些方面應(yīng)用到這種方案的某些思想。我對(duì)該種方案取名為：半服務(wù)器同步。大體的設(shè)計(jì)思路如下：

　　首先客戶端需要在登陸世界的時(shí)候建立很多張廣播列表，這些列表在客戶端后臺(tái)和服務(wù)器要進(jìn)行不及時(shí)同步，之所以要建立多張列表，是因?yàn)橐獜V播的類型是不止一種的，比如說(shuō)有l(wèi)ocal message,有remote message,還有g(shù)lobal message 等等，這些列表都需要在客戶端登陸的時(shí)候根據(jù)服務(wù)器發(fā)過(guò)來(lái)的消息建立好。在建立列表的同時(shí)，還需要獲得每個(gè)列表中廣播對(duì)象的latency，并且要維護(hù)一張完整的用戶狀態(tài)列表在后臺(tái)，也是不及時(shí)的和服務(wù)器進(jìn)行同步，根據(jù)本地的用戶狀態(tài)表，可以做到一部分決策由客戶端自己來(lái)決定，當(dāng)客戶端發(fā)送這部分決策的時(shí)候，則直接將最終決策發(fā)送到各個(gè)廣播列表里面的客戶端，并對(duì)其時(shí)間進(jìn)行校對(duì)，保證每個(gè)客戶端在收到的消息的時(shí)間是和根據(jù)本地時(shí)間進(jìn)行校對(duì)過(guò)的。那么再采用預(yù)測(cè)拉扯中提到過(guò)的計(jì)算提前量，提高速度行走過(guò)去的方法，將會(huì)使同步變得非常的smooth。該方案的優(yōu)點(diǎn)是不通過(guò)服務(wù)器，客戶端自己之間進(jìn)行同步，大大的降低了由于網(wǎng)絡(luò)延遲而帶來(lái)的誤差，并且由于大部分決策都可以由客戶端來(lái)做，也大大的降低了服務(wù)器的資源。由此帶來(lái)的弊端就是由于消息和決策權(quán)都放在客戶端本地，所以給外掛提供了很大的可乘之機(jī)。

　　下面我想來(lái)談?wù)勱P(guān)于服務(wù)器上NPC的設(shè)計(jì)以及NPC智能等一些方面涉及到的問(wèn)題。首先，我們需要知道什么是NPC，NPC需要做什么。NPC的全稱是（Non-Player Character），很顯然，他是一個(gè)character，但不是玩家，那么從這點(diǎn)上可以知道，NPC的某些行為是和玩家類似的，他可以行走，可以戰(zhàn)斗，可以呼吸（這點(diǎn)將在后面的NPC智能里面提到），另外一點(diǎn)和玩家物件不同的是，NPC可以復(fù)生（即NPC被打死以后在一定時(shí)間內(nèi)可以重新出來(lái)）。其實(shí)還有最重要的一點(diǎn)，就是玩家物件的所有決策都是玩家做出來(lái)的，而NPC的決策則是由計(jì)算機(jī)做出來(lái)的，所以在對(duì)NPC做何種決策的時(shí)候，需要所謂的NPC智能來(lái)進(jìn)行決策。

　　下面我將分兩個(gè)部分來(lái)談?wù)凬PC，首先是NPC智能，其次是服務(wù)器如何對(duì)NPC進(jìn)行組織。之所以要先談NPC智能是因?yàn)橹挥挟?dāng)我們了解清楚我們需要NPC做什么之后，才好開(kāi)始設(shè)計(jì)服務(wù)器來(lái)對(duì)NPC進(jìn)行組織。


NPC智能

　　NPC智能分為兩種，一種是被動(dòng)觸發(fā)的事件，一種是主動(dòng)觸發(fā)的事件。對(duì)于被動(dòng)觸發(fā)的事件，處理起來(lái)相對(duì)來(lái)說(shuō)簡(jiǎn)單一些，可以由事件本身來(lái)呼叫NPC身上的函數(shù)，比如說(shuō)NPC的死亡，實(shí)際上是在NPC的HP小于一定值的時(shí)候，來(lái)主動(dòng)呼叫NPC身上的OnDie() 函數(shù)，這種由事件來(lái)觸發(fā)NPC行為的NPC智能，我稱為被動(dòng)觸發(fā)。這種類型的觸發(fā)往往分為兩種：

一種是由別的物件導(dǎo)致的NPC的屬性變化，然后屬性變化的同時(shí)會(huì)導(dǎo)致NPC產(chǎn)生一些行為。由此一來(lái)，NPC物件里面至少包含以下幾種函數(shù)：

class NPC {

public:

    // 是誰(shuí)在什么地方導(dǎo)致了我哪項(xiàng)屬性改變了多少。

    OnChangeAttribute(object_t *who, int which, int how, int where);

Private:

    OnDie();

    OnEscape();

    OnFollow();

    OnSleep();

    // 一系列的事件。

}

　　這是一個(gè)基本的NPC的結(jié)構(gòu)，這種被動(dòng)的觸發(fā)NPC的事件，我稱它為NPC的反射。但是，這樣的結(jié)構(gòu)只能讓NPC被動(dòng)的接收一些信息來(lái)做出決策，這樣的NPC是愚蠢的。那么，怎么樣讓一個(gè)NPC能夠主動(dòng)的做出一些決策呢？這里有一種方法：呼吸。那么怎么樣讓NPC有呼吸呢？

　　一種很簡(jiǎn)單的方法，用一個(gè)計(jì)時(shí)器，定時(shí)的觸發(fā)所有NPC的呼吸，這樣就可以讓一個(gè)NPC有呼吸起來(lái)。這樣的話會(huì)有一個(gè)問(wèn)題，當(dāng)NPC太多的時(shí)候，上一次NPC的呼吸還沒(méi)有呼吸完，下一次呼吸又來(lái)了，那么怎么解決這個(gè)問(wèn)題呢。這里有一種方法，讓NPC異步的進(jìn)行呼吸，即每個(gè)NPC的呼吸周期是根據(jù)NPC出生的時(shí)間來(lái)定的，這個(gè)時(shí)候計(jì)時(shí)器需要做的就是隔一段時(shí)間檢查一下，哪些NPC到時(shí)間該呼吸了，就來(lái)觸發(fā)這些NPC的呼吸。

　　上面提到的是系統(tǒng)如何來(lái)觸發(fā)NPC的呼吸，那么NPC本身的呼吸頻率該如何設(shè)定呢？這個(gè)就好象現(xiàn)實(shí)中的人一樣，睡覺(jué)的時(shí)候和進(jìn)行激烈運(yùn)動(dòng)的時(shí)候，呼吸頻率是不一樣的。同樣，NPC在戰(zhàn)斗的時(shí)候，和平常的時(shí)候，呼吸頻率也不一樣。那么就需要一個(gè)Breath_Ticker來(lái)設(shè)置NPC當(dāng)前的呼吸頻率。

　　那么在NPC的呼吸事件里面，我們?cè)趺礃觼?lái)設(shè)置NPC的智能呢？大體可以概括為檢查環(huán)境和做出決策兩個(gè)部分。首先，需要對(duì)當(dāng)前環(huán)境進(jìn)行數(shù)字上的統(tǒng)計(jì)，比如說(shuō)是否在戰(zhàn)斗中，戰(zhàn)斗有幾個(gè)敵人，自己的HP還剩多少，以及附近有沒(méi)有敵人等等之類的統(tǒng)計(jì)。統(tǒng)計(jì)出來(lái)的數(shù)據(jù)傳入本身的決策模塊，決策模塊則根據(jù)NPC自身的性格取向來(lái)做出一些決策，比如說(shuō)野蠻型的NPC會(huì)在HP比較少的時(shí)候仍然猛撲猛打，又比如說(shuō)智慧型的NPC則會(huì)在HP比較少的時(shí)候選擇逃跑。等等之類的。

　　至此，一個(gè)可以呼吸，反射的NPC的結(jié)構(gòu)已經(jīng)基本構(gòu)成了，那么接下來(lái)我們就來(lái)談?wù)勏到y(tǒng)如何組織讓一個(gè)NPC出現(xiàn)在世界里面。


NPC的組織

　　這里有兩種方案可供選擇，其一：NPC的位置信息保存在場(chǎng)景里面，載入場(chǎng)景的時(shí)候載入NPC。其二，NPC的位置信息保存在NPC身上，有專門(mén)的事件讓所有的NPC登陸場(chǎng)景。這兩種方法有什么區(qū)別呢？又各有什么好壞呢？

　　前一種方法好處在于場(chǎng)景載入的時(shí)候同時(shí)載入了NPC，場(chǎng)景就可以對(duì)NPC進(jìn)行管理，不需要多余的處理，而弊端則在于在刷新的時(shí)候是同步刷新的，也就是說(shuō)一個(gè)場(chǎng)景里面的NPC可能會(huì)在同一時(shí)間內(nèi)長(zhǎng)出來(lái)。而對(duì)于第二種方法呢，設(shè)計(jì)起來(lái)會(huì)稍微麻煩一些，需要一個(gè)統(tǒng)一的機(jī)制讓NPC登陸到場(chǎng)景，還需要一些比較麻煩的設(shè)計(jì)，但是這種方案可以實(shí)現(xiàn)NPC異步的刷新，是目前網(wǎng)絡(luò)游戲普遍采用的方法，下面我們就來(lái)著重談?wù)勥@種方法的實(shí)現(xiàn)：

　　首先我們要引入一個(gè)“靈魂”的概念，即一個(gè)NPC在死后，消失的只是他的肉體，他的靈魂仍然在世界中存在著，沒(méi)有呼吸，在死亡的附近漂浮，等著到時(shí)間投胎，投胎的時(shí)候把之前的所有屬性清零，重新在場(chǎng)景上構(gòu)建其肉體。那么，我們?cè)趺磥?lái)設(shè)計(jì)這樣一個(gè)結(jié)構(gòu)呢？首先把一個(gè)場(chǎng)景里面要出現(xiàn)的NPC制作成圖量表，給每個(gè)NPC一個(gè)獨(dú)一無(wú)二的標(biāo)識(shí)符，在載入場(chǎng)景之后，根據(jù)圖量表來(lái)載入屬于該場(chǎng)景的NPC。在NPC的OnDie() 事件里面不直接把該物件destroy 掉，而是關(guān)閉NPC的呼吸，然后打開(kāi)一個(gè)重生的計(jì)時(shí)器，最后把該物件設(shè)置為invisable。這樣的設(shè)計(jì)，可以實(shí)現(xiàn)NPC的異步刷新，在節(jié)省服務(wù)器資源的同時(shí)也讓玩家覺(jué)得更加的真實(shí)。

（這一章節(jié)已經(jīng)牽扯到一些服務(wù)器腳本相關(guān)的東西，所以下一章節(jié)將談?wù)劮?wù)器腳本相關(guān)的一些設(shè)計(jì)）

補(bǔ)充的談?wù)剢l(fā)式搜索（heuristic searching）在NPC智能中的應(yīng)用。

　　其主要思路是在廣度優(yōu)先搜索的同時(shí)，將下一層的所有節(jié)點(diǎn)經(jīng)過(guò)一個(gè)啟發(fā)函數(shù)進(jìn)行過(guò)濾，一定范圍內(nèi)縮小搜索范圍。眾所周知的尋路A*算法就是典型的啟發(fā)式搜索的應(yīng)用，其原理是一開(kāi)始設(shè)計(jì)一個(gè)Judge(point_t* point)函數(shù)，來(lái)獲得point這個(gè)一點(diǎn)的代價(jià)，然后每次搜索的時(shí)候把下一步可能到達(dá)的所有點(diǎn)都經(jīng)過(guò)Judge()函數(shù)評(píng)價(jià)一下，獲取兩到三個(gè)代價(jià)比較小的點(diǎn)，繼續(xù)搜索，那些沒(méi)被選上的點(diǎn)就不會(huì)在繼續(xù)搜索下去了，這樣帶來(lái)的后果的是可能求出來(lái)的不是最優(yōu)路徑，這也是為什么A*算法在尋路的時(shí)候會(huì)走到障礙物前面再繞過(guò)去，而不是預(yù)先就走斜線來(lái)繞過(guò)該障礙物。如果要尋出最優(yōu)化的路徑的話，是不能用A*算法的，而是要用動(dòng)態(tài)規(guī)劃的方法，其消耗是遠(yuǎn)大于A*的。

　　那么，除了在尋路之外，還有哪些地方可以應(yīng)用到啟發(fā)式搜索呢？其實(shí)說(shuō)得大一點(diǎn)，NPC的任何決策都可以用啟發(fā)式搜索來(lái)做，比如說(shuō)逃跑吧，如果是一個(gè)2D的網(wǎng)絡(luò)游戲，有八個(gè)方向，NPC選擇哪個(gè)方向逃跑呢？就可以設(shè)置一個(gè)Judge(int direction)來(lái)給定每個(gè)點(diǎn)的代價(jià)，在Judge里面算上該點(diǎn)的敵人的強(qiáng)弱，或者該敵人的敏捷如何等等，最后選擇代價(jià)最小的地方逃跑。下面，我們就來(lái)談?wù)剬?duì)于幾種NPC常見(jiàn)的智能的啟發(fā)式搜索法的設(shè)計(jì)：

Target select （選擇目標(biāo)）：

　　首先獲得地圖上離該NPC附近的敵人列表。設(shè)計(jì)Judge() 函數(shù)，根據(jù)敵人的強(qiáng)弱，敵人的遠(yuǎn)近，算出代價(jià)。然后選擇代價(jià)最小的敵人進(jìn)行主動(dòng)攻擊。

Escape（逃跑）：

　　在呼吸事件里面檢查自己的HP，如果HP低于某個(gè)值的時(shí)候，或者如果你是遠(yuǎn)程兵種，而敵人近身的話，則觸發(fā)逃跑函數(shù)，在逃跑函數(shù)里面也是對(duì)周圍的所有的敵人組織成列表，然后設(shè)計(jì)Judge() 函數(shù)，先選擇出對(duì)你構(gòu)成威脅最大的敵人，該Judge() 函數(shù)需要判斷敵人的速度，戰(zhàn)斗力強(qiáng)弱，最后得出一個(gè)主要敵人，然后針對(duì)該主要敵人進(jìn)行路徑的Judge() 的函數(shù)的設(shè)計(jì)，搜索的范圍只可能是和主要敵人相反的方向，然后再根據(jù)該幾個(gè)方向的敵人的強(qiáng)弱來(lái)計(jì)算代價(jià)，做出最后的選擇。

Random walk（隨機(jī)走路）：

　　這個(gè)我并不推薦用A*算法，因?yàn)镹PC一旦多起來(lái)，那么這個(gè)對(duì)CPU的消耗是很恐怖的，而且NPC大多不需要長(zhǎng)距離的尋路，只需要在附近走走即可，那么，就在附近隨機(jī)的給幾個(gè)點(diǎn)，然后讓NPC走過(guò)去，如果碰到障礙物就停下來(lái)，這樣幾乎無(wú)任何負(fù)擔(dān)。

Follow Target（追隨目標(biāo)）：

　　這里有兩種方法，一種方法NPC看上去比較愚蠢，一種方法看上去NPC比較聰明，第一種方法就是讓NPC跟著目標(biāo)的路點(diǎn)走即可，幾乎沒(méi)有資源消耗。而后一種則是讓NPC在跟隨的時(shí)候，在呼吸事件里面判斷對(duì)方的當(dāng)前位置，然后走直線，碰上障礙物了用A*繞過(guò)去，該種設(shè)計(jì)會(huì)消耗一定量的系統(tǒng)資源，所以不推薦NPC大量的追隨目標(biāo)，如果需要大量的NPC追隨目標(biāo)的話，還有一個(gè)比較簡(jiǎn)單的方法：讓NPC和目標(biāo)同步移動(dòng)，即讓他們的速度統(tǒng)一，移動(dòng)的時(shí)候走同樣的路點(diǎn)，當(dāng)然，這種設(shè)計(jì)只適合NPC所跟隨的目標(biāo)不是追殺的關(guān)系，只是跟隨著玩家走而已了。

　　在這一章節(jié)，我想談?wù)勱P(guān)于服務(wù)器端的腳本的相關(guān)設(shè)計(jì)。因?yàn)樵谏弦徽鹿?jié)里面，談NPC智能相關(guān)的時(shí)候已經(jīng)接觸到一些腳本相關(guān)的東東了。還是先來(lái)談?wù)勀_本的作用吧。
　　在基于編譯的服務(wù)器端程序中，是無(wú)法在程序的運(yùn)行過(guò)程中構(gòu)建一些東西的，那么這個(gè)時(shí)候就需要腳本語(yǔ)言的支持了，由于腳本語(yǔ)言涉及到邏輯判斷，所以光提供一些函數(shù)接口是沒(méi)用的，還需要提供一些簡(jiǎn)單的語(yǔ)法和文法解析的功能。其實(shí)說(shuō)到底，任何的事件都可以看成兩個(gè)部分：第一是對(duì)自身，或者別的物件的數(shù)值的改變，另外一個(gè)就是將該事件以文字或者圖形的方式廣播出去。那么，這里牽扯到一個(gè)很重要的話題，就是對(duì)某一物件進(jìn)行尋址。恩，談到這，我想將本章節(jié)分為三個(gè)部分來(lái)談，首先是服務(wù)器如何來(lái)管理動(dòng)態(tài)創(chuàng)建出來(lái)的物件（服務(wù)器內(nèi)存管理），第二是如何對(duì)某一物件進(jìn)行尋址，第三則是腳本語(yǔ)言的組織和解釋。其實(shí)之所以到第四章再來(lái)談服務(wù)器的內(nèi)存管理是因?yàn)樵谇皫渍抡勥@個(gè)的話，大家對(duì)其沒(méi)有一個(gè)感性的認(rèn)識(shí)，可能不知道服務(wù)器的內(nèi)存管理究竟有什么用。

4.1、服務(wù)器內(nèi)存管理
　　對(duì)于服務(wù)器內(nèi)存管理我們將采用內(nèi)存池的方法，也稱為靜態(tài)內(nèi)存管理。其概念為在服務(wù)器初始化的時(shí)候，申請(qǐng)一塊非常大的內(nèi)存，稱為內(nèi)存池（Memory pool），同時(shí)也申請(qǐng)一小塊內(nèi)存空間，稱為垃圾回收站（Garbage recollecting station）。其大體思路如下：當(dāng)程序需要申請(qǐng)內(nèi)存的時(shí)候，首先檢查垃圾回收站是否為空，如果不為空的話，則從垃圾回收站中找一塊可用的內(nèi)存地址，在內(nèi)存池中根據(jù)地址找到相應(yīng)的空間，分配給程序用，如果垃圾回收站是空的話，則直接從內(nèi)存池的當(dāng)前指針位置申請(qǐng)一塊內(nèi)存；當(dāng)程序釋放空間的時(shí)候，給那塊內(nèi)存打上已經(jīng)釋放掉的標(biāo)記，然后把那塊內(nèi)存的地址放入垃圾回收站。
　　下面具體談?wù)勗摲椒ǖ脑敿?xì)設(shè)計(jì)，首先，我們將采用類似于操作系統(tǒng)的段頁(yè)式系統(tǒng)來(lái)管理內(nèi)存，這樣的好處是可以充分的利用內(nèi)存池，其缺點(diǎn)是管理起來(lái)比較麻煩。嗯，下面來(lái)具體看看我們?cè)趺礃觼?lái)定義頁(yè)和段的結(jié)構(gòu)：

　　typedef struct m_segment_s
　　{
　　　　struct m_segment_s *next;　/* 雙線鏈表 + 靜態(tài)內(nèi)存可以達(dá)到隨機(jī)訪問(wèn)和順序訪問(wèn)的目的，
　　　　　　　　　　　　　　　　　　　真正的想怎么訪問(wèn)，就怎么訪問(wèn)。 */
　　　　struct m_segment_s *pre; int flags;　　// 該段的一些標(biāo)記。
　　　　int start;　　　　　　　　　　　　　　 // 相對(duì)于該頁(yè)的首地址。
　　　　int size;　　　　　　　　　　　　　　　// 長(zhǎng)度。
　　　　struct m_page_s *my_owner;　　　　　　 // 我是屬于哪一頁(yè)的。
　　　　char *data;　　　　　　　　　　　　　　// 內(nèi)容指針。
　　}m_segment_t;

　　typedef struct m_page_s
　　{
　　　　unsigned int flags;　　　 /* 使用標(biāo)記，是否完全使用，是否還有空余 */
　　　　int size;　　　　　　　　 /* 該頁(yè)的大小，一般都是統(tǒng)一的，最后一頁(yè)除外 */
　　　　int end;　　　　　　　 　 /* 使用到什么地方了 */
　　　　int my_index;　　　　　　 /* 提供隨機(jī)訪問(wèn)的索引 */
　　　　m_segment_t *segments;　　// 頁(yè)內(nèi)段的頭指針。
　　}m_page_t;

　　那么內(nèi)存池和垃圾回收站怎么構(gòu)建呢？下面也給出一些構(gòu)建相關(guān)的偽代碼：

　　static m_page_t *all_pages;
　　// total_size是總共要申請(qǐng)的內(nèi)存數(shù)，num_pages是總共打算創(chuàng)建多少個(gè)頁(yè)面。
　　void initialize_memory_pool( int total_size, int num_pages )
　　{
　　　　int i, page_size, last_size;　　　　 // 算出每個(gè)頁(yè)面的大小。
　　　　page_size = total_size / num_pages;　// 分配足夠的頁(yè)面。
　　　　all_pages = (m_page_t*) calloc( num_pages, sizeof(m_page_t*) );
　　　　for ( i = 0; i < num_pages; i ++ )
　　　　{
　　　　　　// 初始化每個(gè)頁(yè)面的段指針。
　　　　　　all_pages[i].m_segment_t = (m_segment_t*) malloc( page_size );
　　　　　　// 初始化該頁(yè)面的標(biāo)記。
　　　　　　all_pages[i].flags |= NEVER_USED;
　　　　　　// 除了最后一個(gè)頁(yè)面，其他的大小都是page_size 大小。
　　　　　　all_pages[i].size = page_size;
　　　　　　// 初始化隨機(jī)訪問(wèn)的索引。
　　　　　　all_pages[i].my_index = i;
　　　　　　// 由于沒(méi)有用過(guò)，所以大小都是0
　　　　　　all_pages[i].end = 0;
　　　　}

　　　　// 設(shè)置最后一個(gè)頁(yè)面的大小。
　　　　if ( (last_size = total_size % num_pages) != 0 )
　　　　　　all_pages[i].size = last_size;
　　}

　　下面看看垃圾回收站怎么設(shè)計(jì)：

　　int **garbage_station;
　　void init_garbage_station( int num_pages, int page_size )
　　{
　　　　int i;
　　　　garbage_station = (int**) calloc( num_pages, sizeof( int* ) );
　　　　for ( i = 0; i < num_pages; i ++)
　　　　{
　　　　　　// 這里用unsigned short的高8位來(lái)儲(chǔ)存首相對(duì)地址，低8位來(lái)儲(chǔ)存長(zhǎng)度。
　　　　　　garbage_station[i] = (int*) calloc( page_size, sizeof( unsigned short ));
　　　　　　memset( garbage_station[i], 0, sizeof( garbage_station[i] ));
　　　　}
　　}

　　也許這樣的貼代碼會(huì)讓大家覺(jué)得很不明白，嗯，我的代碼水平確實(shí)不怎么樣，那么下面我來(lái)用文字方式來(lái)敘說(shuō)一下大體的概念吧。對(duì)于段頁(yè)式內(nèi)存管理，首先分成N個(gè)頁(yè)面，這個(gè)是固定的，而對(duì)于每個(gè)頁(yè)面內(nèi)的段則是動(dòng)態(tài)的，段的大小事先是不知道的，那么我們需要回收的不僅僅是頁(yè)面的內(nèi)存，還包括段的內(nèi)存，那么我們就需要一個(gè)二維數(shù)組來(lái)保存是哪個(gè)頁(yè)面的那塊段的地址被釋放了。然后對(duì)于申請(qǐng)內(nèi)存的時(shí)候，則首先檢查需要申請(qǐng)內(nèi)存的大小，如果不夠一個(gè)頁(yè)面大小的話，則在垃圾回收站里面尋找可用的段空間分配，如果找不到，則申請(qǐng)一個(gè)新的頁(yè)面空間。
　　這樣用內(nèi)存池的方法來(lái)管理整個(gè)游戲世界的內(nèi)存可以有效的減少內(nèi)存碎片，一定程度的提高游戲運(yùn)行的穩(wěn)定性和效率。

4.2、游戲中物件的尋址
　　第一個(gè)問(wèn)題，我們?yōu)槭裁匆獙ぶ?？加入了腳本語(yǔ)言的概念之后，游戲中的一些邏輯物件，比如說(shuō)NPC，某個(gè)ITEM之類的都是由腳本語(yǔ)言在游戲運(yùn)行的過(guò)程中動(dòng)態(tài)生成的，那么我們通過(guò)什么樣的方法來(lái)對(duì)這些物件進(jìn)行索引呢？說(shuō)得簡(jiǎn)單一點(diǎn)，就是如何找到他們呢？有個(gè)很簡(jiǎn)單的方法，全部遍歷一次。當(dāng)然，這是個(gè)簡(jiǎn)單而有效的方法，但是效率上的消耗是任何一臺(tái)服務(wù)器都吃不消的，特別是在游戲的規(guī)模比較大之后。
　　那么，我們?cè)趺磥?lái)在游戲世界中很快的尋找這些物件呢？我想在談這個(gè)之前，說(shuō)一下Hash Table這個(gè)數(shù)據(jù)結(jié)構(gòu)，它叫哈希表，也有人叫它散列表，其工作原理是不是順序訪問(wèn)，也不是隨機(jī)訪問(wèn)，而是通過(guò)一個(gè)散列函數(shù)對(duì)其key進(jìn)行計(jì)算，算出在內(nèi)存中這個(gè)key對(duì)應(yīng)的value的地址，而對(duì)其進(jìn)行訪問(wèn)。好處是不管面對(duì)多大的數(shù)據(jù)，只需要一次計(jì)算就能找到其地址，非常的快捷，那么弊端是什么呢？當(dāng)兩個(gè)key通過(guò)散列函數(shù)計(jì)算出來(lái)的地址是同一個(gè)地址的時(shí)候，麻煩就來(lái)了，會(huì)產(chǎn)生碰撞，其的解決方法非常的麻煩，這里就不詳細(xì)談其解決方法了，否則估計(jì)再寫(xiě)個(gè)四，五章也未必談得清楚，不過(guò)如果大家對(duì)其感興趣的話，歡迎討論。
　　嗯，我們將用散列表來(lái)對(duì)游戲中的物件進(jìn)行索引，具體怎么做呢？首先，在內(nèi)存池中申請(qǐng)一塊兩倍大于游戲中物件總數(shù)的內(nèi)存，為什么是兩倍大呢？防止散列表碰撞。然后我們選用物件的名稱作為散列表的索引key，然后就可以開(kāi)始設(shè)計(jì)散列函數(shù)了。下面來(lái)看個(gè)例子：

　　static int T[] =
　　{
　　　　1, 87, 49, 12, 176, 178, 102, 166, 121, 193, 6, 84, 249, 230, 44, 163,
　　　　14, 197, 213, 181, 161, 85, 218, 80, 64, 239, 24, 226, 236, 142, 38, 200,
　　　　110, 177, 104, 103, 141, 253, 255, 50, 77, 101, 81, 18, 45, 96, 31, 222,
　　　　25, 107, 190, 70, 86, 237, 240, 34, 72, 242, 20, 214, 244, 227, 149, 235,
　　　　97, 234, 57, 22, 60, 250, 82, 175, 208, 5, 127, 199, 111, 62, 135, 248,
　　　　174, 169, 211, 58, 66, 154, 106, 195, 245, 171, 17, 187, 182, 179, 0, 243,
　　　　132, 56, 148, 75, 128, 133, 158, 100, 130, 126, 91, 13, 153, 246, 216, 219,
　　　　119, 68, 223, 78, 83, 88, 201, 99, 122, 11, 92, 32, 136, 114, 52, 10,
　　　　138, 30, 48, 183, 156, 35, 61, 26, 143, 74, 251, 94, 129, 162, 63, 152,
　　　　170, 7, 115, 167, 241, 206, 3, 150, 55, 59, 151, 220, 90, 53, 23, 131,
　　　　125, 173, 15, 238, 79, 95, 89, 16, 105, 137, 225, 224, 217, 160, 37, 123,
　　　　118, 73, 2, 157, 46, 116, 9, 145, 134, 228, 207, 212, 202, 215, 69, 229,
　　　　27, 188, 67, 124, 168, 252, 42, 4, 29, 108, 21, 247, 19, 205, 39, 203,
　　　　233, 40, 186, 147, 198, 192, 155, 33, 164, 191, 98, 204, 165, 180, 117, 76,
　　　　140, 36, 210, 172, 41, 54, 159, 8, 185, 232, 113, 196, 231, 47, 146, 120,
　　　　51, 65, 28, 144, 254, 221, 93, 189, 194, 139, 112, 43, 71, 109, 184, 209,
　　};

　　// s是需要進(jìn)行索引的字符串指針，maxn是字符串可能的最大長(zhǎng)度，返回值是相對(duì)地址。
　　inline int whashstr(char *s, int maxn)
　　{
　　　　register unsigned char oh, h;
　　　　register unsigned char *p;
　　　　register int i;

　　　　if (!*s)
　　　　　　return 0;
　　　　p = (unsigned char *) s;
　　　　oh = T[*p]; h = (*(p++) + 1) & 0xff;
　　　　for (i = maxn - 1; *p && --i >= 0; )
　　　　{
　　　　　　oh = T[oh ^ *p]; h = T[h ^ *(p++)];
　　　　}
　　　　return (oh << 8) + h;
　　}

　　具體的算法就不說(shuō)了，上面的那一大段東西不要問(wèn)我為什么，這個(gè)算法的出處是CACM 33-6中的一個(gè)叫Peter K.Pearson的鬼子寫(xiě)的論文中介紹的算法，據(jù)說(shuō)速度非常的快。有了這個(gè)散列函數(shù)，我們就可以通過(guò)它來(lái)對(duì)世界里面的任意物件進(jìn)行非?？斓膶ぶ妨?。

4.3、腳本語(yǔ)言解釋
　　在設(shè)計(jì)腳本語(yǔ)言之前，我們首先需要明白，我們的腳本語(yǔ)言要實(shí)現(xiàn)什么樣的功能？否則隨心所欲的做下去寫(xiě)出個(gè)C的解釋器之類的也說(shuō)不定。我們要實(shí)現(xiàn)的功能只是簡(jiǎn)單的邏輯判斷和循環(huán)，其他所有的功能都可以由事先提供好的函數(shù)來(lái)完成。嗯，這樣我們就可以列出一張工作量的表單：設(shè)計(jì)物件在底層的保存結(jié)構(gòu)，提供腳本和底層間的訪問(wèn)接口，設(shè)計(jì)支持邏輯判斷和循環(huán)的解釋器。
　　下面先來(lái)談?wù)勎锛诘讓拥谋４娼Y(jié)構(gòu)。具體到每種不同屬性的物件，需要采用不同的結(jié)構(gòu)，當(dāng)然，如果你愿意的話，你可以所有的物件都采同同樣的結(jié)構(gòu)，然后在結(jié)構(gòu)里面設(shè)計(jì)一個(gè)散列表來(lái)保存各種不同的屬性。但這并不是一個(gè)好方法，過(guò)分的依賴散列表會(huì)讓你的游戲的邏輯變得繁雜不清。所以，盡量的區(qū)分每種不同的物件采用不同的結(jié)構(gòu)來(lái)設(shè)計(jì)。但是有一點(diǎn)值得注意的是，不管是什么結(jié)構(gòu)，有一些東西是統(tǒng)一的，就是我們所說(shuō)的物件頭，那么我們?cè)趺磥?lái)設(shè)計(jì)這樣一個(gè)物件頭呢？

　　typedef struct object_head_s
　　{
　　　　char* name;
　　　　char* prog;
　　}object_head_t;

　　其中name是在散列表中這個(gè)物件的索引號(hào)，prog則是腳本解釋器需要解釋的程序內(nèi)容。下面我們就以NPC為例來(lái)設(shè)計(jì)一個(gè)結(jié)構(gòu)：

　　typedef struct npc_s
　　{
　　　　object_head_t header;　　　　// 物件頭
　　　　int hp;　　　　　　　　　　　// NPC的hp值。
　　　　int level;　　　　　　　 　　// NPC的等級(jí)。
　　　　struct position_s position;　// 當(dāng)前的位置信息。
　　　　unsigned int personality;　　// NPC的個(gè)性，一個(gè)unsigned int可以保存24種個(gè)性。
　　}npc_t;

　　OK，結(jié)構(gòu)設(shè)計(jì)完成，那么我們?cè)趺磥?lái)設(shè)計(jì)腳本解釋器呢？這里有兩種法，一種是用虛擬機(jī)的模式來(lái)解析腳本語(yǔ)言，另外一中則是用類似匯編語(yǔ)言的那種結(jié)構(gòu)來(lái)設(shè)計(jì)，設(shè)置一些條件跳轉(zhuǎn)和循環(huán)就可以實(shí)現(xiàn)邏輯判斷和循環(huán)了，比如：

　　set name, "路人甲";
　　CHOOSE: random_choose_personality;　　// 隨機(jī)選擇NPC的個(gè)性
　　compare hp, 100;　　　　　　　　　　　// 比較氣血，比較出的值可以放在一個(gè)固定的變量里面
　　ifless LESS;　　　　　　　　　　　　　// hp < 100的話，則返回。
　　jump CHOOSE;　　　　　　　　　　　　　// 否則繼續(xù)選擇，只到選到一個(gè)hp < 100的。
　　LESS: return success;

　　這種腳本結(jié)構(gòu)就類似CPU的指令的結(jié)構(gòu)，一條一條指令按照順序執(zhí)行，對(duì)于腳本程序員（Script Programmer）也可以培養(yǎng)他們匯編能力的說(shuō)。
　　那么怎么來(lái)模仿這種結(jié)構(gòu)呢？我們拿CPU的指令做參照，首先得設(shè)置一些寄存器，CPU的寄存器的大小和數(shù)量是受硬件影響的，但我們是用內(nèi)存來(lái)模擬寄存器，所以想要多大，就可以有多大。然后提供一些指令，包括四則運(yùn)算，尋址，判斷，循環(huán)等等。接下來(lái)針對(duì)不同的腳本用不同的解析方法，比如說(shuō)對(duì)NPC就用NPC固定的腳本，對(duì)ITEM就用ITEM固定的腳本，解析完以后就把結(jié)果生成底層該物件的結(jié)構(gòu)用于使用。
　　而如果要用虛擬機(jī)來(lái)實(shí)現(xiàn)腳本語(yǔ)言的話呢，則會(huì)將工程變得無(wú)比之巨大，強(qiáng)烈不推薦使用，不過(guò)如果你想做一個(gè)通用的網(wǎng)絡(luò)游戲底層的話，則可以考慮設(shè)計(jì)一個(gè)虛擬機(jī)。虛擬機(jī)大體的解釋過(guò)程就是進(jìn)行兩次編譯，第一次對(duì)關(guān)鍵字進(jìn)行編譯，第二次生成匯編語(yǔ)言，然后虛擬機(jī)在根據(jù)編譯生成的匯編語(yǔ)言進(jìn)行逐行解釋，如果大家對(duì)這個(gè)感興趣的話，可以去www.mudos.org上下載一份MudOS的原碼來(lái)研究研究。 大體的思路講到這里已經(jīng)差不多了，下面將用unreal（虛幻）為實(shí)例，談一談網(wǎng)絡(luò)游戲服務(wù)器的設(shè)計(jì)。

　　比如有一個(gè)玩家A向服務(wù)器發(fā)了條指令，說(shuō)我現(xiàn)在在P1點(diǎn)，要去P2點(diǎn)。指令發(fā)出的時(shí)間是T0，服務(wù)器收到指令的時(shí)間是T1，然后向周圍的玩家廣播這條消息，消息的內(nèi)容是“玩家A從P1到P2”有一個(gè)在A附近的玩家B，收到服務(wù)器的這則廣播的消息的時(shí)間是T2，然后開(kāi)始在客戶端上畫(huà)圖，A從P1到P2點(diǎn)。這個(gè)時(shí)候就存在一個(gè)不同步的問(wèn)題，玩家A和玩家B的屏幕上顯示的畫(huà)面相差了T2-T1的時(shí)間。這個(gè)時(shí)候怎么辦呢？

　　有個(gè)解決方案，我給它取名叫 預(yù)測(cè)拉扯，雖然有些怪異了點(diǎn)，不過(guò)基本上大家也能從字面上來(lái)理解它的意思。要解決這個(gè)問(wèn)題，首先要定義一個(gè)值叫：預(yù)測(cè)誤差。然后需要在服務(wù)器端每個(gè)玩家連接的類里面加一項(xiàng)屬性，叫TimeModified，然后在玩家登陸的時(shí)候，對(duì)客戶端的時(shí)間和服務(wù)器的時(shí)間進(jìn)行比較，得出來(lái)的差值保存在TimeModified里面。還是上面的那個(gè)例子，服務(wù)器廣播消息的時(shí)候，就根據(jù)要廣播對(duì)象的TimeModified，計(jì)算出一個(gè)客戶端的CurrentTime，然后在消息頭里面包含這個(gè)CurrentTime，然后再進(jìn)行廣播。并且同時(shí)在玩家A的客戶端本地建立一個(gè)隊(duì)列，保存該條消息，只到獲得服務(wù)器驗(yàn)證就從未被驗(yàn)證的消息隊(duì)列里面將該消息刪除，如果驗(yàn)證失敗，則會(huì)被拉扯回P1點(diǎn)。然后當(dāng)玩家B收到了服務(wù)器發(fā)過(guò)來(lái)的消息“玩家A從P1到P2”這個(gè)時(shí)候就檢查消息里面服務(wù)器發(fā)出的時(shí)間和本地時(shí)間做比較，如果大于定義的預(yù)測(cè)誤差，就算出在T2這個(gè)時(shí)間，玩家A的屏幕上走到的地點(diǎn)P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再繼續(xù)走下去，這樣就能保證同步。更進(jìn)一步，為了保證客戶端運(yùn)行起來(lái)更加smooth，我并不推薦直接把玩家拉扯過(guò)去，而是算出P3偏后的一點(diǎn)P4，然后用(P4-P1)/T(P4-P3)來(lái)算出一個(gè)很快的速度S，然后讓玩家A用速度S快速移動(dòng)到P4，這樣的處理方法是比較合理的，這種解決方案的原形在國(guó)際上被稱為（Full plesiochronous），當(dāng)然，該原形被我篡改了很多來(lái)適應(yīng)網(wǎng)絡(luò)游戲的同步，所以而變成所謂的：預(yù)測(cè)拉扯。

　　另外一個(gè)解決方案，我給它取名叫 驗(yàn)證同步，聽(tīng)名字也知道，大體的意思就是每條指令在經(jīng)過(guò)服務(wù)器驗(yàn)證通過(guò)了以后再執(zhí)行動(dòng)作。具體的思路如下：首先也需要在每個(gè)玩家連接類型里面定義一個(gè)TimeModified，然后在客戶端響應(yīng)玩家鼠標(biāo)行走的同時(shí)，客戶端并不會(huì)先行走動(dòng)，而是發(fā)一條走路的指令給服務(wù)器，然后等待服務(wù)器的驗(yàn)證。服務(wù)器接受到這條消息以后，進(jìn)行邏輯層的驗(yàn)證，然后計(jì)算出需要廣播的范圍，包括玩家A在內(nèi)，根據(jù)各個(gè)客戶端不同的TimeModified生成不同的消息頭，開(kāi)始廣播，這個(gè)時(shí)候這個(gè)玩家的走路信息就是完全同步的了。這個(gè)方法的優(yōu)點(diǎn)是能保證各個(gè)客戶端之間絕對(duì)的同步，缺點(diǎn)是當(dāng)網(wǎng)絡(luò)延遲比較大的時(shí)候，玩家的客戶端的行為會(huì)變得比較不流暢，給玩家?guī)?lái)很不爽的感覺(jué)。該種解決方案的原形在國(guó)際上被稱為（Hierarchical master-slave synchronization），80年代以后被廣泛應(yīng)用于網(wǎng)絡(luò)的各個(gè)領(lǐng)域。

　　最后一種解決方案是一種理想化的解決方案，在國(guó)際上被稱為Mutual synchronization，是一種對(duì)未來(lái)網(wǎng)絡(luò)的前景的良好預(yù)測(cè)出來(lái)的解決方案。這里之所以要提這個(gè)方案，并不是說(shuō)我們已經(jīng)完全的實(shí)現(xiàn)了這種方案，而只是在網(wǎng)絡(luò)游戲領(lǐng)域的某些方面應(yīng)用到這種方案的某些思想。我對(duì)該種方案取名為：半服務(wù)器同步。大體的設(shè)計(jì)思路如下：

　　首先客戶端需要在登陸世界的時(shí)候建立很多張廣播列表，這些列表在客戶端后臺(tái)和服務(wù)器要進(jìn)行不及時(shí)同步，之所以要建立多張列表，是因?yàn)橐獜V播的類型是不止一種的，比如說(shuō)有l(wèi)ocal message,有remote message,還有g(shù)lobal message 等等，這些列表都需要在客戶端登陸的時(shí)候根據(jù)服務(wù)器發(fā)過(guò)來(lái)的消息建立好。在建立列表的同時(shí)，還需要獲得每個(gè)列表中廣播對(duì)象的TimeModified，并且要維護(hù)一張完整的用戶狀態(tài)列表在后臺(tái)，也是不及時(shí)的和服務(wù)器進(jìn)行同步，根據(jù)本地的用戶狀態(tài)表，可以做到一部分決策由客戶端自己來(lái)決定，當(dāng)客戶端發(fā)送這部分決策的時(shí)候，則直接將最終決策發(fā)送到各個(gè)廣播列表里面的客戶端，并對(duì)其時(shí)間進(jìn)行校對(duì)，保證每個(gè)客戶端在收到的消息的時(shí)間是和根據(jù)本地時(shí)間進(jìn)行校對(duì)過(guò)的。那么再采用預(yù)測(cè)拉扯中提到過(guò)的計(jì)算提前量，提高速度行走過(guò)去的方法，將會(huì)使同步變得非常的smooth。該方案的優(yōu)點(diǎn)是不通過(guò)服務(wù)器，客戶端自己之間進(jìn)行同步，大大的降低了由于網(wǎng)絡(luò)延遲而帶來(lái)的誤差，并且由于大部分決策都可以由客戶端來(lái)做，也大大的降低了服務(wù)器的資源。由此帶來(lái)的弊端就是由于消息和決策權(quán)都放在客戶端本地，所以給外掛提供了很大的可乘之機(jī)。

　　綜合以上三種關(guān)于網(wǎng)絡(luò)同步派系的優(yōu)缺點(diǎn)，綜合出一套關(guān)于網(wǎng)絡(luò)游戲傳輸同步的較完整的解決方案，我稱它為綜合同步法（colligate synchronization）。大體設(shè)計(jì)思路如下：

　　首先將服務(wù)器需要同步的所有消息從劃分一個(gè)優(yōu)先等級(jí)，然后按照3/4的比例劃分出重要消息和非重要消息，對(duì)于非重要消息，把決策權(quán)放在客戶端，在客戶端邏輯上建立相關(guān)的決策機(jī)構(gòu)和各種消息緩存區(qū)，以及相關(guān)的消息緩存區(qū)管理機(jī)構(gòu)，如下圖所示：

　　上圖簡(jiǎn)單說(shuō)明了對(duì)于非重要消息，客戶端的大體處理流程，其中有一個(gè)客戶端被動(dòng)行為值得大家注意，其中包括對(duì)服務(wù)器發(fā)過(guò)來(lái)的某些驗(yàn)證代碼做返回，來(lái)確保消息緩存中的消息和服務(wù)器端是一致的，從而有效的防止外掛來(lái)篡改本地消息緩存。其中的消息來(lái)源是包括本地的客戶端響應(yīng)玩家的消息以及遠(yuǎn)程服務(wù)器傳遞過(guò)來(lái)的消息。

　　對(duì)于重要消息，比如說(shuō)戰(zhàn)斗或者是某些牽扯到玩家一些比較敏感數(shù)據(jù)的操作，則采用另外一套方案，該方案首先需要在服務(wù)器和客戶端之間建立一套Ping System，然后服務(wù)器保存和用戶的及時(shí)的ping值，當(dāng)ping比較小的時(shí)候，響應(yīng)玩家消息的同時(shí)先不進(jìn)行動(dòng)作，而是先把該消息反饋給服務(wù)器，并且阻塞，服務(wù)器收到該消息，進(jìn)行邏輯驗(yàn)證之后向所有該詳細(xì)廣播的有效對(duì)象進(jìn)行廣播（包括消息發(fā)起者），然后客戶端收到該消息的驗(yàn)證，才開(kāi)始執(zhí)行動(dòng)作。而當(dāng)ping比較大的時(shí)候，客戶端響應(yīng)玩家消息的同時(shí)立刻進(jìn)行動(dòng)作，并且同時(shí)把該消息反饋給服務(wù)器，值得注意的是這個(gè)時(shí)候還需要在本地建立一個(gè)無(wú)驗(yàn)證消息的隊(duì)列，把該消息入隊(duì)，執(zhí)行動(dòng)作的同時(shí)等待服務(wù)器的驗(yàn)證，還需要保存當(dāng)前狀態(tài)。服務(wù)器收到客戶端的請(qǐng)求后，進(jìn)行邏輯驗(yàn)證，并把消息反饋到各個(gè)客戶端，帶上各個(gè)客戶端校對(duì)過(guò)的本地時(shí)間。如果驗(yàn)證通過(guò)不過(guò)，則通知消息發(fā)起者，該消息驗(yàn)證失敗，然后客戶端自動(dòng)把已經(jīng)在進(jìn)行中的動(dòng)作取消，恢復(fù)原來(lái)狀態(tài)。如果驗(yàn)證通過(guò)，則廣播到的各個(gè)客戶端根據(jù)從服務(wù)器獲得校對(duì)時(shí)間進(jìn)行對(duì)其進(jìn)行拉扯，保證在該行為完成之前完成同步。

　　至此，一個(gè)比較成熟的網(wǎng)絡(luò)游戲的同步機(jī)制已經(jīng)初步建立起來(lái)了，接下來(lái)的邏輯代碼就根據(jù)各自不同的游戲風(fēng)格以及側(cè)重點(diǎn)來(lái)寫(xiě)了。

　　同步是網(wǎng)絡(luò)游戲最重要的問(wèn)題，如何同步也牽扯到各個(gè)方面的問(wèn)題，比如說(shuō)游戲的規(guī)模，游戲的類型以及各種各樣的方面，對(duì)于規(guī)模比較大的游戲，在同步方面可以下很多的工夫，把消息分得十分的細(xì)膩，對(duì)于不同的消息采用不同的同步機(jī)制，而對(duì)于規(guī)模比較小的游戲，則可以采用大體上一樣的同步機(jī)制，究竟怎么樣同步，沒(méi)有個(gè)定式，是需要根據(jù)自己的不同情況來(lái)做出不同的同步?jīng)Q策的