ASYNCHRONOUS MULTIPLAYER:

AUTHORATIVE SERVER

ON SLOW NETWORK

Ivan Dolgushin

Game developer at Appturn

Maze Mash

Maze Mash

Time-keeping in games

Synchronous and asynchronous

If the attainment of a win

as a part of a loop

depends on the actions

of more than one player,

• that loop is synchronous;

• if not, it is asynchronous.

Step 1: Turn-based games

Synchronization:

• once a turn (on commit);

• network latency does not matter;

• race conditions do matter.

Remote Procedure Call (RPC)

Send action, reliably, with turn number.

Return nothing on success.

Parallel simulation

Client Server

Compare world states regularly:

as check-sum or any other way

De-synchronization

Checksum failure strategies:

• Stop the game

• Take client world as correct one

• Take server world as correct one

Step 2: Real-time games

Turn-base ->

-> timed turn-base ->

-> time per turn < 1/30 sec

-> real-time game ^_^

Synchronizability requirements:

• “Fixed” update time-step

• “Fixed” call order in the update-frame

• “Fixed” data types

• “Fixed” math

• “Predictable” randomness

Network latency

Re-synchronization strategies:

• Logical state synchronization

• Lerp visuals in several frames

Step 3: Predictive RT

When the game turn duration is way shorter than network

latency, the network messages never gets to the remote in

time

Server

Client

A

A

B

B

C

C

Time shift

Server

Client

A

A

B

B

C

CLTNCY

Jitter

Server

Client

A

A

B

B

C

CLTNCY

Input caching

Server

Client

A B C

LTNCYJB

QUEUE

A B C

AB C

|0

|0 |100

|100

State synchronization

Server

Client

A B C

LTNCYJB

QUEUE

A B C

AB C

|0

|0 |100

|100

? ?

PREDICTION

PREDICTION

Prediction

Server

Client A B C

LTNCYJB

QUEUE

A B C

AB C

|0

|0 |100

|100

QUEUE A B C

PREDICTION

PREDICTION

Timestamps

Server

Client A B C

LTNCYJB

QUEUE

A B C

AB C

|0

|0 |100

|100

QUEUE A B C

Prediction issues

• Make sure your logic is “prediction-aware”.

No irreversible actions should be done, e.g. object should

not be actually destroyed a while after their “visual death”.

• Make sure your FX logic is “prediction-aware”.

Some action may happen several times in one frame just

because of prediction.

Pros and Cons

Pros:

• is working on a wide range of network qualities

• load depends on actual prediction duration (low load on low-latency networks)

• high security

• moderate server load

• almost out-of-the-box replays

Cons:

• prediction requires relatively large amount processing time (a bunch of “frame” amounts)

• load depends on actual prediction duration (high load on high-latency networks)

• does not work for synchronous multiplayer games

• quite hard to implement

• horribly hard to debug

• require predictable and synchronizable random numbers

Thank you!

Ivan Dolgushin

Game developer at Appturn

ivand@appturn.com