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

以上兩種可根據(jù)屬性配置表格模塊根據(jù)怪物類型讀取到程序，程序根據(jù)類型判斷是否激活擴展AI

表格可如下：
NPC名字  類型 

紫怪  再高級點 定制AI，可在程序里預先定義一組高級AI，比如預先設想好的十種可能，打個比方，放A技能 放B技能 自動加血等等 ，而后也可在表格配置，比如預先表格設定好一種怪物最多可有4個定制AI

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

程序讀取到相應類型而激活相應模塊 或者此組AI 都用腳本預先寫好 也不錯 這樣比寫死在程序里好

BOSS  那就得完全特殊處理了不是，腳本發(fā)揮作用，完全腳本實現(xiàn)  程序事先一組接口，比如掉什么裝備接口，放技能的接口等等，LUA里面就狂寫吧，接口只要完善，寫成個WOW里的一樣也很OK

表格可如下：
NPC名字  類型  定制AI1 定制AI2 定制AI3 定制AI4  腳本AI

像2D游戲 下FB BOSS不夠智能的話 玩家就知道卡BOSS 幾個玩家把BOSS圍一圈，讓外面的遠程玩家打，格子上玩家又是不可重復的，BOSS就出不去 有仇恨系數(shù) 他又只想殺外面打他的玩家 導致就卡那里了，想打的玩家打不到 打的到的玩家又不想打。。。。。。。怎么辦呢，特殊AI處理，卡BOSS？系統(tǒng)判斷BOSS十秒不出手，就放大技能秒殺周圍的人。。。。
    
說到底，AI模塊就是最基本算法，程序定制，腳本定制，屬性表格配置再加腳本特殊化處理，基本就可達到需求了

二：擴展下前面說的數(shù)據(jù)庫模塊和日志模塊
        這里大家要注意，在這類數(shù)據(jù)庫 和IO操作上 盡量使用別的線程來開，不要和主線程搞到一起
 按目前流行的架構，一般都是在服務器上多開線程開啟網(wǎng)絡接口，另外在專門單開代理程序，消息發(fā)送到數(shù)據(jù)代理，讓代理來實現(xiàn)數(shù)據(jù)操作。
       日志模塊，本地調試么，就用文檔記錄，運營日志，單開個代理吧，這個操作挺頻繁的，和登錄保存角色的代理放一起影響性能 而且每什么意思，畢竟這個異步互相是不關聯(lián)的  稍微提醒下就是 你要是做 物品流向的時候 切記不要所有物品都記啊 不然就SB了，這個流向日志 要是都記錄的話 那一天都不知道是多少萬條記錄了 萬？十萬？百萬？
   可以 表格配置：
  物品名字  物品ID  是否記錄日志    //后面其他列是其他屬性
每次產生物品流向時候 比如買一個裝備到包里  交易一個裝備 等等
if(pItemProperty->bCanSaveLog)
{
//sendmessagetologdb
} 

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

按我的分類 我一般將代理分為 賬號代理  角色代理  游戲代理  日志代理  運維控制器代理

這里不一個個講了 放到后面說架構的時候再說每個代理需要做的事情
一個宗旨是 分的細 每一個得壓力就小  但是要保證不要出現(xiàn)數(shù)據(jù)互交叉

也見過某些項目 是沒有具體的數(shù)據(jù)操作代理的，直接是在服務器里直接操作，我個人認為啊，能新開進程 異步的 就開，沒必要給老板省錢，全部都壓一GAME上 扛不住啊，而且如果是分布式的話，你肯定得有一個統(tǒng)一的數(shù)據(jù)出口啊，不然的話。。我沒想過會怎樣，數(shù)據(jù)不統(tǒng)一？數(shù)據(jù)庫死鎖?

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


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

    我是力圖用最淺的語言來表現(xiàn)這些玩意是怎么會事情，高深的我也不懂了，扁我吧，。覺得沒啥意思的也留個言拍下磚頭啊，覺得有意思的留個言讓我高興下，主要是沒打草稿直接寫的就發(fā)了，遺漏 不清不楚肯定還是有的
    http://www.shnenglu.com/ziyebuboka/