如何用JAVA开发游戏服务器？

首先，我得说明的是，目前市场上新人很难去做pc游戏开发，要么是做页游要么是手游。

页游不清楚我就不说了，手游里面，客户端主要就是c2d和u3d。

如果你想做客户端，那么你可以转学u3d，因为它使用的语言是csharp，这个语言和java相似。网上unity的教程也很多，你随便找一下就有了。

再说说手游服务器，其实我入行服务器还是挺巧合的，当初本来是打算做客户端的，都入职了，因为招不到服务器，就让我转服务器了。。

服务器的教程，我至今也没找到，而且也找不到系统的教程。

开源的服务器框架也只熟悉kbengine和scut。其中一个是cpp做底层python做开发的，一个是csharp做开发。而且scut已经两年没有更新了，应该是死掉了。

所以，想要学服务器开发，得碰点运气。

java服务器目前主流框架技术有网络层netty或mina，数据协议protobuf，数据库mysql，缓存数据库redis，jdbc一般是mybaits或者jpa，项目管理maven，设计层面spring

然后还需要熟悉多线程，linux的基本操作，git或者svn。

差不多了，这些都有个大致的了解，会用，应该就能找到工作了。

后面再深入需要学习的也挺多的，到时候你再根据业务需求自己琢磨着学吧。

为什么golang的开发效率高？

golang是一编译型的强类型语言，它在开发上的高效率主要来自于后发优势，不用考虑旧有恶心的历史，又有一个较高的工程视角。良好的避免了程序员因为“ { 需不需要独占一行 ”这种革命问题打架，也解决了一部分趁编译时间找产品妹妹搭讪的阶级敌人。

它有自己的包管理机制，工具链成熟，从开发、调试到发布都很简单方便；

有反向接口、defer、coroutine等大量的syntactic sugar；

编译速度快，因为是强类型语言又有gc，只要通过编译，非业务毛病就很少了；

它在语法级别上支持了goroutine，这是大家说到最多的内容，这里重点提一下。首先，coroutine并不稀罕，语言并不能超越硬件、操作系统实现神乎其神的功能。golang可以做到事情，其他语言也可以做到，譬如c++，在boost库里面自己就有的coroutine实现（当然用起来跟其他boost库一样恶心）。golang做的事情，是把这一套东西的使用过程简化了，并且提供了一套channel的通信模式，使得程序员可以忽略诸如死锁等问题。

goroutine的目的是描述并发编程模型。并发与并行不同，它并不需要多核的硬件支持，它不是一种物理运行状态，而是一种程序逻辑流程。它的主要目的不是利用多核提高运行效率，而是提供一种更容易理解、不容易出错的语言来描述问题。

实际上golang默认就是运行在单OS进程上面的，通过指定环境变量GOMAXPROCS才能转身跑在多OS进程上面。有人提到了的pomelo，开源本来是一件很不错的事情，但是基于自己对callback hell的偏见，我一直持有这种态度：敢用nodejs写大规模游戏服务器的人，都是真正的勇士 : ) 。

2、Erlang与Golang的coroutine有啥区别，coroutine是啥？

coroutine本质上是语言开发者自己实现的、处于user space内的线程，无论是erlang、还是golang都是这样。需要解决没有时钟中断；碰着阻塞式i\o，整个进程都会被操作系统主动挂起；需要自己拥有调度控制能力（放在并行环境下面还是挺麻烦的一件事）等等问题。那为啥要废老大的劲自己做一套线程放user space里面呢？

并发是服务器语言必须要解决的问题；

system space的进程还有线程调度都太慢了、占用的空间也太大了。

把线程放到user space的可以避免了陷入system call进行上下文切换以及高速缓冲更新，线程本身以及切换等操作可以做得非常的轻量。这也就是golang这类语言反复提及的超高并发能力，分分钟给你开上几千个线程不费力。

不同的是，golang的并发调度在i/o等易发阻塞的时候才会发生，一般是内封在库函数内；erlang则更夸张，对每个coroutine维持一个计数器，常用语句都会导致这个计数器进行reduction，一旦到点，立即切换调度函数。

中断介入程度的不同，导致erlang看上去拥有了preemptive scheduling的能力，而golang则是cooperative shceduling的。golang一旦写出纯计算死循环，进程内所有会话必死无疑；要有大计算量少i\o的函数还得自己主动叫runtimeSched()来进行调度切换。

3、golang的运行效率怎么样？

我是相当反感所谓的ping\pong式benchmark，运行效率需要放到具体的工作环境下面考虑。

首先，它再快也是快不过c的，毕竟底下做了那么多工作，又有调度，又有gc什么的。那为什么在那些benchmark里面，golang、nodejs、erlang的响应效率看上去那么优秀呢，响应快，并发强？并发能力强的原因上面已经提到了，响应快是因为大量非阻塞式i\o操作出现的原因。这一点c也可以做到，并且能力更强，但是得多写不少优质代码。

然后，针对游戏服务器这种高实时性的运行环境，GC所造成的跳帧问题确实比较麻烦，前面的大神 @达达 有比较详细的论述和缓解方案，就不累述了 。随着golang的持续开发，相信应该会有非常大的改进。一是屏蔽内存操作是现代语言的大势所趋，它肯定是需要被实现的；二是GC算法已经相当的成熟，效率勉勉强强过得去；三是可以通过incremental的操作来均摊cpu消耗。

用这一点点效率损失换取一个更高的生产能力是不是值得呢？我觉得是值得的，硬件已经很便宜了，人生苦短，让自己的生活更轻松一点吧: )。

4、基于以上的论述，我认为采用go进行小范围的MMORPG开发是可行的。

端游、手游服务端常用的架构是什么样的？

类型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），成为众多网游的鼻祖：

MUDOS采用 C语言开发，因为玩家和玩家之间有比较强的交互（聊天，交易，PK），MUDOS使用单线程无阻塞套接字来服务所有玩家，所有玩家的请求都发到同一个线程去处理，主线程每隔1秒钟更新一次所有对象（网络收发，更新对象状态机，处理超时，刷新地图，刷新NPC）。

游戏世界采用房间的形式组织起来，每个房间有东南西北四个方向可以移动到下一个房间，由于欧美最早的网游都是地牢迷宫形式的，因此场景的基本单位被成为 “房间”。MUDOS使用一门称为LPC的脚本语言来描述整个世界（包括房间拓扑，配置，NPC，以及各种剧情）。游戏里面的高级玩家（巫师），可以不断的通过修改脚本来为游戏添加房间以及增加剧情。早年 MUD1上线时只有17个房间，Roy Trubshaw毕业以后交给他的师弟 Richard Battle，在 Richard Battle手上，不断的添加各种玩法到一百多个房间，终于让 MUD发扬光大。

用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上，使用纯文字进行游戏，每条指令用回车进行分割。比如 1995年国内第一款 MUD游戏《侠客行》，你敲入：”go east”，游戏就会提示你：“后花园 - 这里是归云庄的后花园，种满了花草，几个庄丁正在浇花。此地乃是含羞草生长之地。这里唯一的出口是 north。这里有：花待 阿牧（A mu），还有二位庄丁（Zhuang Ding）”，然后你继续用文字操作，查看阿牧的信息：“look a mu”，系统提示：“花待 阿牧（A mu）他是陆乘风的弟子，受命在此看管含羞草。他看起来三十多岁，生得眉清目秀，端正大方，一表人才。他的武艺看上去不是很高，出手似乎极轻”。然后你可以选择击败他获得含羞草，但是你吃了含羞草却又可能会中毒死亡。在早期网上资源贫乏的时候，这样的游戏有很强的代入感。

用户数据保存在文件中，每个用户登录时，从文本文件里把用户的数据全部加载进来，操作全部在内存里面进行，无需马上刷回磁盘。用户退出了，或者每隔5分钟检查到数据改动了，都会保存会磁盘。这样的系统在当时每台服务器承载个4000人同时游戏，不是特别大的问题。从1991年的 MUDOS发布后，全球各地都在为他改进，扩充，退出新版本，随着 Windows图形机能的增强。1997游戏《UO》在 MUDOS的基础上为角色增加的x,y坐标，为每个房间增加了地图，并且为每个角色增加了动画，形成了第一代的图形网络游戏。

因为游戏内容基本可以通过 LPC脚本进行定制，所以MUDOS也成为名副其实的第一款服务端引擎，引擎一次性开发出来，然后制作不同游戏内容。后续国内的《万王之王》等游戏，很多都是跟《UO》一样，直接在 MUDOS上进行二次开发，加入房间的地图还有角色的坐标等要素，该架构一直为国内的第一代 MMORPG提供了稳固的支持，直到 2003年，还有游戏基于 MUDOS开发。虽然后面图形化增加了很多东西，但是这些MMORPG后端的本质还是 MUDOS。随着游戏内容的越来越复杂，架构变得越来越吃不消了，各种负载问题慢慢浮上水面，于是有了我们的第二代游戏服务器。

类型3：第二代游戏服务器 2003

2000年后，网游已经脱离最初的文字MUD，进入全面图形化年代。最先承受不住的其实是很多小文件，用户上下线，频繁的读取写入用户数据，导致负载越来越大。随着在线人数的增加和游戏数据的增加，服务器变得不抗重负。同时早期 EXT磁盘分区比较脆弱，稍微停电，容易发生大面积数据丢失。因此第一步就是拆分文件存储到数据库去。

此时游戏服务端已经脱离陈旧的 MUDOS体系，各个公司在参考 MUDOS结构的情况下，开始自己用 C在重新开发自己的游戏服务端。并且脚本也抛弃了 LPC，采用扩展性更好的 Python或者 Lua来代替。由于主逻辑使用单线程模型，随着游戏内容的增加，传统单服务器的结构进一步成为瓶颈。于是有人开始拆分游戏世界，变为下面的模型：

游戏服务器压力拆分后得意缓解，但是两台游戏服务器同时访问数据库，大量重复访问，大量数据交换，使得数据库成为下一个瓶颈。于是形成了数据库前端代理（DB Proxy），游戏服务器不直接访问数据库而是访问代理，再有代理访问数据库，同时提供内存级别的cache。早年 MySQL4之前没有提供存储过程，这个前端代理一般和 MySQL跑在同一台上，它转化游戏服务器发过来的高级数据操作指令，拆分成具体的数据库操作，一定程度上代替了存储过程：

但是这样的结构并没有持续太长时间，因为玩家切换场景经常要切换连接，中间的状态容易错乱。而且游戏服务器多了以后，相互之间数据交互又会变得比较麻烦，于是人们拆分了网络功能，独立出一个网关服务 Gate（有的地方叫 Session，有的地方叫 LinkSvr之类的，名字不同而已）：

把网络功能单独提取出来，让用户统一去连接一个网关服务器，再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网管进行交换。这样类型的服务器基本能稳定的为玩家提供游戏服务，一台网关服务1-2万人，后面的游戏服务器每台服务5k-1w，依游戏类型和复杂度不同而已，图中隐藏了很多不重要的服务器，如登录和管理。这是目前应用最广的一个模型，到今天任然很多新项目会才用这样的结构来搭建。

人都是有惯性的，按照先前的经验，似乎把 MUDOS拆分的越开性能越好。于是大家继续想，网关可以拆分呀，基础服务如聊天交易，可以拆分呀，还可以提供web接口，数据库可以拆分呀，于是有了下面的模型：

这样的模型好用么？确实有成功游戏使用类似这样的架构，并且发挥了它的性能优势，比如一些大型 MMORPG。但是有两个挑战：每增加一级服务器，状态机复杂度可能会翻倍，导致研发和找bug的成本上升；并且对开发组挑战比较大，一旦项目时间吃紧，开发人员经验不足，很容易弄挂。

比如我见过某上海一线游戏公司的一个 RPG上来就要上这样的架构，我看了下他们团队成员的经验，问了下他们的上线日期，劝他们用前面稍微简单一点的模型。人家自信得很，认为有成功项目是这么做的，他们也要这么做，自己很想实现一套。于是他们义无反顾的开始编码，项目做了一年多，然后，就没有然后了。

现今在游戏成功率不高的情况下，一开始上一套比较复杂的架构需要考虑投资回报率，比如你的游戏上线半年内 PCU会去到多少？如果一个 APRG游戏，每组服务器5千人都到不了的话，那么选择一套更为贴近实际情况的结构更为经济。即使后面你的项目真的超过5千人朝着1万人目标奔的话，相信那个时候你的项目已经挣大钱了 ，你数着钱加着班去逐步迭代，一次次拆分它，相信心里也是乐开花的。

上面这些类型基本都是从拆分 MUDOS开始，将 MUDOS中的各个部件从单机一步步拆成分布式。虽然今天任然很多新项目在用上面某一种类似的结构，或者自己又做了其他热点模块的拆分。因为他们本质上都是对 MUDOS的分解，故将他们归纳为第二代游戏服务器。

类型4：第三代游戏服务器

2007从魔兽世界开始无缝世界地图已经深入人心，比较以往游戏玩家走个几步还需要切换场景，每次切换就要等待 LOADING个几十秒是一件十分破坏游戏体验的事情。于是对于 2005年以后的大型 MMORPG来说，无缝地图已成为一个标准配置。比较以往按照地图来切割游戏而言，无缝世界并不存在一块地图上面的人有且只由一台服务器处理了：

每台 Node服务器用来管理一块地图区域，由 NodeMaster（NM）来为他们提供总体管理。更高层次的 World则提供大陆级别的管理服务。这里省略若干细节服务器，比如传统数据库前端，登录服务器，日志和监控等，统统用 ADMIN概括。在这样的结构下，玩家从一块区域走向另外一块区域需要简单处理一下：

玩家1完全由节点A控制，玩家3完全由节点B控制。而处在两个节点边缘的2号玩家，则同时由A和B提供服务。玩家2从A移动到B的过程中，会同时向A请求左边的情况，并向B请求右边的情况。但是此时玩家2还是属于A管理。直到玩家2彻底离开AB边界很远，才彻底交由B管理。按照这样的逻辑将世界地图分割为一块一块的区域，交由不同的 Node去管理。

对于一个 Node所负责的区域，地理上没必要连接在一起，比如大陆的四周边缘部分和高山部分的区块人比较少，可以统一交给一个Node去管理，而这些区块在地理上并没有联系在一起的必要性。一个 Node到底管理哪些区块，可以根据游戏实时运行的负载情况，定时维护的时候进行更改 NodeMaster 上面的配置。于是碰到第一个问题是很多 Node服务器需要和玩家进行通信，需要问管理服务器特定UID为多少的玩家到底在哪台 Gate上，以前按场景切割的服务器这个问题不大，问了一次以后就可以缓存起来了，但是现在服务器种类增加不少，玩家又会飘来飘去，按UID查找玩家比较麻烦；另外一方面 GATE需要动态根据坐标计算和哪些 Node通信，导致逻辑越来越厚，于是把：“用户对象”从负责连接管理的 GATE中切割出来势在必行于是有了下面的模型：

网关服务器再次退回到精简的网络转发功能，而用户逻辑则由按照 UID划分的 OBJ服务器来承担，GATE是按照网络接入时的负载来分布，而 OBJ则是按照资源的编号（UID）来分布，这样和一个用户通信直接根据 UID计算出 OBJ服务器编号发送数据即可。而新独立出来的 OBJ则提供了更多高层次的服务：

对象移动：管理具体玩家在不同的 Node所管辖的区域之间的移动，并同需要的 Node进行沟通。

数据广播：Node可以给每个用户设置若干 TAG，然后通知 Object Master 按照TAG广播。

对象消息：通用消息推送，给某个用户发送数据，直接告诉 OBJ，不需要直接和 GATE打交道。

好友聊天：角色之间聊天直接走 OBJ/OBJ MASTER。整个服务器主体分为三层以后，NODE专注场景，OBJ专注玩家对象，

GATE专注网络。这样的模型在无缝场景服务器中得到广泛的应用。但是随着时间的推移，负载问题也越来越明显，做个活动，远来不活跃的区域变得十分活跃，靠每周维护来调整还是比较笨重的，于是有了动态负载均衡。动态负载均衡有两种方法，第一种是按照负载，由 Node Master 定时动态移动修改一下各个 Node的边界，而不同的玩家对象按照先前的方法从一台 Node上迁移到另外一台 Node上：

图11 动态负载均衡

Node Master定时查找地图上的热点区域，计算新的场景切割方式，然后告诉其他服务器开始调整，具体处理方式还是和上面对象跨越边界移动的方法一样。但是上面这种方式实现相对复杂一些，于是人们设计出了更为简单直接的一种新方法：

图12 基于网格的动态负载均衡

于网格的动态负载均衡还是将地图按照标准尺寸均匀切割成静态的网格，每个格子由一个具体的Node负责，但是根据负载情况，能够实时的迁移到其他 Node上。在迁移分为三个阶段：准备，切换，完成。三个状态由Node Master负责维护。准备阶段新的 Node开始同步老 Node上面该网格的数据，完成后告诉NM；NM确认OK后同时通知新旧 Node完成切换。完成切换后，如果 Obj服务器还在和老的 Node进行通信，老的 Node将会对它进行纠正，得到纠正的 OBJ将修正自己的状态，和新的 Node进行通信。

很多无缝动态负载均衡的服务端宣称自己支持无限的人数，但不意味着 MMORPG游戏的人数上限真的可以无限扩充，因为这样的体系会受制于网络带宽和客户端性能。带宽决定了同一个区域最大广播上限，而客户端性能决定了同一个屏幕到底可以绘制多少个角色。

从无缝地图引入了分布式对象模型开始，已经完全脱离 MUDOS体系，成为一种新的服务端模型。又由于动态负载均衡的引入，让无缝服务器如虎添翼，容纳着超过上一代游戏服务器数倍的人数上限，并提供了更好的游戏体验，我们称其为第三代游戏服务端架构。网游以大型多人角色扮演为开端，RPG网游在相当长的时间里一度占据90%以上，使得基于 MMORPG的服务端架构得到了蓬勃的发展，然而随着玩家对RPG的疲惫，各种非MMORPG游戏如雨后春笋般的出现在人们眼前，受到市场的欢迎。

类型5：战网游戏服务器

经典战网服务端和 RPG游戏有两个区别：RPG是分区分服的，北京区的用户和广州区的用户老死不相往来。而战网，虽然每局游戏一般都是 8人以内，但全国只有一套服务器，所有的玩家都可以在一起游戏，而玩家和玩家之使用 P2P的方式连接在一起，组成一局游戏：

玩家通过 Match Making 服务器使用：创建、加入、自动匹配、邀请 等方式组成一局游戏。服务器会选择一个人做 Host，其他人 P2P连接到做主的玩家上来。STUN是帮助玩家之间建立 P2P的牵引服务器，而由于 P2P联通情况大概只有 75%，实在联不通的玩家会通过 Forward进行转发。

大量的连接对战，体育竞技游戏采用类似的结构。P2P有网状模型（所有玩家互相连接），和星状模型（所有玩家连接一个主玩家）。复杂的游戏状态在网状模型下难以形成一致，因此星状P2P模型经受住了历史的考验。除去游戏数据，支持语音的战网系统也会将所有人的语音数据发送到做主的那个玩家机器上，通过混音去重再编码的方式返回给所有用户。

战网类游戏，以竞技、体育、动作等类型的游戏为主，较慢节奏的 RPG（包括ARPG）有本质上的区别，而激烈的游戏过程必然带来到较 RPG复杂的多的同步策略，这样的同步机制往往带来的是很多游戏结果由客户端直接计算得出，那在到处都是破解的今天，如何保证游戏结果的公正呢？

主要方法就是投票法，所有客户端都会独立计算，然后传递给服务器。如果结果相同就更新记录，如果结果不一致，会采取类似投票的方式确定最终结果。同时记录本剧游戏的所有输入，在可能的情况下，找另外闲散的游戏客户端验算整局游戏是否为该结果。并且记录经常有作弊嫌疑的用户，供运营人员封号时参考。

类型7：休闲游戏服务器

休闲游戏同战网服务器类似，都是全区架构，不同的是有房间服务器，还有具体的游戏服务器，游戏主体不再以玩家 P2P进行，而是连接到专门的游戏服务器处理：

和战网一样的全区架构，用户数据不能象分区的 RPG那样一次性load到内存，然后在内存里面直接修改。全区架构下，为了应对一个用户同时玩几个游戏，用户数据需要区分基本数据和不同的游戏数据，而游戏数据又需要区分积分数据、和文档数据。胜平负之类的积分可以直接提交增量修改，而更为普遍的文档类数据则需要提供读写令牌，写令牌只有一块，读令牌有很多块。同帐号同一个游戏同时在两台电脑上玩时，最先开始的那个游戏获得写令牌，可以操作任意的用户数据。而后开始的那个游戏除了可以提交胜平负积分的增量改变外，对用户数据采用只读的方式，保证游戏能运行下去，但是会提示用户，游戏数据锁定。

类型8：现代动作类网游

从早期的韩国动作游戏开始，传统的战网动作类游戏和 RPG游戏开始尝试融合。单纯的动作游戏玩家容易疲倦，留存也没有 RPG那么高；而单纯 RPG战斗却又慢节奏的乏味，无法满足很多玩家激烈对抗的期望，于是二者开始融合成为新一代的：动作 + 城镇 模式。玩家在城镇中聚集，然后以开副本的方式几个人出去以动作游戏的玩法来完成各种 RPG任务。本质就是一套 RPG服务端+副本服务端。由于每次副本时人物可以控制在8人以内，因此可以获得更为实时的游戏体验，让玩家玩的更加爽快。

说了那么多的游戏服务器类型，其实也差不多了，剩下的类型大家拼凑一下其实也就是这个样子而已。

1-技术有什么区别

首先通信上目前的主流是HTTP协议和SOCKET这两种(HTML5提供了一种新的协议，WebScoket，对此了解并不多，因此不做评论，以免误导)。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

（注：在HTTP 11中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。）

Socket又称"套接字"，应用程序通常通过"套接字"向网络发出请求或者应答网络请求。

以J2SDK-13为例，Socket和ServerSocket类库位于http://javanet包中。ServerSocket用于服务器端，Socket是建立网络连接时使用的。在连接成功时，应用程序两端都会产生一个Socket实例，操作这个实例，完成所需的会话。对于一个网络连接来说，套接字是平等的，并没有差别，不因为在服务器端或在客户端而产生不同级别。不管是Socket还是ServerSocket它们的工作都是通过SocketImpl类及其子类完成的。（摘自百科）

在WEB服务器中，一般情况是只需要使用HTTP协议的。因为它不太需要去与浏览器进行主动推送，只需要响应浏览器的访问就足够了

而在游戏服务器，这样的连接方式肯定是不够用的。很多时候游戏服务器是需要主动推送消息，如系统广播。

2-思维有什么区别

WEB服务器并不需要高频即时通讯，对响应速度要求不高。而游戏服务器，大多数是需要很及时的响应速度（暂不讨论弱联网游戏）。如DOTA，这种竞技类型的游戏，1秒就能发生很多事。

因此，在思考方向上，WEB服务器应该考虑是的多平台的兼容，大量用户访问的高并发。

而游戏服务器应该考虑的是高频通讯，高并发。

3-架构的侧重点有什么区别

在架构上面，一般访问量不是很大的网站是只有一台服务器的，访问量高的才会进行分布式设计或者集群设计。

而大部分游戏服务器都是需要分布式设计的。

在现有的网络游戏服务器端架构中，多是以功能和场景来划分服务器结构的。具体的划分是根据项目的需求进行的，并没有一个十分通用的架构。

以上是比较常见的结构，客户端登录的时候，连接GateServer，然后由GateServer去连接LoginServer进行登录。登录后通过CenterServer转发到GameServer（GameServer即是服务器大区）。

而其中的DCServer，主要的功能是缓存玩家角色数据，保证角色数据能快速的读取和保存。

LogServer便是保存日志的了。

4-本质有无区别

本质上，两者并无区别，只是需求不同，侧重点不同罢了。

2006年，我们翻译了“PRO OGRE 3D PROGRAMMING”这本书，创建了OGRE 3D引擎的中文社区，并把这本书的电子版本提供给国内的朋友下载学习。几年之后，OGRE 3D图形引擎在中国已经遍地开花，包括九城、久游、吉比特、搜狐畅游、麒麟游戏，以及网域等游戏公司都在不同程度地使用这款图形引擎，同时也有越来越多的朋友开始关注它。得到电子工业出版社的首肯，笔者有幸能撰写一本关于Ogre3D使用开发的图书。

本书缘起

从2006年我们建立OGRE 3D中文社区开始，不断地得到热心朋友的帮助，翻译了大量的OGRE 3D相关文档，其中包括《Ogre手册》、《基础教程》、《中级教程》，以及相关的一系列文章，以至于今天笔者准备从头撰写一本OGRE 3D相关知识的书籍时，竟然发现大部分的知识内容已经可以在网络上找到，几乎不可能再原创一本专注于OGRE 3D使用的书籍。

笔者绝对不敢冒险东拼西凑提供一本“学术腐败”的论文集给大家看，与其重复那些网络上已有的知识，不如另辟蹊径，即从代码入手讲解如何通过游戏开发框架，在学会OGRE 3D引擎之后进一步完成完整的游戏。

这本书不会告诉读者图形引擎的基础，而是希望告诉读者在了解一款图形引擎之后还缺少哪些工具来完成一个完整的游戏。本书定位于希望进一步了解如何以OGRE 3D为基础开发一款完整游戏的朋友们。

我们在光盘中提供了“PRO OGRE 3D PROGRAMMING”中文版本的下载地址，那里详细地介绍了OGRE 3D相关的知识和细节。希望读者可以结合这两本书来阅读。在这里需要感谢我的编辑袁金敏女士，正是因为她的肯定才让笔者有信心来完成这本书。

基于以上定位，这本书应该是学习OGRE 3D游戏开发的第2本书，帮助读者从一位引擎研究者成为一位可以实战的游戏开发人员。读者可能还没有接触OGRE 3D图形引擎，偶然在书店中看到这本书，正在决定是否加入OGRE 3D的开发人员队伍中来。这本书的第1章将会帮助读者解决疑惑，从一个宏观的角度来描述OGRE 3D图形引擎的发展史及相关资源。我们尽量做到简短和精辟，让读者站在书店的书架旁边就能看完，决定是否有必要学习OGRE 3D，以及是否需要掏钱买这本书。如果发现其中有您感兴趣的游戏开发工具，那么本书一定在某一天会给您的工作带来“雪中送碳”的效用。

本书阅读指南

这本书的最大特点是依赖代码来推进进度。从第2章开始的几乎每一个课程都有相关的代码工程提供给读者参考，这样做可以让读者更直观地了解本书介绍的内容。

网上说行为学的研究表明，如果坚持21天，你就很可能改变或养成一个新的习惯。虽然我不是这方面的专家，但是还是按照《21天精通XXX》书籍的惯例把这个章节的课程划分到3个星期中。每周讲解一个完整工程，至少这样做可使读者很方便地安排自己的阅读时间。

在每个星期的第1天（星期日），我们会讲解一下本周课程的具体内容和背景知识，在接下来的星期一～星期六的课程中会把一个完整的工程分解成为6个部分逐渐完善并依次讲解。

OGRE 3D把自身定位成一个纯粹的图形引擎，优秀的独立性带来的副作用是如果需要完成一款完整的游戏，OGRE 3D并不足够，还需要类似音频引擎、网络引擎、输入引擎等功能性库，以及一个高效稳定且功能强大的框架。不论读者是否做过完整的游戏，都应该能感觉到一个好的框架对于一款游戏是多么重要。本书将着重介绍这方面的知识，在第2章第1周的课程中，我们介绍读者熟悉的OGRE 3D演示程序所使用的框架，并完成一款《打地鼠》游戏。虽然这个框架不足以强壮到完成一款商业游戏，但是至少可以帮助读者了解框架在游戏开发中的重要作用。

OGRE 3D中文社区除了有翻译的大量的文档之外，同时在做一件很有意义的工作，就是开发并完善一款商业强度且基于OGRE 3D思想的游戏开发框架Orz（Open Resources Zone）。在其宣布开源的一年的时间里，我们得到了业内很多朋友的肯定和支持（甚至包括海峡对岸的朋友）。

在第2周的课程中，我们采用Orz框架来代替OGRE 3D演示程序框架实现了《太空侵略者》这款经典游戏。在这周的课程中我们采用快速开发方式来完成游戏原型，没有过多使用Orz框架中的高级特性。这样做可以使读者在不用掌握复杂背景知识的前提下，了解如何通过框架来提高游戏的开发速度和质量。而在实际的商业应用中，Orz确实带来了工作效率的大幅度提升。

如果读者接触了一些其他公司内部的开发框架，会发现Orz并不比这些商业的产品差，甚至在很多方面强于其他产品。

Orz框架有自己的野心，它不仅仅是一款帮助读者提高开发效率的工具，还在框架设计上提供了“理想式分布式开发”的游戏设计方法学基础。我们通过强大的消息系统、插件体系及ID管理器等工具，尽可能减少开发人员之间的沟通成本，实现可以让开发人员在很少协调成本的情况下合作开发巨大型游戏的基础。

基于这个理念，OGRE 3D中文社区曾经组织了一些开发人员各自完成自己的代码，在没有互相沟通的情况下实现了一个《搏击俱乐部》的类游戏。故而，我们在第3周的课程中以这个现实活动作为背景，讲解如何采用“理想的分布式开发”模型来完成一款游戏。在这里我们使用了大量Orz的高级特性和工具，从一个更高的层次来审视Orz游戏开发框架所带来的“甜品”。

不知道这些“甜品”有没有吸引读者的胃口，如果没有，我们在之后的第3章还准备了“大餐”，详细地介绍了Orz框架的使用细节。

Orz在框架的设计上尽可能遵循MVC模式，我们相信一个良好的设计等于简单的框架加上丰富的工具。在框架的设计过程中，我们尽量把一些游戏开发的模块作为独立的工具在相关章节中来依次讲解，读者可以有选择地采用这些工具来简化游戏开发过程。如果读者打算从头构造一款游戏，并准备采用完整的Orz框架，这里也有对其中简单框架的详细介绍。当然和之前的课程一样，我们不仅提供了所有Orz框架的代码，还提供了与每一课程对应的例程。

我相信，在中国土壤中成长出来的游戏开发人员，很多都希望实现一个网络MMO游戏，而不是单机的“俄罗斯方砖”。

感谢熊小磊先生的无私奉献，在Orz中确实存在这样一个独立的游戏开发网络库OrzAsio。OrzAsio是一个高效并可扩展的跨平台异步网络库，目的是为用户提供高效、可靠和灵活的网络程序开发组件，方便用户构建高效且灵活的网络程序。而OrzAsio的一个重要目标是为大型多人在线游戏开发网络模块，并能良好地满足大吞吐量及高负载的网络游戏服务器需求。OrzAsio的网络底层基于boost::asio，这是一个高效、可扩展和跨平台的网络库。如果关心我们的社区，读者会了解熊小磊先生正在完成一个更加前卫且基于公共对象请求代理体系结构规范（CORBA规范）的网络游戏的网络开发架构。

在本书的随附光盘中提供了OrzAsio网络库及其依赖工具Toolkit_Plus的文档。

笔者希望读者都能喜欢我们精心准备的大餐。如果您能开心享用，那是我们的荣幸。然而制作一款完整的游戏并不是一本书能够完全讲清楚的事情，所以我们在这本书的最后提供了这个创造乐园的地图。在 本书的附录中我们提供了Boost库、设计模式及OGRE 3D的简单概述。

致谢

好莱坞奥斯卡的获奖者都会在最重要的时间讲一些感谢的话，我们要说的话如下。

谢谢我现在和之前的老板及同事的支持与鼓励，当然请相信我并没有在上班时间来写作，也没有耽误工作进度。

感谢OGRE 3D社区提供了这么好的软件，虽然引擎的核心开发人员大部分都不懂中文，但是在这本中文书中我还是由衷地感谢他们。

谢谢那些为OGRE 3D引擎在中国普及而努力的人们，Mega的游戏开发小组、盛崇山老师、燕尘，以及谢建华（音译）先生，让我分享了你们的荣誉。

感谢熊小磊先生捐献的网络库和相应文档，感谢Mega的游戏开发小组的任晓宇先生提供《OGRE使用指南》部分章节的授权，感谢梁国栋的“附录C”，感谢兄弟们找的错字。

感谢我的家人对我的关心，感谢父母能容忍我的任性。感谢女朋友对我的支持，竟然接受我每天在外地写稿子，而不是给他们打电话。

如果不是觉得我家里人会看到这本书，那我一定第一个感谢的就是您——现在看到这里的读者。如果您买了这本书，那么便是在经济上援助了我；如果您让身边的朋友阅读了这本书，那就是在梦想上援助了我。

这个梦想是：

让每个看电视的人都能开发游戏。