Juegos con Golang. Box2d y Phaser

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.


Probando Docker en Windows 10

Hoy quería ponerme con un pequeño proyecto para mejorar una de mis webs. He decidido montarlo como un microservicio separado, ya que se trata de una funcionalidad fácilmente separable y me ha aparecido un pequeño problema logístico. Tengo Windows 10 instalado en casa. Generalmente virtualizo máquinas con vmware player para estas cosas, pero como en Waynabox llevamos un tiempo usando Docker  y le he cogido el gustillo, he pensado que podría probar la nueva implementación de Docker para Windows 10.

Y aquí tenéis mis primeras experiencias en lo que sería una guía para novatos, escrita por un novato.

Lo primero, la documentación oficial

Por algún lado hay que empezar, y lo mejor es leerse la página oficial de Docker al respecto, Getting Started with Docker for Windows.

Aquí encontramos algunas advertencias sobre la versión de Windows necesaria y la necesidad de activar Microsoft Hyper-V. De momento voy a ignorar estos avisos, (mi windows está a la última), espero que no explote en la cara dentro de unos minutos.

Paso 1: Instalando Docker

Lo típico, Descargar docker del enlace oficial, botón siguiente, siguiente, etc… Docker instalado y un aviso de que de Hyper-V no está instalado en mi ordenador y la pregunta de si quiero que Docker lo active por mi… Hasta ahora muy limpio todo, si señor.

hyper-v-not-installed-by-docker

Reinicio el ordenador y vuelvo en un minutos…. ¡Fantástico! Docker está instalado y tengo un icono en la bandeja del sistema que me dice que está corriendo.

De momento el invento funciona muy bien.

Paso 2: Probando Docker en Windows

Seguimos con la guía de instalación, abro una consola de sistema (Recordatorio: He de probar bash para Windows,…) y ejecuto docker run hello-word.

¡Genial! Parece que todo funciona. Ha sido tan fácil que incluso me da vergüenza estar escribiendo este tutorial.

Probaremos algo más ambicioso, descargar un ubuntu y ejecutar bash en modo interactivo dentro de ese ubuntu.

Docker se descargará una imagen de ubuntu en pocos segundos y ejecutará bash dentro de el. Hacemos un ls y en efecto, funciona, exactamente igual que en linux. Estoy corriendo en un windows un container docker que tiene un bash corriendo en ubuntu perfectamente funcional. Para cerrarlo, simplemente ejecutamos exit, lo que cerrará el bash. Al estar en modo interactivo ( parámetro -it), el contenedor de docker se cerrará. Si volvemos a lanzarlo veremos que arranca infinitamente más rápido, ya que ahora no necesita descargar la imagen de ubuntu.

¡Docker mola mucho!

Paso 3: Montando contenedores docker

Bueno.. a partir de ahora habría que seguir por lo obvio, exactamente igual que en linux, crear un archivo de configuración con los contenedores que nos interesen, compartir una unidad de disco entre el contenedor y el host si queremos tocar código de manera fácil, o exportar los logs, mapear los puertos internos y externos, etc..

De todo eso se trata en la propia guía de docker Get Started with Docker y se escapa un poco de lo que pretendía ser este artículo.

Por lo que a mi respecta, me voy a buscar una buena imagen para correr apache con php7 y posiblemente otra para un mongodb o un redis (aún no tengo claro) y crearé un docker compose que me lance las 2 y las configure adecuadamente.

Ejercicio Golang: Cálculo números primos con goroutines

Hace tiempo que voy dándole vueltas a la manera en que se desarrollan la mayoría de aplicaciones web, especialmente en php y cada vez más siento la necesidad de cambiar la manera de trabajar, en realidad, casi de cambiar mi lenguaje de programación habitual, php, por otra cosa.

Uno de los lenguajes que me interesa mucho es golang. Me gusta su sintaxis parecida al C, que es un lenguaje compilado, que está muy pensado para ayudar al programador y, sobretodo, me interesa lo fácil que es crear rutinas que corren en paralelo y que se pueden comunicar limpiamente mediante canales seguros.

Las CPUs de hoy en día tienen múltiples cores, cualquier ordenador doméstico o teléfono puede tener fácilmente entre 2 y 8 cpus corriendo y golang es posiblemente el lenguaje que permite usar esa potencia con más facilidad.

Hoy me he decidido a hacer un pequeño ejercicio, un cálculo de  los números primos en un rango dado de enteros. Quería ver si es fácil implementar un problema simple, y también quería probar si es fácil el uso del cálculo paralelo con Go. La verdad es que me he divertido mucho. Go es fácil de usar, el compilador te ayuda mucho a la hora de programar y la sintaxis es limpia y se entiende muy rápido.

El problema a resolver

El problema es sencillo. Dado un rango de números enteros, por ejemplo 1 a 1.000.000, queremos saber cuales de ellos son números primos.

En un lenguaje tradicional como php, o en java o C++ si no queremos complicarnos la vida, el algoritmo sería algo así como:

Para todos los enteros entre <inicio> y <fin>, si es primo, mételo a la lista y mira el siguiente.

Un número primo es aquel que sólo es divisible por 1 y por si mismo, o sea que es un problema que podría resolverse por fuerza bruta, intentando dividir ese número por todos los inferiores superiores a 1. Si el resto (módulo) de la división es cero en algún momento, el número no es primo. Hay otros métodos más óptimos de calcular un número primo, pero no es ese nuestro objetivo y ya nos va bien para el ejercicio usar un mecanismo de fuerza bruta.

¿Que ocurriría si en lugar de iterar sobre un bucle para cada posible candidato, lanzásemos todos los cálculos en paralelo? A fin de cuentas, ¿a quien no se le ha pasado por la cabeza lanzar un millón de procesos en paralelo y ver como la CPU salta por los aires 😉 ? La respuesta: No ha pasado nada. En mi máquina de pruebas, Go ha sido capaz de ejecutar 1 millón de procesos simultáneos sin pestañear, devolviendo la respuesta en menos de 10 segundos.

Te reto a hacer la prueba con php, java o incluso C++. Y en menos de 100 líneas de código.

El código fuente y cómo instalarlo

No es necesario que te bajes el código para seguir el tutorial, pero si quieres toquetear un poco y no te apetece copiar y pegar, lo tienes en https://github.com/x1m3/primeNumberTest.

Primero tendrás que instalar go, en mi caso un simple apt-get golang. Luego tendrás que crear un directorio de trabajo y apuntar la variable GOPATH a este. En mi caso, mkdir golang; cd golang; export GOPATH=pwd.

Finalmente, go get  github.com/x1m3/primeNumberTest bajará el código y te lo dejará dentro de la carpeta ./src. En ./bin encontrarás el ejecutable, que siempre podrás generar de nuevo ejecutando go install  github.com/x1m3/primeNumberTest

¿Fácil, verdad? y es que golang está pensado para que los desarrolladores sean felices.

La ineficiente rutina que nos dice si un número es primo

Vamos a comentar un poco el código, algo que nos vendrá muy bien si eres nuevo en go.

Lo primero que vemos es que hay pocos paréntesis y prácticamente ningún punto y coma. Los condicionales o bucles no necesitan los paréntesis, a fin de cuentas son obvios. Tampoco es necesario usar ; para indicar final de línea. Menos cosas a escribir (Veo que se me coló un ; en la línea 28… si es que salen automáticos ya).

La definición de la función es limpia y no tiene secretos.

La función se llama isPrime, acepta un parámetro de tipo int64 y devuelve un booleano. Primera sorpresa: Golang tiene tipos, algo que puede resultar un poco engorroso para los programadores de javascript o php pero que también puede ayudarnos mucho a la hora de evitar efectos indeseados.

Hay que definir las variables e indicar su tipo. 2 comentarios aquí. Golang no compilará si una variable se ha definido pero no se ha usado. Una buena ayuda para mantener nuestro código limpio. También es posible definir variables en marcha sin especificar el tipo, siempre que este pueda ser inferido por el programador. Para ello, en lugar de usar la asignación con =, escribiremos :=.

Por ejemplo:

Creará una variable llamada i de tipo integer, ya que 5 es un entero. Esto es muy útil para definir variables «tontas», de aquellas que sólo tienen sentido en una pequeña parte del código. Por ejemplo una variable que sólo vaya a usarse en un bucle:

Crearía 3 variables i,j,z que se usarían dentro del bucle pero no tendríamos que definir.

WTF.. ¿Esto es necesario para calcular el módulo? No. Lo hemos hecho así para realizar los cálculos en coma flotante y darle más caña a la CPU. En realidad, podríamos haber usado el operador % sobre integers. Pero ya que estamos, expliquemos de que va.

math.Mod calcula el resto de una división entera entre sus dos parámetros, que son número flotantes de 64 bits. Para usar la función hemos tenido que hacer un import de la librería math. Como no tenemos conversión implícita de tipos, hemos tenido que forzar una conversión (cast) y convertir los enteros en flotantes. La sintaxis es limpia, float64() tiene forma de función, lo cual me parece más agradable que la sintaxis en C o php.

La versión secuencial de la función que calcula todos los primos en un rango

Tampoco hay mucho secreto aquí, aunque si que tendremos que explicar algunos detalles interesantes.

Atentos a los corchetes en el parámetro de retorno. Esta función acepta 2 enteros de 64 bits y devuelve una slice (una «lista») de enteros de 64 bits. Los arrays son de longitud fija en Go, igual que en C. Los slices son un concepto que permite referirnos a un rango dentro de un array. Yo los interpreto con un puntero al array, en el que también sería posible definir la longitud. En el ejemplo que nos interesa a nosotros, podemos considerarlo como una lista de longitud variable.

Por lo demás, ningún secreto en esta función. Se itera desde el primero hasta el último con un bucle for y se va comprobando si es primo llamando a la función isPrime() que ya comentamos antes.

A comentar aquí, para añadir un elemento a la lista primeNumbers hemos de usar la función append, pasándole la lista original y el nuevo elemento. Esto no es muy óptimo, ya que append hace una copia del array y devuelve la nueva copia. Luego ya vendrá el garbage collector a salvarnos el culo, pero este mecanismo podría causarnos problemas de memoria.

La versión paralela. Empieza la fiesta

Hasta ahora, nada interesante. Un código que podríamos haber picado en cualquier lenguaje. Pero nos hemos dado cuenta de una cosa. Averiguar si cada número es primo o no es independiente de sus vecinos. ¿Por qué calcularlos de uno en uno si podríamos hacerlos todos a la vez? O, por lo menos, podríamos hacerlo de cuatro en cuatro u ocho en ocho en función del número de procesadores que tengamos.

La idea sería crear un thread para cada cálculo y recoger la respuesta de alguna manera. Hacer eso con php sería complicado y poco eficiente. Su librería de threads no es lo mejor que se ha inventado. Programadores de C++ o Java se atreverían a picar unas cuantas líneas de código y algún mutex para hacerlo. Un trabajo pesado. Los de javascript y node podrían tenerlo más fácil, usando las funciones de callback. Por desgracia node.js no es precisamente óptimo en operaciones que usan mucha cpu.

¿Y que tal con Golang?

El código completo de este apartado está en rangeParallel.go

Vamos a ir poco a poco. Primero decir que la función se parece mucho a la anterior, salvo unos ligeros cambios. Lo primero que hacemos es definir un canal (chan) que acepta tipos PrimeResult.

PrimeResult es una estructura que hemos definido nosotros así:

es decir, un número y un booleano que nos dice si el número es primo o no.

Ya podemos intuir que eso llamado canal no es otra cosa que un canal de comunicación que usaremos para comunicar procesos. Piensa en ello como algo parecido a un pipe de unix.

Una línea interesante. El mecanismo defer es propio de Golang y sirve para especificar que ese comando debe ejecutarse cuando la función finalice. Así no nos olvidaremos nunca de cerrar el canal, algo que es obligatorio hacer. Por decirlo de manera coloquial, defer close(channel) significa «y cuando acabes, cierra el canal llamado channel».

¡Guau! Nuestra primera llamada a go. A partir de este punto tendremos 2 hilos de ejecución, el actual, y uno nuevo que ejecutará la rutina firePrimeCalculations.

firePrimeCalculations() es muy sencillita, pero importante. Tiene un bucle en el que va lanzando ejecuciones paralelas de isPrimeAsync(). Fijaos en la palabra go antes de la llamada. Por cada vuelta del bucle creará un nuevo hilo de ejecución. ¿Y si el bucle tiene 1.000.000 de valores? Pues.. crearemos 1.000.000 de hilos..

Notar también que cada llamada a isPrimeAsync() recibe un número diferente y el canal por el que debe devolver el resultado.

Aquí tenemos el secreto de la comunicación entre los procesos. Primero creamos un objeto de tipo PrimeResult. Notad el uso del comando new. Luego asignamos sus dos valores number y prime. Para calcular si es primo llamamos a la función isPrime() que habíamos definido al principio.

Y la parte interesante. Devolvemos el resultado por el canal, para quien pueda estar interesado. Notad aquí ese asterisco, que huele a C de mala manera. result es en realidad un puntero, nosotros queremos devolver el valor al que apunta, por eso el *.

Vale, ¿Y quien diablos lee el canal?

Pues tienes la lectura del canal en la función primesInRangeParallel(), cuyo código mostramos bastante arriba. En concreto, en este bucle

La línea res= <- channel es la que nos interesa. Espera a que alguien escriba en el canal y recoge el resultado que llegue. Es importante señalar en que la lectura es bloqueante. Esperará a que cualquier hilo finalice y tomará el resultado.

Todo se ejecuta dentro de un bucle por que si habíamos lanzado n hilos de cálculo, tenemos que esperar n respuestas.

¿Y los benchmarks donde están?

La gracia de esta prueba era probar un poco las posibilidades de golang, y el paralelismo es posiblemente la más importante de ellas.  La verdad es que el ejemplo que hemos usado no es óptimo para probar paralelismo, porque un cálculo de módulo es tan rápido que el overhead introducido a la hora de crear y destruir hilos puede ser mayor que la ventaja obtenida con el paralelismo. Por eso hemos complicado un poco el cálculo del módulo forzando una operación en punto flotante.

No lo he explicado hasta ahora, pero si bajas el código fuente y lo instalas encontrarás un ejecutable llamado primeNumberTest que acepta 3 parámetros: valor inicial, valor final y parallel o sequential.

Con eso podrás hacer pruebas ajustadas a tu ordenador y probar que versión es la más rápida.

Por lo general, la versión secuencial será más rápida en máquinas con pocos nucleos y/o cálculos de números pequeños. Las máquinas con muchos cores se beneficiarán mucho más de la versión paralela.

Atención a la variable de entorno GOMAXPROCS. Le indica a go el número de procesadores que debe usar. Según la documentación se ajusta al número de cores disponibles automáticamente, pero yo me he encontrado con que no era así en un server virtual de linode. Para ello he debido asignarle el valor 4, para que use 4 cores de los 6 que tenía la máquina disponible

Para que te hagas una idea de los tiempos que he obtenido, estos son los resultados, ejecutados con 4 procesadores, en un servidor que actualmente tiene 6 y que estaba trabajando con un apache y un varnish, sirviendo webs en producción (con un par…).

export GOMAXPROCS=4

time ./bin/primeNumberTest 2000000 3000000 parallel

real    0m8.355s
user    0m26.730s
sys     0m2.550s

time ./bin/primeNumberTest 2000000 3000000 sequential

real    0m20.681s
user    0m20.273s
sys     0m0.177s

Ignora el valor de user en el caso paralelo, porque suma el tiempo de cálculo en cada core. Como usamos 4 cores casi al 100% se ha ido a un valor de 26 segundos. Pero el tiempo que el usuario esperó no es ese.

Dicho a lo bruto, la versión paralela ha sido casi 2 veces y media más rápida que la secuencial. A cambio, hemos usado 4 cores en lugar de uno, por lo que hemos perdido casi un core y medio en la gestión del paralelismo. Si el problema hubiese sido diferente, por ejemplo, con conexiones de entrada/salida o esperas de usuario, la eficiencia habría sido superior.

Conclusiones

No me quiero enrollar más, que ya me he alargado mucho, pero quisiera hacer dos o tres comentarios.

Golang me ha parecido agradable de usar y creo que es un lenguaje robusto con mucho recorrido. La sintaxis es clara y los canales y las gorutinas son una maravilla que permite jugar con el paralelismo muy fácilmente.

Golang no es demasiado orientado a objetos. Pero tampoco es un lenguaje procedural. Para mi, es un lenguaje orientado al paralelismo. Quizás se echan a faltar algunas características de la orientación a objetos pero su simpleza sintáctica y las llamadas go permiten resolver problemas de manera sencilla que podrían ser un infierno en otros lenguajes.

Está muy orientado a los flujos de trabajo actuales, por ejemplo la instalación de vendors desde repositorios git. No lo he tratado aquí pero tiene soporte para tests unitarios de serie.

Verdaderamente, creo que golang ha llegado para quedarse. Personalmente, pienso meterme más a fondo con el. Seguro que seguiré dándoos la vara con el.