LAG [Comunicación Server - Client]

Buenas.
Estoy desarrollando una aplicación multiusuario basada en "tiles" (baldosas). He empezado hace poquito.
Por lo pronto he hecho que, en 2D, los usuarios puedan ir al lugar deseado pulsando en él, y funciona muy bien.
El server que uso es Palabre Server. Lo que hago es enviar cada actualización de la posición al server, y así todos la reciben, y tan contentos. Pero claro, para ello mando MUCHA información (cada vez que se mueven un poquito, mandan paquete de info)...
Mi duda, antes de seguir, es la siguiente: ¿Cómo sigo el desarrollo?
- Opción 1: ¿Continuo así, mandando TANTA info? La ventaja que tiene esto es que el cliente no tiene que hacer muchas operaciones, simplemente ._x e ._y = lo que sea, y ya está... Lo malo es que, a la mínima que se conecten 50 y comiencen a moverse... ¡¡¡¡!!!! No se si el Servidor (además Palabre es gratuito y no creo que sea una maravilla) diese a basto.
- Opción 2: Se me ha ocurrido que el usuario podría mandar tan sólo un paquete de información cada vez que llega a una nueva baldosa (a su centro). Me explico: un usuario pulsa, por ejemplo, 3 baldosas más a la derecha de donde está. Comienza a moverse, y cuando pasa por el centro de la primera baldosa, manda info al server. Lo bueno de esta opción es que deja respirar al server, lo malo viene para el cliente: tendría que hacer en flash alguna función que se ejecutase todo el tiempo y que comprobara quienes han mandado paquete con su nueva baldosa, y acto seguido el mismo cliente tendría que hacer una función por cada uno de los usuarios en movimiento para ir moviéndoles de 7 en 7 píxeles (porque moverlos de golpe al centro de baldosa en baldosa pero a "saltos" quedaría bastante cutre...)
- Opción 3: (Ya casi descartada...) El cliente sólo manda la posición a donde QUIERE ir. Es decir, pulsa en la baldosa 5-3, y eso es lo que manda al server y todo el mundo recibe. Con esto, el trabajo del cliente crecería muchísimo, porque no sólo tendría que hacer lo de la Opción 2, también tendría que comprobar si hay obstáculos, etcétera, etcétera, y eso si hay 50 personas moviéndose, pues puede explotar.

Para la respuesta, imaginad un Server normalito (en cuanto a Hardware e Internet) y un máximo de 100 conexiones simultáneas.

¡Gracias!

P.D.: No pido NADA de código, sólo EXPERIENCIA, lo ideal sería alguien que ya haya hecho cosas así y se haya topado con el LAG.
P.D. 2: Yo que me había prometido hacer una entrada corta y me ha quedado aquí la Biblia

Es bastante largo tu POST, pero el principio siempre es el mismo: tienes que mandar la mínima info posible (uses Palabre o un satélite de la NASA), en el caso de un movimiento, el Id del Tile sería suficiente

Jorge

Vamos que la opción 2, ¿no? La mínima posible sería la 3, pero es que esa me da muuuucho miedo...

La lógica del cliente solo la procesa el cliente, no recae en el servidor, con lo cual la opción 3 sería la recomendable

Jorge

Pero Jorge, imagínate que mando sólo la posición final (Opción III). Todo el mundo recibe que X se quiere mover a la tile 6-5, y comienzan a moverla hacia allí. Pero claro, antes de mover, tiene que pasar por todos los filtros de obstáculos y demás...
Ahora imagina que, por lo que sea, uno de los usuarios que ha recibido el mensaje tiene un pequeño retraso, y que justamente cuando X se está moviendo, "Y" también lo hace (convirtiéndose Y en un obstáculo para X). En el que tiene retraso, "Y" aún no ha comenzado a moverse, por lo tanto X seguirá una trayectoria sin tener en cuenta a "Y", mientras que a la gente que no tiene retraso, X seguirá la trayectoria teniendo como obstáculo a "Y".
El resultado sería, al final, el mismo usuario X en una posición diferente en cada uno de los clientes.
No sé si me he explicado

El ejemplo anterior más 'gráfico', sería:
(todo con la Opción 3, mandar al server sólo la tile a donde queremos llegar)
-> EN CLIENTE SIN RETRASO
X se está moviendo desde 1,1 a 6,5... cuando ya está por 3-2, justamente "Y" comienza a moverse, y pasa por el 3-3, que va a ser la siguiente Tile de "X". Como la 3-3 está ocupada, X se para, porque al no ser muy 'inteligente' no sabe buscar otro camino a 6-5.

-> EN CLIENTE CON RETRASO
X se está moviendo desde 1,1 a 6,5... y cuando ya está por la 5-5, recibe que tiene que mover a "Y". Pero como "Y" no va a pasar por ahí, no se va a convertir en obstáculo, así que X llega a su destino 6-5 sin problema.

RESULTADO: En algunos clientes X está en 3-2, en otros en 6-5... Y vaya usted a saber dónde más.

Si es un juego de acción en realtime dependerás de la latencia del servidor, pasado determinado umbral jugar se hace imposible. Luego las trayectorias deben ser predictivas, es decir a partir del movimiento propio y de los demás (trayectoria) debes poder prever la colisión ... pero hay libros enteros sobre el tema. Solo considera que los juegos realtime no son de acción (sino estilo ajedrez o rol) por ese mismo motivo

Jorge

Pero Jorge, ¿cómo voy a prever las colisiones en el cliente si las trayectorias me llegan a diferentes tiempos? ¿o hablas de preverlas en el Server? Dime qué te parece la opción 2, por favor
Y si tienes algún título (libro) castellano con preferencia, te lo agradecería.
Gracias!!!

Mmm ... el mejor sitio para tutos avanzados de juegos es gotoAndPlay.it


Jorge

Lo había visitado alguna vez, ¿pero no tiene todo relacionado con el SmartFox? Y yo ese no lo uso En cualquier caso, muchas gracias por responder cada cosa que te preguntaba
¡Si alguien más sabe algo...! No quiero nadie que me solucione la vida, simplemente alguien con experiencia de haber hecho algo así que sepa por dónde he de seguir, porque no quiero empezar por un sitio que igual con 5 conexiones funciona a las mil maravillas pero que después ya empieza a ir lento...
¡Gracias!

Más o menos todos los servidores de sockets funcionan similar y en base a XML, a menos que uses FMS o Red% y puedas usar un Remote SharedObject

Jorge