What should I keep in mind when developing a game to be multiplayer?

Question

I am making 2d game, and it will be a game where players can move on in a 2D world and there will be physics with projectiles and such.

So far, I don't have much, just a tile engine a few other things.

But this game is going to be fully multiplayer, and I've never made a multiplayer game before. Obviously I can't be making multiplayer as I develop the game, I kind of have to make it and then hope it works once I add multiplayer.

So my question is, is there anything I should keep in mind when developing this game to be multiplayer? I'm not asking, how to make it multiplayer, thats a whole other question. I just don't want to have to re-develope everything because I did something wrong that does not work with multiplayer?

Edit: Also, as a side question, do you have any advice on what general order to create the game, and when to add multiplayer?

Answer 1

I think the basic answer here is to expect to "have to redevelop everything" when you add networking.

Adding networking will touch almost every part of your game - both code and design.

A lot of the difficulty comes down to dealing with latency (there's also things like packet-loss and out-of-order packets). If your game is real-time, you'll want to "hide" these network realities from the user.

Code-wise, this (in an extremely abstract sense) means making your simulation tolerant of inconsistencies - and then introducing a bunch of them. I can't really get any more specific than that without going into a very long and detailed discussion of how game networking works.

That that basically describes the same dilemma that you face: You can't guess at how to make your simulation network-ready without having a full understanding of how game networking works (and how it relates to your game specifically). And the way to fully understand it is to implement it.

Design-wise it's a similar story. There are several classes of gameplay ideas that will not work due to latency. Just one example is any competition where one player can be first, with immediate feedback and split-second timing. Player A might be 100ms slower than player B to hit a button - but because they are separated by 400ms of latency - they both think they won. So if your gameplay contains any scenarios like that, you would have to re-design them.

To summarise: It's perfectly valid to write a single-player game first and then add multiplayer later. One benefit of this strategy is that you get a working single-player game earlier. However, if you go down this route, then expect to have to treat your single-player game like a throw-away prototype when it comes time to make a networked version.

(Trying the opposite path - trying to account for networking without actually implementing it - is a gross violation of YAGNI.)

It's worth finishing by pointing out that making a networked game is easily an order of magnitude more difficult than making non-networked game.

Answer 2

There are generally two ways to implement networking on a high level: Either, you always get the perfect status of every object in your proximity, or you get the actions objects want to perform.

First one can easily be described by using MMORPG as example. You have a character, and the server always tells you what's going on. This means constantly getting positions and state for all objects around you. So the player's end is just a dumb client showing everything. While this will seem much easier than the solution presented below, this have some major drawbacks. This will use a huge amount of network traffic if not planned and executed properly. This will also easily allow cheating if you don't verify the data by the user's somewhere. If you have client/server architecture the clients can be dumb and just show what's given by the server. But the server will either need to apply the technique below for the data received by the players, or verify that their actions are legal. If this is used in a P2P situation, you will have a much harder time detecting cheating.

The second one is how they did the Age of Empires. See this link for some good reading. In this case, each user is sent what the other user's are trying to do. For instance in AoE, each frame sending over the position and state of thousands of units would be a bad idea. If you instead are sent the actions taken by the player it will be much less data. As this will only be some actions per second. Then you will have to take those actions and apply them to your running game. Here you will need good planning to not make the games on different computers get out of synx.

You should fix your timestep if your game has physics or some kind of simulation that depends on it. Otherwise the game will go out of sync fast. Remember that even the slightest difference in the beginning can be huge in the end. The Butterfly Effect. For instance, a can being thrown landing a bit shorter on one of the player's running game. This again will affect the AI on his end, and suddenly he is playing a different match than the others. Read this article about fixing your timestep.

For a big MMO like World of Warcraft this second solution would be bad, as each player has to be running his own server and get the actions for every person logged on. But for games like FPS and RTS with P2P this rocks.

Gafferon has also some good tutorials on networking for game programmers, check them out. Just note that some of his arguments only hold for the kind of game he is talking about. There's a big difference in MMORPG networking and FPS networking.