aoi(area of interest)，中文就是感興趣區域。通俗一點說，感興趣區域就是玩家在場景實時看到的區域；也就是aoi會隨著英雄的移動改變而改變。
一般在遊戲的中，遊戲的世界都是由各種場景組成，場景中有著各種各樣的obj(英雄、怪物、npc和掉落物品等等)。當英雄在移動的時候，玩家需要看到其它在自己視野內玩家的英雄；需要看到在自己視野內的怪物；需要看到打boss掉落的物品；……。
有人會說：這還不簡單，將場景內所有obj的資訊實時廣播給其它玩家，這不就行了嗎？！
當然這樣的做法對於一些類似競技場、擂台這樣的玩法確實是乙個最優的解決方法。畢竟在這個場景只有你們兩個人。但是你能想像一下乙個場景有幾百個英雄，甚至幾千個英雄時候（還不包括其它的obj），它們每移動一步都向你的廣播一下資訊。下面用公式計算一下，假設場景有1000個英雄。每個英雄都向其它各個英雄廣播自己的資訊。也就是說乙個每個英雄都要處理其它1000個英雄的實時資訊（其實是999個，為了方便計算）。這樣一來，伺服器就需要實時處理一百萬條資訊了。但是如果伺服器有對aoi作處理，玩家的視野大約只有50個英雄（aoi裡有50個英雄），那麼只需要這50個英雄向自己的英雄傳送資訊就可以了。那麼伺服器只需要實時處理2500條資訊就可以。效率一下子提高了400倍，而且節約了網路開銷。
下面就介紹實際應用中最常用的aoi處理方法--網格法。
這篇博文只是說清楚aoi網格法的原理，為以後寫場景管理器的時候作一些理論的鋪墊，所以這篇博文不會貼**。
1、首先會將場景劃分等大小的網格。
2、當玩家進入到場景的時候（無論是從傳送點傳送進來，還是飛進來的），會將玩家註冊到某個網格，與此同時通過使用觀察者模式，將新進來自己的英雄資訊通知對這個網格感興趣的其它英雄。懂lua的可以看一下觀察者模式lua實現：
3、與此同時，自己的英雄也有感興趣的區域（aoi），因為感興趣是相互的。如紅色矩形a，他的感興趣的區域就是包含它的4個網格；如果a移動到b，那麼自己的英雄的感興趣的區域就是1、2、3、4、5、6、7、8和9了。也就是說當上述區域的obj發生改變的時候，都要通知自己的英雄。
4、那樣要怎樣才能快速找到aoi呢？可以從圖中看出，這樣劃分成網格後，就會變成矩陣。我們可以將其儲存成二維陣列，這樣就能在o(1)下定位到aoi了。
5、aoi的大小一般大於等於螢幕座標大小。如果小於的話，在邊緣的obj將會看不見。（因為你都沒有發訊息給客戶端）。
6、網格劃分得太小，對記憶體開銷較大；網格劃分得太大，對cpu開銷較大，因為由矩形b可以看出，需要將b的資訊發到不在b的視野內的其它的obj（注意這裡說的是視野，aoi是那9個格仔），大大增加了開銷。
遊戲服務端開發 一
資料儲存伺服器 遊戲中的資料大致分為靜態配置資料和動態的玩家資料。這裡主要討論玩家資料儲存的解決方案。雖然遊戲應用的寫操作要多於讀操作，但是加入快取層仍然有其必要性。多個應用伺服器啟動時從資料庫讀取資料會在瞬間給資料庫造成巨大壓力，如果將相對靜態的資料以檔案的形式放在應用伺服器本地，可以避免這個問題...
遊戲服務端開發 二
應用伺服器的設計 上 應用伺服器的工作有 0 同步廣播玩家的行為 1作為第三方對玩家個體和玩家之間互動行為計算，並將計算結果推送到資料儲存系統 2驅動遊戲中的 npc 3作為乙個特殊的遊戲參與者，與玩家相互作用。應用伺服器最重要的工作莫過於同步廣播玩家之間的行為，使玩家之間能夠互視，多人同時遊戲才有...
遊戲服務端開發 隨想
最近公司上線了一款遊戲，後台服務端出現各種bug,我簡單的將出現的問題做了分類，多執行緒操作的資料一致性bug，邏輯bug,流程bug。雖然感覺這樣分並不能完全表述出現的bug型別，但我認為至少是這三類問題能概括了目前出現的bug.於是大家一起 了怎麼在上線環境來定位bug的問題所在。其實，我想更應...