网络游戏服务器

网络游戏服务器：

网络游戏类型：RPG, ARPG,FPS, MMOPRG, SLG,回合制,养成类 等等

网络游戏的构成：1、前端2、游戏服务器3、后台

1、前端的表现形式：a、客户端b、手机端c、网页（flash、uinity3d等等插件）

2、游戏服务器：与前端交互，进行游戏逻辑的地方

3、后台：游戏玩家信息统计（等级分布、交易追踪、游戏币追踪、创建率等等）、玩家物品补偿、禁言等等功能，通过PHP、其他语言，选择服务器进行操作

游戏系统：

基础人物属性系统（一级属性、二级属性）、

物品系统、

装备系统、

筋脉系统、

坐骑系统、

宠物系统、

技能系统（人物技能、宠物技能）、

VIP系统、

任务系统（人物成长路线）、

交易系统（玩家与系统；玩家与玩家）、

摆摊系统、

玫瑰系统（暂时没有）、

A目标系统，也可叫成就（完成某几件事情）系统（按照章节）、

聊天系统（考虑是否需要单独开设聊天服务器）、

好友系统、

组队系统（组队打副本、组队打boss）、

帮派系统、

新手引导系统、

挂机系统（有外挂---非游戏开发商提供、内挂---游戏开发商提供之分）、

答题系统、

摇奖系统、

商城、神秘商店（好东西全局广播）、NPC商店系统、

炼丹系统、

秘籍系统、

挑战系统、

盟主战系统、

副本系统、

活动系统、

抢旗战、

阵营站、

生存站、

在线奖励系统、

离线系统（离线奖励、离线挂机）

邮件系统、

公告系统、

跨服战、

日志系统、

沉迷系统、

整个游戏开发流程：

1、游戏选型

2、服务器网络模型的确定

3、服务器整体架构设计

4、协议确定

5、根据策划案游戏接口定义和逻辑实现

6、游戏服务器内部测试，跑机器人

7、服务器—客户端联调（频繁交互的过程）

8、内测、公测、封测

9、后台介入（信息查询、数据分析）

10、合服 （节省成本、聚集人气、挑起矛盾）

注意问题：

1、合服（物品ID，角色名字，角色ID等）

2、动态屏蔽功能点

3、脚本动态加载

以下以A游戏为代表：

A游戏服务器构架

A游戏服务器构架有两种理解方式：这种设计分布式设计方式，可伸缩性较强。

1、GameServer管理所有场景，这种其实是分线的方式

2、GameServer管理部分场景，这种属于游戏大区方式

各个游戏服务器功能：

登录服务器：进行用户身份验证，返回Token和游戏服务器IP地址端口，并进行客户端登录时的负载均衡。

中心服务器：各个游戏服务器的数据通道，游戏全局数据的存储缓冲区。

数据库服务器：固话用户数据

游戏服务器：进行游戏逻辑的载体。玩家在此升级、发展、获得荣誉、展示实力。

聊天服务器：可以单独开设、也可以没有聊天服务器。

后台：

进行数据查询、分析。

物品补偿

GM：

发送游戏公告

提供游戏在线帮助

拥有管理权限的GM还可以封号、禁言

各种编辑器：

地图编辑器

道具编辑器

任务编辑器

运营维护：

服务器上线后，进行服务器的维护。

游戏服务器整体架构：

网络

数据库

分布式

负载

逻辑

不同游戏类型采用不同的线程模型：

1、SLG和回合制：

这种处理方式比较简单，整个线程模型也较为简单，前端网络线程承载所有的数据包的接受和发送，所有的逻辑处理在逻辑处理线程。对于这种类型游戏的处理能力至少在3000以上单服务器。

2、ARPG，轻量级的

这种处理方式线程模型比较复杂，单个进程包含了所有的场景，将场景挂载在各个线程，整个驱动方式为：线程驱动网络事件、线程驱动场景。场景驱动场景内物体（人物、怪物、场景事件等等）。可以提高整个游戏的并发量。线程切换时，只需要线程间socket过渡就可以了。不需要在线程间进行数据的交换。可同时支持几千人。

3、ARPG，重量级的

这是一种大区的设计方式，整体模型和第二种类似，不同点是游戏服以多进程+多线程的方式驱动。在涉及到跨进程场景切换时会有服务器内的数据交换。此设计方式在大场景时比较适用，可以同时支撑上万人在线进行游戏。（每个场景控制在1024最大量）

网络游戏服务器构建和当前Sky游戏平台：

终端内置两个IP地址和端口。

这个平台对于处理SLG这一类的游戏，应该没有什么问题，可以在此平台上面来进行游戏的开发，。

对于处理大区概念的ARPG，这个处理方式不是很好。在处理游戏逻辑时候会带来一定的麻烦。应该来说线程模型上会有一定区别。增加编程复杂度。

游戏运营：

运营商为什么不提供SDK，这个其实很难，客户端的渲染引擎可以拿开源的。服务器的开发引擎，各个游戏开发商都有各自的设计方式，甚至有的开发商已经有了一套自己成熟的游戏框架。所有目前在网游市场，运营商更多的只是提供物理服务器的。在目前中国游戏来看，每个区之间的交互较少，基本上局限在跨服战上。还有一个原因：游戏后期也会涉及到联运（好的运营商），甚至卖版权给国外运营商，那么这样每个运营平台又有自己的一种SDK，这样游戏开发商要被搞死了。（在智能机的游戏上，冒昧的想，是不是应该和端游、页游相靠近，更多的是提供运营手段，平台可以不限制太死。对于原有的cp可以继续提供类似平台）

网络游戏服务器端引擎：

鉴于网络游戏服务器端整个逻辑的实现，依赖于游戏选型、游戏策划案、游戏内容的确定包括人物属性、道具属性、任务内容等等。这些内容是千变万化的，基本很难抽象，与其抽象1%来混淆用户，还不如不做。就是因为这些内容的千变万化，容易出现问题，才在游戏中引入了脚本，机制灵活。脚本的引入省却了重新编译，动态脚本的更新更避免了游戏停服带来的影响。要说网络游戏引擎的话，我们只能抽象出不易变的，也就是网络层。只提供数据的收发。但是需要注意的是：这种网络层的线程模型又与游戏的类型紧密相关（此见上面三种网络模型）。

热血三国

傲剑

心动游戏：盛世三国、神仙道

龙将

傲视天地

卧龙吟

神曲

手机游戏比较合适的为：SLG游戏类型、回合制、养成类等等