【正文】 帶些客戶端，現(xiàn)在要所有的連接都從中心服上轉(zhuǎn)發(fā)，那連接數(shù)又遇到單臺服務(wù)器的可最大承載量的瓶頸了。我們來看看結(jié)構(gòu)圖是怎樣的：中心服務(wù)器登錄服 地圖1 地圖2 地圖n客戶端很簡單，不是嗎。正如俗語所說的那樣，三個(gè)和尚可能會碰到?jīng)]水喝的情況。在所有這些基礎(chǔ)邏輯中，與我們要討論的服務(wù)器結(jié)構(gòu)關(guān)系最緊密的當(dāng)屬地圖管理方式。最后，我們的服務(wù)器結(jié)構(gòu)就像這樣：大區(qū)服務(wù)器登錄服1 登錄服2 世界服1 世界服2帳號數(shù)據(jù)庫 DBS DBS這里既然討論到了大區(qū)及帳號數(shù)據(jù)庫，所以順帶也說一下關(guān)于激活大區(qū)的概念。最新的DNS服務(wù)已實(shí)現(xiàn)了根據(jù)服務(wù)器系統(tǒng)狀態(tài)來實(shí)現(xiàn)的動態(tài)負(fù)載均衡，也就是實(shí)現(xiàn)了真正意義上的負(fù)載均衡，這樣也就有效地解決了當(dāng)某臺登錄服當(dāng)機(jī)后，DNS服務(wù)器不能立即做出反應(yīng)的問題。還是拿開新區(qū)的情況來說，即使新增加登錄服滿足了玩家登錄的請求，游戲世界服的承載能力依然有限，玩家一樣只能在排隊(duì)系統(tǒng)中等待，或者是進(jìn)入到游戲世界中導(dǎo)致大家都卡。所以，我們能否更合理地配置登錄服資源，使得整個(gè)大區(qū)內(nèi)的登錄服可以共享就成了下一步改進(jìn)的目標(biāo)。這樣，我們可為每組服務(wù)器單獨(dú)配備一臺登錄服。對于一個(gè)最簡單的游戲服務(wù)器來說，它只需要能夠接受來自客戶端的連接請求，然后處理客戶端在游戲世界中的移動及交互，也即游戲邏輯處理即可。所以游戲開發(fā)人員基本都是多面手，從網(wǎng)絡(luò)到數(shù)據(jù)庫，從游戲邏輯到圖形圖象，每一項(xiàng)都有所了解，并能實(shí)際應(yīng)用。要描述一項(xiàng)技術(shù)或是一個(gè)行業(yè)，一般都會從其最古老的歷史開始說起，我本也想按著這個(gè)套路走，無奈本人乃一八零后小輩，沒有經(jīng)歷過那些苦澀的卻令人羨慕的單機(jī)游戲開發(fā)，也沒有響當(dāng)當(dāng)?shù)哪玫某鍪值膬?yōu)秀作品，所以也就只能就我所了解的一些技術(shù)做些簡單的描述。一來算是敦促自己對知識做個(gè)梳理，二來與大家探討的過程也能夠找到我之前學(xué)習(xí)的不足和理解上的錯(cuò)誤，最后呢，有可能的話也跟業(yè)內(nèi)的同行們混個(gè)臉熟，哪天要是想換個(gè)工作了也好有個(gè)人幫忙介紹下?；蛘哒f都具有非常強(qiáng)的學(xué)習(xí)能力，在接手一項(xiàng)新的任務(wù)后能在很短的時(shí)間內(nèi)對該領(lǐng)域的技術(shù)迅速掌握并消化，而且還能現(xiàn)炒現(xiàn)賣。如果我們把這兩項(xiàng)功能集成到一個(gè)服務(wù)進(jìn)程中，則最終的結(jié)構(gòu)很簡單：clientserver嗯，太簡單了點(diǎn)，這樣也敢叫服務(wù)器結(jié)構(gòu)？好吧，現(xiàn)在我們來往里面稍稍加點(diǎn)東西，讓它看起來更像是服務(wù)器結(jié)構(gòu)一些。最后的結(jié)構(gòu)圖應(yīng)該像這樣：loginServer gameServer client該結(jié)構(gòu)下的玩家操作流程為，先選擇大區(qū)，再選擇大區(qū)下的某臺服務(wù)器，即某個(gè)游戲世界，點(diǎn)擊進(jìn)入后開始帳號驗(yàn)證過程，驗(yàn)證成功則進(jìn)入了該游戲世界。服務(wù)器結(jié)構(gòu)探討登錄服的負(fù)載均衡回想一下我們在玩wow時(shí)的操作流程：，首先就會要求我們輸入用戶名和密碼進(jìn)行驗(yàn)證，驗(yàn)證成功后才會出來游戲世界列表，之后是排隊(duì)進(jìn)入游戲世界，開始游戲...可以看到跟前面的描述有個(gè)很明顯的不同，那就是要先驗(yàn)證帳號再選擇游戲世界。另外，當(dāng)我們在增加或移除登錄服的時(shí)候不應(yīng)該需要對游戲世界服有所改動，也不會要求重啟世界服，當(dāng)然也不應(yīng)該要求客戶端有什么更新或者修改，一切都是在背后自動完成。當(dāng)然，如果找不到這樣的解決方案，自己從頭打造一個(gè)也并不難。wow中一共有八個(gè)大區(qū)，我們想要進(jìn)入某個(gè)大區(qū)游戲之前，必須到官網(wǎng)上激活這個(gè)區(qū)，這是為什么呢？一般來說，在各個(gè)大區(qū)帳號數(shù)據(jù)庫之上還有一個(gè)總的帳號數(shù)據(jù)庫，我們可以稱它為中心數(shù)據(jù)庫。決定了地圖的管理方式也就決定了我們的服務(wù)器結(jié)構(gòu)，我們?nèi)匀幌葟淖詈唵蔚膶?shí)現(xiàn)方式開始說起。當(dāng)人數(shù)繼續(xù)增加，情況就變得不那么簡單了，我們得需要一個(gè)管理者來對我們的工作進(jìn)行分工、協(xié)調(diào)。但是簡單并不表示功能上會有什么損失，簡單也更不能表示游戲不能賺錢。這里有必要再解釋下這個(gè)數(shù)字。至少在現(xiàn)在來說，一個(gè)游戲世界內(nèi)，也就是一組服務(wù)器內(nèi)同時(shí)有五六千個(gè)在線的玩家還是件讓人很興奮的事。我們可以試著對地圖進(jìn)行一些劃分，由一個(gè) Master Server來管理一些更小的Zone Server，玩家通過網(wǎng)關(guān)連接到Master Server上，而實(shí)際與地圖有關(guān)的邏輯是分派給更小的Zone Server去處理。當(dāng)然，這只是一種簡單的實(shí)現(xiàn)，也是普通使用的一種方案，如果后期想對消息廣播做一些優(yōu)化的話，那可能才需要多考慮一下。好了，做完這些優(yōu)化我們的服務(wù)器結(jié)構(gòu)大體也就定的差不多了，暫且也不再繼續(xù)深入，更細(xì)化的內(nèi)容等到各個(gè)部分實(shí)現(xiàn)的時(shí)候再探討。從記錄玩家登錄的時(shí)間，地址，機(jī)器信息到游戲過程中的每一項(xiàng)操作都可以作為日志記錄下來，以備查錯(cuò)及數(shù)據(jù)挖掘用。如果真有權(quán)利去選擇的話，選自己最熟悉的吧。但實(shí)際上，我覺得這是完全沒有必要的，真要出現(xiàn)這樣的錯(cuò)誤，直接斷開這個(gè)客戶端的連接可能更安全。好了，廢話說完了，下一篇，我們開始進(jìn)入登錄服的設(shè)計(jì)吧。關(guān)于為什么要提供用戶名和密碼才能進(jìn)入的問題我們這里不打算做過多討論，云風(fēng)曾對此也提出過類似的疑問，并給出了只用一個(gè)標(biāo)識串就能進(jìn)入的設(shè)想，有興趣的可以去看看他們的討論。早期的游戲大都采用的是這種結(jié)構(gòu)，有些游戲在實(shí)現(xiàn)時(shí)采用了一些技術(shù)手段使得在切換游戲服時(shí)不需要再次驗(yàn)證帳號，但整體結(jié)構(gòu)還是未做改變。我們可以試著從實(shí)際需求的角度來考慮一下這個(gè)問題。一般來說，使用現(xiàn)有的商業(yè)數(shù)據(jù)庫系統(tǒng)比自己手工技術(shù)先進(jìn)要明智得多。而對于數(shù)據(jù)庫的應(yīng)用，在這種結(jié)構(gòu)下，登錄服及游戲世界服都會需要連接數(shù)據(jù)庫。而當(dāng)我們要到一區(qū)去創(chuàng)建角色開始游戲的時(shí)候，在一區(qū)的帳號數(shù)據(jù)庫中并沒有我們的帳號數(shù)據(jù)，所以，我們必須先到官網(wǎng)上做一次激活操作。世界中有些地圖間雖然在地理上是直接相連的，但我們發(fā)現(xiàn)其游戲內(nèi)部的邏輯卻是完全隔離的。一般來說，我們的游戲世界不可能會只有一塊或者兩塊小地圖，那順理成章的，也就需要一個(gè)地圖管理者。服務(wù)器結(jié)構(gòu)探討繼續(xù)世界服都已經(jīng)看出來了，這種每切換一次地圖就要重新連接服務(wù)器的方式實(shí)在是不夠優(yōu)雅，而且在實(shí)際游戲運(yùn)營中也發(fā)現(xiàn)，地圖切換導(dǎo)致的卡號，復(fù)制裝備等問題非常多，這里完全就是一個(gè)事故多發(fā)地段，如何避免這種頻繁的連接操作呢？最直接的方法就是把那個(gè)圖倒轉(zhuǎn)過來就行了。問題恰恰在于你是隨便寫的，而MMORPG的服務(wù)器是復(fù)雜設(shè)計(jì)的。什么？你說夢幻、魔獸還有史先生的那個(gè)什么征途遠(yuǎn)不止這么點(diǎn)人了！噢，我說的是大多數(shù)，是大多數(shù)，不包括那些明星。好吧，我們還是把之前留下的問題拿出來解決掉吧。首先是當(dāng)前的Zone Server要做的事情太多了，以至于他都處理不了多少連接。我們的游戲服務(wù)器也如此。差不多就這么多了吧，接下來我們會按照這個(gè)大致的結(jié)構(gòu)來詳細(xì)討論各部分的實(shí)現(xiàn)。:)然后是網(wǎng)絡(luò)協(xié)議的選擇，以前的選擇大多傾向于UDP，為了可靠傳輸一般自己都會在上面實(shí)現(xiàn)一層封裝，而現(xiàn)在更普通的是直接采用本身就很可靠的TCP，或者TCP與UDP的混用。最后是一個(gè)純技術(shù)問題，有關(guān)socket連接數(shù)的最大限制。為了便于描述，我們暫不引入那些討論過的優(yōu)化手段，先以最簡單的方式實(shí)現(xiàn)，另外也將基本以mangos的代碼作為參考來進(jìn)行描述。噢，不要管那個(gè)王小云的什么論文，如果我真有那么好的運(yùn)氣，早中500w了，還用在這考慮該死的服務(wù)器設(shè)計(jì)嗎？似乎是一個(gè)很完美的方案，外掛制作者再也偷不到我們的密碼了。不過其代碼實(shí)現(xiàn)步驟倒是并不復(fù)雜，mangos中的代碼也還算清晰，我們也不再贅述。服務(wù)器公共組件實(shí)現(xiàn)mangos的游戲主循環(huán)當(dāng)閱讀一項(xiàng)工程的源碼時(shí)，我們大概會選擇從main函數(shù)開始，而當(dāng)開始一項(xiàng)新的工程時(shí)，第一個(gè)寫下的函數(shù)大多也是main。很簡單的結(jié)構(gòu)，也比較容易理解。正如我們曾討論過的，為了游戲主邏輯循環(huán)的流暢運(yùn)行，所有比較耗時(shí)的IO操作都會分享到單獨(dú)的線程中去做，如網(wǎng)絡(luò)IO，數(shù)據(jù)庫IO和日志IO等。}這里就有一個(gè)問題需要探討了，在getMessage()的時(shí)候，我們應(yīng)該去哪里取消息？前面我們考慮過，至少會有三個(gè)消息來源，而我們還討論過，這些消息源的IO操作都是在獨(dú)立的線程中進(jìn)行的，我們這里的主線程不應(yīng)該直接去那幾處消息源進(jìn)行阻塞式的IO操作。我們所能想到的最簡單的消息隊(duì)列可能就是使用stl的list來實(shí)現(xiàn)了，即消息隊(duì)列內(nèi)部維護(hù)一個(gè)list和一個(gè)互斥鎖，putMessage時(shí)將message加入到隊(duì)列尾，getMessage時(shí)從隊(duì)列頭取一個(gè)message返回，同時(shí)在getMessage和putMessage之前都要求先獲取鎖資源。這里為每個(gè)隊(duì)列設(shè)了個(gè)最大消息數(shù)，看來好像是打算只有當(dāng)IO線程寫滿隊(duì)列時(shí)才會將其放回到容器中換另一個(gè)隊(duì)列。兩種方案都是很優(yōu)秀的優(yōu)化方案，但也都是有其適用范圍的。如果追上了怎么辦？那就是沒有數(shù)據(jù)可讀了，先等會兒唄，等跑的人向前跑幾步了再追，總不能讓游戲沒得玩了吧。在解包及解密完成后，我們會將這個(gè)數(shù)據(jù)包復(fù)制到邏輯線程消息隊(duì)列中，如果我們只使用一個(gè)隊(duì)列，那這里也將會是個(gè)環(huán)形緩沖區(qū)，IO線程往里寫，邏輯線程在后面讀，互相追逐?？紤]數(shù)據(jù)緩存的話，那這里這可以有兩種實(shí)現(xiàn)方式了，一是為每個(gè)玩家準(zhǔn)備一個(gè)緩沖區(qū)，另外就是只有一個(gè)全局的緩沖區(qū)，要發(fā)送的數(shù)據(jù)加入到全局緩沖區(qū)的時(shí)候同時(shí)要指明這個(gè)數(shù)據(jù)是發(fā)到哪個(gè)socket的。bool(AuthSocket::*handler)(void)。由于這里的兩個(gè)狀態(tài)標(biāo)識只區(qū)分出了兩種狀態(tài)，所以，我們僅需要兩個(gè)獨(dú)立的類，用以表示兩種狀態(tài)即可。}。BR正如同在設(shè)計(jì)模式中所描述的，所有的模式都是已有問題的另一種解決方案，也就是說這并不是唯一的解決方案。這樣，與QT類似，對于事件我們可以重定義其處理方法，甚至過濾掉某些事件使其不被處理，但對于信號我們只是收到了一個(gè)通知，有些類似于Observe模式中的觀察者，當(dāng)收到更新通知時(shí)，我們只能更新自己的狀態(tài)，對剛剛發(fā)生的事件我不已不能做任何影響。另外還有一個(gè)需要我們關(guān)注的問題是事件和信號處理時(shí)的優(yōu)先級問題。我們需要注意的一個(gè)很重要的問題是會不會引起循環(huán)調(diào)用。LoginServer處理玩家的登錄及世界服選擇請求。類似的，如果DNSServer也可以讓LoginServer自己去注冊，這樣在臨時(shí)LoginServer時(shí)就不需要去改動DNSServer的配置文件了。先從狀態(tài)機(jī)開始，前面也說過了，登錄服上的連接會有兩種狀態(tài)，一是帳號密碼驗(yàn)證狀態(tài)，一是服務(wù)器列表選擇狀態(tài)，其實(shí)還有另外一個(gè)狀態(tài)我們未曾討論過，因?yàn)樗c我們的登錄過程并無多大關(guān)系，這就是升級包發(fā)送狀態(tài)。當(dāng)客戶端選擇了一個(gè)世界之后該怎么辦？wow的做法是，當(dāng)客戶端選擇一個(gè)游戲世界時(shí)，客戶端會主動去連接該世界服的IP和PORT，然后進(jìn)入這個(gè)游戲世界。方法很簡單，去找給他登機(jī)牌的那個(gè)檢票員問一下，這張牌是不是他發(fā)的不就得了。一個(gè)可行的方案是，讓任意時(shí)刻只有一個(gè)地方保存一個(gè)客戶端的session key，這個(gè)地方可能是客戶端當(dāng)前正連接著的服務(wù)器，也可以是它正要去連接的服務(wù)器。不管是怎樣一種方式，了解了其過程，代碼實(shí)現(xiàn)都是比較簡單的，我們就不再贅述了第四篇：游戲架構(gòu)設(shè)計(jì)淺談游戲策劃的前期工作班級：09數(shù)字媒體技術(shù)姓名：廖偉民學(xué)號：090804006摘要：游戲制作所涉及的知識領(lǐng)域極其廣泛，其中就單其游戲策劃這一塊就涉及到三大內(nèi)容：前期的準(zhǔn)備工作、中期的制作工作、后期的宣傳工作。在這篇文章當(dāng)中我將針對游戲策劃當(dāng)中的前期準(zhǔn)備進(jìn)行說明，并發(fā)表自己的看法。如果客戶端這時(shí)想要去某個(gè)游戲世界，那么他必須先通知當(dāng)前連接的LoginServer要去的服務(wù)器地址，LoginServer將session key安全轉(zhuǎn)移給目標(biāo)服務(wù)器，轉(zhuǎn)移的意思是要確保目標(biāo)服務(wù)器收到了session key，本地保存的要?jiǎng)h除掉。那么，LoginServer將這個(gè)key存到數(shù)據(jù)庫中，讓網(wǎng)關(guān)服自己去數(shù)據(jù)庫驗(yàn)證？似乎也是個(gè)可行的方案。這是一個(gè)很必要的設(shè)計(jì)，保證了我們在因意外情況連接不上世界服或者發(fā)現(xiàn)世界服正在排隊(duì)而想換另外一個(gè)試試時(shí)不會需要重新進(jìn)行密碼驗(yàn)證。密碼驗(yàn)證的過程使用了SRP6協(xié)議，具體過程就不多做描述，每個(gè)游戲使用的方式也都不大一樣。這里可以用一個(gè)心跳包來實(shí)現(xiàn)其狀態(tài)的檢測，如果WorldServer的連接斷開或者在規(guī)定時(shí)間內(nèi)未收到心跳包，則將其狀態(tài)更新為離線。在mangos的代碼中，我們注意到登錄服是從數(shù)據(jù)庫中取的世界列表，而在wow官方服務(wù)器中，我們卻會注意到，這個(gè)世界服列表并不是一開始就固定，而是動態(tài)生成的。在上面的文字中就同時(shí)出現(xiàn)了消息、事件和信號三個(gè)相近的概念，而在實(shí)際處理中，經(jīng)常發(fā)現(xiàn)三者不知道如何界定的情況，實(shí)際的情況比我在這里描述的要混亂的多。對于信號的處理則比較簡單，默認(rèn)是沒有順序的，如果需要明確的順序，可以在信號注冊時(shí)顯示地指明槽的位置。但有一項(xiàng)區(qū)別在于，事件處理函數(shù)的返回值是有意義的，我們要根據(jù)這個(gè)返回值來確定是否還要繼續(xù)事件的處理，比如在QT中，事件處理函數(shù)如果返回true，則這個(gè)事件處理已完成，QApplication會接著處理下一個(gè)事件，而如果返回false，那么事件分派函數(shù)會繼續(xù)向上尋找下一個(gè)可以處理該事件的注冊方法。比如在游戲服務(wù)器上玩家的狀態(tài)管理，還有在實(shí)現(xiàn)NPC人工智能時(shí)的各種狀態(tài)管理，這些就留作以后的專題吧。當(dāng)要進(jìn)行狀態(tài)轉(zhuǎn)換時(shí)，調(diào)用MachineBase的ChangeState()方法，顯示地告訴狀態(tài)機(jī)管理類自己要轉(zhuǎn)到哪一個(gè)狀態(tài)。稍作整理，大概的代碼會類似這樣：狀態(tài)基類接口：StateBase{void Enter()= 0。該結(jié)構(gòu)體定義了每個(gè)消息碼的處理函數(shù)及需要的狀態(tài)標(biāo)識，只有當(dāng)前狀態(tài)滿足要求時(shí)才會調(diào)用指定的處理函數(shù)，否則這個(gè)消息碼的出現(xiàn)是不合法的。采用第二種方式還可以附帶一個(gè)優(yōu)化方案。因?yàn)槲覀儗ν粋€(gè)隊(duì)列不再會出現(xiàn)同時(shí)讀和寫的情況，每個(gè)隊(duì)列在寫滿后交給邏輯線程去讀，邏輯線程讀完后清空隊(duì)列再交給IO線程去寫，一段固定大小的緩沖區(qū)即可。要是一直這么反著追，估計(jì)您就只能換一個(gè)跑的更快的追逐者了，要不這游戲還真沒法玩下去。arthur的方案很好的解決了上一個(gè)方案遺留的問題，但因?yàn)橹挥幸粋€(gè)寫隊(duì)列，所以當(dāng)想要提供多個(gè)IO線程時(shí)，線程間互斥地寫入數(shù)據(jù)可能會增大競爭的機(jī)會，當(dāng)然，如果只有一個(gè)IO線程那將是非常完美的。Ghost Cheng在他的描述中沒有講到如何解決這種問題，但我們可以先來看看另一個(gè)方案。其最大的問題在頻繁的鎖競爭上。好比是，我這里提供了一個(gè)倉庫，有很多的供貨商，他們有貨要給我的時(shí)候只需要交到倉庫，然后我再到倉庫去取就是了，這個(gè)倉庫也就是消息隊(duì)列。