淺談遊戲伺服器-》功能模組上來看（二）

接著一繼續，其實寫本文從內行技術角度來看，本身就沒什麼技術含量，但是俗話說的好，隔行隔山，內行看門道，外行那啥什麼，反正就是想觸碰這玩意，但是又沒搞過的人看的。反正都是隨便亂寫了，愛看的看，準備寫個功能模組大概 再寫個架構得大概，而後就去從網路包開始搞個最簡單最輕量的小架構，力圖讓知道編程是啥的就能在上面搞東西
還是繼續談功能模組。
一、還有個 AI模組，這個可不能忘啊
不過要注意，我這裡提到的AI模組和我一裡面所提到的幾個AI地方說指AI不是一會事情。
這裡的AI模組，哈哈，就是所謂的演算法了，演算法達人們NB的地方了。
針對NPC怪物等，比如最基本的尋路演算法。
此模組達到的效果是什麼呢，就是：怪物死了又活，怪物看見你知道追你，怪物知道打你 都知道尋路躲障礙
介紹下最基本的A*演算法吧 什麼A B C D E F D的
怪物要打你 得追你，但是他為啥知道跟你走呢，或者說你點擊一個地方，為啥就能自動走過去，能自動的繞開障礙呢。這個模組就是實現這些基本的東西。
2D的一般都是按格子計算，就說2D了，還有用像素玩的，3D玩座標的，等等 其實都是一會事情
角色身旁一共有8個格子，你點擊一個地方，就等於是指明了一個方向，角色就找到正對方向的身旁最近格子，判斷此格子是否有阻擋，如果無則走過去，如果有阻擋則搜尋身旁另一個格子，然後就是這麼一直遞迴，知道到達終點格子。
基本的自動尋路演算法就是上面這麼一段話，當然實際操作中，肯定不會用這麼費效率的演算法了，這裡就是簡單介紹下這個活在N-》B之前的N-》A*演算法。。NA啊。具體的大家可以去找本人工智慧的書看看
伺服器要算一下怪物走哪了就給周圍玩家同步下訊息，所以伺服器需要這玩意，這理由充分吧、、、
用戶端也需要，給玩家或者寵物自動尋路，內掛使用。
為什麼我說這裡的AI和我在一裡面說的不同呢，是因為這裡是實行基本的自動功能，而後你可以在這個模組的基礎上發展進階AI智能，結合指令碼，表格配置，活用技能。比如一個遊戲裡按檔次有白怪 藍怪 紫怪 BOSS
白怪麼就給他這一套最基本的會走路躲障礙會打人就可
藍怪 稍微進階點了，在基本模組上擴充，程式裡再實現血少到一定程度會逃跑 會喊同夥，

以上兩種可根據屬性配置表格模組根據怪物類型讀取到程式，程式根據類型判斷是否啟用擴充AI

表格可如下：
NPC名字 類型

紫怪 再進階點 定製AI，可在程式裡預先定義一組進階AI，比如預先設想好的十種可能，打個比方，放A技能 放B技能 自動加血等等 ，而後也可在表格配置，比如預先表格設定好一種怪物最多可有4個定製AI

表格可如下：
NPC名字 類型 定製AI1 定製AI2 定製AI3 定製AI4

程式讀取到相應類型而啟用相應模組 或者此組AI 都用指令碼預先寫好 也不錯 這樣比寫死在程式裡好

BOSS 那就得完全特殊處理了不是，指令碼發揮作用，完全指令碼實現 程式事先一組介面，比如掉什麼裝備介面，放技能的介面等等，LUA裡面就狂寫吧，介面只要完善，寫成個WOW裡的一樣也很OK

表格可如下：
NPC名字 類型 定製AI1 定製AI2 定製AI3 定製AI4 指令碼AI

像2D遊戲 下FB BOSS不夠智能的話 玩家就知道卡BOSS 幾個玩家把BOSS圍一圈，讓外面的遠程玩家打，格子上玩家又是不可重複的，BOSS就出不去 有仇恨係數 他又只想殺外面打他的玩家 導致就卡那裡了，想打的玩家打不到 打的到的玩家又不想打。。。。。。。怎麼辦呢，特殊AI處理，卡BOSS？系統判斷BOSS十秒不出手，就放大技能秒殺周圍的人。。。。

說到底，AI模組就是最基本演算法，程式定製，指令碼定製，屬性工作表格配置再加指令碼特殊化處理，基本就可達到需求了

二：擴充下前面說的資料庫模組和日誌模組
這裡大家要注意，在這類資料庫 和IO操作上 盡量使用別的線程來開，不要和主線程搞到一起
按目前流行的架構，一般都是在伺服器上多開線程開啟網路介面，另外在專門單開代理程式，訊息發送到資料代理，讓代理來實現資料操作。
日誌模組，本地調試麼，就用文檔記錄，運營日誌，單開個代理吧，這個操作挺頻繁的，和登入儲存角色的代理放一起影響效能 而且每什麼意思，畢竟這個非同步互相是不關聯的 稍微提醒下就是 你要是做 物品流向的時候 切記不要所有物品都記啊 不然就SB了，這個流向日誌 要是都記錄的話 那一天都不知道是多少萬條記錄了 萬？十萬？百萬？
可以 表格配置：
物品名字 物品ID 是否記錄日誌 //後面其他列是其他屬性
每次產生物品流向時候 比如買一個裝備到包裡 交易一個裝備 等等
if(pItemProperty->bCanSaveLog)
{
//sendmessagetologdb
}

這樣你就記錄些珍貴物品就可

按我的分類 我一般將代理分為 帳號代理 角色代理 遊戲代理 日誌代理 營運控制器代理

這裡不一個個講了 放到後面說架構的時候再說每個代理需要做的事情
一個宗旨是 分的細 每一個得壓力就小 但是要保證不要出現資料互交叉

也見過某些項目 是沒有具體的資料操作代理的，直接是在伺服器裡直接操作，我個人認為啊，能新開進程 非同步 就開，沒必要給老闆省錢，全部都壓一GAME上 扛不住啊，而且如果是分布式的話，你肯定得有一個統一的資料出口啊，不然的話。。我沒想過會怎樣，資料不統一？資料庫死結?

三：營運模組
營運分開就是運營和維護。。 因為他們是走的同一套架構，所以這裡就放一起來說
首先說明他們的產生原因：不可能每一次伺服器更新 或者再監控伺服器 維護過程 或者是提取某某檔案日誌 都是一個個遠程硬體伺服器吧 那樣的話 維護者工作效率就太低了
GM也不可能每一個伺服器都登陸進個用戶端開著吧。。所以這個模組就產生了，對維護者是要實現他們的遠程操作，對GM是要實現他們的線下操作。
工具功能：可監控 開啟 關閉伺服器 可主動推送更新檔案 更新指令碼
GM可線下操作基本命令，監控聊天，賠償物品，發送遊戲郵件等等。
開發人員可主動提取調試日誌記錄
算帳的可主動開後台查看運營日誌記錄計算ARPU值，查看線上記錄，等等等等
我現在是不推薦GM做線上操作的呢，就如同之前傳奇那樣的，都是在聊天框裡輸入GM命令，我個人認為內部操作還是走後門的好 不要和玩家一起從前門走了，注意的是這一塊在中心控制器代理這裡一定要做好監控，和操作記錄，驗證，來保證操作的安全性，防止違規操作。力圖將工具用戶端綁定到某一台機器，比如可在營運登陸工具時候 發送帳號 密碼 MACKEY IP 子網路遮罩 某一個CODE 等等在控制中心驗證 成功才可登入控制中心，工具用戶端才可操作、
這個模組主要注意的就是安全性，操作的方便，和日誌模組結合在一起，日誌記錄 分類 挖掘 良好

具體架構的後面再說
畢竟這個就是淺談，所以沒有什麼實際性的代碼內容，就是讓不瞭解的朋友能夠瞭解這是怎樣的一個架構一個工作流程
看了留言啊 ，這部落格，不同IP，點了就加一閱讀，沒意思啊，我不知道到底有沒有價值繼續啊，

我是力圖用最淺的語言來表現這些玩意是怎麼會事情，高深的我也不懂了，扁我吧，。覺得沒啥意思的也留個言拍下磚頭啊，覺得有意思的留個言讓我高興下，主要是沒打草稿直接寫的就發了，遺漏 不清不楚肯定還是有的