加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 教程 > 正文

游戏服务器开发的基本体系与开发的一些建议

发布时间:2018-07-07 06:36:35 所属栏目:教程 来源:佚名
导读:【资讯】近年来,我身边的朋友有很多都从web转向了游戏开发。他们以前都没有做过游戏服务器开发,更谈不上什么经验,而从网上找的例子或游戏方面的知识,又是那么的少,那么的零散。当他们进入游戏公司时,显得一脸茫然。如果是大公司还好点,起码有人带带

  日志是个好东西呀,一个游戏中更不能少了日志,而且日志一定要记录的详细。它是玩家在整个游戏中的行为记录,有了这个记录,我们就可以分析玩家的行为,查找游戏的不足,在处理玩家在游戏中的问题时,日志也是一个良好的凭证和快速处理方式。

  在游戏中,日志分为:

  系统日志,主要记录游戏服务器的系统情况。比如:数据库能否正常连接,服务器是否正常启动,数据是否正常加载;

  玩家行为日志,比如玩家发送了什么请求,得到了什么物品,消费了多少货币等等;

  统计日志,这种日志是对游戏中所有玩家某种行为的一种统计,根据这个统计来分析大部分玩家的行为,得出一些共性或不同之处,以方法运营做不同的活动吸引用户消费。

  在构架设计中,日志记录一定要做为一种强制行为,因为不强制的话,可能由于某种原因某个功能忘记加日志了,那么当这个功能出问题了,或者运营跟我们要这个功能的一些数据库,就傻眼了。又得加需求,改代码了。日志一定要设计一种良好的格式,日志记录的数据要容易读取,分解。日志行为可以用枚举描述,在功能最后的处理方法里面加上这个枚举做为参数,这样不管谁在调用这个方法时,都要去加参数描述。

  俗话说,工欲善其事,必先利其器。游戏管理工具是对游戏运行中的一系列问题处理的一种工具。它不仅是给开发人员用,大多数是给运营使用。游戏上线后,我们需要针对线上的问题进行不同的处理。不可能把所有问题都让程序员去处理吧,于是程序员们想到了一个办法,给你们做一个工具,你们爱谁处理谁处理去吧。

  六, 游戏管理工具

  游戏管理工具是一个不断增涨的系统,因为它很多时候是伴随着游戏中遇到的问题而实现的。

  但是根据经验,有一些功能是必须有的,比如:

  服务器管理,主要负责服务器的开启,关闭,服务器配置信息,玩家信息查询;

  玩家管理,比如踢人,封号;

  统计查询,玩家行为日志查询,统计查询,次留率查询,邮件服务,修改玩家数据等。

  根据游戏的不同要求,凡是可以能过工具实现的,都做到游戏管理工具里面。它是针对所有服务器的管理。

  一个好的,全的游戏管理工具,可以提高游戏运营中遇到问题处理的效率,为玩家提供更好的服务。

  七,公共组件

  公共组件是为游戏运行中提供公共的服务。例如:

  充值服务器,我们没必须一个服用一个充值,而且你也不能对外提供多个充值服务器地址,和第三方公司对接,他们绝对不干,这是要疯呀;

  还有运营搞活动时的礼包码;

  还有注册用户的管理,玩家一个注册账号可以进不同的区等。

  这些都是针对所有区服提供的服务,所以要单独做,与游戏逻辑分开,这样方便管理,部署和负载均衡。

  还有SDK的登陆验证,现在手游比较多,与渠道对接里要进行验证,这往往是很多http请求,速度慢,所以这个也要拿出来单独做,不要在游戏逻辑中去验证,因为网络IO的访问时间是不可控制的,http是阻塞的请求。

  所以,综上来看,一个游戏服务器起码有几个大的功能模块组成:

  游戏逻辑工程;

  日志处理工程;

  充值工程;

  游戏管理工具工程;

  用户登陆工程;

  公共活动工程等。

  根据游戏的不同需要,可能还有其它的。所在构架的设计中,一定要考虑到系统的分布式部署,尽量把公共的功能拆出来做,这样可以增强系统的可扩展性。

  服务器端开发的一些建议

  本文作为游戏服务器端开发的基本大纲,是游戏实践开发中的总结。

  第一部分 —— 专业基础,用于指导招聘和实习考核;

  第二部分 —— 游戏入门,讲述游戏服务器端开发的基本要点;

  第三部分 —— 服务端架构,介绍架构设计中的一些基本原则。

  希望能帮到大家!

  一、专业基础

  1.1网络

  1.1.1理解TCP/IP协议

  网络传输模型

  滑动窗口技术

  建立连接的三次握手与断开连接的四次握手

  连接建立与断开过程中的各种状态

  TCP/IP协议的传输效率

  思考:

  请解释DOS攻击与DRDOS攻击的基本原理

  一个100Byte数据包,精简到50Byte, 其传输效率提高了50%

  TIMEWAIT状态怎么解释?

  1.1.2掌握常用的网络通信模型

  Select

  Epoll,边缘触发与平台出发点区别与应用

  Select与Epoll的区别及应用

  1.2存储

  计算机系统存储体系

  程序运行时的内存结构

  计算机文件系统,页表结构

  内存池与对象池的实现原理,应用场景与区别

  关系数据库MySQL的使用

  共享内存

  1.3程序

  对C/C++语言有较深的理解

  深刻理解接口,封装与多态,并且有实践经验

  深刻理解常用的数据结构:数组,链表,二叉树,哈希表

  熟悉常用的算法及相关复杂度:冒泡排序,快速排序

  二、游戏开发入门

  2.1防御式编程

  不要相信客户端数据,一定要检验。作为服务器端你无法确定你的客户端是谁,你也不能假定它是善意的,请做好自我保护。(这是判断一个服务器端程序员是否入门的基本标准)

  务必对于函数的传人参数和返回值进行合法性判断,内部子系统,功能模块之间不要太过信任,要求低耦合,高内聚。

  插件式的模块设计,模块功能的健壮性应该是内建的,尽量减少模块间耦合。

  2.2设计模式

  道法自然。不要迷信,迷恋设计模式,更不要生搬硬套

  简化,简化,再简化,用最简单的办法解决问题

  借大宝一句话:设计本天成,妙手偶得之

  2.3网络模型

  自造轮子: Select, Epoll, Epoll一定比Select高效吗?

  开源框架: Libevent, libev, ACE。

  2.4数据持久化

  自定义文件存储,如《梦幻西游》

  关系数据库: MySQL

  NO-SQL数据库: MongoDB

  选择存储系统要考虑到因素:稳定性,性能,可扩展性

  2.5内存管理

  使用内存池和对象池,禁止运行期间动态分配内存

  对于输入输出的指针参数,严格检查,宁滥勿缺

  写内存保护,使用带内存保护的函数(strncpy, memcpy, snprintf, vsnprintf等)

  严防数组下标越界

  防止读内存溢出,确保字符串以''结束

  2.6日志系统

  简单高效,大量日志操作不应该影响程序性能

  稳定,做到服务器崩溃是日志不丢失

  完备,玩家关键操作一定要记日志,理想的情况是通过日志能重建任何时刻的玩家数据

  开关,开发日志的要加级别开关控制

  2.7通信协议

  采用PDL(Protocol Design Language), 如Protobuf,可以同时生成前后端代码,减少前后端协议联调成本, 扩展性好

  JSON,文本协议,简单,自解释,无联调成本,扩展性好,也很方便进行包过滤以及写日志

  自定义二进制协议,精简,有高效的传输性能,完全可控,几乎无扩展性

  2.8全局唯一Key(GUID)

  为合服做准备

  方便追踪道具,装备流向

  每个角色,装备,道具都应对应有全局唯一Key

  2.9多线程与同步

  消息队列进行同步化处理

  2.10状态机

  强化角色的状态

  前置状态的检查校验

  2.11数据包操作

  合并, 同一帧内的数据包进行合并,减少IO操作次数

  单副本, 用一个包尽量只保存一份,减少内存复制次数

  AOI同步中减少中间过程无用数据包

  2.12状态监控

  随时监控服务器内部状态

  内存池,对象池使用情况

  帧处理时间

  网络IO

  包处理性能

  各种业务逻辑的处理次数

  2.13包频率控制

  基于每个玩家每条协议的包频率控制,瘫痪变速齿轮

  2.14开关控制

  每个模块都有开关,可以紧急关闭任何出问题的功能模块

  2.15反外挂反作弊

  包频率控制可以消灭变速齿轮

  包id自增校验,可以消灭WPE

  包校验码可以消灭或者拦截篡改的包

  图形识别码,可以踢掉99%非人的操作

  魔高一尺,道高一丈

  2.16热更新

  核心配置逻辑的热更新,如防沉迷系统,包频率控制,开关控制等

  代码基本热更新,如Erlang,Lua等

  2.17防刷

  关键系统资源(如元宝,精力值,道具,装备等)的产出记日志

  资源的产出和消耗尽量依赖两个或以上的独立条件的检测

  严格检查各项操作的前置条件

  校验参数合法性

  2.18防崩溃

  系统底层与具体业务逻辑无关,可以用大量的机器人压力测试暴露各种bug,确保稳定

  业务逻辑建议使用脚本

  系统性的保证游戏不会崩溃

  2.19性能优化

  IO操作异步化

  IO操作合并缓写 (事务性的提交db操作,包合并,文件日志缓写)

  Cache机制

  减少竞态条件 (避免频繁进出切换,尽量减少锁定使用,多线程不一定由于单线程) 多线程不一定比单线程快

  减少内存复制

  自己测试,用数据说话,别猜

  2.20运营支持

  接口支持:实时查询,控制指令,数据监控,客服处理等

  实现考虑提供http接口

  2.21容灾与故障预案

  略

  三、服务器端架构

  3.1什么是好的架构?

  满足业务要求

  能迅速的实现策划需求,响应需求变更

  系统级的稳定性保障

  简化开发。将复杂性控制在架构底层,降低对开发人员的技术要求,逻辑开发不依赖于开发人员本身强大的技术实力,提高开发效率

  完善的运营支撑体系

  3.2架构实践的思考

  简单,满足需求的架构就是好架构

  设计性能,抓住重要的20%, 没必要从程序代码里面去抠性能

  热更新是必须的

  人难免会犯错,尽可能的用一套机制去保障逻辑的健壮性

  游戏服务器的设计是一项颇有挑战性的工作,游戏服务器的发展也由以前的单服结构转变为多服机构,甚至出现了bigworld引擎的分布式解决方案,最近了解到Unreal的服务器解决方案atlas也是基于集群的方式。

  负载均衡是一个很复杂的课题,这里暂不谈bigworld和atlas的这类服务器的设计,更多的是基于功能和场景划分服务器结构。

  首先说一下思路,服务器划分基于以下原则:

  分离游戏中占用系统资源(cpu,内存,IO等)较多的功能,独立成服务器。

  在同一服务器架构下的不同游戏,应尽可能的复用某些服务器(进程级别的复用)。

  以多线程并发的编程方式适应多核处理器。

  宁可在服务器之间多复制数据,也要保持清晰的数据流向。

  主要按照场景划分进程,若需按功能划分,必须保持整个逻辑足够的简单,并满足以上1,2点。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读