接着一继续，其实写本文从内行技术角度来看，本身就没什么技术含量，但是俗话说的好，隔行隔山，内行看门道，外行那啥什么，反正就是想触碰这玩意，但是又没搞过的人看的。反正都是随便乱写了，爱看的看，准备写个功能模块大概 再写个架构得大概，而后就去从网络包开始搞个最简单最轻量的小架构，力图让知道编程是啥的就能在上面搞东西
还是继续谈功能模块。
一、还有个 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，点了就加一阅读，没意思啊，我不知道到底有没有价值继续啊，
我是力图用最浅的语言来表现这些玩意是怎么会事情，高深的我也不懂了，扁我吧，。觉得没啥意思的也留个言拍下砖头啊，觉得有意思的留个言让我高兴下，主要是没打草稿直接写的就发了，遗漏 不清不楚肯定还是有的