Basado en ¿Por qué es tan difícil desarrollar un MMO? :
El desarrollo de juegos en red no es trivial; Hay grandes obstáculos que superar no solo en la latencia, sino también en la prevención de trampas, la gestión del estado y el equilibrio de carga. Si no tienes experiencia en escribir un juego en red, este será un ejercicio de aprendizaje difícil.
Conozco la teoría sobre sockets, servidores, clientes, protocolos, conexiones y esas cosas.
Ahora me pregunto cómo se puede aprender a escribir un juego en red:
- ¿Cómo equilibrar los problemas de carga?
- ¿Cómo gestionar el estado del juego?
- ¿Cómo mantener las cosas sincronizadas?
- ¿Cómo proteger la comunicación y el cliente de la ingeniería inversa?
- ¿Cómo solucionar problemas de latencia?
- ¿Qué cosas deben calcularse localmente y qué cosas en el servidor?
- ...
¿Hay buenos libros, tutoriales, sitios, artículos interesantes u otras preguntas al respecto?
Estoy buscando respuestas amplias, pero las específicas también están bien para aprender la diferencia.
networking
multiplayer
books
scalability
Tamara Wijsman
fuente
fuente
Respuestas:
Además del artículo vinculado en otras respuestas, puedo contar un poco sobre la experiencia del Proyecto Arianne .
¿Cómo mantener las cosas sincronizadas?
Tenemos el marco de trabajo " Marauroa " en torno al concepto de acciones y percepciones: las acciones se envían desde el cliente al servidor llevando la entrada del usuario como (caminar a la izquierda, atacar a los monstruos # 47, decir 'hola'). Y las percepciones se envían desde el servidor a los clientes informándoles sobre el estado del mundo que los rodea. Esas percepciones se envían cada turno. Dependiendo del juego, usamos tiempos de giro de 30ms a 300ms.
Tenemos dos tipos de percepciones : se envía una percepción completa al iniciar sesión y cuando el jugador ingresa a una nueva área (zona). Después de eso, se envían percepciones diferenciales que incluyen solo los atributos modificados (por ejemplo, la posición) de los objetos modificados y, por supuesto, los objetos nuevos y eliminados.
¿Cómo solucionar problemas de latencia?
Creemos firmemente en "el servidor siempre tiene la razón". El cliente hace algunas predicciones como caminar sin problemas, verificaciones de colisiones, etc. Pero si un cliente y el servidor no están de acuerdo con algo, el servidor gana. El subproyecto Stendhal (un RPG 2D) utiliza un tiempo de giro de 300 ms de forma predeterminada (con mucho suavizado hecho del lado del cliente). Esto hace que Stendhal sea muy resistente al retraso.
Nota: Algunos otros juegos confían en el cliente hasta cierto punto para minimizar el impacto del retraso de la red. En WoW a menudo se explotaba en uno de los campos de batalla llamado "Warsong Gulch". Hay dos formas en que un jugador con la bandera puede elegir: Encendido en el medio a través de un túnel y uno en la mira derecha que sube la colina. Entonces, un jugador infiel corre hacia el túnel y luego se atrasa. El servidor y los otros clientes continuarán viéndolo correr hacia él. Pero después de un tiempo, este cliente puede decirle al servidor que se dirigió hacia la colina. WoW verificará que la distancia entre las últimas coordenadas transmitidas y las actuales se ajuste al segmento de tiempo y lo aceptará.
Uso de UDP vs. TCP
En versiones anteriores, usábamos UDP para reducir la sobrecarga de TCP. Manejamos paquetes perdidos por nuestra cuenta. Esto funcionó perfectamente en los primeros días del proyecto. Pero cuando el servidor se trasladó de una conexión DSL doméstica a un centro de datos real hace varios años, tuvimos grandes problemas. UDP es (o al menos hace 5 años) extremadamente exigente con la potencia de CPU del hardware del firewall: el conjunto de reglas debe aplicarse a cada paquete UDP. Sin embargo, para TCP, el conjunto de reglas solo se aplica a los primeros 3 paquetes. Después de eso se establece la conexión. Todos los siguientes paquetes omitirán el conjunto de reglas normal porque están en la tabla de seguimiento de conexión o porque no tienen un indicador SYN.
¿Cómo proteger la comunicación y el cliente de la ingeniería inversa?
Arianne es completamente de código abierto, esto incluye el cliente, el servidor, los gráficos, la música. Y, por supuesto, eso incluye nuestra documentación de protocolo e incluso un analizador utilizado para la depuración.
Es fácil proteger la comunicación contra el rastreo no autorizado por parte de terceros que utilizan SSL.
Sin embargo, es imposible protegerlo contra la ingeniería inversa. Claro que puedes ofuscarlo y usar técnicas anti depuración. Pero al final no puede evitar la ingeniería inversa del software que regala a los usuarios. Hay una presentación muy interesante sobre cómo se invirtió Skype a pesar de que los desarrolladores pusieron mucho esfuerzo en las técnicas contra la depuración: http://recon.cx/en/f/vskype-part1.pdf
Nota: Hay algunos países en los que la ingeniería inversa es ilegal o que permiten incluir un párrafo en la licencia o ToS que no permiten la ingeniería inversa. Pero hay otros países (como el que estoy viviendo) que permiten explícitamente la ingeniería inversa en el contexto del desarrollo de formatos de almacenamiento de datos compatibles o protocolos de transmisión, párrafos en la licencia o ToS que intentan rechazar que son nulos. (Todo lo que se incluye en esta sección es, por lo que sé, no soy abogado)
¿Qué cosas deben calcularse localmente y qué cosas en el servidor?
Calculamos todo lo relacionado con la lógica del juego en el servidor. El cliente predecirá ciertos eventos para que el juego funcione sin problemas. Pero al final el servidor siempre tiene la razón.
Los eventos predichos son, por ejemplo, la detención del movimiento cuando se golpea una colisión. Stendhal usa una cuadrícula para posicionar elementos. Y desde el punto de vista del servidor, la esquina superior izquierda de cada entidad está exactamente en un cuadrado. Pero el cliente los moverá suavemente entre los mosaicos. También dibujará el pseudo efecto 3d. Entonces, una entidad que tiene una base de 1x1 puede ser más alta en el cliente.
¿Cómo equilibrar los problemas de carga?
Trate de mantener esto lo más simple posible, para facilitar el mantenimiento.
El equilibrio de carga de contenido estático es bien conocido en el área de clústeres de servidores http y redes de distribución de contenido.
Un concepto bastante simple para el equilibrio de carga de los servicios de juegos es dividir servidores en regiones / zonas. Entonces las zonas AC están en un servidor y las zonas DF están en otro. Esto es especialmente fácil si no puede mirar desde zonas en un conjunto a zonas en otro conjunto. Debe poner algunas comprobaciones allí para que un cliente solo pueda conectarse a un servidor de zona responsable de la zona en la que se encuentra el jugador.
La forma más fácil de transferir jugadores de un servidor a otro es escribirlos en la base de datos, decirle al cliente que se conecte al otro servidor de zona y desconectarlos del actual. El cliente se conectará al nuevo servidor de zona que lo cargará desde la base de datos. (Como necesita la carga desde / almacenar al código de la base de datos de todos modos, la comunicación directa entre los servidores para la transferencia puede implementarse más adelante).
Se necesitan algunos servicios globales adicionales a través de: Al iniciar sesión, se debe indicar a los clientes que se conecten al servidor de zona correcto. Y es posible que desee un sistema de chat mundial.
Entré en detalles sobre este tema en ¿Cómo se logra el equilibrio de carga en los MMO?
fuente
http://gafferongames.com/networking-for-game-programmers/
Es un gran conjunto de artículos sobre diversos problemas y soluciones relacionados con las redes de juegos.
fuente
Dependiendo del tipo de juego que estés escribiendo, es posible que puedas evitar parte de la programación de red de bajo nivel. Algunos tipos de juegos no requieren mucha comunicación de ida y vuelta entre los clientes y el servidor. En tales casos, uno podría optar por utilizar un marco de nivel superior. Por ejemplo, estoy desarrollando un juego de estrategia por turnos en C # /. NET. Los juegos de estrategia por turnos son algo únicos, ya que la gran mayoría de la comunicación cliente / servidor se produce al principio y al final de un turno, con relativamente poco en el medio. Por lo tanto, opté por utilizar Windows Communication Foundation (WCF), un marco de comunicaciones de alto nivel diseñado principalmente para servicios web. En lugar de trabajar directamente con sockets y toda esa basura de redes de bajo nivel, puedo hacer lo que parecen ser llamadas a métodos estándar, y dejar que WCF se encargue del protocolo y las capas de transporte por mí. La única vez que tuve que lidiar con las cosas de la red de bajo nivel fue cuando configuré mis puntos finales, que es más o menos una sola vez en un archivo de configuración. Puede que aún sea necesario implementar alguna lógica de serialización personalizada, pero debería hacer ese tipo de cosas independientemente.
fuente
La pregunta es demasiado amplia. Las respuestas podrían llenar un sitio web por su cuenta. Pero, hay libros que tocan esto, principalmente estos dos:
Tenga en cuenta que incluso estos libros no son una guía completa, sino que son una colección de ideas y enfoques que puede usar, algunos de los cuales no funcionarán juntos, o incluso son contradictorios. Por lo general, supone cierta experiencia desarrollando juegos, aplicaciones de red o, idealmente, ambos.
(Tenga en cuenta que estoy hablando más sobre los MMO en la pregunta original: un 'juego de red' podría significar todo tipo de cosas, desde un juego de texto basado en PHP hasta un MMO, y las subpreguntas anteriores no todas aplicar a cada tipo).
fuente
tamaño geográfico fijo + instancias múltiples es la solución más fácil. Los chicos que trabajan en SWG probaron el tamaño dinámico y lo lamentaron.
El servidor tiene autoridad.
Actualizaciones periódicas de sincronización del servidor. (no estoy seguro de cuál es la preocupación aquí)
Imposible. solo asegúrese de no confiar en nada de lo que reciba del cliente y de que el servidor tenga autoridad.
Esto va muy lejos, pero superficialmente ejecutas la misma simulación en el cliente que en el servidor y cuando ocurre la sincronización, arregla las cosas. Todas las decisiones tomadas en el cliente también se simulan en el servidor, por lo que puede haber malas decisiones, pero las cosas generalmente funcionan.
Piense en el cliente como si ejecutara una simulación no autorizada de lo que está sucediendo en el servidor. La capacidad de respuesta es clave para la experiencia del jugador, por lo que debes hacer algo cada vez que un jugador toma una decisión, incluso si solo está comenzando un compás.
A decir verdad, muchos de estos problemas son ortogonales y pueden aplicarse soluciones más adelante. Simplemente comienza a hacer el juego y no te preocupes demasiado por estas cosas.
fuente
Esta pregunta es muy amplia. También es un área muy difícil de dominar, los programadores de red son muy buscados en la industria con un salario equivalente, lo que indica que es un área 'no resuelta'. ¿Hay libros por ahí? Sí, muchos. ¿Hay buenos libros por ahí, sin duda? ¿Hay libros por ahí que responderán a sus preguntas? ... No lo creo. Es posible que tengan soluciones que funcionen en algunas situaciones o indicadores sobre qué buscar, pero casi todas sus preguntas dependen del juego ... esta es un área en la que realmente tendrá que trabajar mucho solo, aparentemente trivial y puede salir mal de muchas maneras (no controladas).
fuente