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

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

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

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

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

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

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

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

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

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

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

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

　　“非關鍵邏輯”，在不同的游戲中，會有不同的概念。在通常的MMORPG中，玩家移動邏輯的判斷，是算作關鍵邏輯的，否則，如果服務器端不對客 戶端發(fā)過來的移動包進行判斷那就很容易造成玩家的瞬移以及其它毀滅性的災難。而在泡泡堂中，玩家移動邏輯到底應不應該算作關鍵邏輯還是值得考慮的。泡泡堂 中的玩家可以取勝的方法，通常是確實因為打得好而贏得勝利，不會因為瞬移而贏得勝利，因為如果外掛要作泡泡堂的瞬移，它需要考慮的因素和判斷的邏輯太多 了，由于比賽進程的瞬息萬變，外掛的瞬移點判斷不一定就比真正的玩家來得準確，所在，在玩家移動這個邏輯上使用外掛，在泡泡堂這樣的游戲中通常是得不償失 的（當然，那種特別變態(tài)的高智能的外掛除外）。從目前我查到的消息來看，泡泡堂的外掛多數(shù)是一些按鍵精靈腳本，它的本質還不是完全的游戲機器人，并不是通 過純粹的協(xié)議接管實現(xiàn)的外掛功能。這也從反面驗證了我以上的想法。

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

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

但是，不管采用哪種方案，服務器上都應該保留一份本地圖內道具所在點的信息。因為服務器要用它來驗證一個關鍵邏輯：玩家拾取道具。當玩家要在某點拾取道具時，服務器必須要判定此點是否有道具，否則，外掛可以通過頻繁地發(fā)拾取道具的包而不斷取得道具。

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

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