En el juego que dirigí (al que llegué cuando algunos programadores ya habían metido las zarpas), había que mantener un mapa de 160x80 (12800) "habitaciones".Cada habitación, a su vez, tenía 40 posiciones internas.
Mientras era importante saber en qué habitación estaba un jugador (lógico), qué posición tenía dentro de la habitación, era aleatoria.
Una traslación directa de estos requisitos a una BD, llevaba a una tabla de...12800*40 = 512000 filas.
Lógicamente, bajo esas condiciones, enviar un mapa completo al cliente, era imposible.
Pero, a la vez, mostrar un interfaz de usuario con 160x80 posiciones de mapa, y con 15000 jugadores por servidor, te lleva a que es imposible mostrar sobre el mapa toda esa información.
Así que hice una primera aproximación: para el mapa global, lo importante es mostrar si no hay nadie en esa "habitación", o si hay alguien (1,2 o más usuarios).Eso se codifica en 2 bits.
Dos bits por 12800 posiciones de mapa, no son más que 25Kb. Esto se puede enviar fácilmente a los clientes, por ajax, y con javascript, decodificar el mapa binario.
Y, cuando un jugador selecciona una cierta habitación, es entonces cuando se consulta la BD para mostrarle todos los jugadores que hay en esa habitación, pero ya es un acceso por primary key.
Quién mantiene ese mapa? El cron job que se ejecuta cada 30 segundos.Mueve las cosas en la base de datos, obtiene quien se ha movido en ese intervalo de tiempo, y actualiza el mapa que vive en memcached.
Por supuesto, el tiempo de moverse de una habitación a otra, era bastante grande (varios minutos, cosas tipicas en juegos tipo ogame), y, en cada turno, el numero de cambios de habitación no era muy grande.
Para las posiciones *dentro* de cada habitación, al ser indiferente qué posición ocupaba cada jugador, con un generador de números pseudoaleatorios, y con el timestamp de entrada en la habitación, era bastante.
Los problemas más serios vinieron....por culpa de los antivirus.Hay muchos antivirus que escanean el tráfico HTTP.Por lo tanto, si usas COMET (y supongo que por eso el OP habla de Node.js), vía iframe o vía ajax, los antivirus retienen todo el tráfico HTTP hasta recibir la respuesta completa....que nunca llega.Por lo tanto, el cliente no recibe eventos.
Otras alternativas sería evaluar la posibilidad de usar servidores open-source para juegos existentes.Por ejemplo, para Ultima online existen servidores y clientes open-source.Se puede reaprovechar mucho de ahí, para juegos serios.
Tras dejar esa empresa, hice un motor de pintado isométrico con html5, precisamente para juegos en tiempo real con websockets (sí tengo experiencia en servidores de comunicaciones para juegos en tiempo real...en C, claro)...pero ahora está por algún lado pillando polvo..
