Básicamente el título lo dice todo. He visto y trabajado con Django, Rails y un poco con Cake PHP. Me gustaría saber si hay un marco que sea excelente para admitir el desarrollo casual de juegos basados en navegador, 2D. Lo más cercano que he visto es flash, pero me gustaría encontrar algo de código abierto. Algo que pueda manejar tanto los gráficos como la comunicación a una base de datos sería ideal. ¿Alguna sugerencia?
browser-based-games
casual-games
Albert Perrien II
fuente
fuente
Respuestas:
Mantengo una lista de recursos relacionados con el desarrollo de juegos javascript que he encontrado útiles, incluida una lista de motores de juegos y servicios web que puede integrar.
Debe realizar un seguimiento de dos conceptos diferentes: presentación del lado del cliente y procesamiento del lado del servidor. Si está desarrollando un juego casual de estilo flash, el juego completo probablemente será la presentación del lado del cliente, mezclado con algunos servicios web para obtener puntajes altos y similares. Sin embargo, si quieres hacer muchos juegos de estilo social, multijugador o estilo mmo, si no la mayoría del juego estará en el servidor para evitar trampas, y el cliente simplemente actuará como una terminal tonta. Cómo se maneja eso es probablemente un tema para otra pregunta.
De interés para cualquiera que quiera comunicarse en tiempo real entre el navegador y el servidor debe ser socket.io, que es una abstracción en la parte superior de los websockets con respaldo utilizando flash en navegadores antiguos.
fuente
Hay varios motores / marcos de juego emergentes con HTML5. Aquí hay algunos enlaces que pueden ser de interés:
Además del Rocket Engine, estos motores solo cubren el lado del cliente de un juego. Por lo tanto, no hay comunicación directa con una base de datos (a menos que esté usando algo como Google Gears ).
Dependiendo de su juego, todavía tiene que implementar algunas cosas de back-end en Ruby, Java, PHP, ASP o similar. En mi humilde opinión, cualquier marco de aplicación web regular será suficiente para eso. Node.js probablemente merece una mención especial, porque puede implementar el backend en el mismo idioma que su juego (JavaScript).
fuente
La cuestión es que, en el desarrollo web, una gran parte de la presentación generalmente se realizaría en el lado del servidor (utilizando un marco que incrusta algún tipo de sistema de plantillas para enviar HTML al cliente). Si quieres hacer un juego interactivo, gran parte del trabajo tiene que suceder en el lado del cliente (en el navegador), por lo que el problema no es tanto cómo generas HTML, sino cómo haces que las cosas se muevan en la pantalla del usuario.
Para esta parte del lado del cliente, como se mencionó, su elección es Flash o JS (potencialmente usando Canvas para el navegador moderno).
Para la parte de comunicación cliente-servidor-base de datos, cualquiera de las tecnologías que mencionó estaría bien. El navegador y el servidor pueden comunicarse mediante llamadas ajax clásicas si es necesario.
No conozco un marco que pueda manejar ambos problemas, pero probablemente sea porque son realmente distintos y suceden en un lado diferente de la combinación cliente-servidor.
fuente