Recientemente, dos amigos míos, ambos desarrolladores de videojuegos profesionales con experiencia en la industria, han empezado por separado y sin saber el uno del otro a programar un juego por turnos. De las conversaciones con ambos sobre cómo estaban estructurando el código y cómo planeaban organizar la arquitectura de partes del programa surge esta reflexión sobre cómo las herramientas que usamos dirigen y limitan nuestra capacidad para pensar en soluciones.

El punto de disenso principal entre la arquitectura que ambos habían planteado y mi visión de cómo estructuraría un juego por turnos es que los dos habían terminado organizando su juego como un conjunto de objetos independientes en un mundo continuo. Curiosamente ambos estaban haciendo un juego basado en casillas, donde la posición de un objeto no es un vector real sobre un plano o espacio continuo sino un par de índices discretos en una cuadrícula. También, en uno de los casos, la detección de qué casilla era adyacente a qué otra, en lugar de mediante una rutina que implementara las reglas del juego sobre adyacencia y conectividad de las casillas del tablero, se hacía poniendo sobre cada casilla una caja invisible y lanzando desde ella rayos en distintas direcciones en busca de las cajas invisibles de otras casillas. De la misma manera, la aplicación de algunas reglas del juego se hacía no programando explícitamente las reglas del juego sino creando objetos físicos en el tablero y usando la colisión de estos objetos con las fichas de los jugadores para encontrar a qué jugador afecta ese fenómeno. También, se usaba una malla de navegación para guiar el movimiento de los jugadores de una casilla a otra por el tablero en lugar de una búsqueda de grafo por el grafo de las casillas, lo que hace que el movimiento se vea muy raro porque los personajes intentaban recortar las esquinas.

Un juego por turnos no necesita físicas ni colisiones. Tampoco necesita posiciones continuas para los objetos ya que en realidad su posición está limitada a las casillas del tablero. Para un juego por turnos, la mejor arquitectura sería una estructura de datos que represente fielmente el estado de una partida y funciones que implementen las transformaciones sobre el estado de la partida de acuerdo a las reglas del juego. Por último, una función que dado el estado de la partida dibuje una representación visual de éste a la pantalla. Sobre esto, se puede implementar efectos visuales, sonidos, animaciones y movimientos de cámara teniendo algo de estado auxiliar a lo que es puramente el estado de la partida y haciendo que las funciones que aplican las reglas del juego generen eventos o comandos que inicien este tipo de efectos decorativos.

Lo que me lleva a plantear esta reflexión es el preguntarme qué llevo a dos desarrolladores de videojuegos experimentados y perfectamente competentes a plantear una arquitectura bastante inefectiva para el problema a solucionar, y que en ambos casos las dos personas para un problema similar eligieran una arquitectura con las mismas asunciones y limitaciones, cuando ésta no es ni de lejos la idónea para lo que intentaban hacer. Ante todo, decir que esto no es un problema de competencia de estos individuos. Creo que a todo esto subyace un problema estructural, que intentaré describir a continuación.

Cuando uno abre la mayoría de motores de videojuegos, pensemos en Unity o Unreal pero también Godot o los motores internos de empresas AAA, lo primero con lo que uno se encuentra es con una escena tridimensional vacía a la que uno puede arrastrar objetos para componer un mundo y configurar estos objetos individualmente para darles sus atributos visuales y jugables. La forma más fácil de añadir reglas al juego es partir de todo el código que estos objetos ya traen consigo y añadirles pequeños scripts que configuren su comportamiento en determinadas situaciones. Por ejemplo, podemos tener un objeto tridimensional con su simulación física y sus colisiones al que por encima de eso aplicamos una velocidad en cierta dirección cuando el jugador pulsa un botón o restamos unos puntos de su atributo de vida cuando colisiona con otro objeto marcado como enemigo. Este es el statu quo de los motores de videojuegos a día de hoy, y el camino de menor resistencia para hacer un juego. Si uno quisiera implementar sobre Unreal o Unity una arquitectura como la que describo arriba, tendría que hacerlo sobre un motor que no necesariamente está pensado para ello, y la cantidad de trabajo y de fricción inicial sería mayor. Hay que decir también que esta forma de trabajar funciona de maravilla para juegos en tiempo real con objetos físicos, así que el hecho de que estos motores estén pensados así no es necesariamente un error. Pero sí que hay que ser conscientes de que los motores traen consigo un sesgo sobre cómo esperan ser usados, y que este sesgo a menudo acota o al menos dirige las soluciones que podemos pensar para los problemas que queremos resolver. Si estas son las herramientas que tenemos para hacer juegos, haremos menos juegos por turnos, por ejemplo, por esa fricción extra que implica hacerlos así. También es cierto que otros motores tienen otros sesgos. Al abrir RPG Maker por ejemplo lo primero que vemos es una cuadrícula sobre la que dibujar un nivel del estilo de los RPGs por turnos de los 90 y de las consolas portátiles de los 2000. Esto también dirige mucho las soluciones que un desarrollador decide llevar a cabo, en una dirección totalmente distinta a la descrita anteriormente. Sin embargo, si creo que merece la pena hablar sobre este tema, es porque hoy en día todos los motores de videojuegos ampliamente usados se parecen mucho entre sí, y creo que reflexionar sobre el impacto que esto puede tener en los videojuegos que hacemos y que se nos puede ocurrir hacer es beneficioso.

Por último, me gustaría terminar con una mención de honor a un juego en concreto:

.

ha sido un verdadero fenómeno este año, con millones de jugadores publicando su partida de

cada día en redes sociales. En cuestión de semanas el juego había sido traducido a decenas de idiomas. El juego original fue comprado por el New York Times por más de un millón de dólares. Gran parte del éxito de

ha sido gracias a su simplicidad. Una partida dura menos de cinco minutos, se puede jugar en el móvil y es accesible a todo el mundo, aunque no hayan jugado a un juego antes jamás.

está escrito en HTML5, y se parece más a una página web o a una interfaz de usuario de una aplicación que a lo que uno pensaría de normal cuando le dicen “videojuego”. Tener una apariencia familiar a todo el mundo y no sólo a un nicho ha sido también otra de las claves de su éxito. Y si lo pensamos un poco,

no podría estar escrito en ninguna otra plataforma. No porque no se pueda. Uno puede hacer

en Unity o Unreal, si quiere. Sino porque a una persona abriendo Unity o Unreal y encontrándose con ese mundo físico tridimensional esperando a ser llenado de objetos es casi imposible que el juego que se le ocurra hacer sea

. Y ese es el verdadero fenómeno irónico y algo problemático. El juego más exitoso de este año no lo ha hecho ningún desarrollador de videojuegos ni se ha hecho con ninguna de las herramientas que uno usaría típicamente para hacer un juego. Lo ha hecho un programador web en HTML5.

Las herramientas que usamos acotan y dirigen nuestra capacidad para imaginar soluciones. Esto no sería tan malo si no fuera porque la mayoría de herramientas para hacer videojuegos llevan una década convergiendo en unos diseños muy similares entre sí, que benefician mucho el desarrollo de cierto tipo de juegos mientras que dificultan el de otros. Esto está llevando y puede llevar a la larga a una similitud todavía mayor entre todos los videojuegos ya que todos parten de las mismas ideas. El caso de

, aunque discutiblemente anecdótico, podría ser interpretado como una llamada de atención. Hay videojuego más allá de los mundos físicos en tiempo real. Hay cientos de mecánicas chulas por explorar que no estamos haciendo, y posiblemente explorar esas ideas requiera alejarse un poco de las herramientas que usamos habitualmente e ir adelante, como botes que reman a contracorriente, incesantemente arrastrados hacia Unreal.