How to write a network game? [closed]

Question

Based on Why is it 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.

Answer 1

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?

Answer 2

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

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

Answer 3

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.

Answer 4

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:

• Massively Multiplayer Game Development
• Massively Multiplayer Game Development 2

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.)

Answer 5

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.

Answer 6

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.