125

No, UDP is still superior in terms of performance latency, and will always be faster, because of the philosophy of the 2 protocols - assuming your communication data was designed with UDP or any other lossy communication in mind. TCP creates an abstraction in which all network packets arrive, and they arrive in the exact order in which they were sent. To ...


66

This is not for performance. This is a failsafe. If the world saves every few minutes, then if something happens to the server and it shuts down everyone will only lose a few minutes' progress. By saving on disconnect, if the server has an issue everyone will lose everything they have done since they logged on. For those on particularly long play sessions (...


64

I think Dummynet is what you are looking for. Dummynet is a network emulation tool which can simulate bandwidth limitations, delays, packet losses, and many more. You can easily choose which traffic you want to intercept and configure the limitations, e.g. to limit all incoming TCP traffic to 2Mbit/s you do ipfw add pipe 2 in proto tcp ipfw pipe 2 config bw ...


48

By simply only loading those parts of the world into memory which are close to the player. Anything else is suspended to hard drive. When there is a tiny object laying around two kilometers away, then the player can not see it and can not interact with it. So there is no reason to update it or send it to the GPU for rendering. The smaller the object and its ...


47

I've worked on the networking code for two real time AAA networked games, one for smartphones and one for a handheld console. To directly answer your question "why", well, some games use one or the other because it suits them better than the other. This depends not only on the type of game, but also on what type of network we're talking about (linked arcade ...


43

There are times when you cannot avoid sending the full game state - such as on load of a saved multiplayer game, or when a resync is needed. But sending full state is usually avoidable, and that's where delta encoding comes in. Generally, this is all that delta compression is about; your example doesn't really describe that situation. The reason delta ...


35

Network Link Conditioner If you're on a Mac, you can use Network Link Conditioner. You can simulate various cases of bad internet connections, including Edge and 3G. In addition, you can create your own profiles with your own settings: It is a free download in Xcode (go to Xcode → Open Developer Tool → More Developer Tools… and download the Hardware IO ...


32

This is a form of the Two Generals Problem, and you're right - no number of retries is enough to perfectly guarantee receipt. In practice in games, there's usually a time horizon beyond which the information doesn't really matter though even if it technically arrives reliably. Like finding out you had a perfect headshot lined up 2 seconds ago - it's too ...


30

A TCP segment has quite a lot of overhead. When you send a 10 byte message with one TCP packet you actually send: 16 bytes of IPv4 header (will increase to 40 byte when IPv6 becomes common) 16 bytes of TCP header 10 bytes of payload additional overhead for the data-link and physical layer protocols used resulting in 42 bytes of traffic for transporting 10 ...


23

You have the wrong delta. You're looking at the delta of the individual elements. You need to think of the delta of the entire scene. Suppose you have 100 elements in your scene, but only 1 of them moved. If you send 100 element vectors, 99 of them are wasted. You really only need to send 1. Now, let's say you have a JSON object that stores all your element ...


22

Simple answer: cheat or don't be that accurate! If you've played some shooter online, you'll most likely have experienced the so called "rubber banding" if your connection to the server is bad. This is caused by your client correcting your position from time to time. Basically, what happens on the two sides: The server will track your movement and send ...


22

You have two very different things to manage: The server must manage the entire world, in an authorative manner. For that, communication with N clients (where N is "massive") is necessary. The client could, in principle, know about the entire world, but it needs not. For the client, it is sufficient to know about what's nearby the player. Assuming for ...


19

We agree upon both TCP and UDP being protocols built on top of IP, don't we? IP specifies how messages are delivered across the internet, but nothing is about the messages structure, format. Here come TCP and UDP protocols. They use IP properties, but let the programmer focus on the message exchange without worrying about the lower layers of net ...


15

If you are on linux you can use netem to simulate all of the possible problems with network like high latency, low bandwidth, packet losses and many others. There is an option for windows called NetLimiter but I haven't used it so can't vouch for it. Just found a Mac App called SlowlyApp.


14

There is no reason to communicate over the network when the player selects units, because in most games just selecting a unit has no game-mechanical consequences. So this is an information which isn't relevant to the server or to the other players. But what would be important is when the player gives a command to one or more units. When issuing a move-...


13

Here's my two cents: P2P: Pros: No need for a central server: this makes it much cheaper, and more viable for low-budget indie games. Scales very well (up to a certain point when the average client just can't handle the bandwidth). Very good for data distribution: Suits games where user-created content is dynamically synced (e.g. torrents). More Stable: ...


13

Server-side hit detection isn't to prevent aimbots, it's to prevent cheaters who simply tell the server "I hit!" regardless of where they are aiming.


12

Clumsy, for Windows Vista & 7.


12

Your goal of synchronizing 50 events per second in real-time sounds to me like it is not realistic. This is why the lock-step approach talked about in the 1500 archers article is, well, talked about! In one sentence: The only way to synchronize too many items in too short time over a too slow network is to NOT synchronize too many items in too short time ...


12

Without knowing more about the exact game you're writing, and how you're writing it, it is very difficult to say generic solutions to your problem. However, you may want to consider this decision you're taking of leaving the networking code to the end, depending on how crucial networking is for your game. What I mean is that, if you're writing a network ...


12

Rule number one for multiplayer netcode design: Anything that matters for gameplay should be calculated server-sided. Never trust the client. The client is in the hands of the enemy. You can not efficiently prevent players from modifying their game client to gain an advantage. The only reasons why you would do damage calculation on the client are: Your ...


11

In such cases, you may be better off letting the client be slightly authoritative. For such precise controls you're extremely unlikely to get good behavior even with really advanced correction and prediction. The client needs to extend from just sending "I jumped" messages to sending "I jumped from X,Y at time T" messages. The server then checks that the ...


11

After searching around, it seems that synchronizing the clocks of 2 or more computers is not a trivial task. A protocol like NTP does a good job but is supposedly slow and too complex to be practical in games. Also, it uses UDP which won't work for me because I'm working with web-sockets, which don't support UDP. I found a method here however, which seems ...


11

Option 3: The client sends a click event to the server, the server decides where this click event has landed, decides if there is a hit or a miss, then applies the damage and sends the updated world state back to the client. Don't even trust the client to tell if there is a hit or a miss.


10

One large one (within reason) is better. As you said, packet loss is the main reason. Packets are generally sent in frames of a fixed size, so it is better to take up one frame with a big message than 10 frames with 10 small ones. However with standard TCP, this isn't really an issue, unless you disable it. (It is called Nagle's algorithm, and for games ...


10

A ping is a method to measure round trip time. The process of "pinging" is to send a "ping". A "ping" is a network message which serves no other purpose than to get an immediate response from the receiver. This can be used to measure the round trip time. It can also be used to verify that another system is able and willing to respond to network messages at ...


9

One of the most common misunderstandings of TCP vs UDP is that TCP's main feature is reliability. The main feature of TCP is that it abstracts a stream of data to send from one socket to another. Reliability, as provided by TCP is a requirement for the abstraction to work, but is not the central idea behind TCP. You might want to consider basing your ...


9

TCP <- Transmission Control Protocol. It's made to control transmission. TCP was created to be a good and diplomatic network citizen. It focuses on making the networking a good experience for everyone, and willingly decreases it's throughput to achieve that. It adjusts to the environment by adding latency. Reasons are for example: Receiver detects a ...


9

It results in packet loss for UDP due to contention between the two protocols - remember that UDP is not guaranteed delivery, while TCP is. More TCP packets will get through while UDP suffers - TCP induces UDP packet loss. There has also been the (historical) idea that router infrastructure favours TCP over UDP, though I doubt that is still true by this late ...


Only top voted, non community-wiki answers of a minimum length are eligible