Arquitectura de servidor para un juego multijugador? [cerrado]

Question

Estoy planeando construir un pequeño juego multijugador que podría ejecutarse como un applet de Java o un archivo flash en el navegador web. No he hecho ninguna programación de servidor antes, así que me pregunto qué tipo de arquitectura de servidor debería tener.

Será fácil para mí crear archivos perl / php en el servidor, que el código java / flash contacta para actualizar la posición / acciones del jugador, etc. Pero estoy considerando si debería obtener un servidor web dedicado , qué sistema operativo usar, qué base de datos, etc. Además, se debe tener en cuenta la cantidad de ancho de banda utilizado y la escalabilidad.

Otra opción podría ser utilizar un sistema de alojamiento en la nube (a diferencia de un servidor dedicado), por lo que se encargarían de agregar máquinas adicionales a medida que el juego crezca. Siempre que cada servidor ejecute los archivos centrales perl / php para actualizar la base de datos, debería funcionar bien.

Otra opción más podría ser utilizar el motor de aplicaciones de Google.

¡Cualquier idea sobre la arquitectura del servidor, la elección del sistema operativo / base de datos y si mi método de usar scripts perl / php / python para la programación del lado del servidor es bueno, será apreciado!

Answer 1

Debes aclarar más sobre el juego y pensar más sobre la arquitectura en lugar de los detalles de implementación específicos.

La pregunta principal es si su juego será en tiempo real, por turnos o por demoras (por ejemplo, ajedrez por correo electrónico). Otra pregunta es si va a congelar o no el estado para recargas posteriores.

Recomiendo encarecidamente averiguar de antemano si todos los jugadores del mismo juego se alojarán o no en el mismo servidor (por ejemplo, 1000 de 4 partidos de jugador en comparación con 4 partidos de 1000 jugadores cada uno). Si es posible, vaya con el primero y pegue a todos los que están en el mismo juego bajo el mismo servidor. Te resultará bastante difícil sincronizar varios clientes en un servidor, en lugar de tener varios servidores con los que se sincronizan los jugadores. De lo contrario, la definición de coherencia es problemática.

Si es posible, haga que cada cliente se comunique con el servidor y luego el servidor distribuya las actualizaciones a los clientes. De esta manera, tiene un '' estado oficial '', y puede hacer una variedad de resoluciones de conflictos, fantasmas, etc. Peer to peer ofrece un mejor rendimiento en juegos más rápidos (por ejemplo, FPS), pero presenta muchos problemas.

No puedo por mi vida ver ninguna razón convincente para hacer esto y perl o PHP. Tu juego no está basado en la web, ¿por qué escribirlo en un lenguaje orientado a la web? Utilice el viejo J2EE para el servidor e intercambie datos con sus clientes a través de XML y AJAX. Si es posible, ejecute una aplicación Java real en clientes en lugar de servlets. Entonces puede beneficiarse del uso de JMS, que le quitará una gran carga al abstraer muchos de los detalles de comunicación para usted.

Answer 2

Para la arquitectura de su servidor, puede echar un vistazo a Código de tres anillos . Han escrito varios juegos muy escalables en Java (tanto del lado del cliente como del servidor).

Answer 3

También desalentaría el uso de PHP, también HTTP no es la mejor idea ya que no tiene estado y es hablador. Estuve trabajando durante algún tiempo en una compañía que actualmente desarrolla un juego multijugador realmente masivo. El back-end es JVM simple (se conecta a través de tomcat por múltiples clientes y desde móviles uno por cliente). Entonces sé que cuantos menos datos transfieras, las memorias intermedias más pequeñas que necesitas en el servidor, > más clientes en una máquina y también respuestas un poco más rápidas. También considere la seguridad, https es bastante costoso, especialmente si necesita transferir gráficos y sonidos. El protocolo Binnary propio con un contenedor de cliente que no sea navegador haría lo mejor (una buena opción es el protocolo conmutable para el tiempo de depuración de desarrollo). Quizás suene complicado pero no lo es.

@Sarah buena pista, gracias también;)