Multiplayer / Networking Features for a 2D Physics Game

Question

Summary:

My 50% complete 2D scroller with Box2D as a physics engine should have multi-user support in the final version. However, the current code is just a one-player game.

• What should I do now?
• And more importantly, how do I implement multiplayer and combine it with singleplayer?
• Is it a good idea to encode singleplayer mode, separate from multiplayer mode (e.g. Notch did this with Minecraft)?

Performance in a single player should be as good as possible (simulating physics using a loopback server to implement singleplayer mode would be a problem)

Full background / questions:

I am working on a relatively large 2D game project in C ++, with physics as its main element. (I use Box2D for this)

The finished game should have full support for the multiplayer game, however I made a mistake that I did not plan the network part correctly and basically worked on the single-player game so far.

I thought that multiplayer support could be added to an almost finished single-player game relatively easily and clearly, but from what I read it seems to be wrong.

I even read that a multiplayer game should be programmed as one from the very beginning, and singleplayer mode actually consists only of hosting an invisible local server and connecting to it via loopback. (I found that most FPS engines do it this way, as an example, Source)

So here I am, with my half-finished 2D scrolling, and I really don't know how to do this.

Just continuing to work on singleplayer / client is now useless for me now, as I will have to transcode and reorganize even later.

Firstly, a general question for anyone who is in this situation:

• How do I proceed?

Then, more specific - I tried to figure out how I can approach the network part for my game:

• Invisible / loopback server for single player

This will have the advantage that, in principle, there is no difference between singleplayer mode and multiplayer mode. No additional code required.

Big flaw: performance and other limitations in a single player. There will be two physics simulators. One for the client and one for the loopback server.

Even if you work by providing a direct path for data from the loopback server, through direct switching by streams, for example, a single player will be limited.

This is a problem because people need to be allowed to play with masses of objects at the same time.

• Split single player / multiplayer mode

In single player mode, there will be no server.

I'm not sure how this will work. But at least I think that there will be a lot of extra work, because all singleplayer functions need to be reimplemented or glued to multi-user mode.

• Multiplayer mode as a module for a single player

This is just a quick thought. Multiplayer can consist of a single-player game, with an additional network module loaded and connected to a server that sends and receives data and updates the world with one player.

In retrospect, I regret that I had not planned a multiplayer mode before. I am really stuck at this point, and I hope someone here can help me!

Answer 1

I think Notch is in pain from developing SP and SMP separately. Moreover, he told the Bukkit development team that he plans to switch to the "local server for a single player" approach (as you said, for example, Source Engine).

There is no reason why you should work with several physical simulators, the latency between the local server and the client will be insignificant, delay compensation can be completely disabled.

At the moment, there are two main models: A special server program that makes all the brains of your game and allows clients to connect. A listening server where the game can basically act as a server or client depending on user settings. There is no separate server program.

The easiest way to make a client is to add dummy flags to your objects so that these mannequins are controlled directly by the server. Then go to interpolation. (Sending object updates at 60 Hz is unrealistic, so smoothing between points makes things still enjoyable. The source does this by adding a slight artificial lag if you ever played GTA4 Multiplayer when connected to a sub-Internet connection, you can see the effect of being exaggerated on fast cars.)

It is also recommended that you read: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Answer 2

You can use the mute output visualization approach. The advantage is that it is relatively easy to integrate without prior design into your engine. The disadvantage is that latency will not be compensated using prediction methods, and if there are many visible objects, the bandwidth can be high.

One idea is to separate the game state and its evolution from the graph. Thus, each frame converts the game state into a graphical representation (rejecting the screen saver). Then in a single player you visualize it directly, and in multiplayer you send this graphical representation over the network. And sent the network login to the server.

How well this works depends on the number of drawn objects and the complexity of their graphic description. But this description is usually quite small for 2D games.

I expect this to work well on the local network as it has good latency and bandwidth. I don’t know how well it works over the Internet.

---

Here is a document describing how unreal network code works. And the introduction describes several simpler approaches. You might want to implement one of them. http://unreal.epicgames.com/Network.htm