Golang es un lenguaje perfecto para trabajar en el mundo del backend, gracias a su velocidad de ejecución, sus librerías estáticas y su capacidad para la concurrencia.
Sin embargo, es poco considerado en el mundo del gaming, probablemente por su poco acceso a interfaces gráficas, la dificultad de crear aplicaciones mobile y la mala fama que tienen los garbage collectors en el mundo del gaming.
Tampoco vamos a obviar que entornos como Godot o Unity, donde gran parte del boilerplate se hace a golpe de click y te permiten tenerlo todo bajo control en el mismo entorno, ayudan poco a que la gente se lie con go en el mundo del gaming.
El escenario.
Existen un tipo de juegos que pueden beneficiarse mucho de un lenguaje tan rápido como Golang. Los juegos de tipo multijugador masivo que tan de moda se han puesto.
Este tipo de juegos mantienen gran parte del estado del juego en el servidor. La idea es que todo el juego se mantiene en un server centralizado que se comunica con cada uno de los clientes pasando el estado apropiado. El cliente es quien realiza la magia de hacer que todo vaya fluido y perfecto, pero siguiendo siempre las ordenes que recibe desde el server.
El ejercicio que propongo aquí se basa en un juego tipo slither.io donde unas peonzas controladas por los usuarios rebotan en un mundo que vive en el servidor. Para el motor de física hemos propongo usar el port de box2d que hicieron los amigos de ByteArena
Para renderizar, cambiaremos la foto completamente y usaremos el framework phaser y javascript.
En todo caso, como yo soy un programador de backend, estoy enfocando el problema como un server que proporciona un API a un cliente frontend. Si el rendimiento de Phaser no es adecuado, o necesitamos un cliente no html, siempre podríamos programarlo en Unity, Godot o cualquier otra cosa y seguir usando el mismo backend.
Box2D
Box2D es un motor de física en 2D que funciona verdaderamente bien. Tiene ya unos años, se programó entre el 2006 y 2008 en C++ por Erin Catto. Muchos juegos importantes la han usado y está incluido como motor de física en la mayoria de frameworks. Ha sido portada a prácticamente todos los lenguajes usados en el gaming. La versión de go no está documentada pero no es difícil moverse usando la documentación original escrita para C++. Es un producto tan bueno que apenas ha cambiado con los años.
Phaser
Phaser es un framework javascript fantástico para hacer juegos en html5 accediendo directamente a webgl, aunque también es capaz de hacer fallback a canvas.
La capacidad de acceso a WebGL permite a los navegadores usar las funciones de renderizado de la tarjeta gráfica. A pesar de que webGL no nos va a dar lo mismo que Open GL o DirectX, os aseguro que el rendimiento y la cantidad de cosas que pueden hacerse es muy alto, llegando a calidades que uno no imaginaría en un browser y javascript.
Phaser proporciona varios motores de física, y uno de ellos es, Box2D. O sea que tenemos la posibilidad de pensar en 2 mundos diferentes con el mismo motor físico.
De todos modos, apenas usaremos el motor de físicas de phaser. Las colisiones, creación o destrucción de objetos y toda la lógica del juego se realizarán en el server. Phaser se encargará sólo de dibujar. Crearemos objetos que en el server sólo son círculos, pero que en phaser se decorarán ricamente. El server irá actualizando velocidad y posición y phaser se encargará de mover los objetos «aproximadamente» al mismo lugar que dice el server.
A primera vista, usar un framework web puede parecer que nos limite mercado sólo a los navegadores. Pero siempre podemos encapsular esa «web» en un electron, por ejemplo, para tener una aplicación standalone o usar Phonegap para crear una aplicación mobile.
¿Y las comunicaciones? Websockets al rescate.
Ya tenemos el mundo virtual moviéndose en el server y un fantástico framework como Phaser para dibujarlo en el cliente. ¿Pero, como nos comunicamos?
Existe muchísima documentación en el mundo del gaming sobre como implementar comunicaciones. El gaming necesita de mucho ancho de banda y poca latencia, por lo que el consenso general es que TCP es lento y que toda implementación que se precie debe pasar por UDP y técnicas muy esotéticas de gestión de paquetes.
Yo no estoy especialmente de acuerdo en eso. Como el escenario que estamos planteando usa javascript y correrá en un browser, no nos quedan muchas alternativas de comunicación.
Podemos usar llamadas HTTP vía ajax, pero eso nos va a complicar la vida terriblemente, dado lo ineficaz del protocolo para datos pequeños. Tampoco tendríamos una manera sencilla de implementar comunicaciones a demanda del servidor, o hacer broadcasting a todos los clientes.
La solución pasan por los websockets. Estos nos permiten abrir un canal de comunicación TCP a partir de una primera llamada HTTP. La comunicación es óptima, permitiendo enviar datos binarios, y además es bidireccional, es decir, el servidor puede enviar el dato que quiera cuando quiera.
El único problema es la latencia, especialmente en redes móviles o en WIFI. En mi opinión, este es un problema con el que tendremos que vivir. Deberemos diseñar el juego de manera que una latencia de 10 o 20ms no sea un problema para la experiencia de juego.
Juegos como slither.io o agar.io están usando websockets para sus comunicaciones y su experiencia de usuario es más que correcta en la mayoría de ocasiones.
Otra ventaja de los websockets es que tanto Golang como javascript manejan muy bien el protocolo, permitiendo usar unas comunicaciones estándar que luego nos van a dar mucha flexibilidad para implementar nuevos clientes.
En un principio usaremos jsons para codificar mensajes. No es lo más óptimo, dado su elevado peso en datos binarios, pero es legible y fácil de procesar por javascript. No soy muy amigo de las early optimizations, o sea que primero llevaremos json al límite y luego buscaremos una mensajería más compacta.
Pero.. ¿Funciona?
Y tanto que funciona. No sólo eso. Tengo una versión casi implementada que pronto os enseñaré y probablemente diseccionaré en este blog.
No considero que el código esté en absoluto presentable aún, por lo que no voy a enlazarlo. Aunque los más espabilados quizás son capaces de encontrarlo en mi github, mezclado en alguno de los proyectos.