Lo hice para un juego de carreras comercial de PSP, que funcionó tanto en una red ad hoc como a través de un punto de acceso inalámbrico. (O a un servidor estático en Internet, si lo desea)
Debido al punto 2, el sistema no necesita ser complejo con respecto a la optimización
En mi experiencia, esto no es cierto. Los dispositivos inalámbricos (especialmente los portátiles pequeños) no son como las computadoras con conexiones de red cableadas: los teléfonos inteligentes y las consolas de juegos inalámbricas tienden a tener interfaces de red lentas para fines de juego.
No me malinterpreten: su rendimiento suele ser bueno (es decir, la cantidad de datos por segundo; excelente para la transmisión de películas o etc.), pero la latencia en la entrega de un paquete en particular puede ser extremadamente mala, y puede serlo. Es muy variable que sea difícil incluso estimar cuánto tiempo llevará entregar un paquete individual. Esta variación empeora aún más a medida que se agrupan más dispositivos inalámbricos en un área general, ya que sus señales comienzan a interferir entre sí. Como resultado de esto, pasé mucho de mi tiempo reduciendo la cantidad de paquetes que debían enviarse, por lo que tendríamos menos colisiones de paquetes. (Tenga en cuenta que esto es un problema menor en el caso de que esté involucrado un punto de acceso de red alimentado, en lugar de hacer que los dispositivos se comuniquen entre sí directamente a través de una red ad hoc)
Como ejemplo de este tipo de optimización, nuestro juego de carreras tuvo lugar en un mundo que tenía semáforos. Miles de ellos Y teníamos que asegurarnos de que sus señales estuvieran sincronizadas entre todos los jugadores en una sesión de red. En lugar de tratar de enviar paquetes diciéndoles a todos qué luces estaban en qué estado, definimos un horario estático para todos los semáforos, y luego nos aseguramos de que todos los clientes estuvieran de acuerdo con el "tiempo de juego" actual. Como todos sabían el tiempo del juego, y todos los estados de los semáforos podían determinarse a partir del tiempo del juego, sincronizamos todos esos datos de estado sin enviar ningún dato especial. Este cambio hizo una gran diferencia para nuestro rendimiento de red.
Dicho esto, establecer una sincronización de reloj confiable entre múltiples dispositivos inalámbricos (con tiempos de ping muy variables debido en gran parte a la pérdida de paquetes) fue un gran desafío. Feliz de hablar más sobre eso si tiene interés.
Cada cliente puede ser una fuente autorizada de datos sobre sí mismo y su entorno inmediato (por ejemplo, viñetas).
Esto es lo que hicimos, y funcionó bien para nosotros en nuestra situación (automóviles). La parte problemática, por supuesto, es cuando un objeto deja de estar más cerca del jugador 'a' que del jugador 'b', y su propiedad, por lo tanto, se transfiere de un jugador a otro.
Esta es en realidad una negociación sorprendentemente compleja entre jugadores, donde el juego 'a' propone el juego 'b': "Creo que este objeto está más cerca de ti. Debes tomar el control de él". Y luego el juego 'b' puede aceptar o rechazar, en función de su propia visión de la situación. Las diferencias en el estado percibido del juego entre 'a' y 'b', y el cambio en el tiempo entre el envío y la recepción de la solicitud y la respuesta hacen que esta sea una pequeña negociación particularmente desagradable para ser confiable, y puede degenerar fácilmente en un juego de "papa caliente", con propiedad de objetos que se balancea continuamente entre múltiples jugadores. E incluso cuando funciona correctamente, cuando se ve desde el punto de vista del juego 'c', allí '
Mi intuición es que este tipo de enfoque de "propiedad de objetos" probablemente sea demasiado engorroso para objetos pequeños y de corta duración como las balas. Lo usamos para autos de tráfico y corredores de IA, que tendieron a vivir en la simulación durante un tiempo relativamente largo. Parece que un enfoque más eficaz, si estás dispuesto a confiar en los clientes, sería hacer que el juego de cada jugador sea dueño de su posición y sus proyectiles, y declarar cuándo ese jugador ha sido golpeado por el proyectil de otra persona. (Entonces, como "juego A", soy responsable de decir dónde están los proyectiles del jugador A y del jugador A, pero el jugador B es responsable de decir si he golpeado al jugador B). Con un buen cálculo de los muertos, debería ser capaz de obtener un comportamiento bastante razonable de un sistema como este.