具有物理功能的 2D 游戏的多人游戏/网络选项
摘要：
我的 50% 成品 2D 横向卷轴游戏以 Box2D 作为物理引擎，最终版本应该支持多人游戏。然而，当前的代码只是一个单人游戏。
- 我现在该怎么办？
- 更重要的是，我应该如何实现多人游戏并将其与单人游戏结合起来？
- 将单人游戏模式与多人游戏模式分开进行编码是一个坏主意吗（就像 Notch 在 Minecraft 中所做的那样）？
单人游戏中的性能应该尽可能好（使用环回服务器来模拟物理来实现单人游戏模式将是一个问题）
完整背景/问题：
我正在开发一个相对较大的 2D 游戏C++ 项目，以物理为核心元素。 （我为此使用 Box2D）
完成的游戏应该具有完整的多人游戏支持，但是我犯了一个错误，我没有正确规划网络部分，并且到目前为止基本上都在单人游戏上工作。
我认为多人游戏支持可以以一种相对简单和清晰的方式添加到即将完成的单人游戏中，但显然，从我所读到的情况来看，这是错误的。
我什至读到，多人游戏应该从一开始就被编程为一个游戏，单人游戏模式实际上只包括托管一个不可见的本地服务器并通过环回连接到它。 （我发现大多数 FPS 游戏引擎都是这样做的，Source 就是一个例子）
所以我在这里，带着我的半成品 2D 横向卷轴游戏，我真的不知道如何继续。
现在，仅仅继续在单人游戏/客户端上工作对我来说似乎毫无用处，因为我以后还必须重新编码和重构。
首先，向可能遇到这种情况的任何人提出一个一般性问题：
- 我应该如何进行？
然后，更具体的一个 - 我一直在试图找出如何处理我的游戏的网络部分：
- 单人游戏的隐形/环回服务器
这将具有单人游戏和多人游戏模式之间基本上没有区别的优点。不需要太多额外的代码。
一个很大的缺点：单人游戏中的性能和其他限制。将运行两个物理模拟。一种用于客户端，另一种用于环回服务器。
即使您通过为来自环回服务器的数据提供直接路径（例如通过线程直接通信）来解决问题，单人游戏也会受到限制。
这是一个问题，因为应该允许人们同时玩弄大量物体。
- 独立的单人游戏/多人游戏模式
单人游戏模式不会涉及服务器。
我不太确定这会如何运作。但至少我认为会有很多额外的工作，因为所有单人游戏功能都必须重新实现或粘在多人游戏模式上。
- 多人游戏模式作为单人游戏的模块
这只是我的一个快速想法。多人游戏可以由单人游戏组成，加载附加的网络模块并连接到服务器，该服务器发送和接收数据并更新单人游戏世界。
回想起来，我很遗憾没有早点规划多人模式。我真的很困惑，我希望这里有人能够帮助我！
Summary:
My 50% finished 2D sidescroller with Box2D as physics engine should have multiplayer support in the final version. However, the current code is just a singleplayer game.
- What should I do now?
- And more important, how should I implement multiplayer and combine it with singleplayer?
- Is it a bad idea to code the singleplayer mode separated from multiplayer mode (like Notch did it with Minecraft)?
The performance in singleplayer should be as good as possible (Simulating physics with using a loopback server to implement singleplayer mode would be a problem there)
Full background / questions:
I'm working on a relatively large 2D game project in C++, with physics as a core element of it. (I use Box2D for that)
The finished game should have full multiplayer support, however I made the mistake that I didn't plan the networking part properly and basically worked on a singleplayer game until now.
I thought that multiplayer support could be added to the almost finished singleplayer game in a relatively easy and clear way, but apparently, from what I have read this is wrong.
I even read that a multiplayer game should be programmed as one from the beginning, with the singleplayer mode actually just consisting of hosting an invisible local server and connecting to it via loopback. (I found out that most FPS game engines do it that way, an example would be Source)
So here I am, with my half finished 2D sidescroller game, and I don't really know how to go on.
Simply continueing to work on the singleplayer / client seems useless to me now, as I'd have to recode and refactor even more later.
First, a general question to anybody who possibly found himself in a situation like this:
- How should I proceed?
Then, the more specific one - I have been trying to find out how I can approach the networking part for my game:
- Invisible / loopback server for singleplayer
This would have the advantage that there basically is no difference between singleplayer and multiplayer mode. Not much additional code would be needed.
A big disadvantage: Performance and other limitations in singleplayer. There would be two physics simulations running. One for the client and one for the loopback server.
Even if you work around by providing a direct path for the data from the loopback server, through direct communcation by the threads for example, the singleplayer would be limited.
This is a problem because people should be allowed to play around with masses of objects at once.
- Separated singleplayer / Multiplayer mode
There would be no server involved in singleplayer mode.
I'm not really sure how this would work. But at least I think that there would be a lot of additional work, because all of the singleplayer features would have to be re-implemented or glued to multiplayer mode.
- Multiplayer mode as a module for singleplayer
This is merely a quick thought I had. Multiplayer could consist of a singleplayer game, with an additional networking module loaded and connected to a server, which sends and receives data and updates the singleplayer world.
In the retrospective, I regret not having planned the multiplayer mode earlier. I'm really stuck at this point and I hope that somebody here is able to help me!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为Notch感受到了分别开发SP和SMP的痛苦。特别是自从他告诉 Bukkit 开发团队他计划过渡到“单人游戏本地服务器”方法（正如您所说，如源引擎）。
您没有理由必须运行多个物理模拟，延迟本地服务器和客户端之间的延迟可以忽略不计，可以完全禁用滞后补偿。
此时您可以使用两种基本模型：
一个专用的服务器程序，它负责游戏的所有大脑并让客户端进行连接。
一个监听服务器，其中游戏基本上可以充当服务器或客户端，具体取决于用户设置。没有单独的服务器程序。
制作客户端的最简单方法是向您的对象添加“虚拟”标志，以便这些虚拟对象将直接由服务器控制。然后，进入插值。 （以 60 Hz 传输对象更新是不现实的，因此点之间的平滑使事情看起来仍然不错。Source 通过添加一点人为延迟来实现这一点，如果您曾经在低于标准的互联网连接上玩过 GTA4 多人游戏，您可以看到效果在快车上过度。）
此外，建议阅读：
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
I think Notch is feeling the pain of developing SP and SMP separately. Especially since he told the Bukkit development team that he was planning to transition to the "local server for single player" approach (As you said, like the Source Engine.)
There is no reason you have to have multiple physics simulations running, the latency between the local server and the client would be negligible, the lag compensation could be completely disabled.
There are two basic models you could go off of at this point:
A dedicated server program which does all the brains of your game and lets clients connect.
A listen server where a game can basically act as a server or a client depending on the user setting. There is no separate server program.
The easiest way to make a client would be to add "dummy" flags to your objects so those dummies will be controlled directly by the server. Then, move into the interpolation. (Transmitting object updates at 60 Hz is unrealistic, so smoothing between points makes things still look nice. Source does this by adding a little artificial lag, if you've ever played GTA4 Multiplayer on a sub-par internet connection you can see the effect being overdone on fast cars.)
Also, recommended read:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
您可以使用哑渲染终端方法。优点是集成起来相对容易，无需从一开始就将其设计到您的引擎中。缺点是无法使用预测技术补偿延迟，并且如果有许多可见对象，则带宽可能会很高。
一种想法是将游戏状态及其演变与图形分开。因此，每一帧您都将游戏状态转换为图形表示（剔除屏幕外的内容）。然后，在单人游戏中，您可以直接渲染它，而在多人游戏中，您可以通过网络发送该图形表示。并将输入通过网络发送到服务器。
其效果如何取决于绘制对象的数量以及它们的图形描述的复杂程度。但对于 2D 游戏来说，这个描述通常相当小。
我希望它在 LAN 中运行良好，因为它具有良好的延迟和带宽。不知道它在互联网上的效果如何。
这是一个描述虚幻网络代码如何工作的文档。并在引言中描述了几种更简单的方法。您可能想要实现其中之一。
http://unreal.epicgames.com/Network.htm
You could use the dumb render terminal approach. The advantage is that it's relatively easy to integrate without designing it into your engine from the start. The disadvantage is that latency won't be compensated using prediction techniques, and if there are many visible objects the bandwidth might be high.
One idea is separating the game-state and its evolution from the graphic. So each frame you translate the game-state into a graphic representation (culling offscreen stuff). Then in single-player you render that directly, and in multiplayer you send that graphic representation over the network. And sent the input over the network to the server.
How well that works depends on the number of drawn objects and how complex their graphic description is. But that description is usually rather small for 2D games.
I expect this to work well in a LAN since that has good latency and bandwidth. No idea how well it works over the internet.
Here is a document describing how the unreal network code works. And in the introduction in describes several simpler approaches. You might want to implement one of those.
http://unreal.epicgames.com/Network.htm