找回密码
 用户注册

QQ登录

只需一步,快速开始

查看: 5283|回复: 1

如何设计属于自己的游戏服务器(二)

[复制链接]
发表于 2014-10-23 13:50:20 | 显示全部楼层 |阅读模式
很多游戏都在花费大篇幅讲解网络模型,其实,这些对于你而言,完全不必关心,现有的模型一大把。就比如PSS,你用它就可以忽略网络IO模型,直接负责处理到达的数据和如何回应就行了。
那么,我们来说说游戏服务器的一些细节。
以端游为例,现在的端游可以说各种花哨,各种副本,公会战,任务,锻造,跑商等等等等。。系统繁多。
但是请静下心来,拨开那些层层迷雾。
其实游戏服务器没什么神秘的,就几个专业的算法可能比较耗一些功夫,比如,AOI,比如,寻路,比如,脚本。
先不要去想这些实现手段,首先要知道,我们有什么武器?
无论任何游戏,都分为两种消息,一种是客户端主动提交给服务器的,一种是服务器主动下发给客户端的。简单的来说,无外乎,一去一回,一回一去,一去,一回。
一去一回,就是客户端主动发起一个事件,需要得到服务器的回应。
一回一去,就是服务器有事件发生了,需要通知客户端。
一去,客户端只是通知服务器一个事件。不需要回应。
一回,服务器通知客户端一个事件,不需要回应。
很好,先明确这个概念,也就是,服务器和客户端之间的通讯,是一种或者几种事件机制。
网上一些说游戏服务器的文章,说每秒吞吐几万个数据包如何如何性能了得,我很想问问,实际的游戏服务器,你真需要这么大的服务器吞吐量吗?
当然,你可以说,像Dota,星际那种实时对战游戏,对数据包有及是毫秒级的要求,毕竟人家讲的是DPS。但是,我想说的是,大多数游戏,根本不需要这么多的数据包吧。
很多时候,设计是可以优化的,如果我是一个玩家,1秒钟内在地图点击了10个地点,如果控制的小人都去那些地方,光服务器和客户端来回耗时就会很多。先不谈网络优劣的问题。问题是,这些数据有必要服务器去处理吗?
(1)必须先明确,什么是无效的数据和事件。
对,什么是无效的数据。无效的数据很空泛,其实从用户行为分析,你可以分析出用户在你的游戏中,哪些是属于无效操作。客户端主动屏蔽这些无效操作。比如,1秒钟我换了10个方向,那么我只需要取得最后一个防线即可。也就是前9个我完全可以忽略。当然,客户端需要处理一下这为展示。再比如,我反复的打开了商店界面,因为商品在一定时间内是稳定的,那么完全可以过一段时间同步一下商店数据即可。不用每次都发送请求。
不过从实际运行来看,并不是说客户端屏蔽了这些无效操作就可以了。服务器一样要做这些动作,因为你无法约束数据包行为。或许外挂,特殊情况,会有垃圾数据包到来。
就好比,你把服务器看做一个餐厅,进来一批食客,其中保不齐有周围餐馆派来砸场的,你的厨师就那么几位,有些人故意点了一大桌子不吃,害的你的厨师忙死,却让真正想吃饭的食客等不及而离场,这明显是得不偿失的。所以,你的服务器需要一个经验丰富的"侍者",它可以分辨食客的点餐餐单,那些是有明显问题的,比如,有i一个食客连续点了10个宫保鸡丁,你就要看看这个食客到底是要干什么。
服务器的这个"侍者",就是要对客户端上来的各种"餐单"(数据包)进行初步过滤,起码,不能让那些明显处问题的餐单来占据你的服务器资源。
从设计的角度来讲,我可以对某一个用户的数据包进行归类,某一类数据包不能短时间出现多次。如果出现了且非要回复,只取得在这段时间内最新的一个即可,其他的同类数据包丢弃。
我这里要讲一个设计关键原则,就是一定要保证优质的游戏玩家享受最好的服务,而那些质量差的玩家,很少会为你的游戏多付费,所以,想办法保证一切优质客户很重要,服务器的资源也应当倾向于此。
(2)那些是必须现在返回的,哪些是可以等一会再返回的。
很多网络讲游戏服务器的文章,更加更关注的技术的实现细节,而实际上,我们跳出这些繁复的代码。仔细分析一下?哪些是 "立即"和"暂缓"。
还是拿餐厅举例,一般人气火爆的餐厅,大多不会一个客户点一个菜立刻抄一个。抄完了在看下一个餐单。
而是,会等那么一小会,看这一小会会不会有相同的餐单到达,一锅烩,一起出盘。
别小看餐厅的学问,好好的和他们学习,你会学到非常多的服务器设计知识。而且,好的餐厅往往能教你怎么做一个伟大的服务器。
那么,你看,这些餐单,实际是可以"等那么一会也没什么大问题的"。
而有些则是必须马上返回的,比如,食客下了餐单,你必须交给厨房以后迅速的告知食客,你的餐单已经到达了厨房。
拿游戏中的一个实际功能来说,玩家发出一个"行走"指令,实际上,客户端已经可以行走了。服务器只要返回一个收到了即可。只要定时计算服务器和客户端的玩家点位是否匹配即可。有差距拉回来。
而对于服务器,完全可以等那么一等,比如,等1秒,这1秒钟所有的玩家行走指令都收齐了,一个定时器一口气算出来。
或许就有那么讨厌的玩家,连续1秒钟换了3,4个终结点。
换个话说,有哪些餐馆讨厌的食客,刚下单就要换菜品,犹豫不决,如果餐厅没有这个"缓冲"时间,那么做出来的菜谁去消费?明显是浪费食物。(浪费服务器资源)
还有就是,游戏中的交易,必须时时反馈,交易成功了还是失败了,必须第一时间让玩家知道。
餐馆也是这样,结账的时候,食客提出刷卡,如果服务器员说你等会,等到一波食客一起刷,人家不骂你才怪。
所以,从设计上来讲,要学会细分这两项,仔细想清楚,会给你的服务设计带来非常好的体验提升。
(3)如何规划数据流
还是拿网上的文章来说,很多文章在游戏服务器上推崇多线程。
多线程,对于初学者总觉得会很快,而当实际使用的时候,总是发现各种数据需要再不同的线程里同步的问题,造成大量的数据锁,代码复杂了不说,自己估计以后都难以看懂。
所以,这里要说,组织多线程是一门学问。
还是那个餐厅。
我有10个桌子的食客,其中6个点了甜点,有4个点了鱼肉,有7个点了小吃。
如果让一个厨师去做这些菜。肯定会慢的出奇。
看看现实中是怎么解决的?有甜点师,有配菜师,有几个大厨,分别应对不同的菜品。同时去做,各自互不干扰。做鱼的不用知道食客点了多少甜品。
那么,游戏服务器是怎么表现呢?
我有一个玩家进了一个场景,那么理论上,一个场景内,只有这个场景内的玩家会对他产生影响。别的场景都可以不用知道这个玩家的存在。
那么,如果把这个场景看做一个厨师,那么"玩家"实际就是一个个餐单。不同的厨师去料理不同的餐单即可。菜可以同时上,也可以一个个上。
实际上,90%的多线程数据锁,是完全可以用这种或者那种数据模式去解决的。

大自然教会了我们如何生存,也教会了我们,如何用这些规则造福别人。所以,很多程序设计上很难的问题,实际你的生活早就教给了你解决方法,关键是,要学会去发现,去思考。
发表于 2014-12-11 09:52:56 | 显示全部楼层
真正要把服务器写好挣钱,还真的要学学VIP这种服务,花钱的却是是大爷,要好好服务。
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

Archiver|手机版|小黑屋|ACE Developer ( 京ICP备06055248号 )

GMT+8, 2024-3-28 21:16 , Processed in 0.027732 second(s), 10 queries , Redis On.

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表