Publicado el Deja un comentario

Explorando el multijugador para WebGL: mi experiencia con Colyseus y próximos pasos

En la búsqueda de nuevos caminos para explorar en el desarrollo de videojuegos, uno de los grandes retos que surgió fue cómo implementar multijugador en un juego WebGL, pensando en su futura publicación en plataformas como Poki.com o Itch.io.

En el mundo de los navegadores, el multijugador tiene un punto en común: todo debe funcionar sobre WebSockets. Esto es por las restricciones de seguridad de los navegadores, que no permiten el uso de protocolos como UDP, habituales en los juegos nativos.

Con esta limitación en mente, decidí comenzar explorando algunas de las tecnologías más sonadas para multijugador WebGL.

Mi primera parada: Colyseus

La primera tecnología que probé fue Colyseus, un framework open source que combina un servidor en Node.js con clientes en varios lenguajes (incluido Unity).

Lo que más me llamó la atención de Colyseus fue su propuesta:

  • Salas (rooms): donde los jugadores se conectan y comparten estado.
  • Schemas: estructuras de datos que se sincronizan automáticamente entre el servidor y el cliente.

La idea me parecía elegante: en lugar de enviar cada posición o evento manualmente, defines un “schema” que representa el estado del juego, y Colyseus se encarga de mantenerlo sincronizado.

Pero… también me encontré con algunos retos:

  • La curva de aprendizaje no es trivial. Los schemas requieren compilarse y aprender a trabajar con su formato.
  • Es necesario instalar varias dependencias y manejar un entorno Node.js.
  • Si solo quieres algo simple (por ejemplo, mandar posiciones y disparos), puede sentirse que estás “cargando una maquinaria grande para un problema pequeño”.

En otras palabras: Colyseus no es plug & play. Es poderoso, pero implica aprender y adoptar su forma de hacer las cosas.

¿Y ahora qué sigue?

Después de probar Colyseus, me quedó claro que necesito evaluar qué tanto de esa complejidad vale la pena para mi proyecto.

Mis siguientes pasos son:

  1. Probar WebSockets puros.
    • Montar un pequeño servidor en Node.js con ws.
    • Enviar datos básicos (conexión, movimiento, disparos) y entender bien el flujo.
  2. Explorar Unity Netcode con transporte WebSockets.
    • Ver si puedo mantenerme dentro del ecosistema Unity sin perder flexibilidad.
  3. Decidir cuál es la mejor tecnología según el tipo de multijugador que quiero:
    • ¿Algo casual, donde basta con ver a otros jugadores moviéndose?
    • ¿O algo más profundo que necesite sincronización compleja del estado del juego?

Conclusión
Por ahora, Colyseus me dejó una buena impresión como tecnología potente, pero con una curva que debo evaluar si realmente necesito recorrer.
Mi siguiente meta es probar WebSockets desde cero para entender las bases, y luego decidir si vuelvo a una solución más robusta o si mantengo un enfoque minimalista.

En el camino, iré compartiendo lo que aprendo sobre estas tecnologías y cómo encajan en el desarrollo de un juego WebGL.

Publicado el Deja un comentario

Como NO programar un juego multijugador HTML5

A continuación presento un proyecto en el que estuve trabajando, que en papel es súper interesante debido a la implementación multijugador entre Phaser y Croquet.IO, sin embargo he llegado a constatar ciertas características que debo tomar en cuenta antes de continuar con el desarrollo de un juego como el planteado.

Se trata de un juego tipo PACMAN, AGAR.io, Bomberman, una mezcla de jugabilidad que pensaba podía implementar fácilmente utilizando la tecnología Croquet.IO.

El prototipo funciona bastante bien hasta donde logré desarrollarlo, y se puede apreciar las bondades de utilizar Croquet como marco de desarrollo para juegos multijugador.

Sin embargo tuve que detener el proyecto al constatar que la forma en la que estaba implementando ciertas características de los juegos multijugador es incorrecta.

El prototipo tiene el problema que al momento remite la información en tiempo real de todos los jugadores conectados pero no hace ningún cálculo en el servidor de predicción, lo que provoca desfases al actualizar la posición de cada jugador en los diferentes clientes conectados. Es un típico problema de programación de juegos multijugador en los que normalmente se deja al servidor predecir la posición de todos los jugadores conectados, sin embargo por ser algo nuevo en este tipo de desarrollos decidí ver con mis propios ojos este problema de latencia, y he terminado en un camino que todavía debo descifrar frente a la programación de videojuegos multijugador.

Se puede apreciar dos jugadores conectados al mismo tiempo

¿Qué hace al momento este videojuego?

Este pequeño desarrollo hasta el momento es capaz de administrar las conexiones en un canal determinado randómico que puede ser compartido para jugar con quien se requiera para probarlo. Si se habilita la consola de desarrollo del navegador web se podrá ver algo de esta implementación en práctica, para probarlo a manera de multijugador, en la pantalla de inicio se debe escoger «play with friends»

El sistema genera un cuarto aleatoreo

El sistema genera un ID para jugar y un URL que se debe compartir con las personas a jugar. El sistema registra los usuarios e internamente crea una instancia de juego en por cada jugador conectado, esto es parte de la tecnología Croquet, que como ventaja principal frente a las implementaciones tradicionales por ejemplo con socket.io, NO SE REQUIERE la implementación de un servidor dedicado que administre las conexiones, sino que con una infraestructura propietaria evita al desarrollador tener que hacer toda la implementación multijugador y simplemente permite enfocarse en el desarrollo del videojuego.

Nótese la conjunción entre Croquet y Phaser

Para ver el videojuego y probar la implementación con Croquet.IO y Phaser puedes dar click en el siguiente enlace:

CLICK PARA IR AL PROYECTO