NpcServer，Npc服務器，負責Npc的AI處理。
把關於Npc的AI單獨拿出來處理，主要是基於效率的考慮，並且如果npcserver宕機，馬上重啓，並不導致其它服務器宕機。把npc的處理從場景中拿出來，場景上的開銷主要就是和NpcServer的數據交互了，NpcServer和場景服務器上，不管是哪個服務器上的npc數據變化，都要同步到另一個服務器上。在npc處理中，npc的尋路是最耗時的，在之前自己的帖子裏也講述了A*尋路失敗的耗時，所以很有必要把這個拿出來，當時在公司的服務器上測的，4核3.33GHZ，8G內存，A*耗時太大，並且策劃想讓npc能走很遠的路，還加入了區域尋路（navigation mesh）的方法。總之呢，就是策劃不能配置很多npc同時尋路的活動。比如怪物衝城，一次招幾百個npc，並且距離很遠。尋路就說這麼多，在npc處理的時候，還有很多處理，着重說AI了。
每個具有AI的npc攜帶一個狀態機，根據它的AI配置去執行自己的動作，比如有一個AI：
<aimove_random>
<event= enemy_close switch = attack>
<aiattack>
<event= enemy_lose switch = move_random>
意思就是，npc在範圍走動時，有敵人靠近，它就去攻擊，敵人走了，又在這個範圍隨機移動。在我們的遊戲中當然不可能只有這麼一些AI，已經AI事件。
Npc進入遊戲後，會有一張自己的AI表，表裏面規定了這個NPC的所有動作，npc出來後會有一個初始狀態，比如這裏是隨機移動，然後npc每一幀去檢查一下，看有沒有敵人靠近，如果有敵人靠近的話，把這個敵人加入自己的仇恨列表，發送一個敵人靠近的事件，接着轉入攻擊狀態，接下來準備攻擊了，如果攻擊過程中，發現敵人lose了，又會向狀態機發送一個敵人lose事件，這時就轉入了隨機移動狀態，雖然轉入了移動狀態，但是在進行移動前，會去做一次事件收集，在這一幀去掃描一下週圍，看有沒有其他的敵人，如果有，又轉入攻擊狀態，然後執行攻擊，如果沒有敵人，則進入移動。
與lua交互，把與npc有關的操作全部暴露給策劃，讓策劃自己去配置，讓策劃自己去配置Ai相關的操作。
在功能設計的早期，自己多在擴展性上考慮，這樣在後期，只要去做配置就行，不管多複雜，自己都不用去操心，只需要去配合策劃去做事情就可以了。
