¿Arquitectura de servidor para un juego multijugador?

Question

Estoy planeando crear un pequeño juego de varios jugadores 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.

Me será fácil crear archivos perl/php en el servidor, que el código java/flash se contacta para actualizar la posición/acciones del reproductor, etc. Pero estoy considerando si debería obtener una web dedicada host, qué sistema operativo usar, qué base de datos, etc. Además, la cantidad de ancho de banda utilizado y la escalabilidad es una consideración.

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

Otra opción podría ser usar el motor de la aplicación de Google.

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

Answer 1

Necesita aclarar más sobre el juego y pensar más en arquitectura que en detalles específicos de implementación.

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

Recomiendo encarecidamente saber si todos los jugadores en el 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. Tendrá tiempo suficiente para sincronizar múltiples clientes a un servidor, en lugar de tener múltiples servidores contra los cuales los jugadores están sincronizados. De lo contrario, la definición de consistencia 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 tienes un "estado oficial" y puedes 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 introduce toneladas de problemas.

No puedo 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 buen 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 real de Java en clientes en lugar de servlets. A continuación, puede beneficiarse del uso de JMS, lo que le quitará una gran carga de la espalda al resumir muchos de los detalles de comunicación por usted.

Answer 2

Para la arquitectura de su servidor, puede echarle un vistazo a Three Rings' code. 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 es sin estado y locuaz. Estuve trabajando durante un tiempo en una empresa 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 de móviles uno por cliente). Así que sé que mientras menos datos transfiera, los búferes más pequeños que necesita 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 costosa, especialmente si necesita transferir gráficos y sonidos.Su propio protocolo Binnary con contenedor de cliente que no es navegador haría lo mejor (buena opción es el protocolo conmutable para el tiempo de depuración del desarrollo). Tal vez suena complicado, pero no lo es.

@Sarah buena pista, gracias también;)