老手拍磚，新手看，轉載注明
http://www.shnenglu.com/ziyebuboka/ 接著一繼續，其實寫本文從內行技術角度來看，本身就沒什么技術含量，但是俗話說的好，隔行隔山，內行看門道，外行那啥什么，反正就是想觸碰這玩意，但是又沒搞過的人看的。反正都是隨便亂寫了，愛看的看，準備寫個功能模塊大概 再寫個架構得大概，而后就去從網絡包開始搞個最簡單最輕量的小架構，力圖讓知道編程是啥的就能在上面搞東西
還是繼續談功能模塊。
一、還有個 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，點了就加一閱讀，沒意思啊，我不知道到底有沒有價值繼續啊，
我是力圖用最淺的語言來表現這些玩意是怎么會事情，高深的我也不懂了，扁我吧，。覺得沒啥意思的也留個言拍下磚頭啊，覺得有意思的留個言讓我高興下，主要是沒打草稿直接寫的就發了，遺漏 不清不楚肯定還是有的
http://www.shnenglu.com/ziyebuboka/