Multiplayer / Networking options for a 2D game with physics

Question

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!

Answer 1

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

Answer 2

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