不同的游戏，端游如何实现切换线路
第一，选择什么样的架构。
不同的游戏适用不同的架构。卡牌游戏架构、MMO游戏架构、MOBA游戏架构、FPS游戏架构
第二，选择单线程还是多线程。
操作系统的同步与异步，进程与线程。
第三，如何在游戏中使用脚本。
lua语言、lua与C、C++的交互
第四，如何处理网络通讯。
消息队列（zmq等）、epoll（libevent等）
两种处理方式：
一种是跟游戏服务器耦合带一起，游戏服务器既处理问落接入相关的逻辑，也处理游戏逻辑。
一种是把网络通信部分剥离住来，向游戏服务器提供一种以消息为单位的、非阻塞的、有Qos能力的中间服务，游戏服务器看不到网络的细节。
第五，如何处理游戏通信协议。
序列化（protobuf等，lua的pbc库）包头包体设计
第六，如何设计存储结构。
sql（mysql）、nosql（redis）、文件服务器（hdfs，fastdfs等）
从游戏来讲，所有的在线游戏通常使用数据库来存储用户数据。通常MMO使用关系型数据库来存储数据，后面主要针对MMO进行存储方式的讨论。会有两种方式：一种是把游戏的每一个数据对象的属性看成一个单独字段，遵循RDBMS的要求来设计数据库表和索引，尽量符合3NF。以MMO为例，有帐号表、角色基本信息表、物品表、装备表等等，这是一种方式。
还有一种方式更具体，角色的列表类数据尽量采用blob来存储而不是另一个表。原则是这些列表数据只被角色自身所拥有，就是这个玩家所拥有，其他玩家不会拥有个数据，它的生命周期跟玩家是一致的，不存在其他的交叉拥有情况，技能、物品、装备、任务、好友等等都属于这种情况。
优点是存储表结构简单，通常几张表就可以玩一个游戏，不超过10个。存取交互简单，角色登录或者推出时通常只需要存取一到二条记录。同一个角色的数据易于保持一致，易于多版本数据共存。我们把这些数据存到数据库的时候，会把编码存到数据库里面。所以在数据库里面做完的数据可能会不一样，不过不会影响，它会共存。
这种方式也会有缺点，数据维护工具、客服工具实现相对复杂，需要提供特殊的API来操作数据。如果手上工具是通用的，可能比以前要直白一点。某些类型的统计相对要麻烦一些，有些常用的数据，比如说角色的等级，在这方面可以用一些方式解决你的问题。
第七，如何设计网络同步。
网络同步面临的主要问题：第一如何减少网络波动对同步的影响；第二如何减少外挂对同步的破坏。
为了解决问题我们有一些基本方法：首先要探测玩家的网络质量；第二在玩家机器与服务器之间进行时钟同步；第三基于游戏特点，设计合理的同步机制。
第八，如何定义性能基准。
可以通过经验的方式，或者计算的方式来确确定理论上限。网络IO，可以分析，取悦于由游戏类型、游戏设计所形成的业务模型，可估算。内存，相对来讲更简单，取决于用到的主要数据结构，相对来讲更聚焦，更能估算出来支撑多少人。CPU计算能力，其实也不是计算，需要更多对CPU的支撑，简单的方式，这个游戏取决于游戏类型导致的逻辑复杂性。推过这三点，可以有一个目标，大概需要多少人。
（细节：数据结构与算法，整体：整个游戏的内存管理和网络IO，吞吐量）
第九，如何在不同项目间进行代码复用。
把共用的代码收归一个独立的组织来开发和维护，形成公共组件