Duda programación Php para juego en Html5

[adolfoeresidiota]

Hola, amigos. Llevo tiempo aprendiendo html5, js y php con el objetivo de diseñar algún juego de navegador bien bonito. Pero me gustaría dar un salto y tratar de desarrollar un juego online, ya sea un mmorpg similar a BrowserQuest o uno con salas (cualquier minijuego multijugador).

Mi duda es la siguiente:

Con php y una base de datos que actualice posiciones se podría hacer (o daria mucho lag?

O por el contrario tengo que meterme a aprender a usar sockets?

Gracias, amigos.

[Nemutagk]

Sin querer destruir tus sueños pero, diseñar un MMO no es nada sencillo, ni en web ni escritorio, primero domina los lenguajes a usar y luego piensas en grande (aprende a caminar y luego corres), lo digo porque el simple hecho de pensar en usar una DB para guardar posiciones y mover en cada refresco es completamente ilógico (por no decir otra cosa), solo imagina cuantas veces tendrías que actualizar/insertar datos para actualizar la posición del usuario, y ya ni hablemos para obtener la posición actual de los jugadores al rededor del jugador principal (el que estés manejando), con solo esa información volarías (por decir de alguna forma) el servidor DB cuando sean un numero grande de usuarios usando el juego al mismo tiempo, eso sin hablar que la mayoría de DB relacionales bloquean las tablas cuando se insertan/actualizan datos, así que tendrías un cuello de botella enorme...

Por cierto, el problema que generarías sería completamente diferente a lag, lag es cuando tarda en llegar la respuesta o información del servidor al cliente, en tu caso el servidor tardaría mucho en procesar para enviar y luego en llegar...

Para finalizar, si quieres ver en el navegador monitos (personajes) moviéndose en tiempo real o al menos en cada refresco deberás usar sockets, pero no con PHP ya que sería algo similar, en todo caso puedes usar websockets con nodejs o similar

[adolfoeresidiota]

Entiendo, gracias por tu respuesta. Me he puesto a mirarme nodejs y me asalta una duda:

Para usarlo necesitas instalar un servidor. El tema es, que si mi proyecto quisiera subirlo a un servidor profesional (arsys, mismamente) podría? he mirado y no veo nada de node.js entre sus especificaciones.

[dashtrash]

Yo he dirigido un proyecto de mmorpg (del tipo "estrategia", subir niveles de cosas, etc,etc), y se usaba la base de datos para mantener posiciones.De hecho, se usaba para *todo*.Cada medio minuto se lanzaban casi 100 queries (incluyendo updates, inserts) sobre datos que salían de tablas con más de 1 millón de propiedades (ojo, "salían", no "estaban").

Pero, para hacerlo así, necesitas 2 cosas clave: particionado e interpolación.El particionado afecta a todo , desde el mapa ("salas"), reloj del juego, contexto de eventos...Y con la interpolación se aparenta "tiempo real", cuando en realidad es un sistema de turnos.

A la vez, estuve trabajando con gente que llevaba otro juego del mismo tipo ("estrategia"), que había ido por la vía de python y un servidor tipo "demonio" que realmente mantenía los objetos en memoria todo el tiempo, etc,etc....Y era una pesadilla de mantener.

Ambos juegos llegaron a tener +100.000 inscritos.Nunca tuve problemas de BD, ahora bien, cada query era optimizada durante horas (incluso días).Y, por supuesto, el js y php que necesitas no es el que usa un blog...

[Nemutagk]

Es interesante lo que cuentas @dashtrash, yo también desarrolle un mmo hace un tiempo, pero de lejos pude obtener un juego fluido con solo PHP y MySQL por ejemplo, pero ojo, que hablo de un juego en navegador en 2D en vista lateral con vista de mobs y otros jugadores en "tiempo real", en donde si me funciono sin problemas es en un mmo tipo ogame o similar, estaría bien que compartieras mas info sobre tu proyecto...

[dashtrash]

En el juego que dirigí (al que llegué cuando algunos programadores ya habían metido las zarpas), había que mantener un mapa de 160x80 (12800) "habitaciones".Cada habitación, a su vez, tenía 40 posiciones internas.
Mientras era importante saber en qué habitación estaba un jugador (lógico), qué posición tenía dentro de la habitación, era aleatoria.
Una traslación directa de estos requisitos a una BD, llevaba a una tabla de...12800*40 = 512000 filas.
Lógicamente, bajo esas condiciones, enviar un mapa completo al cliente, era imposible.
Pero, a la vez, mostrar un interfaz de usuario con 160x80 posiciones de mapa, y con 15000 jugadores por servidor, te lleva a que es imposible mostrar sobre el mapa toda esa información.
Así que hice una primera aproximación: para el mapa global, lo importante es mostrar si no hay nadie en esa "habitación", o si hay alguien (1,2 o más usuarios).Eso se codifica en 2 bits.
Dos bits por 12800 posiciones de mapa, no son más que 25Kb. Esto se puede enviar fácilmente a los clientes, por ajax, y con javascript, decodificar el mapa binario.
Y, cuando un jugador selecciona una cierta habitación, es entonces cuando se consulta la BD para mostrarle todos los jugadores que hay en esa habitación, pero ya es un acceso por primary key.
Quién mantiene ese mapa? El cron job que se ejecuta cada 30 segundos.Mueve las cosas en la base de datos, obtiene quien se ha movido en ese intervalo de tiempo, y actualiza el mapa que vive en memcached.
Por supuesto, el tiempo de moverse de una habitación a otra, era bastante grande (varios minutos, cosas tipicas en juegos tipo ogame), y, en cada turno, el numero de cambios de habitación no era muy grande.
Para las posiciones *dentro* de cada habitación, al ser indiferente qué posición ocupaba cada jugador, con un generador de números pseudoaleatorios, y con el timestamp de entrada en la habitación, era bastante.

Los problemas más serios vinieron....por culpa de los antivirus.Hay muchos antivirus que escanean el tráfico HTTP.Por lo tanto, si usas COMET (y supongo que por eso el OP habla de Node.js), vía iframe o vía ajax, los antivirus retienen todo el tráfico HTTP hasta recibir la respuesta completa....que nunca llega.Por lo tanto, el cliente no recibe eventos.

Otras alternativas sería evaluar la posibilidad de usar servidores open-source para juegos existentes.Por ejemplo, para Ultima online existen servidores y clientes open-source.Se puede reaprovechar mucho de ahí, para juegos serios.

Tras dejar esa empresa, hice un motor de pintado isométrico con html5, precisamente para juegos en tiempo real con websockets (sí tengo experiencia en servidores de comunicaciones para juegos en tiempo real...en C, claro)...pero ahora está por algún lado pillando polvo..

[Nemutagk]

Bastante interesante, mi juego funcionaba de forma diferente ya que yo si tenia que enviar la posición "precisa" de cada jugador que estuviera dentro de un rango, ya que los jugadores podrían interactuar entre si, por lo tanto se me alentaba mucho la aplicación y en test con un numero no muy grande el servidor consumía demasiados recursos, probablemente si se depuraba mas podría lograrse algo, pero tocando websockets y nodejs encontré una solución mas fácil y con un consumo mucho mas ligero y lo mejor, comunicación entre jugadores en tiempo real, únicamente usaba la db para persistir la posición del jugador una vez que se cerraba la conexión entre el cliente y el servidor, todo lo demás es posible llevarlo sin problemas con PHP y una DB