Firefly游戏服务器学习笔记 9 ———— game1模块
game1 囊括了几乎所有游戏逻辑，内容很多。但是多也只是app内容多， 前面的firefly框架启动流程没有什么差别。
如果看官是一直看下来的，扫一眼代码就一目了然，这里不提。直接跳到app部分。
def loadModule():
"""
"""
load_config_data() #加载数据
registe_madmin() #注册几个表到memcache
from gatenodeapp import * #实际上是注册各种services的命令
逻辑上game/app启动逻辑分3个部分。
Load_config_data()；里面东西虽然多，但是并不复杂，如下：
def getExperience_Config():
"""获取经验配置表信息"""
global tb_Experience_config
sql = "select * fromtb_experience"
result = dbpool.fetchAll(sql) ########我改过了
for _item in result:
tb_Experience_config[_item['level']] =_item
只是取一些游戏中常用的数据表的内容，然后直接保存在game1的内存数据中，不是memcache，因为这是常驻内存，而不是缓存起来的。
其中 result = dbpool.fetchAll(sql) 是我改动了一下，只是把原先copy paste的代码风格整理一下。10几个地方全部是同样复制的代码看起来非常不舒服。
不过这里不但是体力活，而且是细致活，分3中fetch，具体看我改动后的github代码，没有啥技术含量就不提了。
然后是用MAdminManager，来注册管理几个表，这个和前面db章节提到的一模一样。需要注意的是，下面的代码：
def registe_madmin():
"""注册数据库与memcached对应
"""
MAdminManager().registe(memmode.tb_character_admin)
MAdminManager().registe(memmode.tb_zhanyi_record_admin)
MAdminManager().registe(memmode.tbitemadmin)
MAdminManager().registe(memmode.tb_matrix_amin)
看上去做的只是注册到MAdminManager，并没有初始化。但是其实在文件开头有一个
import memmode
而memmode.py里面是直接裸写的全局变量。所以实际上在这个python文件开头就已经初始化了。
建议把import memmode放到registe_madmin（）函数开头部分。这样逻辑上清晰一些。
或者干脆吧memmode里面的内容全部封装到一个init函数里面更好。
大家明白就好，我懒得改了。
下面看第三行
fromgatenodeapp import *
这个就是利用import+修饰符方式，添加一批services的命令处理函数。跟进去看：
remoteservice = CommandService("gateremote")
GlobalObject().remote["gate"].setServiceChannel(remoteservice)
def remoteserviceHandle(target):
"""
"""
remoteservice.mapTarget(target)
可以看出，实际上是给连接gate模块的leafNode的services添加的。这样gate转发过来的命令，都会被这些函数解析，处理。然后把结果返回给gate，再返回给net，最终到client端。
前面net章节已经分析了用户登录时，net到gate的数据流。这里唯一不同的是gate的消息处理不再是由localservices处理，而是有gate的root转发出去。（下面是gate模块中对应的代码）
node =VCharacterManager().getNodeByClientId(dynamicId)
returnGlobalObject().root.callChild(node, key, dynamicId, data)
我们可以看出，firefly中是由gate模块来维护一个虚拟角色管理类，并由这个管理类来管理一批登陆的虚拟角色。
这些VirtualCharacter中会记录用户的虚拟角色到底是在那个game模块上；虽然我们这里只有game1一个游戏内容处理模块（游戏逻辑服务器），但是可以看出firefly的逻辑是支持多个game模块的。
同时也确定了，这些分发管理是由gate模块（或者叫gate服务器）来负责的。
这里的命令虽然很多，但是相互之间比较独立，同事也和firefly的系统架构关联性不大，独立理解起来很方便。我们就不在一一介绍了。
这个部分其实是和系统策划，游戏逻辑密切相关的，所以，如果有空，我们在后面反推暗黑的游戏逻辑的时候，结合cocos2dx客户端再详细说明上面提到的所有的services处理函数的各个功能，以此来展现一个完整的暗黑游戏框架。而不是这里讨论的firefly服务器框架。
OK，OK
这个系列基本告一段落，大概花费我3天时间码字，如果有什么疏忽的地方，冒犯的地方，或者错误的地方，还请各位看官，9miao的朋友多担待。
也请大家积极反馈，批评指点，帮助我改正错误。
最后再次感谢9miao的开源精神，毫无疑问，firefly和暗黑的代码给我提供了极大的帮助！