• Advertisement
Sign in to follow this  

General Approach for Realtime Multiplayer Games

This topic is 2357 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,
I have written a small engine for 2d games. The only thing which is missing is the networking. I want to allow multiplayer with 2 or more players, probably with one player being the server.

I really got problem realizing it. Are there any general tutorials for network engines? The programming and the tcp/udp stacks are not the problem, I studied informatics. The problem is rather the concepts behind reliable network gaming in non-turn-based games.

This is my current approach:

All player machines calculate the game independently. Because all game actions (including the random generator with same seed) are deterministic, the game should yield the same result on each machine without the necessity to exchange any information. The only point where I need to exchange information is when a player does something. This has to be communicated to all players. I identified some problems with this:

1.) The player action may only be started once all players receive it. This is a major problem. How to ensure that all players receive it in a given time?

2.) What if a machine doesnt receive the action of another player on time (because his network had a short congestion or something)? If the machine continues the simulation beyond the point where the action started, everything is lost, since the engine does not support to go back in time. So this has to be averted at all costs.

The only approach I can think of which solves the problems is a "heartbeat" approach.
I.e. the server sends frequent heartbeats to all clients which also carry all actions which players want to execute. I.e. if a player wants to do an action, a message is sent to the server and is broadcasted by it with the next heartbeat. This in turn means that a playeraction might have a delay up to the period of a heartbeat. To minimize latency of actions, the heartbeats must be frequent (maybe around 5-10 per second).

Since the heart beats are periodic, a client anticipates a heartbeat each period. If he receives none, he immediately pauses the simulation (because he could otherwise miss player actions which are carried by the heartbeat. Clients also send heartbeats to the server (but maybe less frequently). Once the server does not receive an anticipated heartbeat from a client. He tells all other clients to pause and wait for that player. If the player does not respond within a time limit he is disconnected from the game and the other players keep on playing without him.

So this is basically my approach. Does it go in the right direction, or are other concepts better than this one? It might have the problem that the frequent heartbeats might cause (unnecessary) high traffic. Are 10 heartbeats per second ok?

I always wondered how for example Warcraft 3 handles the networking. It has very low latency but never misses a player action / detects a connection loss very quickly. Does anyone have a clue how these commercial network engines work?

Share this post


Link to post
Share on other sites
Advertisement

I really got problem realizing it. Are there any general tutorials for network engines? The programming and the tcp/udp stacks are not the problem, I studied informatics. The problem is rather the concepts behind reliable network gaming in non-turn-based games.


This question comes up literally every other week on this forum! Lots of the reference in the FAQ deals with this problem.
In general, there are two options:
1) Send commands to the server, and only execute them when all the clients have given commands for a particular step. This ends up being similar to the "lock step" model, but you don't necessarily need a deterministic simulation if you do periodic snapshot updates or detect-and-correct using checksums.
2) Optimistically perform simulation right away on the client, and then be prepared to adjust as the server keeps sending your own state back to you in potentially different configurations.

Additionally, there are approaches to masking your command latency (in case 1) or the latency of other players (in case 2) on the local client. such as displaying extrapolated (not strictly physically correct) positions of remote players.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement