應用伺服器的設計（上）
應用伺服器的工作有：0
同步廣播玩家的行為；
1作為第三方對玩家個體和玩家之間互動行為計算，並將計算結果推送到資料儲存系統；
2驅動遊戲中的
npc；
3作為乙個特殊的遊戲參與者，與玩家相互作用。
應用伺服器最重要的工作莫過於同步廣播玩家之間的行為，使玩家之間能夠互視，多人同時遊戲才有意義。
對客戶端和伺服器都是不可忽視的壓力。理想情況下每個玩家的行為訊息的受眾是那些看的見此人的玩家。每個玩家都維護了乙個列表，表中元素是自己看得見的其他玩家。我們假設每個玩家的視力情況是一樣的，我看見你的同時你也看到了我。這樣每個訊息的傳送目標就是這個列表的所有元素。至於這個列表，是隨著玩家的移動而更新的。
伺服器程式開發兩個指標最重要，一是要快，二是要穩。面對紛至沓來的客戶端請求不可能像apache
那樣為每個請求派生乙個子程序或執行緒來完成業務計算，也不能為每個客戶端的連線派生子程序或執行緒，利用執行緒池也是應該避免設計思路。換句話說，對客戶端的請求不應該設計平行計算的思路。我們假設現在有兩個以上的玩家攻擊乙個
npc，如果我們對客戶端傳來的攻擊請求做平行計算，那麼在
npc很可能死上兩次以上。因為玩家
a讀取的
npc血量為1，
cpu切換到另乙個玩家的執行緒，玩家
b讀取的
npc血量為
1，玩家
b繼續殺戮，
npc的血量從1到
0，死亡一次，這時
cpu切換到玩家
a的執行緒，在這個上下文裡，
npc又經歷了一次死亡。這種荒誕的現象正是多執行緒資料不同步造成的。而同時遊戲應用裡資料讀寫操作十分頻繁，對資料加鎖並不是乙個好主意。如果鎖的粒度過小，系統將在鎖的檢查上浪費掉大量的計算時間；如果過大則非同步併發沒有意義，試想一下我們將每次攻擊設計乙個同步塊，那麼對乙個
boss
會有多大的延遲。
另外乙個致命的問題是，玩家之間是非同步的，每個玩家的行為是序列的。如果將玩家每個行為交由執行緒池計算，則這種序列性無法保證；如果將當前玩家當前所有的行為以佇列結構交由執行緒池處理，則會占用cpu
資源，對其他玩家並不公平。
多工作業系統其實在某乙個瞬間也只是執行了乙個程序，可是系統卻在少食多餐，表面上多個任務同時在進行。遊戲應用程式也可以對所有玩家做迭代計算，每次只計算乙個行為，保證所有玩家在短時間內都是活躍的即可。
遊戲服務端開發 一
資料儲存伺服器 遊戲中的資料大致分為靜態配置資料和動態的玩家資料。這裡主要討論玩家資料儲存的解決方案。雖然遊戲應用的寫操作要多於讀操作，但是加入快取層仍然有其必要性。多個應用伺服器啟動時從資料庫讀取資料會在瞬間給資料庫造成巨大壓力，如果將相對靜態的資料以檔案的形式放在應用伺服器本地，可以避免這個問題...
遊戲服務端開發 隨想
最近公司上線了一款遊戲，後台服務端出現各種bug,我簡單的將出現的問題做了分類，多執行緒操作的資料一致性bug，邏輯bug,流程bug。雖然感覺這樣分並不能完全表述出現的bug型別，但我認為至少是這三類問題能概括了目前出現的bug.於是大家一起 了怎麼在上線環境來定位bug的問題所在。其實，我想更應...
服務端學習二 OA D 開源遊戲服務端學習
今天開始oa.d.的開源遊戲服務端學習，由於沒有老師，一切都需要自己重頭學，一開始會感覺有點困難，但是我相信經過不懈的努力會取得成功的！遊戲開發者 廢話不多說，現在先看一下目錄結構，我放在了vs2012上執行，跑了一下，沒什麼問題，目錄結構如下 其中 collada 3d標準庫的相應操作，用於場景檔...