Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Based on Why is so hard to develop a MMO?:

Networked game development is not trivial; there are large obstacles to overcome in not only latency, but cheat prevention, state management and load balancing. If you're not experienced with writing a networked game, this is going to be a difficult learning exercise.

I know the theory about sockets, servers, clients, protocols, connections and such things.

Now I wonder how one can learn to write a network game:

  • How to balance load problems?
  • How to manage the game state?
  • How to keep things synchronized?
  • How to protect the communication and client from reverse engineering?
  • How to work around latency problems?
  • Which things should be computed local and which things on the server?
  • ...

Are there any good books, tutorials, sites, interesting articles or other questions regarding this?

I'm looking for broad answers, but specific ones are fine too to learn the difference.

share|improve this question
4  
Yes, there are books, tutorials, sites, interesting articles and other questions regarding this. –  Ricket Jul 14 '10 at 21:49
1  
I added bounty to push the question without modifying it and give users a reason to answer as this question deserves answers, thus the best answerer gets reputation for their work but there is not a single answer which answers the question. –  Tom Wijsman Jul 28 '10 at 15:06
add comment

closed as not a real question by Tetrad Jan 21 '12 at 20:56

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

6 Answers

In addition to the article linked in other answers, I can tell a bit about the experience of the Arianne Project.

How to keep things synchronized?

We have build framework „Marauroa“ around the concept of actions and perceptions: Actions are sent from the client to the server carrying user input like (walk left, attack monsters #47, say 'hello'). And perceptions are sent from the server to the clients telling them about the state of the world closely around them. Those perceptions are sent every turn. Depending on the game we use turn times of 30ms to 300ms.

We have two types of perceptions: A full perception is sent on login and when the player enters a new area (zone). After that differential perceptions are sent including only the modified attributes (e. g. position) of the modified objects, and of course new and removed objects.

How to work around latency problems?

We strongly belief in “the server is always right”. The client does some predictions like smooth walking, collisions checks and so on. But if a client and the server disagree about something, the server wins. The subproject Stendhal (a 2D RPG) uses a turn time of 300ms by default (with a lot of smoothing done client side). This makes Stendhal very resistant against lag.

Note: Some other games trust the client to some extend to minimize the impact of network lag. In WoW it was often exploited in one of the battle field called “Warsong Gulch”. There are two ways which a player with the flag can choose: On in the middle through a tunnel and one on the right sight going up the hill. So a cheating player runs towards the tunnel, and then causes lag for himself. The server and the other clients will continue to see him running towards it. But after a little time this client can tell the server that it went towards the hill. WoW will check that the distance between the last transmitted coordinates and the current ones fits within the time segment and accept that.

Use of UDP vs. TCP

In early versions we used UDP to reduce the overhead of TCP. We handled lost packets on our own. This worked perfectly at the early days of the project. But when the server was moved from some home DSL connection to a real data center several years ago, we got huge issues. UDP is (or at least was 5 years ago) extremely demanding on CPU power of firewall hardware: The ruleset has to be applied to every single UDP packet. For TCP, however, the ruleset is only applied for the first 3 packets. After that the connection is established. All following packets will bypass the normal ruleset because they are in the connecting tracking table or because they don't have a SYN flag.

How to protect the communication and client from reverse engineering?

Arianne is completely open source, this include the client, server, graphics, music. And of course that includes our protocol documentation and even an analyzer used for debugging.

It is easy to protect the communication against unauthorized sniffing by third parties using SSL.

It is, however, impossible to protect it against reverse engineering. Sure you can obfuscate it and use anti debugging techniques. But in the end you cannot prevent reverse engineering of software you give away to users. There is a very interesting presentation on how Skype was reversed engineered despite the developers putting a lot of effort into anti debugging techniques: http://recon.cx/en/f/vskype-part1.pdf

Note: There are some countries in which reverse engineering is illegal or which allow to put a paragraph into the license or ToS disallowing reverse engineering. But there are other countries (like the one I am living in) which explicitly allow reverse engineering in the context of developing compatible data storage formats or transmissions protocols, paragraphs in the license or ToS trying to disallow that are void. (Everything in this section is as far as I know, I am not a lawyer)

Which things should be computed local and which things on the server?

We compute everything related to the game logic on the server. The client will predict certain events in order to make the game play smoothly. But in the end the server is always right.

Predicted events are for example stopping of movement when a collision is hit. Stendhal uses a grid to position elements. And from the server point of view, the top left corner of every entity is on exactly one square. But the client will move them around smoothly between tiles. It will draw the pseudo 3d effect, too. So an entity that has a base of 1x1 may be higher in the client.

How to balance load problems?

Try to keep this as simple as possible, to ease maintenance.

Load balancing of static content is well known in the area of http server clusters and content distribution networks.

An rather simple concept for load balancing of game services is to split servers across regions/zones. So zone A-C are on one server and zones D-F are on another. This is especially easy if you cannot look from zones in one set to zones in another set. You need to put some checks in there so that a client can only connect to a zone server responsible for the zone the player is in.

The easiest way to transfer players from one server to the other is to write them to the database, tell the client to connect to the other zone server, and disconnect them from the current one. The client will then connect to the new zone server which will load it from the database. (Since you need the load from / store to database code anyway, direct communication between the servers for handover can be implemented later).

Some additional global services are needed through: On login the clients have to be told to connect to the correct zone server. And you might want a world wide chat system.

I went into detail on this topic at How is load balancing achieved in MMOs?

share|improve this answer
1  
You mentioned that UDP requires slightly more CPU, but you failed to mention that TCP requires at least three trips between the client and server before the packet is processed, AND the packets are buffered until all previous packets have been received, meaning you might experience ridiculous amounts of lag waiting for packets that are no longer even relevant. Seems like an important thing to mention. –  BlueRaja - Danny Pflughoeft Jun 24 '11 at 20:52
    
@Danny, There are three packets required to initiate a new TCP-connection: client to server: SYN, server to client: SYN ACK, client to server: ACK + data. That is one round trip more than UDP, but it only happens at the very beginning when the client contacts the server for the first time. In an established connection every packet is processed immediately without any additional round trips. There will be an ACK-answer but that the received data is already processed while the ACK packets travels back. –  Hendrik Brummermann Jun 24 '11 at 21:40
    
@Danny, TCP handles packet loss automatically and in a quite efficient way. It is hard to reimplement that yourself using UDP; unless your protocol is fine with random undelivered packets. The next problem is that TCP ensures that the order of packets, while UDP packets might be received in the wrong order. Again, it is difficult to reimplement that yourself, unless you can just ignore older packets for example based on an packet counter. If a very short response time is required for TCP, Nagle's algorithm needs to be disabled. –  Hendrik Brummermann Jun 24 '11 at 21:43
add comment

How to balance load problems?

fixed geographical size + multiple instances is the easiest solution. The guys working on SWG tried dynamic size and regretted it.

How to manage the game state?

Server is authoritative.

How to keep things synchronized?

Periodic sync updates from server. (not quite sure what the concern is here)

How to protect the communication and client from reverse engineering?

Impossible. just make sure you don't trust anything you receive from the client, and that the server is authoritative.

How to work around latency problems?

This goes miles deep, but superficially you run the same simulation on the client as the server and when the sync happens, fix things. All decisions made on the client are simulated on the server as well, so there may be bad decisions, but things generally work out.

Which things should be computed local and which things on the server?

Think of the client as running a non-authoritative sim of what is going on on the server. Responsiveness is key for the player experience, so you have to do something every time a player makes a decision, even if it is just starting a bar.

Truth be told, a lot of these problems are orthogonal, and can have solutions applied later. Just start doing the game and don't worry too much about these things.

share|improve this answer
add comment

The question is far too broad. The answers could fill a website all on their own. But, there are books that touch on this, primarily these two:

Note that even these books are not a complete guide, but are instead a collection of ideas and approaches you can use, some of which won't work together, or are even contradictory. Typically it assumes some experience developing games, network applications, or ideally both.

(Note that I'm talking more about the MMOs in the original question - a 'network game' could mean all sorts of things from a PHP-based text game right through to an MMO, and the sub-questions above don't all apply to each type.)

share|improve this answer
add comment

http://gafferongames.com/networking-for-game-programmers/

Is a great set of articles on various problems and solutions dealing with game networking.

share|improve this answer
    
+1, but please don't trust them blindly. According to my experience for example it is not a good idea to use UDP and reinventing the feature of TCP. UPD is useful only if lost packages do not have any impact at all, i. e. every UDP package contains the complete relevant state of the world. WoW uses TCP, SL is in the progress of moving from UDP to TCP (even HTTP for static content) and has improved performance significantly with these changes. –  Hendrik Brummermann Jul 31 '10 at 10:19
2  
You're not reinventing the TCP features though, not all of them at least. TCP flow control and packet loss semantics are terrible for a game that requires a low latency connection. TCP is only useful if you don't care about latency or minimising required bandwidth. –  jsimmons Aug 1 '10 at 5:19
1  
Second Life massively improved performance by going from UDP to HTTP over TCP: blogs.secondlife.com/community/technology/blog/2010/08/13/… –  Hendrik Brummermann Aug 17 '10 at 21:16
3  
Uh not really, they improved performance of their asset streaming by changing how it works. Using HTTP/TCP in that instance made it easier for them to implement, not faster. I might also note that zeromq is an interesting project, and it may scale very nicely to game networking. zeromq.org –  jsimmons Aug 19 '10 at 4:41
add comment

This question is very broad. It's also a very tricky area to master, network programmers are pretty sought after in the industry with a matching pay, which kinda indicates it's a 'non-solved' area. Are there books out there, yes, plenty. Are there good books out there, no doubt. Are there books out there that will answer your questions?...I don't think so. They might have solutions that work in some situations or pointers on what to look for, but almost all your questions are game dependent....this is an area where you'll really have to work a lot on your own, it's so seemingly trivial and it can go wrong in so many (uncontrolled) ways.

share|improve this answer
add comment

Depending on the type of game you're writing, you may be able to avoid some of the low-level network programming. Some types of games do not require a lot of back-and-forth communication between the clients and the server. In such cases, one could opt to use a higher level framework. For example, I am developing a turn-based strategy game in C#/.NET. Turn-based strategy games are somewhat unique in that the vast majority of client/server communication occurs at the beginning and end of a turn, with relatively little in between. Thus, I opted to use the Windows Communication Foundation (WCF), a high-level communications framework designed primarily for web services. Instead of working directly with sockets and all of that low-level networking gunk, I can make what appear to be standard method calls, and let WCF deal with the protocol and transport layers for me. The only time I've had to deal with the low-level network stuff was when I configured my endpoints, which is pretty much a one-time deal in a config file. It may still be necessary to implement some custom serialization logic, but you'd need to do that sort of thing regardless.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.