游戏服务器与普通服务器有什么区别

首先，游戏服务器与普通服务器相比较来说，游戏服务器需要能够保存更多的用户的状态。用户的等级等属性不用说，一般的IM服务也会有，还有一些时刻变化的数据，比如某个玩家的生命值，发技能前后的法力值等等，这些值区别于一般的属性值如名字，ID这些，这些数据会经常性的变化，还会参与到逻辑的计算中，比如你一个多少等级的玩家吃了什么东西之后战力值变化为多少，打在一个多少属性的玩家身上会不会被他闪避，会不会产生暴击…诸如此类的信息，在游戏服务器中都会一一保存。
其次，游戏服务器中每一个用户都是独立存在的，每一个用户的数据、请求等都是独立的，用户彼此间的数据并没有任何交互。这也是游戏服务器与普通服务器之间最大的区别。至于客户端之间会有交互这一点，举最简单的例子，一个人在一个场景里面说了一句话，那么“同一个屏幕”的玩家也需要能够看到他说的这句话。此时游戏服务器就需要判断，多远的距离以内的玩家，会认定为是"同屏幕"的玩家，需要向这些玩家广播这个玩家说的这句话。
这个广播就比较麻烦了。首先，需要计算哪些玩家属于"同屏幕"，就是我们在第一点提到的玩家身上某些经常变化的属性需要做的运算，在这里需要根据玩家的坐标，找出来跟在同屏幕的玩家，用到的是AOI的概念。另外，找到了这些需要接收这个消息的玩家之后，将消息转发给它们又是一个IO密集的 *** 作，假如场景中有10个人，那么一句话就需要同时广播给另外9个人，假如有100人，1000人呢，数据量就更大了，而且时间的延迟也不能太长，这对于游戏服务器的性能就要求很高了。所以同样的一个硬件配置的服务器，可能跑Nginx可以同时处理上万的链接，但是对于一个游戏服务器就只有1，2千了，就是因为游戏服务器是一个CPU密集而且IO密集的服务器类型。而且不仅需要这样的游戏服务器不仅要求性能比较高，还需要服务器具有极高的稳定性，总不能隔一会就宕机了，那大家还怎么玩。
此外，游戏服务器需要更好的数据承载能力和处理能力。而普通服务器则在各个方面都比较均衡。在寻找游戏服务器租用商的时候，一定要选择那种CPU性能非常出色的。
最后一点，游戏行业一直以来是网络攻击的重灾区，很多游戏刚上线没多久就频繁遭到攻击，导致玩家大量流失口碑下降，最后可能导致直接关服。所以游戏服务器一定要带高防流量包。

逻辑实现者：工作是实现从游戏主循环到每个游戏元素的逻辑。在小团队里一般是唯一的一名程序员，在大团队里是GPP(Game play Programmer)。注意如果是独立游戏项目的话，借助第三方插件，非程序员也可以担任这个角色。
内容设计者(读作cehua)：在大团队里基本上就是策划职位，和传统策划的区别是因为Unity团队里负责这个任务的人基本上是一定要摆弄场景、制作prefab的，没有点动手能力光会写文档可不行。
美术：工作包括从游戏概念图的设计到模型动画等美术资源的设计制作。具体细分可以参考游戏工业标准，Unity团队也不例外。
交互设计和实现：界面设计、界面实现编程，由于Unity下有很多不错的UI插件，所以这份包括设计师和程序员的工作我给合并到了一起。在Unity下就算是由设计师自己来做交互实现编程也不会很难。
主程序/架构设计师：适用于大项目或大团队的高端职业，他们的主要任务不是生产用户能玩到的具体游戏性，而是为其他团队成员搭建一个可以沟通协作的框架或
工具集。对大型Unity项目来说，如果团队里没有这么一个经验丰富思路清晰的高手，很快项目就会被各种突飞猛进(因为Unity开发新功能原型实在太快
了，很容易让人忽略结构问题)的feature生产搞的累赘不堪，然后在没有人指导项目重构的情况下，生产效率从每周一个feature下降到每个月一个
feature，还伴随无数难以修复的bug。
服务器程序员：网游项目必备，其描述适用于游戏工业标准，这里不赘述。
版本管理员：适用于大项目，最好精通Git或plasticscm这类分布式版本控制系统，好处是方便做branching而且可以拆分项目为多个子项目，Unity项目大了以后运行效率是很差的，拆分项目也有利于控制不同分工的团队成员的权限。
音效设计师：可选，推荐还是外包音效+内部实现的做法，因为Unity并没有一个完全封装好的音效中间件，如果音效设计师要进行实际调试，就要完全掌握
Unity组件系统，在国内来说这个要求还是比较高的。怕麻烦的话拿到外包的文件然后让程序员或策划去导入和测试就好了。

案例1：寝室斗地主

案例2：社区斗地主

什么是服务器架构

案例：MMORPG 轩辕传奇 服务器架构 分区多世界

MMORPG：大型 多人 在线 角色扮演

分区多世界：运营视角

分区多世界：运维视角

双通服：世界上最遥远的距离，是从电信到网通的距离。

分区多世界：客户端视角

分区多世界：服务器视角

轩辕服务器为什么要这么多进程和机器 - 多维度切分

初始设计

一个进程包揽所有游戏服务器功能

问题：开第2个服应该怎么做呢？

按世界分离

公共服分离

公共服热备

按功能分离

按重要性分离

百万注册 = 10W活跃 = 1W在线，缓存应重点放在活跃身上。

设计演进：分区多世界原型v2

继续分离公共服

分离逻辑部分弱相关的功能，公共服分离服务器列表、版本升级、账号信息等功能。

切分逻辑进程

当前的现状是所有鸡蛋都放在一个篮子里，所有玩家都在一个进程上，好处是一个特性可以方便地 *** 作到所有玩家上，风险是一个特性的bug可能会影响到所有玩家。

所有特性都在一个进程所带来的风险是：特性的不断的引入会使该进程稳定性和服务质量降低。

设计演进：分区多世界原型v3

如何做切分，参考原则如下：

服务器为长线运营的准备

基本原则：可用、可控、可扩展性

接入与负载

可用性

在线控制

过载保护

服务器中服务介绍

版本升级 tcus

目录服务 tdir

显示服务器列表，繁忙程度（参照在线人数）。

游戏过程 world/scene

运营支持 GM平台/idip

---