Arquitectura para el juego de navegador multijugador social (opción de backend + opción de interfaz [flash / silverlight]) [cerrado]

Question

Estoy pensando en desarrollar un juego social multijugador en línea. El estado compartido del mundo requeriría algo rápido en el backend, por lo que las posibles soluciones parecen ser:

1. motor de juego rápido en el servidor (p. ej. c ++) y algún lenguaje frontend (php / python / ruby) + flash

2. pila completa en python (usando python retorcido o sin pila) + flash

3. .NET (asp.net o asp.net mvc) + flash

4. .NET + silverlight

el primero puede ser una exageración desde el punto de vista de la productividad (3 capas heterogéneas)

Nr. 4 puede ser el paraíso del programador (entorno común en todas las capas), pero:

• No se ha construido algo así con Silverlight, tal vez hay algunos topes ocultos a la vuelta de la esquina
• Puede ser difícil encontrar diseñadores de Silverlight
• A pesar de que se critica el modelo de película / clip Flash en comparación con la arquitectura SL OO completa, ¿no es una ventaja cuando se trata de diseñar partes adicionales del mundo virtual por diseñadores externos? Simplemente pueden preparar .swf con, por ejemplo, 4 perspectivas de un elemento en 4 cuadros: ¿no sería más difícil con SL?
• Silvelight aparentemente carece de algunas funciones de juego (como detección de colisión)

¿Qué opinas?

[EDITAR] El juego en sí sería parte del portal más grande, por lo tanto, sería bueno integrar el motor con algún marco web.

Answer 1

La opción 2, usar Python sin pila, es lo que usa Eve Online.

http://support.eve-online.com /Pages/KB/Article.aspx?id=128

---

Editar

Hasta que tenga un software real, por supuesto, es imposible crear una arquitectura que funcione razonablemente bien. Entonces, cualquier juicio aquí es solo especulación ociosa.

Considere lo siguiente, sin embargo.

1. El contenido estático (archivos .js, .css, .png, etc.) tiende a dominar el ancho de banda de su red. Tendrá que usar un servidor proxy inverso (por ejemplo, calamar) para manejar esto.

2. Squid tiene que obtener el contenido de alguna parte. Desea un servidor de archivos ligero que proporcione contenido estático a los calamares. Nginx o lighttpd o algo así. Apache funcionará para esto, pero, hasta cierto punto, podría ser excesivo.

3. Su contenido dinámico, al parecer, tendrá dos formas.

   • JSON para soportar el juego.

   • HTML para admitir el portal.

   Para esto, sería más feliz con un motor mod_wsgi. Apache ciertamente hace esto; ngingnx y lighttpd también podrían funcionar.

   • Su material JSON debe ser un conjunto de URI. REST es un buen patrón de diseño. A través de mod_wsgi, estos se conectan al servidor orientado al juego usando, si es necesario, Python sin pila. Su front-end (Apache, por ejemplo) tiene una ubicación, directorio o host virtual para filtrar estos URI y enrutarlos a un demonio mod_wsgi que sirve el juego. Mire Wekzeug para construir esto.

   • Su contenido HTML es otro conjunto de URI. A través de mod_wsgi, estos se conectan a un servidor Django que ejecuta Python convencional. Su front-end (Apache, por ejemplo) tiene una ubicación, directorio o host virtual para filtrar estos URI y enrutarlos a un demonio mod_wsgi.

Answer 2

Pasé un año trabajando en un juego multijugador masivo en línea usando Silverlight para el frontend y Python para el backend (en realidad usé IronPython en Silverlight para simplificar el desarrollo)

Silverlight es muy adecuado para esto, no haría un juego en línea serio en ninguna otra cosa. Ya tiene el 35% del mercado, para cuando haya terminado de desarrollarlo debería ser lo suficientemente alto como para no importar mucho más. Para juegos serios, a la mayoría de las personas realmente no les importará instalar un complemento de navegador de 4MB. Si solo quieres un pequeño clon de asteroides, usa flash.

Si tuviera que hacerlo de nuevo, creo que mantendría Python para el servidor, porque es la tecnología de servidor con la que estoy más capacitado, pero creo que usaría C # en la interfaz y usaría JSON para pasar datos .

El mejor consejo que puedo darle es:

1. Utilice las bibliotecas y el código existentes tanto como sea posible
2. No pienses en el rendimiento prematuramente

La parte más difícil será terminar el juego, usar tecnología que conozcas bien y optimizar tu tiempo, no el código. Espero que puedas hacer lo que yo no pude: terminar el maldito juego :)

Editar

Con respecto a por qué usaría C # si tuviera que hacerlo de nuevo:

IronPython tenía sus ventajas y desventajas. Fue genial poder compartir archivos de código (constantes, modelos, etc.) entre el servidor y el cliente. Hacer un cambio y actualizar el navegador para ver que fue increíble. La depuración no fue tan amigable como C #.

Pero de alguna manera es un ciudadano de segunda clase para C #, el enlace de datos no funcionó y no se pueden usar las clases IronPython en xaml. El tiempo de carga era un problema, por lo que dediqué mucho esfuerzo para configurar la importación en paralelo en subprocesos en segundo plano para acelerarlo. Debido al segundo estado de ciudadano en lo que respecta a xaml, utilicé un lenguaje de plantilla para generar el xaml como si fuera html, que en realidad funcionó mejor que el enlace de datos, pero ningún lenguaje de plantilla de Python funcionó en IronPython, así que escribí el mío ( otra vez se hunden.)

Para habilitar el uso compartido de modelos tuve que escribir mi propio ORM. Eso fue bastante fácil. Pero para transferirlos pasé JSON e hice un formato binario optimizado que funcionó entre IronPython y Python. Ese fue otro sumidero de tiempo.

En retrospectiva, no debería haberme distraído con todos esos senderos de conejos.

Answer 3

Twisted se ha utilizado para este propósito con éxito. Al estar basado en llamadas asincrónicas, es muy eficiente para aplicaciones que requieren conexiones persistentes. También tiene una buena implementación RTMP para usar con flash. Compruebe chesspark, está construido con Twisted:

http://www.chesspark.com/

Además, el motor del juego realmente no tiene que estar en c / c ++. Depende de la complejidad y el tipo de juego. Pero también está la biblioteca de pygame, que es bastante buena.

Personalmente, te desanimaría de usar Silverlight. El complemento flash se adopta mucho mejor y continuará en el futuro previsible, especialmente en sistemas operativos que no sean MS. No tomes esto en serio, pero no instalaría Silverlight solo para ver tu juego.