老手拍磚，新手看，轉(zhuǎn)載注明
http://m.shnenglu.com/ziyebuboka/ 接著一繼續(xù)，其實寫本文從內(nèi)行技術(shù)角度來看，本身就沒什么技術(shù)含量，但是俗話說的好，隔行隔山，內(nèi)行看門道，外行那啥什么，反正就是想觸碰這玩意，但是又沒搞過的人看的。反正都是隨便亂寫了，愛看的看，準備寫個功能模塊大概 再寫個架構(gòu)得大概，而后就去從網(wǎng)絡(luò)包開始搞個最簡單最輕量的小架構(gòu)，力圖讓知道編程是啥的就能在上面搞東西
還是繼續(xù)談功能模塊。
一、還有個 AI模塊，這個可不能忘啊
不過要注意，我這里提到的AI模塊和我一里面所提到的幾個AI地方說指AI不是一會事情。
這里的AI模塊，哈哈，就是所謂的算法了，算法達人們NB的地方了。
針對NPC怪物等，比如最基本的尋路算法。
此模塊達到的效果是什么呢，就是：怪物死了又活，怪物看見你知道追你，怪物知道打你 都知道尋路躲障礙
介紹下最基本的A*算法吧 什么A B C D E F D的
怪物要打你 得追你，但是他為啥知道跟你走呢，或者說你點擊一個地方，為啥就能自動走過去，能自動的繞開障礙呢。這個模塊就是實現(xiàn)這些基本的東西。
2D的一般都是按格子計算，就說2D了，還有用像素玩的，3D玩坐標的，等等 其實都是一會事情
角色身旁一共有8個格子，你點擊一個地方，就等于是指明了一個方向，角色就找到正對方向的身旁最近格子，判斷此格子是否有阻擋，如果無則走過去，如果有阻擋則搜索身旁另一個格子，然后就是這么一直遞歸，知道到達終點格子。
基本的自動尋路算法就是上面這么一段話，當(dāng)然實際操作中，肯定不會用這么費效率的算法了，這里就是簡單介紹下這個活在N-》B之前的N-》A*算法。。NA啊。具體的大家可以去找本人工智能的書看看
服務(wù)器要算一下怪物走哪了就給周圍玩家同步下消息，所以服務(wù)器需要這玩意，這理由充分吧、、、
客戶端也需要，給玩家或者寵物自動尋路，內(nèi)掛使用。
為什么我說這里的AI和我在一里面說的不同呢，是因為這里是實行基本的自動功能，而后你可以在這個模塊的基礎(chǔ)上發(fā)展高級AI智能，結(jié)合腳本，表格配置，活用技能。比如一個游戲里按檔次有白怪 藍怪 紫怪 BOSS
白怪么就給他這一套最基本的會走路躲障礙會打人就可
藍怪 稍微高級點了，在基本模塊上擴展，程序里再實現(xiàn)血少到一定程度會逃跑 會喊同伙，
以上兩種可根據(jù)屬性配置表格模塊根據(jù)怪物類型讀取到程序，程序根據(jù)類型判斷是否激活擴展AI
表格可如下：
NPC名字 類型
紫怪 再高級點 定制AI，可在程序里預(yù)先定義一組高級AI，比如預(yù)先設(shè)想好的十種可能，打個比方，放A技能 放B技能 自動加血等等 ，而后也可在表格配置，比如預(yù)先表格設(shè)定好一種怪物最多可有4個定制AI
表格可如下：
NPC名字 類型 定制AI1 定制AI2 定制AI3 定制AI4
程序讀取到相應(yīng)類型而激活相應(yīng)模塊 或者此組AI 都用腳本預(yù)先寫好 也不錯 這樣比寫死在程序里好
BOSS 那就得完全特殊處理了不是，腳本發(fā)揮作用，完全腳本實現(xiàn) 程序事先一組接口，比如掉什么裝備接口，放技能的接口等等，LUA里面就狂寫吧，接口只要完善，寫成個WOW里的一樣也很OK
表格可如下：
NPC名字 類型 定制AI1 定制AI2 定制AI3 定制AI4 腳本AI
像2D游戲 下FB BOSS不夠智能的話 玩家就知道卡BOSS 幾個玩家把BOSS圍一圈，讓外面的遠程玩家打，格子上玩家又是不可重復(fù)的，BOSS就出不去 有仇恨系數(shù) 他又只想殺外面打他的玩家 導(dǎo)致就卡那里了，想打的玩家打不到 打的到的玩家又不想打。。。。。。。怎么辦呢，特殊AI處理，卡BOSS？系統(tǒng)判斷BOSS十秒不出手，就放大技能秒殺周圍的人。。。。
說到底，AI模塊就是最基本算法，程序定制，腳本定制，屬性表格配置再加腳本特殊化處理，基本就可達到需求了
二：擴展下前面說的數(shù)據(jù)庫模塊和日志模塊
這里大家要注意，在這類數(shù)據(jù)庫 和IO操作上 盡量使用別的線程來開，不要和主線程搞到一起
按目前流行的架構(gòu)，一般都是在服務(wù)器上多開線程開啟網(wǎng)絡(luò)接口，另外在專門單開代理程序，消息發(fā)送到數(shù)據(jù)代理，讓代理來實現(xiàn)數(shù)據(jù)操作。
日志模塊，本地調(diào)試么，就用文檔記錄，運營日志，單開個代理吧，這個操作挺頻繁的，和登錄保存角色的代理放一起影響性能 而且每什么意思，畢竟這個異步互相是不關(guān)聯(lián)的 稍微提醒下就是 你要是做 物品流向的時候 切記不要所有物品都記啊 不然就SB了，這個流向日志 要是都記錄的話 那一天都不知道是多少萬條記錄了 萬？十萬？百萬？
可以 表格配置：
物品名字 物品ID 是否記錄日志 //后面其他列是其他屬性
每次產(chǎn)生物品流向時候 比如買一個裝備到包里 交易一個裝備 等等
if(pItemProperty->bCanSaveLog)
{
//sendmessagetologdb
}
這樣你就記錄些珍貴物品就可
按我的分類 我一般將代理分為 賬號代理 角色代理 游戲代理 日志代理 運維控制器代理
這里不一個個講了 放到后面說架構(gòu)的時候再說每個代理需要做的事情
一個宗旨是 分的細 每一個得壓力就小 但是要保證不要出現(xiàn)數(shù)據(jù)互交叉
也見過某些項目 是沒有具體的數(shù)據(jù)操作代理的，直接是在服務(wù)器里直接操作，我個人認為啊，能新開進程 異步的 就開，沒必要給老板省錢，全部都壓一GAME上 扛不住啊，而且如果是分布式的話，你肯定得有一個統(tǒng)一的數(shù)據(jù)出口啊，不然的話。。我沒想過會怎樣，數(shù)據(jù)不統(tǒng)一？數(shù)據(jù)庫死鎖?
三：運維模塊
運維分開就是運營和維護。。 因為他們是走的同一套架構(gòu)，所以這里就放一起來說
首先說明他們的產(chǎn)生原因：不可能每一次服務(wù)器更新 或者再監(jiān)控服務(wù)器 維護過程 或者是提取某某文件日志 都是一個個遠程硬件服務(wù)器吧 那樣的話 維護者工作效率就太低了
GM也不可能每一個服務(wù)器都登陸進個客戶端開著吧。。所以這個模塊就產(chǎn)生了，對維護者是要實現(xiàn)他們的遠程操作，對GM是要實現(xiàn)他們的線下操作。
工具功能：可監(jiān)控 開啟 關(guān)閉服務(wù)器 可主動推送更新文件 更新腳本
GM可線下操作基本命令，監(jiān)控聊天，賠償物品，發(fā)送游戲郵件等等。
開發(fā)者可主動提取調(diào)試日志記錄
算帳的可主動開后臺查看運營日志記錄計算ARPU值，查看在線記錄，等等等等
我現(xiàn)在是不推薦GM做線上操作的呢，就如同之前傳奇那樣的，都是在聊天框里輸入GM命令，我個人認為內(nèi)部操作還是走后門的好 不要和玩家一起從前門走了，注意的是這一塊在中心控制器代理這里一定要做好監(jiān)控，和操作記錄，驗證，來保證操作的安全性，防止違規(guī)操作。力圖將工具客戶端綁定到某一臺機器，比如可在運維登陸工具時候 發(fā)送賬號 密碼 MACKEY IP 子網(wǎng)掩碼 某一個CODE 等等在控制中心驗證 成功才可登入控制中心，工具客戶端才可操作、
這個模塊主要注意的就是安全性，操作的方便，和日志模塊結(jié)合在一起，日志記錄 分類 挖掘 良好
具體架構(gòu)的后面再說
畢竟這個就是淺談，所以沒有什么實際性的代碼內(nèi)容，就是讓不了解的朋友能夠了解這是怎樣的一個架構(gòu)一個工作流程
看了留言啊 ，這博客，不同IP，點了就加一閱讀，沒意思啊，我不知道到底有沒有價值繼續(xù)啊，
我是力圖用最淺的語言來表現(xiàn)這些玩意是怎么會事情，高深的我也不懂了，扁我吧，。覺得沒啥意思的也留個言拍下磚頭啊，覺得有意思的留個言讓我高興下，主要是沒打草稿直接寫的就發(fā)了，遺漏 不清不楚肯定還是有的
http://m.shnenglu.com/ziyebuboka/