Im making my way here towards my first "real" game, a nethack inspired rpg game. The very first game I did actually complete was a snake clone (that little game found on mobile phones :P) the rest have just been SDL "demos". However, as I was walking around in my dungeon in the first version of some very early alpha, I thought... multiplayer is dead fun. :P I wanted it to be possible for me and a couple of friends to run around in that dungeon together. I looked around here on GameDevs articles and saw that most of them were about lag reducing techniques. And I must admit, I feel quite intimidated my the subject, Ive always thought that a good networking program was the utterly most challenging thing you could possible write. Is that the truth? Or do you think I could make something that just lets the client mapvector sync with the server mapvector? Or is it so hard that I shouldnt even go to google and type "absolute beginner winsock tutorial"? :P It was quite hard to write a topic like this to, I didnt want to come across as one of the "I have this über idea of an mmo that lets you do anything you want!". Comments?

Networking is not the hardest thing to code.
Following some tutorials in the FAQ is a good place to start. After learning how to get server/client working with another application (maybe a small chat program), you could design a method to implement it into your game.

Q1 of the FAQ has links to some tutorials for Winsock and Unix sockets.
Q8 of the FAQ has links to other libraries which should make coding easier.

If you use TCP, make sure to read Q14 of the FAQ as well, which will give you a hint about how to design sending/receiving of data.

Other questions in the FAQ might be important depending on where you are at in development :)

As long as your topic doesn't start with, "I have this dream to start the most uber MMORPG evar but I don't know whether I can write the networking part in &#106avascript. Would Visual Basic be better?" you won't come as one of those newbies.

I recommend taking a look at the library raknet I haven't used it but have heard a lot of good things and looked at the documentation, it looks fairly easy to set up. Unless of course you want to code it all yourself.

Gathering from the answers it doesnt seem impossible at least. [smile] Ill look at the FAQ again, must have missed some parts there obviously.

@Alpha_ProgDes: Yes I am. But Im not tackling many subjects at once, Im merely deciding which to tackle next. ;) First, I wrote a tileengine, when it was working, I wrote a sprite system (animations and such). I could now walk around on a tilemap. :) Last night I finished my A* algorithm so that monsters can walk around, they dont have any behaviour yet though. :P And now, Im thinking of either making the game more "gamey" or implent network support right away.

hplus0603:
What part of developing a multiplayer game would you find harder than developing a graphics engine? I've read that designing a good reliable protocol yourself on top of udp would be challeging (well at least to get it right that is) and that covering up for latency in games that rely heavily on physics is very hard. But I've only read about this as given "facts", maybe you have concrete examples that would really explain why?

Lets give an example of one of the simplest games: pong.

The clients first have to find a way to synchronize a timer, and decide when the game starts, where the ball will be placed on the field, and it's initial velocity.

So far, so good. As long as their initial time has been set up ok, the ball will move exactly the same on both machines. As long as neither player actually moves his paddle.

The trouble starts when we actually have player input:

Lets say both clients have a 400ms ping to each other. Data from one player will take 200 ms to get to the other player (ignoring now latency induced by game loop time, order of send/recieve, and input, etc.., which is another issue the network programmer has to deal with)

So player 1 see's the position of player 2 as 200ms old.

Who controls the movement of the ball? If the ball is coming at player 2, and player 2 just barely manages to hit the ball, what will player 1 see?

Well, since player 1 sees an 200ms old version of player 2, he will see a goal, but player 2 will see a block.

The game has just diverged, we need to deal with this somehow.

We can say that player1 owns the ball, and his view of the ball is authorative. In this case, player1 will send updates telling player2 where the ball is. These updates however, are 200 ms old. So player2 will be aiming his paddle at where the ball was in the past, not where it is now. Not to mention he needs to send his paddle position back to player1 who is simulating the ball. This means that player2's response time gets decreased by 400MS! that makes the game unplayable.

We could choose to do client side prediction on the ball, to guess where it will go based on it's current velocity, so we can calculate It's actual current position. With this methos we only have response time decreased by 200ms, but thats still a lot. But that only helps us if the ball is going towards our paddle. What happens if it's going towards player1's paddle. He can move and stop his paddle quickly. We can try to predict his paddle position, but it won't nessecarily be correct. If we predict the position of the ball, as well as the oppondets paddle, and overpredict the position of his paddle, yet again our simulation can diverge, where we think we have scored, but he has really blocked it.

We could choose to make player1 owner of the entire board, and just send him our controller input. If we turned off prediction, What we see on the screen would be the actual gamestate (200ms ago) but we wouldn't run into any divergent simulation problems. BUT our paddle would take 400ms before we saw it respond to our controller input.. Way too sluggish to be playable.

How do you hide this latency and make the game playable for both players, and fair for both players? And this is an extremely simple game.. Now add a nondeterministic physics engine and multiple AI agents and players. The problem becomes more complicated the more things are added. This is the high level problem that the network programmer has to deal with.

At lower levels we have to deal with MTU's and aggregation intervals. We neet to keep payload to header ratios high (which involves aggregation, which adds latency) in order to keep bandwidth down. We need to make sure that we can deal with lost data, or data that is sent twice. We need to do advanced compression and bit packing to keep bandwidth low. We have to interpolate discrete samples and make them look good over the network, handpicking different algorithms sometimes for different unit types based on their behavior. The toolset we use to make things looks good is the same as the graphics programmers use: vectors, quaternions, splines. I've done a lot of really advanced DSP work for voice chat in game, to reduce jitter and blend samples. Network touches more code than most people probably realise.. The animation, and game state machines; The locomotion engine; The physics system; The sound system; The scripting system, even graphics and UI at times.

Networking is a very problem solving oriented field. Much less can be accomplished by taking a formula, or shader out of a book and plopping it into the code for a new effect. Soultions must be hand coded for each game. Every game I have worked on has had a different approach for network, because each game has different properties, and different issues to deal with.

Now this isn't to say that graphics engine programming isn't hard, it is. I'm just saying that it seems much more emphasis is put on graphics than other fields. Networking is one that has so many layers, and so much intricacy at each layer. This is one of the reasons why you see "network programmer" as a seperate position in game job advertisements. It's one of those fields, like graphics programming, that requires specialization in order to be good.

I think one of the reasons people don't appreciate the difficulty of the network programmer, is because the issues are very sublime. The sort of things that sneak up behind you and hit you over the head when you are 3/4 of the way through writing your game. I think anyone who has ever actually networked thir game can appreciate this ;)