游戏引擎设计:多人游戏和监听服务器
我的游戏引擎现在由一个可运行的单人游戏部分组成。我现在开始考虑如何进行多人游戏部分。
我发现很多游戏实际上并没有真正的单人游戏模式,但是当你单独玩时,你实际上也在托管一个本地服务器,几乎一切都像多人游戏一样运行(除了数据包可以通过通过替代路线以获得更好的性能)
我的引擎需要进行重大重构才能适应此模型。存在三种可能的模式:专用客户端、专用服务器和客户端-服务器(监听模式)
- 监听-服务器模型在游戏行业中使用的频率如何?
- 它有哪些(缺点)优点?
- 我还有哪些其他选择?
My game engine right now consists of a working singleplayer part. I'm now starting to think about how to do the multiplayer part.
I have found out that many games actually don't have a real singleplayer mode, but when playing alone you are actually hosting a local server as well, and almost everything runs as if you were in multiplayer (except that the data packets can be passed over an alternate route for better performance)
My engine would need major refactoring to adapt to this model. There would be three possible modes: Dedicated client, Dedicated server and Client-Server (listen mode)
- How often is the listen-server model used in the gaming industry?
- What are the (dis)advantages of it?
- What other options do I have?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我会看看我是否能尽力回答这个问题:
当谈到大多数在线游戏时,您会发现绝大多数游戏都使用客户端-服务器架构,尽管并不总是按照您想象的方式。以任何 Source 游戏为例。大多数人将使用具有主服务器架构的标准客户端-服务器(以列出可用的游戏),其中一个人将托管一个专用服务器,任何拥有客户端的人都可以加入它。
然而,有些游戏和服务,例如《Left 4 Dead》、《英雄联盟》和一些 Xbox Live 游戏,采用的方法略有不同。这些都使用带有控制服务器的客户端-服务器架构。这里的主要思想是有人创建一个不“运行”任何游戏的专用服务器。控制服务器将创建某种“大厅”,当游戏开始时,控制服务器会将它们添加到队列中,当轮到该大厅时,它将选择一个匹配的专用服务器(在位置/速度、可用性、众多因素),并将玩家分配到该服务器。只有这样服务器才会真正“运行”游戏。这是相同的想法,但有点简化,因为客户端不需要“选择”服务器,只需加入游戏并让控制服务器完成工作。
当然,最大的客户端-服务器模型是MMO模型,其中一台或多台服务器运行一个处理几乎所有数据和逻辑的持久世界。使用这种模型的一些比较著名的游戏有《魔兽世界》、《无尽的任务》等等。
那么监听服务器在哪里合适呢?说实话,不是那么好,但是,你仍然会发现很多游戏都在使用它。例如,大多数 Source 游戏都允许创建监听服务器,许多 Xbox Live 游戏也这样做(已经有一段时间了,但我相信《反恐精英》、《雷神之锤 4》和许多其他游戏都这样做了)。但总的来说,由于客户端-服务器模型的优势,它们似乎不受欢迎,这让我们想到了下一个要点。
首先也是最重要的:性能。在客户端-服务器模型中,客户端将处理游戏每个周期的本地更改(例如输入、图形、声音等)。在循环结束时,它将打包相关数据(例如,玩家是否移动?如果是,去哪里?她/他现在在看哪里?速度?他们开枪了吗?如果是,则有关子弹的信息。等等)并将其发送到服务器进行处理。服务器将获取此数据并确定所有内容是否有效,例如用户是否以表明黑客行为的方式移动(稍后详细介绍)、移动是否有效(有什么问题吗?)、玩家的子弹是否有效1 击中玩家 2?等等。然后服务器将其打包,并将其发送给客户端,然后客户端更新任何必要的内容,例如如果玩家被射击则调整生命值,如果确定玩家正在黑客攻击则踢玩家等等。
但是,侦听服务器必须同时处理所有这些。由于我假设您熟悉编程,因此您可能会意识到游戏可以从计算机中夺走多少能力,尤其是设计不佳的游戏。添加网络处理、安全处理等以及客户端游戏,您可以看到性能会受到严重影响,至少就标准处理而言是如此。此外,大多数服务器都在快速网络上运行,并且是为承受网络流量而设计的服务器。如果监听服务器的网络速度很慢,整个游戏都会受到影响。
第二个安全性,如前所述,服务器要做的主要事情之一是确定玩家是否正在利用游戏。您可能已经将它们视为 Punkbuster、VAC 等。运行这些程序有一组非常复杂的规则,例如,确定黑客与非常优秀的玩家之间的区别。如果您无法抓住黑客,这对您的游戏来说将是非常糟糕的,但如果您对被错误指控的黑客采取行动,情况会更糟。
侦听服务器通常无法处理客户端的游戏、服务器处理和黑客检测,并且在大多数情况下,像 Punkbuster 这样的检测器很难(如果不是不可能的话)在侦听服务器上运行,因为它是如果没有必要的处理能力,它很难正确运行,因为通常游戏逻辑优先于安全性,如果不允许探测器处理一帧,它可能会丢失定罪某人所需的数据。
最后,游戏玩法。服务器最大的一点就是它们是持久性的,这意味着即使所有人都离开了,服务器也会继续运行。如果您有一个受欢迎的服务器,在夜间没有太多活动,那么人们仍然可以在准备玩游戏时加入,而不必等待服务器重新上线,这非常有用。
在监听服务器中,主要缺点是一旦托管监听服务器的客户端离开,游戏必须转移给另一个玩家(在游戏中创建一个在某些情况下可能持续几分钟的 lul),或者必须完全结束。这在大型服务器上并不可取,因为主机必须要么保持在线(浪费服务器中的插槽和他/她的计算机能力,这也可能减慢游戏速度),要么结束每个人的游戏。
然而,尽管存在这些问题,监听服务器确实有一些优点。
易于设置:大多数监听服务器只不过是点击“新游戏”并让人们加入。对于那些只想和朋友一起玩而不希望尝试找到空的专用服务器或与其他人一起玩的人来说,这很容易。
适合测试:如果拥有专用服务器并希望更改其配置,通常最好首先测试配置。用户要么必须创建专用服务器的备份,然后盲目地进行更改,唯一的选择是在出现问题时回滚,创建一个新的专用服务器来测试它们,或者只创建一个简单的监听服务器测试他们。对于第 1 点,这些通常更容易启动和配置。尤其如此,因为大多数专用服务器不在管理员的直接访问范围内(大多数专用服务器是从远程位置租用的)。将配置更改以及重新启动命令等推送到远程位置比管理员当前所在的计算机花费的时间要长得多。
资源较少:在大多数专用服务器中,具有相同IP的用户无法连接到专用服务器(这意味着客户端必须要么托管服务器,要么玩游戏,不能两者兼而有之)。如果客户希望在他/她自己的服务器上玩游戏,他们通常需要第二台机器来托管服务器,或者购买或租用一个专用服务器,以便他们可以实际在上面玩游戏。监听服务器只需要一台机器,这可能是客户端唯一可以使用的东西。
无论哪种情况,两者都有优点和缺点,您需要根据您愿意设计和实现的内容来权衡它们。根据我的经验,我相信,如果您要实现一个侦听服务器,那么它会被使用,即使只是为了一些希望与朋友一起玩或测试设置的用户。
最后:
这是一个工业蠕虫罐头。实际上,任何类型的网络架构都可以应用于视频游戏。然而,据我所知,就像大多数互联网通信一样,大多数都归结为某种形式的客户端-服务器模型。
如果我没有回答您的问题,或者您需要扩展一些内容,请告诉我,我会看看我能做些什么。
I'll see if I can answer this the best I can:
When it comes to most online games, you'll find that a large majority of games use a client-server architecture, though not always in the way you think. Take any Source game, for instance. Most will use a standard client-server with a master server architecture (to list games available), in that one person will host a dedicated server and anyone with a client can join it.
However, you have some games and services, take for instance Left 4 Dead, League of Legends, and some XBox Live games, that take a slightly different approach. These all use a client-server architecture with a controlling server. The main idea here is that someone creates a dedicated server that isn't "running" any game. The controlling server will create a "lobby" of sorts, and when the game is started, the controlling server will add them to a queue, and when it is that lobby's turn, it will select a matching dedicated server (in terms of location/speed, availability, numerous factors), and assign the players to that server. Only then will the server actually "run" the game. It's the same idea, but a little simplified, as the client doesn't need to "pick" a server, only join a game and let the controlling server do the work.
Of course, the biggest client-server model is the MMO model, where one or many servers runs a persistent world that handles almost all data and logic. Some of the more famous games using this model are World of Warcraft, Everquest, anything like that.
So where does a listen server fit in here? To be honest, not really that well, however, you will still find many games using it. For instance, most Source games allow listen servers to be created, and many XBox Live games do (it's been a while, but I believe Counter Strike did, as well as Quake 4, and many others). In general though, they seem to be frowned upon due to the advantages of the client-server model, which brings us to our next point.
First and foremost: performance. In a client-server model, the client will handle local changes (such as input, graphics, sounds, etc) on each cycle of the game. At the end of the cycle, it will package up relevant data (such as, did the player move? If so, where to? Where is s/he looking now? Velocity? Did they shoot? If so, information on the bullet. Etc) and send that to the server for processing. The server will take this data and determine if every thing is valid such as, is the user moving in a way that indicates hacking (more on that later), is the move valid (anything in the way?), did the bullet from player 1 hit player 2?, and more. Then the server packages this up, and sends it to the clients, which then update whatever necessary, such as adjusting health if the player was shot, kicking the player if it is determined that they are hacking, etc.
A listen server, however, must deal with all of this at the same time. Since I assume you are familiar with programming, you probably realize how much power a game can rob from a computer, especially a poorly designed one. Adding on network processing, security processing, and more as well as the client's game, you can see where performance would take a serious hit, at least as far as just standard processing goes. Furthermore, most servers run on fast networks, and are servers designed to withstand network traffic. If a listen server's network is slow, the entire game will suffer.
Second security, as stated earlier, one of the main things a server will do is determine if a player is exploiting the game. You may have seen these as Punkbuster, VAC, etc. There are a very complicated set of rules that run these programs, for instance, determining the difference between a hacker, and just a very good player. It would be very bad for your game if you weren't able to catch hackers, but even worse if you executed action against a falsely accused one.
A listen server will generally not be able to handle the client's game, the server processing, and the hack detection, and in most cases, detectors like Punkbuster are very hard to, if not impossible to get to run on a listen server, because it's hard for it to function correctly without the necessary processing power, as generally the game logic is prioritized over security, and if the detector is not allowed to process for one frame it may lose the data it needed to convict someone.
Lastly, gameplay. The biggest thing about servers is that they are persistent, meaning that even if everyone leaves, the server will continue to run. This is useful if you have a popular server that doesn't have much activity in the night time, people can still join when they are ready to play and not have to wait for it to be brought back online.
In a listen server, the main disadvantage is that as soon as the client hosting the listen server leaves, the game must either be transferred to another player (creating a lul in the game that can last minutes in some cases), or must end completely. This is not preferable on a big server, as the host must either stay online (wasting a slot in the server, and his/her computer power, which could also slow the game), or end the game for everyone.
However, despite these problems, listen servers do have a few advantages.
Easy to set up: Most listen servers are nothing more than hitting "New game" and letting people join. This is easy for people who just want to play with their friends, and don't wish to have to try to find an empty dedicated server, or play with other people.
Good for testing: If one owns a dedicated server and wishes to change it's configuration, it is generally a better idea to test the configuration first. The user would either have to create a backup of the dedicated server and go blindly into the changes, with the only option being to roll back if something goes wrong, create a new dedicated server to test them, of just create a simple listen server to test them. And in with point 1, these are generally easier to start up and configure. This is especially true, as most dedicated servers are not within the administrators immediate access (most dedicated servers are rented from a remote location). It takes much longer to push configuration changes, as well as commands for restarting, etc, to a remote location than a machine that the administrator is currently on.
Less resources: In most dedicated servers, a user with the same IP cannot connect to the dedicated server (meaning, the client must either host the server, or play, they cannot do both). If the client wishes to play on his/her own server, they will usually need a second machine to host the server, or buy or rent a dedicated server so that they can actually play on it. A listen server requires only one machine, which may be the only thing the client can use.
In either case, both have advantages and disadvantages, and you need to weigh them with what you're willing to design and implement. From my experience, I believe that if you were to implement a listen server it would get used, if for nothing else than for a few users wishing to play around with friends, or test settings.
Lastly:
This is an industrial can of worms. In reality, any type of network architecture can be applied to video games. However, from what I've seen, like most internet communication, most boil down to some form of client-server model.
Please let me know if I didn't answer your question, or if you need something expanded, and I'll see what I can do.