一.摘要1.網(wǎng)絡(luò)游戲MMORPG整體服務(wù)器框架，包括早期,中期，當(dāng)前的一些主流架構(gòu)
2.網(wǎng)絡(luò)游戲網(wǎng)絡(luò)層,包括網(wǎng)絡(luò)協(xié)議,IO模型，網(wǎng)絡(luò)框架，消息編碼等。
3.網(wǎng)絡(luò)游戲的場景管理,AI，腳本的應(yīng)用等。
4.開源的網(wǎng)絡(luò)服務(wù)器引擎
5.參考書籍，博客
二.關(guān)鍵詞網(wǎng)絡(luò)協(xié)議 網(wǎng)絡(luò)IO 消息 廣播 同步 CS TCP/UDP IP 集群 負(fù)載均衡 分布式
網(wǎng)關(guān)服務(wù)器 GateServer 心跳 多線程/線程池 開源網(wǎng)絡(luò)通訊框架/模型阻塞/非阻塞/同步/異步 Proactor/Reactor/Actor Select/Poll/Epoll/Iocp/Kqueue
游戲開發(fā)中的設(shè)計模式/數(shù)據(jù)結(jié)構(gòu)短連接和長連接 游戲安全 緩存 消息編碼協(xié)議 腳本語言
Socket Nagle/粘包/截斷/TCP_NODELAY AI/場景 分線/分地圖 開源MMORPG服務(wù)器三.正文框架結(jié)構(gòu)1. 早期的MMORPG服務(wù)器結(jié)構(gòu)Client<->GameServer<->DB 所有業(yè)務(wù),數(shù)據(jù)集中處理 優(yōu)點:簡單,快速開發(fā)
缺點:
1.所有業(yè)務(wù)放在一起,系統(tǒng)負(fù)擔(dān)大大增加.一個bug可能導(dǎo)致整個服務(wù)器崩潰,造成所有玩家掉線甚至丟失等嚴(yán)重后果。
2.開服一剎那,所有玩家全部堆積在同一個新手村.->>>>卡，客戶端卡（同屏人數(shù)過多渲染/廣播風(fēng)暴） 服務(wù)器卡(處理大量同場景消息/廣播風(fēng)暴) 2. 中期-用戶分離集群式 GameServe1Client | DB GameServer2玩家不斷增多->分線->程序自動或玩家手動選擇進(jìn)入缺點:運營到后期,隨著每條線玩家的減少, 互動大大減少。3. 中后期 數(shù)據(jù)分離集群式  按地圖劃分服務(wù)器,當(dāng)前主流 新手村問題：《天龍八部》提出了較好的解決方案，建立多個平行的新手村地圖，一主多副，開服時盡可能多的同時容納新用戶的涌入，高等級玩家從其它地圖回新手村只能到達(dá)主新手村。4. 當(dāng)前主流的網(wǎng)絡(luò)游戲架構(gòu) 注：在GateServer和CenterServer之間是有一條TCP連接的。而GameServer和LogServer之間的連接可以是UDP連接。這是有一個大概的圖，很多地方需要細(xì)化。
GateServer:網(wǎng)關(guān)服務(wù)器,AgentServer、ProxyServer 優(yōu)點: (1)作為網(wǎng)絡(luò)通信的中轉(zhuǎn)站，負(fù)責(zé)維護(hù)將內(nèi)網(wǎng)和外網(wǎng)隔離開，使外部無法直接訪問內(nèi)部服務(wù)器，保障內(nèi)網(wǎng)服務(wù)器的安全，一定程度上較少外掛的攻擊。 (2)網(wǎng)關(guān)服務(wù)器負(fù)責(zé)解析數(shù)據(jù)包、加解密、超時處理和一定邏輯處理，這樣可以提前過濾掉錯誤包和非法數(shù)據(jù)包。 (3)客戶端程序只需建立與網(wǎng)關(guān)服務(wù)器的連接即可進(jìn)入游戲，無需與其它游戲服務(wù)器同時建立多條連接，節(jié)省了客戶端和服務(wù)器程序的網(wǎng)絡(luò)資源開銷。 (4)在玩家跳服務(wù)器時，不需要斷開與網(wǎng)關(guān)服務(wù)器的連接，玩家數(shù)據(jù)在不同游戲服務(wù)器間的切換是內(nèi)網(wǎng)切換，切換工作瞬問完成，玩家?guī)缀醪煊X不到，這保證了游戲的流暢性和良好的用戶體驗。 缺點: 1.網(wǎng)關(guān)服務(wù)器成為高負(fù)載情況下的通訊瓶頸問題2由于網(wǎng)關(guān)的單節(jié)點故障導(dǎo)致整組服務(wù)器無法對外提供服務(wù)的問題 解決：多網(wǎng)關(guān)技術(shù)。顧名思義，“多網(wǎng)關(guān)” 就是同時存在多個網(wǎng)關(guān)服務(wù)器，比如一組服務(wù)器可以配置三臺GameGme。當(dāng)負(fù)載較大時，可以通過增加網(wǎng)關(guān)服務(wù)器來增加網(wǎng)關(guān)的總體通訊流量，當(dāng)一臺網(wǎng)關(guān)服務(wù)器宕機(jī)時，它只會影響連接到本服務(wù)器的客戶端，其它客戶端不會受到任何影響。DCServer:數(shù)據(jù)中心服務(wù)器。主要的功能是緩存玩家角色數(shù)據(jù)，保證角色數(shù)據(jù)能快速的讀取和保存CenterServer:全局服務(wù)器/中心服務(wù)器,也叫WorldServer. 主要負(fù)責(zé)維持GameServer之間數(shù)據(jù)的轉(zhuǎn)發(fā)和數(shù)據(jù)廣播。另外一些游戲系統(tǒng)也可能會放到Center上處理，比如好友系統(tǒng),公會系統(tǒng)。 改進(jìn):將網(wǎng)關(guān)服務(wù)器細(xì)化為LogingateServer和多個GameGateServer.5. 按業(yè)務(wù)分離式集群由于網(wǎng)絡(luò)游戲存在很多的業(yè)務(wù)，如聊天，戰(zhàn)斗，行走，NPC等，可以將某些業(yè)務(wù)分到單獨的服務(wù)器上。這樣每個服務(wù)器的程序則會精簡很多。而且一些大流量業(yè)務(wù)的分離,可以有效的提高游戲服務(wù)器人數(shù)上限。 
優(yōu)點： 1.業(yè)務(wù)的分離使得每種服務(wù)器的程序變的簡單，這樣可以降低出錯的幾率。即使出錯，也不至于影響到每一個整個游戲的進(jìn)行,而且通過快速啟動另一臺備用服務(wù)器替換出錯的服務(wù)器。 2.業(yè)務(wù)的分離使得流量得到了分散，進(jìn)而相應(yīng)速度回得到提升 。 3.大部分業(yè)務(wù)都分離了成了單獨的服務(wù)器,所以可以動態(tài)的添加，從而提高人數(shù)上限。改進(jìn)：甚至可以將登陸服務(wù)器細(xì)化拆分建角色,選擇角色服務(wù)器6. 一種簡單實用的網(wǎng)絡(luò)游戲服務(wù)器架構(gòu)下圖中每個方框表示一個獨立的進(jìn)程APP組件，每個服務(wù)進(jìn)程如果發(fā)生宕機(jī)會影響部分用戶，整體服務(wù)但不會全部中斷。在宕機(jī)進(jìn)程重啟后，又可以并入整體，全部服務(wù)得以繼續(xù)。 gls：game login server，游戲登錄服務(wù)器，某種程序上，其不是核心組件，gls調(diào)用外部的接口，進(jìn)行基本的用戶名密碼認(rèn)證。此外需要實現(xiàn)很多附屬的功能：登錄排隊（對開服非常有幫助），GM超級登錄通道（GM可以不排隊進(jìn)入游戲），封測期間激活用戶控制，限制用戶登錄，控制客戶端版本等。db：實質(zhì)上是后臺sql的大內(nèi)存緩沖，隔離了數(shù)據(jù)庫操作，比較內(nèi)存中的數(shù)據(jù)，只把改變的數(shù)據(jù)定時批量寫入sql。系統(tǒng)的算法，開發(fā)穩(wěn)定性都要求非常高。center：所有組件都要在這里注冊，在線玩家的session狀態(tài)都在這里集中存放，和各組件有心跳連接。所有對外的接口也全部通過這里。角色入口：玩家登錄游戲后的選擇角色gs：game server，最核心組件，同一地圖，所有游戲邏輯相關(guān)的功能，都在這里完成。gate：建立和用戶的常鏈接，主要作sockt轉(zhuǎn)發(fā)，屏蔽惡意包，對gs進(jìn)行保護(hù)。協(xié)議加密解密功能，一個gate共享多個gs，降低跳轉(zhuǎn)地圖連接不上的風(fēng)險。IM，關(guān)系，寄售：表示其它組件，負(fù)責(zé)對應(yīng)的跨地圖發(fā)生全局的游戲邏輯。7.另一個架構(gòu)圖 1- 這是一條WebService的管道，在用戶激活該區(qū)帳號，或者修改帳號密碼的時候，通過這條通道來插入和更新用戶的帳號信息。
2- 這也是一條WebService管道，用來獲取和控制用戶該該組內(nèi)的角色信息，以及進(jìn)行付費商城代幣之類的更新操作。
3- 這是一條本地的TCP/IP連接，這條連接主要用來進(jìn)行服務(wù)器組在登陸服務(wù)器的注冊，以及登陸服務(wù)器驗證帳戶后，向用戶服務(wù)器注冊帳戶登陸信息，以及進(jìn)行對已經(jīng)登陸的帳戶角色信息進(jìn)行操作（比如踢掉當(dāng)前登陸的角色），還有服務(wù)器組的信息更新（當(dāng)前在線玩家數(shù)量等）。
4- 這也是一條本地TCP/IP連接，這條連接用來對連接到GameServer的客戶端進(jìn)行驗證，以及獲取角色數(shù)據(jù)信息，還有傳回GameServer上角色的數(shù)據(jù)信息改變。
5- 這條連接也是一條本地的TCP/IP連接，它用來進(jìn)行公共信息服務(wù)器和數(shù)個游戲服務(wù)器間的交互，用來交換一些游戲世界級的信息（比如公會信息，跨服組隊信息，跨服聊天頻道等）。
6- 這里的兩條連接，想表達(dá)的意思是，UserServer和GameServer的Agent是可以互換使用的，也就是玩家進(jìn)入組內(nèi)之后，就不需要再切換Agent。如果不怕亂套，也可以把登陸服務(wù)器的Agent也算上，這樣用戶整個過程里就不需要再更換Agent，減少重復(fù)連接的次數(shù)，也提高了穩(wěn)定性。（畢竟連接次數(shù)少了，也降低了連不上服務(wù)器的出現(xiàn)幾率）
在這個架構(gòu)里面，GameServer實際上是一個游戲邏輯的綜合體，里面可以再去擴(kuò)展成幾個不同的邏輯服務(wù)器，通過PublicServer進(jìn)行公共數(shù)據(jù)交換。
UserServer實際上扮演了一個ServerGroup的領(lǐng)頭羊的角色，它負(fù)責(zé)向LoginServer注冊和更新服務(wù)器組的信息（名字，當(dāng)前人數(shù)），并且對Agent進(jìn)行調(diào)度，對選擇了該組的玩家提供一個用戶量最少的Agent。同時，它也兼了一個角色管理服務(wù)器的功能，發(fā)送給客戶端當(dāng)前的角色列表，角色的創(chuàng)建，刪除，選擇等管理操作，都是在這里進(jìn)行的。而且，它還是一個用戶信息的驗證服務(wù)器，GameServer需要通過它來進(jìn)行客戶端的合法性驗證，以及獲取玩家選擇的角色數(shù)據(jù)信息。
采用這種架構(gòu)的游戲，通常有以下表現(xiàn)。
1- 用戶必須激活一個大區(qū)，才能在大區(qū)內(nèi)登陸自己的帳號。
2- 用戶啟動客戶端的時候，彈出一個登陸器，選擇大區(qū)。
3- 用戶啟動真正的客戶端的時候，一開始就是輸入帳號密碼。
4- 帳號驗證完成之后，進(jìn)行區(qū)內(nèi)的服務(wù)器選擇。
5- 服務(wù)器選擇完成之后，進(jìn)入角色管理。同時，角色在不同的服務(wù)器里不能共享。 四.正文網(wǎng)絡(luò)通訊1.網(wǎng)絡(luò)協(xié)議
根據(jù)游戲類型 實時性要求/是否允許丟包 來決定 TCP/UDP協(xié)議
a.TCP:面向連接,可靠,保證順序,慢,有延遲
TCP每次發(fā)送一個數(shù)據(jù)包后都要等待接收方發(fā)送一個應(yīng)答信息，這樣TCP才可以確認(rèn)數(shù)據(jù)包通過因特網(wǎng)完整地送到了接收方。如果在一段時間內(nèi)TCP沒有收到接收方的應(yīng)答，他就會停止發(fā)送新的數(shù)據(jù)包，轉(zhuǎn)而去重新發(fā)送沒有收到應(yīng)答2的數(shù)據(jù)包，并且持續(xù)這種發(fā)送狀態(tài)知道收到接收方的應(yīng)答。所以這會造成網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)难舆t，若網(wǎng)絡(luò)情況不好，發(fā)送方會等待相當(dāng)長一段時間
UDP:無連接,不可靠,不保證順序,快
b.長連接/短連接
長連接，指在一個TCP連接上可以連續(xù)發(fā)送多個數(shù)據(jù)包，在TCP連接保持期間，如果沒有數(shù)據(jù)包發(fā)送，需要雙方發(fā)檢測包以維持此連接，一般需要自己做在線維
連接→數(shù)據(jù)傳輸→保持連接(心跳)→數(shù)據(jù)傳輸→保持連接(心跳)→……→關(guān)閉連接
短連接是指通信雙方有數(shù)據(jù)交互時，就建立一個TCP連接，數(shù)據(jù)發(fā)送完成后，則斷開此TCP連接,如Http
連接→數(shù)據(jù)傳輸→關(guān)閉連接 2.IO模型 Unix5中io模型1. 阻塞IO (Blocking I/O Model)2. 非阻塞IO (Nonblocking I/O Model)3. IO復(fù)用 (I/O Multiplexing Model)4. 信號驅(qū)動IO (Signal-Driven I/O Model)5. 異步IO (Asynchronous I/O Model)IO分兩個階段：1.通知內(nèi)核準(zhǔn)備數(shù)據(jù)。2.數(shù)據(jù)從內(nèi)核緩沖區(qū)拷貝到應(yīng)用緩沖區(qū)根據(jù)這2點IO類型可以分成： 1.阻塞IO，在兩個階段上面都是阻塞的。 2.非阻塞IO，在第1階段，程序不斷的輪詢直到數(shù)據(jù)準(zhǔn)備好，第2階段還是阻塞的 3.IO復(fù)用，在第1階段，當(dāng)一個或者多個IO準(zhǔn)備就緒時，通知程序，第2階段還是阻塞的，在第1階段還是輪詢實現(xiàn)的，只是所有的IO都集中在一個地方，這個地方進(jìn)行輪詢 4.信號IO，當(dāng)數(shù)據(jù)準(zhǔn)備完畢的時候，信號通知程序數(shù)據(jù)準(zhǔn)備完畢，第2階段阻塞 5.異步IO，1，2都不阻塞   同時阻塞多個I/O操作。而且可以同時對多個讀操作，多個寫操作的I/O函數(shù)進(jìn)行檢測，直到有數(shù)據(jù)可讀或可寫時，才真正調(diào)用I/O操作函數(shù)Java#Selector 允許套接口進(jìn)行信號驅(qū)動I/O,并安裝一個信號處理函數(shù)，進(jìn)程繼續(xù)運行并不阻塞。當(dāng)數(shù)據(jù)準(zhǔn)備好時，進(jìn)程會收到一個SIGIO信號，可以在信號處理函數(shù)中調(diào)用I/O操作函數(shù)處理數(shù)據(jù).
Java#NIO2發(fā)出系統(tǒng)調(diào)用后,直接返回。通知IO操作完成。前四種同步IO，最后一種異步IO.二者區(qū)別:第二個階段必須要求進(jìn)程主動調(diào)用recvfrom.而異步io則將io操作全部交給內(nèi)核完成,完成后發(fā)信號通知。此期間,用戶不需要去檢查IO操作的狀態(tài)，也不需要主動的去拷貝數(shù)據(jù)。3.線程阻塞的原因: 1.Thread.sleep(),線程放棄CPU，睡眠N秒,然后恢復(fù)運行 2.線程要執(zhí)行一段同步代碼,由于無法獲得相關(guān)的鎖,阻塞。獲得同步鎖后，才可以恢復(fù)運行。 .線程執(zhí)行了一個對象的wait方法，進(jìn)入阻塞狀態(tài),只有等到其他線程執(zhí)行了該對象的notify、nnotifyAll，才能將其喚醒。 4.IO操作,等待相關(guān)資源阻塞線程的共同特點是：放棄CPU,停止運行，只有等到導(dǎo)致阻塞的原因消除，才能恢復(fù)運行 。或者被其他線程中斷，該線程會退出阻塞狀態(tài)，并拋出InterruptedException.4.阻塞/非阻塞/同步/異步同步/異步關(guān)注的是消息如何通知的機(jī)制。而阻塞和非阻塞關(guān)注的是處理消息。是兩組完全不同的概念。5.幾個常用概念Select PollEpoll(Linux) Kqueue(FreeBSD) IOCP windows ReactorDispatcher（分發(fā)器），Notifer（通知器）, 事件到來時，使用Dispatcher（分發(fā)器）對Handler進(jìn)行分派，這個Dispatcher要對所有注冊的Handler進(jìn)行維護(hù)。同時，有一個Demultiplexer（分揀器）對多路的同步事件進(jìn)行分揀。 ProactorProactor和Reactor都是并發(fā)編程中的設(shè)計模式.用于派發(fā)/分離IO操作事件的。這里所謂的IO事件也就是諸如read/write的IO操作。"派發(fā)/分離"就是將單獨的IO事件通知到上層模塊。兩個模式不同的地方在于，Proactor用于異步IO，而Reactor用于同步IO。兩個模式的相同點，都是對某個IO事件的事件通知(即告訴某個模塊，這個IO操作可以進(jìn)行或已經(jīng)完成)。在結(jié)構(gòu)上，兩者也有相同點：demultiplexor負(fù)責(zé)提交IO操作(異步)、查詢設(shè)備是否可操作(同步)，然后當(dāng)條件滿足時，就回調(diào)handler。不同點在于，異步情況下(Proactor)，當(dāng)回調(diào)handler時，表示IO操作已經(jīng)完成；同步情況下(Reactor)，回調(diào)handler時，表示IO設(shè)備可以進(jìn)行某個操作(can read or can write)，handler這個時候開始提交操作。6.網(wǎng)絡(luò)通訊框架TCP Server框架: Apache MINA(Multipurpose Infrastructure for Network Applications)2.0.4Netty 3.5.0FinalGrizzly 2.2Quickserver是一個免費的開源Java庫，用于快速創(chuàng)建健壯的多線程、多客戶端TCP服務(wù)器應(yīng)用程序。使用QuickServer，用戶可以只集中處理應(yīng)用程序的邏輯/協(xié)議Cindy 強(qiáng)壯，可擴(kuò)展，高效的異步I/O框架xSocket一個輕量級的基于nio的服務(wù)器框架用于開發(fā)高性能、可擴(kuò)展、多線程的服務(wù)器。該框架封裝了線程處理、異步讀/寫等方面ACE 6.1.0 C++ADAPTIVE CommunicationEnvironment,SmaxFoxServer 2.X 專門為Adobe Flash設(shè)計的跨平臺socket服務(wù)器7.消息編碼協(xié)議AMF/JSON/XML/自定義/ProtocolBuffer無論是做何種網(wǎng)絡(luò)應(yīng)用，必須要解決的問題之一就是應(yīng)用層從字節(jié)流中拆分出消息的問題，也就是對于 TCP 這種字節(jié)流協(xié)議，接收方應(yīng)用層能夠從字節(jié)流中識別發(fā)送方傳輸?shù)南?1.使用特殊字符或者字符串作為消息的邊界，應(yīng)用層解析收到的字節(jié)流時，遇見此字符或者字符串則認(rèn)為收到一個完整的消息 2.為每個消息定義一個長度，應(yīng)用層收到指定長度的字節(jié)流則認(rèn)為收到了一個完整的消息消息分隔標(biāo)識（separator）、消息頭（header）、消息體（body） len | message_id | data |separator | header | body | | len | message_id | data8. 粘包:TCP粘包是指發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時粘成一包，從接收緩沖區(qū)看，后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾。 1.發(fā)送方引起的粘包是由TCP協(xié)議本身造成的，TCP為提高傳輸效率，發(fā)送方往往要收集到足夠多的數(shù)據(jù)后才發(fā)送一包數(shù)據(jù)。若連續(xù)發(fā)送幾次的數(shù)據(jù)都很少，通常TCP會根據(jù)優(yōu)化算法把這些數(shù)據(jù)合成一包后一次發(fā)送出去，這樣接收方就收到了粘包數(shù)據(jù)。 2.接收方引起的粘包是由于接收方用戶進(jìn)程不及時接收數(shù)據(jù)，從而導(dǎo)致粘包現(xiàn)象。這是因為接收方先把收到的數(shù)據(jù)放在系統(tǒng)接收緩沖區(qū)，用戶進(jìn)程從該緩沖區(qū)取數(shù)據(jù)，若下一包數(shù)據(jù)到達(dá)時前一包數(shù)據(jù)尚未被用戶進(jìn)程取走，則下一包數(shù)據(jù)放到系統(tǒng)接收緩沖區(qū)時就接到前一包數(shù)據(jù)之后，而用戶進(jìn)程根據(jù)預(yù)先設(shè)定的緩沖區(qū)大小從系統(tǒng)接收緩沖區(qū)取數(shù)據(jù)，這樣就一次取到了多包數(shù)據(jù)解決措施: 1.對于發(fā)送方引起的粘包現(xiàn)象，用戶可通過編程設(shè)置來避免，TCP提供了強(qiáng)制數(shù)據(jù)立即傳送的操作指令push，TCP軟件接收到該操作指令后，就立即將本段數(shù)據(jù)發(fā)送出去，而不必等待發(fā)送緩沖區(qū)滿；TCP-NO-DELAY-關(guān)閉了優(yōu)化算法,不推薦 2.對于接收方引起的粘包，則可通過優(yōu)化程序設(shè)計、精簡接收進(jìn)程工作量、提高接收進(jìn)程優(yōu)先級等措施，使其及時接收數(shù)據(jù)，從而盡量避免出現(xiàn)粘包現(xiàn)象-當(dāng)發(fā)送頻率高時依然可能出現(xiàn)粘包 3.接收方控制，將一包數(shù)據(jù)按結(jié)構(gòu)字段，人為控制分多次接收，然后合并，通過這種手段來避免粘包。-效率低 4.接收方創(chuàng)建一預(yù)處理線程，對接收到的數(shù)據(jù)包進(jìn)行預(yù)處理，將粘連的包分開分包算法思路:基本思路是首先將待處理的接收數(shù)據(jù)（長度設(shè)為m）強(qiáng)行轉(zhuǎn)換成預(yù)定的結(jié)構(gòu)數(shù)據(jù)形式，并從中取出數(shù)據(jù)結(jié)構(gòu)長度字段，即n，而后根據(jù)n計算得到第一包數(shù)據(jù)長度1) 若n<m，則表明數(shù)據(jù)流包含多包數(shù)據(jù)，從其頭部截取n個字節(jié)存入臨時緩沖區(qū)，剩余部分?jǐn)?shù)據(jù)一次繼續(xù)循環(huán)處理，直至結(jié)束。2) 若n=m，則表明數(shù)據(jù)流內(nèi)容恰好是一完整結(jié)構(gòu)數(shù)據(jù)，直接將其存入臨時緩沖區(qū)即可。3) 若n>m，則表明數(shù)據(jù)流內(nèi)容尚不夠構(gòu)成一個完整結(jié)構(gòu)數(shù)據(jù)，需留待與下一包數(shù)據(jù)合并后再行處理。五.正文之場景管理、ai、腳本 AOI: (Area Of Interest),廣義上，AOI系統(tǒng)支持任何游戲世界中的物體個體對一定半徑范圍內(nèi)發(fā)生的事件進(jìn)行處理；但MMOPRG上絕大多數(shù)需求只是對半徑范圍內(nèi)發(fā)生的物體離開/進(jìn)入事件進(jìn)行處理。當(dāng)你進(jìn)入一個游戲場景時，如果你能看到其他玩家，那背后AOI系統(tǒng)就正在運作. 1. 很容易想象，AOI的需求最簡單的做法是全世界玩家信息全部同步給客戶端。這個方案是O(n^2)的復(fù)雜度，對服務(wù)器來說是不能承受之重。但如果是超小地圖十人以下的特殊需求倒可能是個簡潔的方案。 2. 比較流行的方案是網(wǎng)格法，簡單，高效：將地圖按設(shè)定的格子大小劃分為網(wǎng)格，設(shè)玩家移動到某坐標(biāo)，我們很容易地將玩家歸入該坐標(biāo)所屬的網(wǎng)格G的玩家鏈中，而這個玩家的可見集可以簡單地將以網(wǎng)格G為中心的九宮格中的玩家鏈聚合而得到。而要獲得兩次移動間的可見集差異，也非難事.轉(zhuǎn)自云風(fēng)Blog:所謂 AOI ( Area Of Interest ) ，大致有兩個用途。 一則是解決 NPC 的 AI 事件觸發(fā)問題。游戲場景中有眾多的 NPC ，比 PC 大致要多一個數(shù)量級。NPC 的 AI 觸發(fā)條件往往是和其它 NPC 或 PC 距離接近。如果沒有 AOI 模塊，每個 NPC 都需要遍歷場景中其它對象，判斷與之距離。這個檢索量是非常巨大的（復(fù)雜度 O(N*N) ）。一般我們會設(shè)計一個 AOI 模塊，統(tǒng)一處理，并優(yōu)化比較次數(shù)，當(dāng)兩個對象距離接近時，以消息的形式通知它們。 二則用于減少向 PC 發(fā)送的同步消息數(shù)量。把離 PC 較遠(yuǎn)的物體狀態(tài)變化的消息過濾掉。PC 身上可以帶一個附近對象列表，由 AOI 消息來增減這個列表的內(nèi)容。在服務(wù)器上，我們一般推薦把 AOI 模塊做成一個獨立服務(wù) 。場景模塊通知它改變對象的位置信息。AOI 服務(wù)則發(fā)送 AOI 消息給場景AOI 的傳統(tǒng)實現(xiàn)方法大致有三種：第一，也是最苯的方案。直接定期比較所有對象間的關(guān)系，發(fā)現(xiàn)能夠觸發(fā) AOI 事件就發(fā)送消息。這種方案實現(xiàn)起來相當(dāng)簡潔，幾乎不可能有 bug ，可以用來驗證服務(wù)協(xié)議的正確性。在場景中對象不對的情況下其實也是不錯的一個方案。如果我們獨立出來的話，利用一個單獨的核，其實可以定期處理相當(dāng)大的對象數(shù)量。第二，空間切割監(jiān)視的方法。把場景劃分為等大的格子，在每個格子里樹立燈塔。在對象進(jìn)入或退出格子時，維護(hù)每個燈塔上的對象列表。對于每個燈塔還是 O(N * N) 的復(fù)雜度，但由于把對象數(shù)據(jù)量大量降了下來，所以性能要好的多，實現(xiàn)也很容易。缺點是，存儲空間不僅和對象數(shù)量有關(guān)，還和場景大小有關(guān)。更浪費內(nèi)存。且當(dāng)場景規(guī)模大過對象數(shù)量規(guī)模時，性能還會下降。因為要遍歷整個場景。對大地圖不太合適。這里還有一些優(yōu)化技巧，比如可以把格子劃分為六邊形 的。第三，使用十字鏈表 (3d 空間則再增加一個鏈表維度) 保存一系列線段，當(dāng)線段移動時觸發(fā) AOI 事件。算法不展開解釋，這個用的很多應(yīng)該搜的到。優(yōu)點是可以混用于不同半徑的 AOI 區(qū)域。2.AI 1.怪物AI 2.NPC AI 3.世界環(huán)境AI實現(xiàn)方法：狀態(tài)機(jī) 其他: 尋路：A* 神經(jīng)網(wǎng)絡(luò) 遺傳算法3.腳本語言的選擇：Lua/Python/Erlang
Groovy/JRuby/Scala/Fantom/JPython-五大基于JVM的語言
作用:可應(yīng)用于部分應(yīng)用層邏輯經(jīng)常發(fā)生變化的系統(tǒng)。如任務(wù)系統(tǒng)。以在不需要重新編譯整個工程的情況下調(diào)整、 測試和修改游戲運行的機(jī)制和特性 六.正文之開源網(wǎng)絡(luò)游戲服務(wù)器魔獸世界模擬器mangosTrinity TrinityCore2天堂2模擬器L2J
永恒之塔模擬器Arianne七.正文之參考書籍，博客1.云風(fēng)Blog ttp://codingnow.com/
2.書籍<大型多人在線游戲開發(fā)><網(wǎng)絡(luò)游戲服務(wù)器編程><UNIX網(wǎng)絡(luò)編程>
注：有部分內(nèi)容來自網(wǎng)絡(luò),謝謝你們！
|