三年来的写的代码真的很多，有必要试着理清一下思路，找到不依赖公司的框架，能够带走的东西。

三年来主要的工作是完成手机游戏的功能需求。公司的游戏客户端是使用lua语言。服务器是使用c++。以下举例的游戏主要基于ARPG的，SLG的部分另外有一篇 http://www.cnblogs.com/yao2yaoblog/p/6723621.html。

客户端

1.mvc

有借鉴意义的一部分是客户端view的管理。分三层：view，ctrl，data。是一个mvc的思想。view是加载面板layout，展示游戏画面的。data是存储服务端下发的数据。ctrl是负责调度的。ctrl通常可以写成单例，作为全局可方便调用的。

我拿下图的一个业务来举例。福利大厅里面领取奖励。

1） 服务器下发数据之后，首先是用data来存放这些数据（可领取，不可领取）。通常会调用ctrl里面的函数来把数据传到data，类似这样

LevelRewardCtrl:Instance():SavaRewardData()

2）页面上要展示的内容，首先是由layout布局决定的，view加载这个layout。再取data里的数据对页面上的内容进行update。

local data = LevelRewardCtrl:Instance():GetRewardData()

mvc这种结构，很有借鉴意义，会使得逻辑清晰很多。

2.NGUI的DrawCall优化。

NGUI是Unity一个开源的制作UI的插件。DrawCall是NGUI里面的一个概念。

Unity准备好数据通知GPU绘制的过程叫DrawCall。至于准备哪些数据，没有深入过源码就不深究了。一次DrawCall会消耗大量GPU资源，所以通常制作UI时需要减少DrawCall的数量。

所有的UI组件都有个UIWidget的脚本。每个UIWidget的显示渲染顺序都是由其面板UIPanel的depth和自己的depth共同决定的。

1）面板深度加权重。假设有UIPanel：P1，P2，UIWidget：W1，W2。W1在P1里，W2在P2里，P1的depth大于P2的depth，那么无论W1，W2的depth哪个大，W1最后算出来的depth都比W2大。

2）尽量避免图集交叉。假设有图集A，B。UIWidget：WA1，WA2使用图集A。UIWidget：WB1，WB2使用图集B。深度从小到大如果是WA1，WA2，WB1，WB2。那么会是2个DrawCall。如果是WA1，WB1，WA2，WB2，那么会变成4个DrawCall。相邻的深度如果是同一个图集，通常会合并成一个DrawCall。

DrawCall合并算法：先把UIPanel中的Widget按depth从小到大排序，如果depth相同那按照material的ID来排序。然后遍历每个元素，把material相同的Widget归类到同一个drawCall。

3）动态元素和静态元素区分。也不能一味的合并DrawCall。游戏里有一些元素是长时间不动的，比如背景的一些元素。有一些元素是经常需要变动的。如果把大量静态元素和动态元素合并成了一个DrawCall，也会浪费开销。

4）改变Position代替SetActive。SetActive需要做大量工作，如果只是改变Position，开销会小很多。

5）文字置顶。UILabel，UIRichlabel的深度置顶。会使得关于文字的drawcall全部合并。

3.lua的闭包

http://www.cnblogs.com/yao2yaoblog/p/6413190.html

4.内存池。

在游戏里的物品格子使用了内存池的策略。物品格子在很多地方需要使用，而且里面的组件不少。sprite，texture，label组合都有。在经历了多个游戏，多个版本之后最终采用的是内存池的方法。

也就是说使用不需要业务手动创建，而是从内存池取得，销毁改为放回内存池。

服务端

c++是属于我的编程母语。不过确实是一门深不见底的语言，无论看多少资料，总会新的东西展现在眼前。三年的代码量只能保证业务需求变化不大的情况下，尽量精简，不要犯低级错误。用最稳妥的写法，不要秀语法，不要秀语法，不要秀语法。能上篮别扣。

因为服务器是c++的，所以空指针，数组越界的问题很容易就让服务器崩溃了。崩溃了需要重启，对游戏运营会造成损失，玩家会流失的。肯定要尽可能少重启。

服务器的所有进程如图：

1.个人系统。

指的是玩家自己的系统，只涉及客户端和GameWorld进程，加上数据库存储的操作。

可以拿坐骑进阶系统举例，简化而言，服务器有个数据ride_level。客户端根据服务器下发的这个ride_level，在场景上，UI上展示不同的模型。

ride_level是玩家登陆的时候，从数据库取上来，放到内存里，组织在userlogic类里面。userlogic类声明在Role类里。这样通过Role的实例就可以拿到这个ride_level。于是各个人系统之间都可以通过role实例互相取得数据。

比如坐骑系统的等级是根据翅膀系统的等级而变（瞎编的需求），可以这样在翅膀系统写代码（伪代码），翅膀升级的时候导致坐骑升级。

void Wing::Levelup()
{wing_level++;role->GetRide()->Levelup();
}void Ride::Levelup()
{ride_level++;
}

这些个人系统的数据会在玩家下线的时候存储到数据库，或者是服务器进程退出的时候存储到数据库，或者每隔一段时间存储到数据库。

至于数据库的存取使用的是json，存到mysql里的是一个json的字符串。

2.全服系统

比如帮派系统，比如结婚系统，比如全服的活动。数据区别与玩家自己的数据，在数据库中存在全服的数据表里，全服的功能在一个Global进程里。

Globa里通常会有全服的在线玩家list，每当一个玩家登录时，会从GW同步数据到Global，用一个简化的用户信息结构GlobalUser管理。

通常情况，如果需要得到其他玩家的数据，就必须经过Global得到。既是考虑多人的功能时，需要考虑Global和GW的通信问题。副本比较特殊，副本可以在GW管理多人信息。

举个例子。帮派神树的浇灌，大意是说整个帮派所有玩家共有一颗树，大家可以消耗自己的物品或者帮贡，来对树升级。

首先可能在客户端判断自己的帮贡是否足够，发消息到GW，判断自己的帮贡是否足够，发消息到Global对神树升级，在发消息回GW对自己的帮贡进行扣除。伪代码如下：

// client lua
function ProtocalArmy::ReqUpTree(need_data)
{Protocal.Begin(1000)//协议号Protocal.SetData("i", need_data)    //设置传输数据Protocal.Send(NetId)    //根据Ip地址发到服务端
}// GW c++
RoleArmy::ReqUpTree(need_data)
{if (m_data < need_data){// 帮贡不够return;}// 发消息到Global 带着数据或不带
    TreeUpReqStruct turs;turs.need_data = need_data;SendToGlbal(net_id, (const char*)&turs, sizeof(TreeUpReqStruct));
}// Global c++
ArmyManager::ReqUpTree(need_data)
{// 神树升级
    TreeUp();// 发消息回GW 带着数据或不带
    TreeUpReqSucBackStruct tursbs;tursbs.need_data = need_data;SendToGW(net_id, (const char*)&tursbs, sizeof(TreeUpReqSucBackStruct));
}// GW c++
RoleArmy::ReqUpTreeSucBack(need_data)
{// 减帮贡m_data -= need_data;// 发消息回客户端 给玩家反馈
}

整个流程大概如上，可见涉及Global的功能已经比只涉及GW难一些，因为涉及到GW和Global之间消息互发，如果思路不是很清晰，容易混乱。做功能之前需要弄清楚哪些数据在GW有，哪些数据在Globa有，数据会怎样改变。

在这个需求里面，为什么不直接从客户端发消息到Global呢，而要经过GW。是因为个人的帮贡信息是放在GW的，Global没有，先要在GW用帮贡数据做个判断。这个时候需要扣除的帮贡还不能直接扣除，需要等Global的神树数据改变后，再返回来改变帮贡。

其中有一个异常问题值得思考。假如Global数据变化之后，发消息会GW时，两个进程断开了，会怎样。岂不是会造成数据错乱。导致神树升级，但是帮贡没扣。

这样讲可能感受不深。借用数据库”事务“的概念来说。银行转账的例子，银行A转账到银行B，实际上是银行A减，银行B加，必须保证两者都完成，才算一次转账操作，否则要回滚。

刚才讲的例子是Global进程的神树数据和GW进程的帮贡数据也要同时改变，否则理论上应该回滚。但是我们的服务器好像没做这方面的考虑。因为GW和Global通常在一台服务器上，通信时间可以忽略不计。几乎不可能出现上述情况。

但是在我做过的另一个SLG服务器架构里面就有可能出这个问题。是一个悬而未决的问题。记录在这里，也许以后会得到答案。

3.跨服系统

跨服副本。

4.技能系统

技能系统是已有的基础模块了，不过我做过一个功能叫魔神系统。简而言之，是人物可以变身，变身之后人物的技能列表换掉，等变身时间到技能列表再还原回来。

这就涉及到技能模块和个人系统模块。个人系统模块可能是控制变身的条件，状态，cd等等。真正的大头在技能模块。

技能大致可以分为，被动和主动。

5.aoi模块

6.副本管理

副本管理全部在GW进程。副本其实就是涉及到场景管理。所有场景都是副本，有一个logic作为基类。如果是普通场景，没有什么特殊操作，那么用一个default子类即可。如果需要特殊操作则用子类，重载基类的方法来实现。

要创建一个场景，通常需要3个变量，scend_id，scene_key，logic_type。

bool CreateFb(int scene_id, int scene_key, int logic_type);

scene_id是由配置而来，scene_key用来唯一标志这个场景，logic_type代表这个副本的玩法。其中单人副本中，scene_key通常采用自增方法得到，而多人副本中，scene_key通常需要记录下来，以保证多人进入的是同一副本。

副本玩法比较重要的几个，需要重载的方法。心跳，人物进入，人物退出，人物死亡，人物被攻击等等。

virtual void Update(unsigned long interval, time_t now_second){}

首先心跳，重载这个函数，可以来控制副本的状态。interval是两次调用的间隔，now_second是现在的时间戳。例如如果副本有准备，开始，结束3个状态。可以在副本初始化的时候，算好这2个关键时间点m_begin_time，m_end_time。在update里分别与now作比较：

switch(m_status)
{case FB_READY:{if (now_second > m_begin_time){m_status = FB_BEGIN;}break;      }
    case FB_BEGIN:{if (now_second > m_end_time){m_status = FB_END;}break;      }
    case FB_END:{// destroyfb(); break;      }
} 

从而切换副本的状态。

人物的进出。副本通常会有一个玩家列表，来管理这个副本里玩家的信息。单人副本比较简单，多人副本需要根据需求在进出副本的时候写逻辑。比如玩家出了副本，在副本记录的信息需不需要清空。通常是会清空的。

清空和不清空的区别，在于一套对象管理的机制。场景里新创建一个人物，会有一个role对象产生，通常用一个obj_id标志这个对象。这个obj_id产生的策略，我理解为抢占式的。

如果A进入场景，那么obj_id = 1给A，B再进入，那么obj_id = 2给B，这时副本管理列表里obj_id = 1, 2分别是A，B玩家。这时A玩家推出了副本，C玩家进来了，这时obj_id = 1就给了C。同时列表里的信息覆盖掉A的信息。

如果需求是清空的，那就没任何问题。新进来的玩家覆盖旧玩家的信息。但是如果需求是清空的，那么A的第一次进入副本的信息怎么记录呢，比如他杀了个怪。这就需要另一个表了。

一个表是正在副本里的玩家信息m_on_fb_user_map，一个表是进来过副本又出去了的玩家信息m_out_fb_user_map。通常这个结构是写成一个std::map< UserId, UserInfo >的map。

通信相关

1.服务器进程间通信

2.服务端客户端通信。