手游项目总结

该手游是我从事游戏行业真正意义上接触的第一个项目，算起来在项目组待了也有1年半的时间，所以觉得很有必要把自己通过这个项目所获得的经验和心得记录一下。
该游戏是一款卡牌策略经营养成类游戏。该游戏的服务器分为loginserver、gateserver、gameserver、dbserver、socialserver、battleserver、routerserver、gmserver 、matchserver。

loginserver：php框架，登录服
gateserver:C++,网关服务器
dbserver：mysql，数据库
socialserver：C++，社交服务器
battleserver：C++，战斗服务器
routerserver：etcd服务，负责各服务器之间消息的转发
gmserver ：C++，游戏gm服务器，接收gm指令
matchserver：C++，匹配服务器
此外，游戏还使用了redis服务作为游戏业务数据的临时存储，lua开发相关活动。
我认为项目中值得学习的地方：
1.ProtoBuf的使用
该游戏的服务器与客户端的通信协议采用了protobuf协议。protobuf与平台无关，语言无关具有良好的拓展性，并且提供了友好的动态库，使用简单。Protobuf采用的非常巧妙的little-endian编码方法，序列化后所生成的二进制消息非常紧凑，与XML相比，其序列化之后的数据量约为1/3到1/10。相较于xml，protobuf只需要简单地将一个二进制序列，按照指定的格式读取到 C++ 对应的结构类型中就可以了，decoding反之，所以转换速度非常快。在项目中，用户某些并不是很重要的数据都是通过protobuf的二进制形式落地的。
2.业务代码模块化的方式
各个具体的模块分别用一个命名的.h和.cpp文件来表示便于代码的书写和各个具体功能得管理，降低了代码的耦合度。每一个模块都可以通过在其他模块中注册来调用其公有的方法。
3.某些功能通过接入已有的组件来实现
例如聊天、排行榜、排队、屏蔽字等功能都是通过接入技术中心的组件来实现，某些功能在其他项目中已经得到了充分的测试验证，减少了项目组重新开发组件的时间，同时在该项目的使用中，这些组件得到了进一步的拓展和完善，提高了这些组件的适用性。
4.多进程单线程的服务器设计模式
各个进程可以分布在不同的物理服务器上，可以做成分布式的服务器框架，例如可以将数据存储单独放到一个物理服务器上，供几个区的服务器使用。同时可以通过守护进程监控其它进程状态，例如有进程死掉，马上重启该进程，或者某个进程cpu使用率接近100%（基本可以判断是某个逻辑死循环了）, 强制kill掉该进程，然后重启。若单个服务器进程异常退出，只要不是网络通讯进程（一般这个都会比较稳定，没什么逻辑），那么就可以及时被守护进程重启，不会造成玩家掉线，只会造成在1-2秒内，某个逻辑功能无法使用，甚至玩家都感觉不到，并发性较高。
我认为项目中存在的不足：
1.数据落地方式的选择，实时存还是定时存？
一开始，该项目采用的是实施落地数据库的方式来存储玩家的数据，但是在之后压力测试的时候发现MySQL的性能存在瓶颈，无法支持大量玩家事实落地的压力，最后改成了定时存储的方式。
2.项目的配置表结构管理
配置表是游戏业务的一些关键数据都是从配置表生成的xml文件中读取的，一般来说，配置表的结构都是由程序来设计，策划负责更改数据的。由策划管理表的结构可能会增加了程序实现功能的难度，而频繁更改表结构可能会导致服务器无法成功编译，被这个坑过很多次。
3.业务功能测试流程不够规范
如果说一款游戏的研发团队直接反应了这款游戏的品质，那么游戏的测试就是决定游戏后续发展的最重要环节，包括灰度测试和机器人压力测试都是不可或缺的。
该项目某些业务功能没有进行系统的测试以及压力测试，导致很多bug没有及时得到发现和修复。某些功能在更改策划案之后，同样缺少及时系统的测试和验证，在线上暴露了很多问题，例如月卡发放，奖励邮件等功能。

项目感想：
1.IP很重要，拥有大IP能保证游戏的市场。
2.服务器尽量使用成熟的组件和库，避免踩坑，想用新的东西也可以但是一定要充分的测试，尽量避免出现问题。
3.策划案的制定之后需要和前端，后端以及美术讨论敲定，最好不要频繁变动。
4.几轮测试非常重要（内测，公测，正式上线），特别是内测阶段主要对游戏操作性调整的阶段，可以把握核心玩家以及泛用户的游戏需求来更改游戏的相关业务功能。
5.前端和后端决定了游戏的稳定性（服务器bug，客户端卡死），好的策划(制作人)很重要，不但系统和数值要设计好，玩家在玩游戏过程中的感受也要调整好。
6.工作流程要规范，不论是业务功能的实现和测试，还是游戏的打包和发布都要遵循流程。