In the previous blog post, we learned how one should plan and build the game architecture to reduce the network load and to use network resource in a more optimized way. It particularly talked about the game physics involved in multiplayer games.

En la entrada del blog pasada, aprendimos como se debería planificar y construir la arquitectura de los juegos para reducir la carga de la red y utilizar los recursos de la red de una forma más óptima. Particularmente, hablaba sobre la física de juegos involucrada en los juegos de varios jugadores.

Pero la incorporación de la física en juegos para varios jugadores nos conduce a otro reto, probablemente el mayor; como lo es por ejemplo el sincronizar la física de juegos.

La razón por la que surge este reto es el hecho de que cada red lucha con un período de latencia. Puede que usted instale los mejores servidores y utilice los algoritmos de la red optimizados como nosotros lo hicimos en AppWarp, pero no puede garantizar la misma calidad de la red del lado del cliente; por ejemplo, el cliente podría estar utilizando redes más lentas tales como 2G o red telefónica o puede que se encuentren geográficamente lejos del servidor, etc. Por lo tanto, distintos usuarios pueden obtener la misma información en momentos específicos;es decir, diferentes jugadores pueden ver al mismo jugador en distintas posiciones mientras dicho jugador ya se ha movido a una posición nueva.

Observe la siguiente ilustración:

En la figura anterior, la información enviada al instante por el cliente A llega al instante t´ al cliente B, por lo tanto el cliente B siempre obtiene la información acerca del cliente A que sucedió en el pasado. Similarmente, el cliente A obtiene información pasada sobre el cliente B.

No se puede eliminar este periodo de latencia pero se puede compensar utilizando ciertas técnicas. Aquí estaremos discutiendo sobre las técnicas de predicción del lado del cliente. Como las mismas se describen, la predicción del lado del cliente trata sobre predecir la posición de un jugador en el lado del cliente. La predicción del lado del cliente típica se llevó a cabo para predecir la posición propia en servidores autoritarios en los cuales se debe esperar a que el servidor valide la acción, pero fácilmente podemos extendernos a predecir la posición de otro jugador en motores de juegos de varios jugadores BaaS.

Un algoritmo de predicción popular es “Estimación Muerta” (también estimación ded (por deducción en Inglés) o DR (por sus siglas en Inglés) la cual es el proceso de calcular una posición actual utilizando una posición previamente determinada o fija y avanzar a dicha posición basado en velocidades sobre tiempo transcurrido y trayectoria previamente estimados. (Fuente: Wikipedia)

Suponga que el Cliente A envía su posición

x(t) = x + v(t)

En el instante t

Esta información llega al cliente B al instante t´ pero hasta ahora el cliente A ya se ha movido a
x(t´) = x + v(t´)

Si el cliente B coloca al cliente A en su simulación en x(t), esto no será correcto; por lo tanto el cliente B deberá predecirpor sí mismo la nueva ubicación del cliente A utilizando la diferencia entre la velocidad y el tiempo dt = t´-t. La nueva posición predicha es

x(t´) = x(t) + v(tp-t)

La diferencia del tiempo es el viaje de ida y vuelta del mensaje, es decir, el tiempo empleado por el mensaje para viajar del cliente A al servidor y luego del servidor al cliente B. El periodo de latencia se calcula como la mitad de este viaje de ida y vuelta. Por lo tanto, el periodo de latencia se convierte en un factor importante en los juegos de varios jugadores para sincronizar la física a través de los clientes.

Existen dos métodos básicos para incorporar el periodo de latencia en cálculos físicos, uno de ellos es el de enviar sellos de tiempo en su mensaje. Así, en la ubicación del cliente fácilmente se puede calcular la diferencia de tiempo pero el reloj debería estar uniforme entre los clientes y el servidor. Otro método y una mejor forma de hacerlo es calcular el periodo de latencia y enviarlo con el mensaje. Cada mensaje (solicitud) enviada por el cliente a AppWarp desencadena una respuesta devuelta. Fácilmente usted puede calcular su periodo de latencia reduciendo a la mitad el tiempo de ida y vuelta del mensaje y luego enviando dicho periodo de latencia con su próximo mensaje. Cuando este mensaje llega al otro cliente, puede que éste también haya estado calculando su periodo de latencia, así que la diferencia de tiempo actual en cliente B será el periodo de latencia recibido por cliente A más el período de latencia propio del cliente B.

De esta forma se puede sincronizar la física en los juegos. Espero que este artículo le haya sido de ayuda. Si usted tiene alguna pregunta o necesita previa asistencia, por favor escríbanos a support@shephertz.com

<------------Facebook Pixel Code----------------------->



But incorporating physics in multiplayer games, leads to another challenge and probably the biggest challenge i.e. synchronizing the game physics.

The reason this challenge arises is the fact that every network struggles with some latency. You might install the best servers and use optimized network algorithms like we did in AppWarp, but you can’t guarantee the same quality of network on client side e.g. the client may be running on slower networks like 2G or dial-up or may be they are geographically far away from the server etc. Therefore, different users might get same information at different instants of time e.g. different players might see the same player at different positions while the actual player has already moved on to a new position.

Take a look at the following figure:

In the above figure, information sent at instant t by Client A arrives at instant t’ at Client B, hence client B always gets the information about client A that happened in the past. Similarly, client A gets past information of client B.

You can not remove this latency but you can compensate it using some techniques. Here, we will be discussing about the client side prediction techniques. As the name describes itself, client side prediction is about predicting the position of a player at client side. The classical client side prediction was done to predict one’s own position in authoritative servers where one has to wait for the server to validate his action but we can easily extend it to predict other player’s position in BaaS multiplayer game engines.

One popular prediction algorithm is “Dead Reckoning” (also ded (for deduced) reckoning or DR) is the process of calculating one’s current position by using a previously determined position, or fix, and advancing that position based upon known or estimated speeds over elapsed time, and course. (Source: Wikipedia)

Suppose Client A sends his position

x(t) = x + v(t)

at instant t

This information arrives at client B at instant t’  but till now client A has already been moved to

x(t’) = x + v(t’)

If client B places client A in his simulation at x(t), it will not be correct; hence client B should itself predict the new location of client A by using the velocity and time difference dt = t’-t. The new position predicted is

x(t’) = x(t) + v(t’-t)

The time difference is the round trip of the message i.e. the time taken by the message to travel from client A to server and then from server to client B. The latency is calculated as half of this round trip. Hence, latency becomes an important factor in multiplayer games to synchronize all the physics across the clients.

There are two basic ways to incorporate latency in calculating physics, one way is to send timestamps in your message. So, at client site you can easily calculate the time difference but the clock should be uniform across all the clients and server. Another and a better way is to calculate the latency and send it with the message. Every message(request) sent by the client to AppWarp triggers a callback response. You can easily calculate your latency by halving your message’s round trip time, and then sending that latency with your next message. When this message arrives at another client, he might have also been calculating his latency, so the actual time difference at client B will be the latency of client A received plus the own latency of client B.

This way you can synchronize your game physics. Hope this article helped you.If you have any questions or need any further assistance, please feel free to write us at support@shephertz.com