本文作者：sodme
本文出處：http://blog.csdn.net/sodme
聲明：本文可以不經(jīng)作者同意任意轉(zhuǎn)載、復(fù)制、引用。但任何對(duì)本文的引用，均須注明本文的作者、出處以及本行聲明信息。

　　之前，我分析過QQ游戲（特指QQ休閑平臺(tái)，并非QQ堂，下同）的通信架構(gòu)（http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx），分析過魔獸世界的通信架構(gòu)（http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx）， 似乎網(wǎng)絡(luò)游戲的通信架構(gòu)也就是這些了，其實(shí)不然，在網(wǎng)絡(luò)游戲大家庭中，還有一種類型的游戲我認(rèn)為有必要把它的通信架構(gòu)專門作個(gè)介紹，這便是如泡泡堂、QQ 堂類的休閑類競(jìng)技游戲。曾經(jīng)很多次，被網(wǎng)友們要求能抽時(shí)間看看泡泡堂之類游戲的通信架構(gòu)，這次由于被逼交作業(yè)，所以今晚抽了一點(diǎn)的時(shí)間截了一下泡泡堂的 包，正巧昨日與網(wǎng)友就泡泡堂類游戲的通信架構(gòu)有過一番討論，于是，將這兩天的討論、截包及思考總結(jié)于本文中，希望能對(duì)關(guān)心或者正在開發(fā)此類游戲的朋友有所 幫助，如果要討論具體的技術(shù)細(xì)節(jié)，請(qǐng)到我的BLOG（http://blog.csdn.net/sodme）加我的MSN討論..

　　總體來說，泡泡堂類游戲（此下簡(jiǎn)稱泡泡堂）在大廳到房間這一層的通信架構(gòu)，其結(jié)構(gòu)與QQ游戲相當(dāng)，甚至要比QQ游戲來得簡(jiǎn)單。所以，在房間這一層的通信架構(gòu)上，我不想過多討論，不清楚的朋友請(qǐng)參看我對(duì)QQ游戲通信架構(gòu)的分析文章（http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx）。可以這么說，如果采用與QQ游戲相同的房間和大廳架構(gòu)，是完全可以組建起一套可擴(kuò)展的支持百萬人在線的游戲系統(tǒng)的。也就是說，通過負(fù)載均衡＋大廳＋游戲房間對(duì)游戲邏輯的分?jǐn)偅耆梢詫?shí)現(xiàn)一個(gè)可擴(kuò)展的百萬人在線泡泡堂。

　　但是，泡泡堂與斗地主的最大不同點(diǎn)在于：泡泡堂對(duì)于實(shí)時(shí)性要求特別高。那么，泡泡堂是如何解決實(shí)時(shí)性與網(wǎng)絡(luò)延遲以及大用戶量之間矛盾的呢？

　　閱讀以下文字前，請(qǐng)確認(rèn)你已經(jīng)完全理解TCP與UDP之間的不同點(diǎn)。

　　我們知道，TCP與UDP之間的最大不同點(diǎn)在于：TCP是可靠連接的，而UDP是無連接的。如果通信雙方使用TCP協(xié)議，那么他們之前必須事先 通過監(jiān)聽＋連接的方式將雙方的通信管道建立起來；而如果通信雙方使用的是UDP通信，則雙方不用事先建立連接，發(fā)送方只管向目標(biāo)地址上的目標(biāo)端口發(fā)送 UDP包即可，不用管對(duì)方到底收沒收到。如果要說形象點(diǎn)，可以用這樣一句話概括：TCP是打電話，UDP是發(fā)電報(bào)。TCP通信，為了保持這樣的可靠連接， 在可靠性上下了很多功夫，所以導(dǎo)致了它的通信效率要比UDP差很多，所以，一般地，在地實(shí)時(shí)性要求非常高的場(chǎng)合，會(huì)選擇使用UDP協(xié)議，比如常見的動(dòng)作射 擊類游戲。

　　通過載包，我們發(fā)現(xiàn)泡泡堂中同時(shí)采用了TCP和UDP兩種通信協(xié)議。并且，具有以下特點(diǎn)：
1.當(dāng)玩家未進(jìn)入具體的游戲地圖時(shí)，僅有TCP通信存在，而沒有UDP通信；
2.進(jìn)入游戲地圖后，TCP的通信量遠(yuǎn)遠(yuǎn)小于UDP的通信量
3.UDP的通信IP個(gè)數(shù)，與房間內(nèi)的玩家成一一對(duì)應(yīng)關(guān)系(這一點(diǎn)，應(yīng)網(wǎng)友疑惑而加，此前已經(jīng)證實(shí))

　　以上是幾個(gè)表面現(xiàn)象，下面我們來分析它的本質(zhì)和內(nèi)在。^&^

　　泡泡堂的游戲邏輯，簡(jiǎn)單地可以歸納為以下幾個(gè)方面：
1.玩家移動(dòng)
2.玩家埋地雷（如果你覺得這種叫法比較土，你也可以叫它：下泡泡，呵呵）
3.地雷爆炸出道具或者地雷爆炸困住另一玩家
4.玩家撿道具或者玩家消滅/解救一被困的玩家

　　與MMORPG一樣，在上面的幾個(gè)邏輯中，廣播量最大的其實(shí)是玩家移動(dòng)。為了保持玩家畫面同步，其他玩家的每一步移動(dòng)消息都要即時(shí)地發(fā)給其它玩家。

　　通常，網(wǎng)絡(luò)游戲的邏輯控制，絕大多數(shù)是在服務(wù)器端的。有時(shí)，為了保證畫面的流暢性，我們會(huì)有意識(shí)地減少服務(wù)器端的邏輯判斷量和廣播量，當(dāng)然，這 個(gè)減少，是以“不危及游戲的安全運(yùn)行”為前提的。到底如何在效率、流暢性和安全性之間作取舍，很多時(shí)候是需要經(jīng)驗(yàn)積累的，效率提高的過程，就是邏輯不斷優(yōu) 化的過程。不過，有一個(gè)原則是可以說的，那就是：“關(guān)鍵邏輯”一定要放在服務(wù)器上來判斷。那么，什么是“關(guān)鍵邏輯”呢？

　　拿泡泡堂來說，下面的這個(gè)邏輯，我認(rèn)為就是關(guān)鍵邏輯：玩家在某處埋下一顆地雷，地雷爆炸后到底能不能炸出道具以及炸出了哪些道具，這個(gè)信息，需要服務(wù)器來給。那么，什么又是“非關(guān)鍵邏輯”呢？

　　“非關(guān)鍵邏輯”，在不同的游戲中，會(huì)有不同的概念。在通常的MMORPG中，玩家移動(dòng)邏輯的判斷，是算作關(guān)鍵邏輯的，否則，如果服務(wù)器端不對(duì)客 戶端發(fā)過來的移動(dòng)包進(jìn)行判斷那就很容易造成玩家的瞬移以及其它毀滅性的災(zāi)難。而在泡泡堂中，玩家移動(dòng)邏輯到底應(yīng)不應(yīng)該算作關(guān)鍵邏輯還是值得考慮的。泡泡堂 中的玩家可以取勝的方法，通常是確實(shí)因?yàn)榇虻煤枚A得勝利，不會(huì)因?yàn)樗惨贫A得勝利，因?yàn)槿绻鈷煲髋菖萏玫乃惨疲枰紤]的因素和判斷的邏輯太多 了，由于比賽進(jìn)程的瞬息萬變，外掛的瞬移點(diǎn)判斷不一定就比真正的玩家來得準(zhǔn)確，所在，在玩家移動(dòng)這個(gè)邏輯上使用外掛，在泡泡堂這樣的游戲中通常是得不償失 的（當(dāng)然，那種特別變態(tài)的高智能的外掛除外）。從目前我查到的消息來看，泡泡堂的外掛多數(shù)是一些按鍵精靈腳本，它的本質(zhì)還不是完全的游戲機(jī)器人，并不是通 過純粹的協(xié)議接管實(shí)現(xiàn)的外掛功能。這也從反面驗(yàn)證了我以上的想法。

　　說到這里，也許你已經(jīng)明白了。是的！TCP通信負(fù)責(zé)“關(guān)鍵邏輯”，而UDP通信負(fù)責(zé)“非關(guān)鍵邏輯”，這里的“非關(guān)鍵邏輯”中就包含了玩家移動(dòng)。 在泡泡堂中，TCP通信用于本地玩家與服務(wù)器之間的通信，而UDP則用于本地玩家與同一地圖中的其他各玩家的通信。當(dāng)本地玩家要移動(dòng)時(shí)，它會(huì)同時(shí)向同一地 圖內(nèi)的所有玩家廣播自己的移動(dòng)消息，其他玩家收到這個(gè)消息后會(huì)更新自己的游戲畫面以實(shí)現(xiàn)畫面同步。而當(dāng)本地玩家要在地圖上放置一個(gè)炸彈時(shí)，本地玩家需要將 此消息同時(shí)通知同一地圖內(nèi)的其他玩家以及服務(wù)器，甚至這里，可以不把放置炸彈的消息通知給服務(wù)器，而僅僅通知其他玩家。當(dāng)炸彈爆炸后，要拾取物品時(shí)才向服 務(wù)器提交拾取物品的消息。

　　那么，你可能會(huì)問，“地圖上某一點(diǎn)是否存在道具”這個(gè)消息，服務(wù)器是什么時(shí)候通知給客戶端的呢？這個(gè)問題，可以有兩種解決方案：
1.客戶端如果在放置炸彈時(shí)，將放置炸彈的消息通知給服務(wù)器，服務(wù)器可以在收到這個(gè)消息后，告訴客戶端炸彈爆炸后會(huì)有哪些道具。但我覺得這種方案不好，因?yàn)檫@樣作會(huì)增加游戲運(yùn)行過程中的數(shù)據(jù)流量。
2.而這第2種方案就是，客戶端進(jìn)入地圖后，游戲剛開始時(shí)，就由服務(wù)器將本地圖內(nèi)的各道具所在點(diǎn)的信息傳給各客戶端，這樣，可以省去兩方面的開 銷：a.客戶端放炸彈時(shí)，可以不通知服務(wù)器而只通知其它玩家；b.服務(wù)器也不用在游戲運(yùn)行過程中再向客戶端傳遞有關(guān)某點(diǎn)有道具的信息。

但是，不管采用哪種方案，服務(wù)器上都應(yīng)該保留一份本地圖內(nèi)道具所在點(diǎn)的信息。因?yàn)榉?wù)器要用它來驗(yàn)證一個(gè)關(guān)鍵邏輯：玩家拾取道具。當(dāng)玩家要在某點(diǎn)拾取道具時(shí)，服務(wù)器必須要判定此點(diǎn)是否有道具，否則，外掛可以通過頻繁地發(fā)拾取道具的包而不斷取得道具。

　　至于泡泡堂其它游戲邏輯的實(shí)現(xiàn)方法，我想，還是要依靠這個(gè)原則：首先判斷這個(gè)邏輯是關(guān)鍵邏輯嗎？如果不全是，那其中的哪部分是非關(guān)鍵邏輯呢？對(duì) 于非關(guān)鍵邏輯，都可以交由客戶端之間（UDP）去自行完成。而對(duì)于關(guān)鍵邏輯，則必須要有服務(wù)器(TCP)的校驗(yàn)和認(rèn)證。這便是我要說的。

　　以上僅僅是在理論上探討關(guān)于泡泡堂類游戲在通信架構(gòu)上的可能作法，這些想法是沒有事實(shí)依據(jù)的，所有結(jié)論皆來源于對(duì)封包的分析以及個(gè)人經(jīng)驗(yàn)，文章 的內(nèi)容和觀點(diǎn)可能跟真實(shí)的泡泡堂通信架構(gòu)實(shí)現(xiàn)有相當(dāng)大的差異，但我想，這并不是主要的，因?yàn)槲业哪康氖窍虼蠹医榻B這樣的TCP和UDP通信并存情況下，如 何對(duì)游戲邏輯的進(jìn)行取舍和劃分。無論是“關(guān)鍵邏輯”的定性，還是“玩家移動(dòng)”的具體實(shí)施，都需要開發(fā)者在具體的實(shí)踐中進(jìn)行總結(jié)和優(yōu)化。此文全當(dāng)是一個(gè)引子 罷，如有疑問，請(qǐng)加Msn討論。