原文：http://hi.baidu.com/huangyunjun999/blog/item/7396b8c2378e4a3ce4dd3bda.html

接觸了一段時(shí)間的網(wǎng)游封包設(shè)計(jì)，有了一些初步的思路，想借這篇文章總結(jié)一下，同時(shí)也作個(gè)記錄，以利于以后更新自己的思路。
網(wǎng)絡(luò)游戲的技術(shù)研發(fā)，分為三個(gè)主要的方面：服務(wù)器設(shè)計(jì)，客戶端設(shè)計(jì)，數(shù)據(jù)庫設(shè)計(jì)。而在服務(wù)器和客戶端之間實(shí)現(xiàn)游戲邏輯的中介則是游戲數(shù)據(jù)包，服務(wù)器和 客戶端通過交換游戲數(shù)據(jù)包并根據(jù)分析得到的數(shù)據(jù)包來驅(qū)動游戲邏輯。網(wǎng)絡(luò)游戲的實(shí)質(zhì)是互動，而互動的控制則由服務(wù)器和客戶端協(xié)同完成，協(xié)同就必然要依靠數(shù)據(jù) 來完成。
當(dāng)前網(wǎng)絡(luò)游戲中的封包，其定義形式是各種各樣的，但歸納起來，一般都具有如下要素：封包長度，封包類型，封包參數(shù)，校驗(yàn)碼等。
封包長度用于確定當(dāng)前游戲數(shù)據(jù)包的長度，之所以提供這個(gè)數(shù)據(jù)，是因?yàn)樵诘讓拥腡CP網(wǎng)絡(luò)傳輸中，出于傳輸效率的考慮，傳輸有時(shí)會把若干個(gè)小的數(shù)據(jù)包合 并成一個(gè)大的數(shù)據(jù)包發(fā)送出去，而在合并的過程中，并不是把每一個(gè)邏輯上完整的數(shù)據(jù)包全部合并到一起，有時(shí)可能因?yàn)檫@種合并而將一個(gè)在邏輯上具有完整意義的 游戲數(shù)據(jù)包分在了兩次發(fā)送過程中進(jìn)行發(fā)送，這樣，當(dāng)前一次的數(shù)據(jù)發(fā)送到接受方之后，其尾部的數(shù)據(jù)包必然造成了“斷尾”現(xiàn)象，為了判定這種斷尾的情況以及斷 尾的具體內(nèi)容，游戲數(shù)據(jù)包在設(shè)計(jì)時(shí)一般都會提供封包長度這個(gè)信息，根據(jù)這個(gè)信息接受方就知道收到的包是否有斷尾，如果有斷尾，則把斷尾的數(shù)據(jù)包與下次發(fā)過 來的數(shù)據(jù)包進(jìn)行拼接生成原本在邏輯意義上完整的數(shù)據(jù)包。
封包類型用于標(biāo)識當(dāng)前封包是何種類型的封包，表示的是什么含義。
封包參數(shù)則是對封包類型更具體的描述，它里面指定了這種類型封包說明里所必須的參數(shù)。比如說話封包，它的封包類型，可以用一個(gè)數(shù)值進(jìn)行表示，而具體的說話內(nèi)容和發(fā)言的人則作為封包參數(shù)。
校驗(yàn)碼的作用是對前述封包內(nèi)容進(jìn)行校驗(yàn)，以確保封包在傳遞過程中內(nèi)容不致被改變，同時(shí)根據(jù)校驗(yàn)碼也可以確定這個(gè)封包在格式上是不是一個(gè)合法的封包。以 校驗(yàn)碼作為提高封包安全性的方法，已經(jīng)是目前網(wǎng)游普遍采用的方式。封包設(shè)計(jì)，一般是先確定封包的總體結(jié)構(gòu)，然后再來具體細(xì)分有哪些封包，每個(gè)封包中應(yīng)該含 有哪些內(nèi)容，最后再詳細(xì)寫出封包中各部分內(nèi)容具體占有的字節(jié)數(shù)及含義。
數(shù)據(jù)包的具體設(shè)計(jì)，一般來說是根據(jù)游戲功能進(jìn)行劃分和圈定的。比如游戲中有聊天功能，那么就得設(shè)計(jì)客戶端與服務(wù)器的聊天數(shù)據(jù)包，客戶端要有一個(gè)描述發(fā) 言內(nèi)容與發(fā)言人信息的數(shù)據(jù)包，而在服務(wù)器端要有一個(gè)包含用戶發(fā)言內(nèi)容及發(fā)言人信息的廣播數(shù)據(jù)包，通過它，服務(wù)器端可以向其他附近玩家廣播發(fā)送當(dāng)前玩家的發(fā) 言內(nèi)容。再比如游戲中要有交易功能，那么與這個(gè)功能相對應(yīng)的就可能會有以下數(shù)據(jù)包：申請交易包，申請交易的信息包，允許或拒絕交易包，允許或拒絕交易的信 息包，提交交易物品包，提交交易物品的信息包，確認(rèn)交易包，取消交易包，取消交易的信息包，交易成功或失敗的信息包。需要注意的是，在這些封包中，有的是 一方使用而另一方不使用的，而有的則是雙方都使用的包。比如申請交易包，只可能是一方使用，而另一方會得到一個(gè)申請交易的信息包；而確認(rèn)交易包和提交交易 物品這樣的數(shù)據(jù)包，都是雙方在確定要進(jìn)行交易時(shí)要同時(shí)使用的。封包的設(shè)計(jì)也遵從由上到下的設(shè)計(jì)原則，即先確定有哪些功能的封包，再確定封包中應(yīng)該含有的信 息，最后確定這些信息應(yīng)該占有的位置及長度。一層層的分析與定義，最終形成一個(gè)完善的封包定義方案。在實(shí)際的封包設(shè)計(jì)過程中，回溯的情況是經(jīng)常出現(xiàn)的。由 于初期設(shè)計(jì)時(shí)的考慮不周或其它原因，可能造成封包設(shè)計(jì)方案的修改或增刪，這時(shí)候一個(gè)重要的問題是要記得及時(shí)更新你的設(shè)計(jì)文檔。在我的封包設(shè)計(jì)中，我采用的 是以下的封包描述表格進(jìn)行描述：
封包編號　　　功能描述　　對應(yīng)的類或結(jié)構(gòu)體名　　類型命令字　　命令參數(shù)結(jié)構(gòu)體及含義　
根據(jù)游戲的功能，我們可以大致圈定封包的大致結(jié)構(gòu)及所含的大致內(nèi)容。但是，封包設(shè)計(jì)還包含有其它更多的內(nèi)容，如何在保證封包邏輯簡潔的前提下縮短封包 的設(shè)計(jì)長度提高封包的傳輸速度和游戲的運(yùn)行速度，這也是我們應(yīng)該考慮的一個(gè)重要問題。一般情況下，設(shè)計(jì)封包時(shí)，應(yīng)該盡量避免產(chǎn)生一百字節(jié)以上的封包，多數(shù) 封包的定義控制在100字節(jié)以內(nèi)，甚至20－50字節(jié)以內(nèi)。在我所定義的封包中，多數(shù)在20字節(jié)以內(nèi)，對于諸如傳遞服務(wù)器列表和用戶列表這樣的封包可能會 大一點(diǎn)。總之一句話，應(yīng)該用盡可能短的內(nèi)容盡可能簡潔清晰地描述封包功能和含義。
在封包結(jié)構(gòu)設(shè)計(jì)方面，我有另一種可擴(kuò)展的思路：對封包中各元素的位置進(jìn)行動態(tài)定義。這樣，當(dāng)換成其它游戲或想更換當(dāng)前游戲的封包結(jié)構(gòu)時(shí)，只要改變這些 元素的動態(tài)定義即可，而不需要完全重新設(shè)計(jì)封包結(jié)構(gòu)。比如我們對封包編號，封包類型，封包參數(shù)，校驗(yàn)碼這些信息的開始位置和長度進(jìn)行定義，這樣就可以形成 一個(gè)動態(tài)定義的封包結(jié)構(gòu)，對以后的封包移植將會有很大幫助，一個(gè)可能動態(tài)改變封包結(jié)構(gòu)的游戲數(shù)據(jù)包，在相當(dāng)程度上增加了外掛分析封包結(jié)構(gòu)的難度。
在進(jìn)行封包設(shè)計(jì)時(shí)，最好根據(jù)封包客戶端和服務(wù)器端的不同來分類進(jìn)行設(shè)計(jì)。比如大廳與游戲服務(wù)器的封包及游戲服務(wù)器與游戲客戶端的封包分開來進(jìn)行設(shè)計(jì)，在包的編號上表示出他們的不同（以不同的開頭單詞表示），這樣在封包的總體結(jié)構(gòu)上就會更清晰。