游戏服务器的设计主要分为两大块，一是整体框架结构的设计（比如容灾/容错、扩缩容等机制，要结合游戏类型进行相应设计），二是玩法模块的设计。
对于服务器来说，除了游戏具体业务逻辑外，主要是玩家的请求在各个进程间流转、校验与回复的过程。一般来说战斗玩法是游戏中最核心并且最复杂的玩法，主要分为外围系统、匹配机制、战斗机制三大部分。战斗机制是三者中最复杂的部分，主要有战斗接入、战斗结算、状态同步、断线重连、战斗验证、异常处理等功能。
- 外围系统
- 活动管理类
- 配置管理类
- 赛季管理类
- 英雄修改类（修改项叠加形式灵活组合）
- 模块管理类
- 战报管理类
- 统计数据类
-
匹配机制
要求匹配的设计具有足够的灵活性、可扩展性，支持多开、玩法隔离等机制。可以考虑发起匹配抽象成匹配方，不直接通过玩家或者队伍进行匹配，支持玩家和空缺队伍组合进行匹配，双方无感知，无入队/离队等操作。
比如发起方获得一个matchid，作为key，构建匹队友队列(mateQueue)（对应一个Group结构，包含member字段，搜集user，可以为team）
PVP时人数满，直接进入匹对手队列(matchQueue)，仍以matchid为key
GVG时可以支持匹一个缺人的队伍matchid1或者单个玩家matchid2，组合为一个Group（Group合并）
保存matchid到userid/teamid的映射
- 战斗框架
- Update检查接入，发送准备，超时强制进入
- Update帧同步，帧合并转发
- 上报、结算、断线重连、战斗验证
- 状态定义、状态检查、状态切换、状态同步、消息重发等（抽离到配置）
战斗完整功能逻辑主要有
-
游戏服赛季管理（赛季类、活动周期类）
-
游戏服玩家数据管理（初始化、加载/存储、结算等）
-
游戏服数据填充与状态判断（玩法数据、伙伴数据等）
-
匹配服匹配逻辑（匹配、队伍管理等）
-
战斗服战斗逻辑（接入、帧同步、断线重连、上报结算等）
-
战斗流程的状态同步机制（容灾容错、异常恢复等）
新增同类玩法一般不会改动战斗主体流程，主要是在选角、匹配、结算等过程做玩法区分。游戏服的玩法模块逻辑，一般大多数接口都是相同的，所以可以考虑设定一个接口类，各个玩法继承实现，也便于玩法隔离。
可以不用Mgr进行管理，直接挂在User身上，比如：
UserPvP->UserPvP_Rank，后续新增UserPvP_Match、UserPvP_Train、UserPvP_xxx等等
UserTvT->UserTvT_2v2，后续新增UserTvT_3v3、UserTvT_1v3、UserTvT_xxx等等
如果考虑大统一？PVP与GVG主要在于有没有队伍操作，考虑队伍通用话，PVP是每队1人，队伍不可见，多了一层队伍包裹；队伍可见性、数量等可以通过配置实现灵活调整。不过需要前期一次性打通队伍通用化、匹配通用化、战斗通用化等机制，前期开发框架的搭建就显得很重要。
UserGvG:
UserGvG_1v1_Rank
UserGVG_1v1_Match
UserGVG_1v1_Train
UserGVG_1v1_xxx
UserGvG_2v2
UserGvG_2v2_xxx
UserGvG_1v3
UserGvG_3v3
