用户5493735505294
第一，选择什么样的架构。
不同的游戏适用不同的架构。卡牌游戏架构、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，吞吐量）
第九，如何在不同项目间进行代码复用。
把共用的代码收归一个独立的组织来开发和维护，形成公共组件
小迷弟糖豆
手游页游和端游的服务端本质上没区别，区别的是游戏类型。
类型1：卡牌、跑酷等弱交互服务端
卡牌跑酷类因为交互弱，玩家和玩家之间不需要实时面对面PK，打一下对方的离线数据，计算下排行榜，买卖下道具即可，所以实现往往使用简单的 HTTP服务器：
登录时可以使用非对称加密（RSA, DH），服务器根据客户端uid，当前时间戳还有服务端私钥，计算哈希得到的加密 key 并发送给客户端。之后双方都用 HTTP通信，并用那个key进行RC4加密。客户端收到key和时间戳后保存在内存，用于之后通信，服务端不需要保存 key，因为每次都可以根据客户端传上来的 uid 和 时间戳 以及服务端自己的私钥计算得到。用模仿 TLS的行为，来保证多次 HTTP请求间的客户端身份，并通过时间戳保证同一人两次登录密钥不同。
每局开始时，访问一下，请求一下关卡数据，玩完了又提交一下，验算一下是否合法，获得什么奖励，数据库用单台 MySQL或者 MongoDB即可，后端的 Redis做缓存（可选）。如果要实现通知，那么让客户端定时15秒轮询一下服务器，如果有消息就取下来，如果没消息可以逐步放长轮询时间，比如30秒；如果有消息，就缩短轮询时间到10秒，5秒，即便两人聊天，延迟也能自适应。
此类服务器用来实现一款三国类策略或者卡牌及酷跑的游戏已经绰绰有余，这类游戏因为逻辑简单，玩家之间交互不强，使用 HTTP来开发的话，开发速度快，调试只需要一个浏览器就可以把逻辑调试清楚了。
类型2：第一代游戏服务器 1978
1978年，英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个MUD程序《MUD1》，在University of Essex于1980年接入 ARPANET之后加入了不少外部的玩家，甚至包括国外的玩家。《MUD1》程序的源代码在 ARPANET共享之后出现了众多的改编版本，至此MUD才在全世界广泛流行起来。不断完善的 MUD1的基础上产生了开源的 MudOS（1991），成为众多网游的鼻祖： 类型3：第二代游戏服务器 2003
2000年后，网游已经脱离最初的文字MUD，进入全面图形化年代。最先承受不住的其实是很多小文件，用户上下线，频繁的读取写入用户数据，导致负载越来越大。随着在线人数的增加和游戏数据的增加，服务器变得不抗重负。同时早期 EXT磁盘分区比较脆弱，稍微停电，容易发生大面积数据丢失。因此第一步就是拆分文件存储到数据库去。
MUDOS采用 C语言开发，因为玩家和玩家之间有比较强的交互（聊天，交易，PK），MUDOS使用单线程无阻塞套接字来服此时游戏服务端已经脱离陈旧的 MUDOS体系，各个公司在参考 MUDOS结构的情况下，开始自己用 C在重新开发自己的游戏服务端。并且脚本也抛弃了 LPC，采用扩展性更好的 Python或者 Lua来代替。由于主逻辑使用单线程模型，随着游戏内容的增加，传统单服务器的结构进一步成为瓶颈。
玥娱乐解说
一般在游戏界面会有切换线路的地方，也可以组队，点击都有信息，右键单击跟随分线
小猫老师888
哈哈哈，端游是使用键盘里的字母来切换路线的
