¿Técnicas MMO, algoritmos y recursos para mantener bajo el ancho de banda?

9

¿Existe algún recurso y documentación sobre cómo los MMO actuales manejan los datos de acción y movimiento desde la compresión hasta el manejo en el cliente? ¿Algún recurso para algoritmos de predicción de movimiento?

Estoy especialmente interesado en aquellos que tienen movimiento wsad y se centran en mantener la latencia baja. ¿Cuál es la tasa y el tamaño de los paquetes para los diferentes tipos de MMO (en cuanto a la red)?

¿Hay alguna forma de escalar la tasa de paquetes o desactivar por completo algunos paquetes si el jugador no puede alcanzarlos o, en el último caso, verlos?

adrix89
fuente

Respuestas:

9

Bueno, está este libro , que es un poco viejo ahora, y nunca lo he leído realmente, pero es de un editor de buena reputación. También encontré este , que es más nuevo, pero nunca antes había oído hablar de él. Ambos afirman que cubren problemas de desarrollo de juegos MMO (o al menos en línea); Dicho esto, la predicción del lado del cliente es más o menos la misma independientemente de la escala de su base de jugadores concurrentes, y Google tiene mucha información al respecto .

Es importante darse cuenta de que desde una perspectiva práctica es bastante difícil para un desarrollador independiente / aficionado armar un juego que sea lo suficientemente popular como para incluso reunir suficientes jugadores para lograr una concurrencia máxima teórica lo suficientemente alta como para ser considerado "masivo". Pero las técnicas aún pueden ser educativas para la investigación.

Hay dos clasificaciones principales de cosas que puede hacer:

  • Sea agresivo al enviar solo la cantidad mínima de datos al conjunto mínimo de clientes que lo necesitan.
  • Diseña un juego que no ofrezca a los jugadores incentivos para agruparse demasiado, ayudándote a mantener el "conjunto de clientes que necesitan" cosas pequeñas en general.

El segundo es realmente un problema de diseño de juegos y manipulación social: es especialmente complicado porque los juegos multijugador son naturalmente sociales, eso es parte de su atractivo, por lo que no debes desalentar demasiado a los grupos de jugadores. Por otro lado, será difícil escalar un juego en el que todos en el mundo acampan: el único que arroja el mejor botín del juego será difícil de escalar.

Para la primera opción, podría considerar hacer mensajes escalonados: hay algunas cosas sobre otros jugadores que siempre es importante saber, como las posiciones. Pero otras cosas, como la salud, pueden no ser tan importantes para los objetos que el jugador actual aún no puede ver, por lo que puede bloquear lo que envía a ese jugador en función de la distancia relativa de todas las demás entidades en su vecindad; esto es esencialmente un estrangulamiento los datos que envía, como mencionó en el último bit de su pregunta, así como también el filtrado.

Las arquitecturas multijugador a muy gran escala también amortiguarán los informes que no necesitan tomar medidas inmediatas sobre ellos. Los mensajes de guardado de caracteres enviados al servidor se pueden hacer en deltas, con actualizaciones completas solo en puntos críticos, y estas actualizaciones se pueden almacenar en un servidor de regulación para que se envíen al servidor que realmente mantiene los datos de caracteres de manera estable, moda periódica: a medida que la base de su reproductor escala, debe preocuparse por optimizar la E / S del disco y el tráfico de la red. No quieres hacer que tu base de datos de personajes se agite.

La velocidad y el tamaño del paquete difieren mucho de un juego a otro, tal como lo haría para los juegos que no son MMO. Realmente es algo muy específico de requisitos y no hay estándares generalizados.


fuente
1
También hay una secuela del primer libro (Massively Multiplayer Game Development 2). En mi opinión, no es una serie de libros terriblemente útil (definitivamente no es un libro de principio a fin para hacer un MMO en x horas como lo son la mayoría de los libros de desarrollo de juegos), pero discute algunos de los problemas teóricos preguntado en esta pregunta. Y tal vez sería más útil para alguien que ya tiene un MMO desarrollado en parte.
Ricket
5

Además de la respuesta anterior, lea sobre TCP_NODELAY y cómo funciona el escalado de ventanas. Comprender los detalles de TCP (y sí, desea utilizar TCP, no UDP, a menos que la perspectiva de manejar actualizaciones diferenciales que lleguen fuera de servicio le parezca divertido) y la retransmisión es crítica para el control de la latencia.

coderanger
fuente
44
Repetiré que si está usando actualizaciones diferenciales (generalmente diferencias binarias de estructuras en el juego) y usa cualquier cosa con entrega fuera de orden (confiable o no), lo lamentará. Las personas a las que no les gusta el TCP en los juegos generalmente no saben lo suficiente (como saber lo que hace NODELAY). UDP tiene sentido para cosas como datos de voz, donde los paquetes desordenados simplemente se pueden descartar, esto rara vez es el caso en un juego.
coderanger
1
"rara vez el caso en un juego"? Siempre que el servidor me dé estados de juego autorizados en cada cuadro, no me importa lo que sucedió en el pasado. Un número de trama simple que aumenta monotónicamente de los paquetes UDP es perfecto para esto. ¿Cuántos datos realmente necesita transmitir de manera confiable?
ChrisE
2
"Siempre que el servidor me dé estados de juego autorizados en cada cuadro" Claro, si lo tratas como un hecho. Tenga en cuenta que dije "si está utilizando actualizaciones diferenciales", que sería lo contrario de estropear el estado completo de cada cuadro. En un MMO con cualquier nivel de complejidad para el mundo, rápidamente será imposible enviar actualizaciones completas con tanta frecuencia.
coderanger
1
Incluso si envía el estado completo de las cosas que cambian, terminará con problemas de entrega fuera de orden donde fusionar las cosas puede volverse inviable. Piense en las actualizaciones "x = 1, y = 2" y luego "y = 1, z = 2". Si esos llegan al revés, desea soltar el "primero" para que el valor de y sea correcto, pero luego pierde el cambio a x.
coderanger
1
@ Adam Por eso dije que deberías leer las especificaciones de TCP y entender cómo funciona el escalado de ventanas y cómo interactúa con la retransmisión ;-) Reescribir TCP es básicamente incorrecto, las posibilidades de arruinarlo son cercanas al 100%. Si desea una entrega confiable y en orden, no debería usar UDP.
coderanger