序言
网络游戏，作为游戏与网络有机结合的产物，把玩家带入了新的娱乐领域。网络游戏在中国开始发展至今也仅有3，4年的历史，跟已经拥有几十年开发历史的单机游戏相比，网络游戏还是非常年轻的。当然，它的形成也是根据历史变化而产生的可以说没有互联网的兴起，也就没有网络游戏的诞生。作为新兴产物，网络游戏的开发对广大开发者来说更加神秘，对于一个未知领域，开发者可能更需要了解的是网络游戏与普通单机游戏有何区别，网络游戏如何将玩家们连接起来，以及如何为玩家提供一个互动的娱乐环境。本文就将围绕这三个主题来给大家讲述一下网络游戏的网络互连实现方法。
网络游戏与单机游戏
说到网络游戏，不得不让人联想到单机游戏，实际上网络游戏的实质脱离不了单机游戏的制作思想，网络游戏和单机游戏的差别大家可以很直接的想到：不就是可以多人连线吗？没错，但如何实现这些功能，如何把网络连线合理的融合进单机游戏，就是我们下面要讨论的内容。在了解网络互连具体实现之前，我们先来了解一下单机与网络游戏它们各自的运行流程，只有了解这些，你才能深入网络游戏开发的核心。
现在先让我们来看一下普通单机游戏的简化执行流程：
Initialize() // 初始化模块
{
初始化游戏数据;
}
Game() // 游戏循环部分
{
绘制游戏场景、人物以及其它元素;
获取用户操作输入;
switch( 用户输入数据)
{
case 移动:
{
处理人物移动;
}
break;
case 攻击:
{
处理攻击逻辑:
}
break;
...
其它处理响应;
...
default:
break;
}
游戏的NPC等逻辑AI处理;
}
Exit() // 游戏结束
{
释放游戏数据;
离开游戏;
}
我们来说明一下上面单机游戏的流程。首先，不管是游戏软件还是其他应用软件，初始化部分必不可少，这里需要对游戏的数据进行初始化，包括图像、声音以及一些必备的数据。接下来，我们的游戏对场景、人物以及其他元素进行循环绘制，把游戏世界展现给玩家，同时接收玩家的输入操作，并根据操作来做出响应，此外，游戏还需要对NPC以及一些逻辑AI进行处理。最后，游戏数据被释放，游戏结束。
网络游戏与单机游戏有一个很显著的差别，就是网络游戏除了一个供操作游戏的用户界面平台（如单机游戏）外，还需要一个用于连接所有用户，并为所有用户提供数据服务的服务器，从某些角度来看，游戏服务器就像一个大型的数据库，提供数据以及数据逻辑交互的功能。让我们来看看一个简单的网络游戏模型执行流程：
客户机：
Login()// 登入模块
{
初始化游戏数据;
获取用户输入的用户和密码;
与服务器创建网络连接;
发送至服务器进行用户验证;
...
等待服务器确认消息;
...
获得服务器反馈的登入消息;
if( 成立 )
进入游戏;
else
提示用户登入错误并重新接受用户登入;
}
Game()// 游戏循环部分
{
绘制游戏场景、人物以及其它元素;
获取用户操作输入;
将用户的操作发送至服务器;
...
等待服务器的消息;
...
接收服务器的反馈信息;
switch( 服务器反馈的消息数据 )
{
case 本地玩家移动的消息:
{
if( 允许本地玩家移动 )
客户机处理人物移动;
else
客户机保持原有状态;
}
break;
case 其他玩家/NPC的移动消息:
{
根据服务器的反馈信息进行其他玩家或者NPC的移动处理;
}
break;
case 新玩家加入游戏:
{
在客户机中添加显示此玩家;
}
break;
case 玩家离开游戏:
{
在客户机中销毁此玩家数据;
}
break;
...
其它消息类型处理;
...
default:
break;
}
}
Exit()// 游戏结束
{
发送离开消息给服务器;
...
等待服务器确认;
...
得到服务器确认消息;
与服务器断开连接;
释放游戏数据;
离开游戏;
}
服务器：
Listen() // 游戏服务器等待玩家连接模块
{
...
等待用户的登入信息;
...
接收到用户登入信息;
分析用户名和密码是否符合;
if( 符合 )
{
发送确认允许进入游戏消息给客户机;
把此玩家进入游戏的消息发布给场景中所有玩家;
把此玩家添加到服务器场景中;
}
else
{
断开与客户机的连接;
}
}
Game() // 游戏服务器循环部分
{
...
等待场景中玩家的操作输入;
...
接收到某玩家的移动输入或NPC的移动逻辑输入;
// 此处只以移动为例
进行此玩家/NPC在地图场景是否可移动的逻辑判断;
if( 可移动 )
{
对此玩家/NPC进行服务器移动处理;
发送移动消息给客户机;
发送此玩家的移动消息给场景上所有玩家;
}
else
发送不可移动消息给客户机;
}
Exit() // 游戏服务＝器结束
{
接收到玩家离开消息;
将此消息发送给场景中所有玩家;
发送允许离开的信息;
将玩家数据存入数据库;
注销此玩家在服务器内存中的数据;
}
}
让我们来说明一下上面简单网络游戏模型的运行机制。先来讲讲服务器端，这里服务器端分为三个部分（实际上一个完整的网络游戏远不止这些）：登入模块、游戏模块和登出模块。登入模块用于监听网络游戏客户端发送过来的网络连接消息，并且验证其合法性，然后在服务器中创建这个玩家并且把玩家带领到游戏模块中；游戏模块则提供给玩家用户实际的应用服务，我们在后面会详细介绍这个部分；在得到玩家要离开游戏的消息后，登出模块则会把玩家从服务器中删除，并且把玩家的属性数据保存到服务器数据库中，如：经验值、等级、生命值等。
接下来让我们看看网络游戏的客户端。这时候，客户端不再像单机游戏一样，初始化数据后直接进入游戏，而是在与服务器创建连接，并且获得许可的前提下才进入游戏。除此之外，网络游戏的客户端游戏进程需要不断与服务器进行通讯，通过与服务器交换数据来确定当前游戏的状态，例如其他玩家的位置变化、物品掉落情况。同样，在离开游戏时，客户端会向服务器告知此玩家用户离开，以便于服务器做出相应处理。
以上用简单的伪代码给大家阐述了单机游戏与网络游戏的执行流程，大家应该可以清楚看出两者的差别，以及两者间相互的关系。我们可以换个角度考虑，网络游戏就是把单机游戏的逻辑运算部分搬移到游戏服务器中进行处理，然后把处理结果(包括其他玩家数据)通过游戏服务器返回给连接的玩家。
网络互连
在了解了网络游戏基本形态之后，让我们进入真正的实际应用部分。首先，作为网络游戏，除了常规的单机游戏所必需的东西之外，我们还需要增加一个网络通讯模块，当然，这也是网络游戏较为主要的部分，我们来讨论一下如何实现网络的通讯模块。
一个完善的网络通讯模块涉及面相当广，本文仅对较为基本的处理方式进行讨论。网络游戏是由客户端和服务器组成，相应也需要两种不同的网络通讯处理方式，不过也有相同之处，我们先就它们的共同点来进行介绍。我们这里以Microsoft Windows 2000 [2000 Server]作为开发平台，并且使用Winsock作为网络接口（可能一些朋友会考虑使用DirectPlay来进行网络通讯，不过对于当前在线游戏，DirectPlay并不适合，具体原因这里就不做讨论了）。
确定好平台与接口后，我们开始进行网络连接创建之前的一些必要的初始化工作，这部分无论是客户端或者服务器都需要进行。让我们看看下面的代码片段：
WORD wVersionRequested;
WSADATAwsaData;
wVersionRequested MAKEWORD(1, 1);
if( WSAStartup( wVersionRequested, &wsaData ) !0 )
{
Failed( WinSock Version Error!" );
}
上面通过调用Windows的socket API函数来初始化网络设备，接下来进行网络Socket的创建，代码片段如下：
SOCKET sSocket socket( AF_INET, m_lProtocol, 0 );
if( sSocket == INVALID_SOCKET )
{
Failed( "WinSocket Create Error!" );
}
这里需要说明，客户端和服务端所需要的Socket连接数量是不同的，客户端只需要一个Socket连接足以满足游戏的需要，而服务端必须为每个玩家用户创建一个用于通讯的Socket连接。当然，并不是说如果服务器上没有玩家那就不需要创建Socket连接，服务器端在启动之时会生成一个特殊的Socket用来对玩家创建与服务器连接的请求进行响应，等介绍网络监听部分后会有更详细说明。
有初始化与创建必然就有释放与删除，让我们看看下面的释放部分：
if( sSocket != INVALID_SOCKET )
{
closesocket( sSocket );
}
if( WSACleanup() != 0 )
{
Warning( "Can't release Winsocket" );
}
这里两个步骤分别对前面所作的创建初始化进行了相应释放。
接下来看看服务器端的一个网络执行处理，这里我们假设服务器端已经创建好一个Socket供使用，我们要做的就是让这个Socket变成监听网络连接请求的专用接口，看看下面代码片段：
SOCKADDR_IN addr;
memset( &addr, 0, sizeof(addr) );
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl( INADDR_ANY );
addr.sin_port = htons( Port ); // Port为要监听的端口号
// 绑定socket
if( bind( sSocket, (SOCKADDR*)&addr, sizeof(addr) ) == SOCKET_ERROR )
{
Failed( "WinSocket Bind Error!");
}
// 进行监听
if( listen( sSocket, SOMAXCONN ) == SOCKET_ERROR )
{
Failed( "WinSocket Listen Error!");
}
这里使用的是阻塞式通讯处理，此时程序将处于等待玩家用户连接的状态，倘若这时候有客户端连接进来，则通过accept()来创建针对此玩家用户的Socket连接，代码片段如下：
sockaddraddrServer;
int nLen sizeof( addrServer );
SOCKET sPlayerSocket accept( sSocket, &addrServer, &nLen );
if( sPlayerSocket == INVALID_SOCKET )
{
Failed( WinSocket Accept Error!");
}
这里我们创建了sPlayerSocket连接，此后游戏服务器与这个玩家用户的通讯全部通过此Socket进行，到这里为止，我们服务器已经有了接受玩家用户连接的功能，现在让我们来看看游戏客户端是如何连接到游戏服务器上，代码片段如下：
SOCKADDR_IN addr;
memset( &addr, 0, sizeof(addr) );
addr.sin_family = AF_INET;// 要连接的游戏服务器端口号
addr.sin_addr.s_addr = inet_addr( IP );// 要连接的游戏服务器IP地址，
addr.sin_port = htons( Port );//到此，客户端和服务器已经有了通讯的桥梁，
//接下来就是进行数据的发送和接收：
connect( sSocket, (SOCKADDR*)&addr, sizeof(addr) );
if( send( sSocket, pBuffer, lLength, 0 ) == SOCKET_ERROR )
{
Failed( "WinSocket Send Error!");
}
这里的pBuffer为要发送的数据缓冲指针，lLength为需要发送的数据长度，通过这支Socket API函数，我们无论在客户端或者服务端都可以进行数据的发送工作，同时，我们可以通过recv()这支Socket API函数来进行数据接收：
if( recv( sSocket, pBuffer, lLength, 0 ) == SOCKET_ERROR )
{
Failed( "WinSocket Recv Error!");
}
其中pBuffer用来存储获取的网络数据缓冲，lLength则为需要获取的数据长度。
现在，我们已经了解了一些网络互连的基本知识，但作为网络游戏，如此简单的连接方式是无法满足网络游戏中百人千人同时在线的，我们需要更合理容错性更强的网络通讯处理方式，当然，我们需要先了解一下网络游戏对网络通讯的需求是怎样的。
网游服务器端结构设计方面的问题。
随着网游从业者的规模和需求不断扩大，越来越多的朋友进入了网游开发这个领域，使得市场中网游开发技术相关的需求量迅猛增长。目前，（网游）网络游戏行业比较紧缺的是具有较深技术功底的“专家型”开发者，这主要包括两个方面：服务器端设计人员以及客户端设计人员。对于网络游戏而言，由于其主要的游戏逻辑计算是在服务器端完成的，数据同步与广播信息的传递也是通过服务器完成的，所以，是否拥有一个有经验的服务器端设计人员已经成为一款网游产品能否成功的关键之一。鉴于此，本文将试图就网游服务器设计的一系列问题展开讨论和总结，笔者将结合自己的开发经验和体会，将其中各方面内容逐一呈现。希望能够对以下三类人员有所帮助：
有一定网络编程基础、准备进入（网游）网络游戏行业作服务器端设计的人员；
正在从事网游服务器设计的人员；
网游项目的技术负责人。
由于网游服务器的设计牵涉到太多内容，比如：网络通信方面、人工智能、数据库设计等等，所以本文将重点从网络通信方面的内容展开论述。谈到网络通信，就不能不涉及如下五个问题：
1、 常见的网游服务通信器架构概述
2、 网游服务器设计的基本原则
3、 网游服务器通信架构设计所需的基本技术
4、 网游服务器通信架构的测试
5、 网游服务器通信架构设计的常见问题
下面我们就从第一个问题说起：
常见的网游服务器通信架构概述
目前，国内的网游市场中大体存在两种类型的网游游戏：MMORPG（如：魔兽世界）和休闲网游（如：QQ休闲游戏和联众游戏，而如泡泡堂一类的游戏与 QQ休闲游戏有很多相同点，因此也归为此类）。由于二者在游戏风格上的截然不同，导致了他们在通信架构设计思路上的较大差别。下面笔者将分别描述这两种网游的通信架构。
1．MMORPG类网游的通信架构
网游的通信架构，通常是根据几个方面来确定的：游戏的功能组成、游戏的预计上线人数以及游戏的可扩展性。
目前比较通用的MMORPG游戏流程是这样的：
a. 玩家到游戏官方网站注册用户名和密码。
b. 注册完成后，玩家选择在某一个区激活游戏账号。
c. 玩家在游戏客户端中登录进入已经被激活的游戏分区，建立游戏角色进行游戏。
通常，在这样的模式下，玩家的角色数据是不能跨区使用的，即：在A区建立的游戏角色在B区是无法使用的，各区之间的数据保持各自独立性。我们将这样独立的A区或B区称为一个独立的服务器组，一个独立的服务器组就是一个相对完整的游戏世界。而网游服务器的通信架构设计，则包括了基于服务器组之上的整个游戏世界的通信架构，以及在一个服务器组之内的服务器通信架构。
我们先来看看单独的服务器组内部的通信是如何设计的。
一个服务器组内的各服务器组成，要依据游戏功能进行划分。不同的游戏内容策划会对服务器的组成造成不同的影响。一般地，我们可以将一个组内的服务器简单地分成两类：场景相关的（如：行走、战斗等）以及场景不相关的（如：公会聊天、不受区域限制的贸易等）。为了保证游戏的流畅性，可以将这两类不同的功能分别交由不同的服务器去各自完成。另外，对于那些在服务器运行中进行的比较耗时的计算，一般也会将其单独提炼出来，交由单独的线程或单独的进程去完成。
各个网游项目会根据游戏特点的不同，而灵活选择自己的服务器组成方案。经常可以见到的一种方案是：场景服务器、非场景服务器、服务器管理器、AI服务器以及数据库代理服务器。
以上各服务器的主要功能是：
场景服务器：它负责完成主要的游戏逻辑，这些逻辑包括：角色在游戏场景中的进入与退出、角色的行走与跑动、角色战斗（包括打怪）、任务的认领等。场景服务器设计的好坏是整个游戏世界服务器性能差异的主要体现，它的设计难度不仅仅在于通信模型方面，更主要的是整个服务器的体系架构和同步机制的设计。
非场景服务器：它主要负责完成与游戏场景不相关的游戏逻辑，这些逻辑不依靠游戏的地图系统也能正常进行，比如公会聊天或世界聊天，之所以把它从场景服务器中独立出来，是为了节省场景服务器的CPU和带宽资源，让场景服务器能够尽可能快地处理那些对游戏流畅性影响较大的游戏逻辑。
服务器管理器：为了实现众多的场景服务器之间以及场景服务器与非场景服务器之间的数据同步，我们必须建立一个统一的管理者，这个管理者就是服务器组中的服务器管理器。它的任务主要是在各服务器之间作数据同步，比如玩家上下线信息的同步。其最主要的功能还是完成场景切换时的数据同步。当玩家需要从一个场景A切换到另一个场景B时，服务器管理器负责将玩家的数据从场景A转移到场景B，并通过协议通知这两个场景数据同步的开始与结束。所以，为了实现这些内容繁杂的数据同步任务，服务器管理器通常会与所有的场景服务器和非场景服务器保持socket连接。
AI（人工智能）服务器：由于怪物的人工智能计算非常消耗系统资源，所以我们把它独立成单独的服务器。AI服务器的主要作用是负责计算怪物的AI，并将计算结果返回给场景服务器，也就是说，AI服务器是单独为场景服务器服务的，它完成从场景服务器交过来的计算任务，并将计算结果返回给场景服务器。所以，从网络通信方面来说，AI服务器只与众多场景服务器保持socket连接。
数据库代理服务器：在网游的数据库读写方面，通常有两种作法，一种是在应用服务器中直接加进数据库访问的代码进行数据库访问，还有一种方式是将数据库读写独立出来，单独作成数据库代理，由它统一进行数据库访问并返回访问结果。