Cómo crear un videojuego en 12 horas y no morir en el intento

Comprar un pascuero, montar un blog, tener churumbeles y crear un videojuego. Bueno, igual no es así, pero esto último es algo que se le pasa por la cabeza a cualquiera que lleve unos años dándole a las maquinitas. Hace unos días visité la sede del último evento promovido por la asociación MalagaJam donde se juntaron 250 valientes con la intención de crear juegos durante un fin de semana. Tal y como comenté en esta entrevista, eventos así son una oportunidad única para conocer a gente afín y poner a prueba tus aptitudes en un entorno creativo donde la motivación resulta contagiosa. Como era de esperar, a los pocos días me picó el gusanillo.

Dado que MundoReal(tm) no me da muchos respiros, veo complicado eso de poder dedicar 72 horas íntegras de mi vida a cumplir una gesta así, por lo que que decidí hacer un experimento. Como creativo que no ejerce en el sector desde hace más de una década e «informático de letras» que no pica código prácticamente desde que salió de la facultad, decididí comprobar si es posible crear un videojuego en tan solo 12 horas netas. Una suerte de micro game jam cuyo principal aliciente radicaría en optimizar las diferentes facetas del proceso para lograr tener un prototipo mínimamente digno en tan poco tiempo. Para ello, opté por dividir el proyecto en cuatro sprints de tres horas que distribuiría a lo largo de los huecos que pudiera ir haciendo durante todo un fin de semana.

Dicho lo cual, podría simplemente haber compartido mi creación por ahí y darme después unas palmaditas de autocomplacencia, pero considero que el verdadero valor del experimento es documentar el proceso para que las personas interesadas en este noble arte reciban un empujoncito que les convenza definitivamente para ponerse manos a la obra. Mitificar determinadas prácticas artíticas es más fruto del desconocimiento previo que de la propia dificultad que conlleva dominarlas, y el gamedev no es una excepcion. Sirva este arco dramático para demostrar que los pasos a seguir son mucho más mundanos de lo que cabría esperar y que, más allá de trabas e impedimentos, cualquier persona puede adentrarse en este mundo tan apasionante como frustrante.

Bueno, a ver qué pasa.

Sprint 1: idea inicial, esbozo y planificación

Todo el mundo puede tener una buena idea, pero lo verdaderamente jodido es hacerla viable y acorde a nuestras posibilidades reales. Como aquí la cosa va de ser prácticos y el tiempo vuela, decidí echar mano de lo primero que se me pasara por la cabeza para tener alguna referencia de inicio. La noche antes de comenzar este sindiós estuve viendo Possession, una febril película de 1981 en la que tienen cabida dramas domésticos, posesiones demoniacas, monstruos tentaculares y psicosis social durante la guerra fría. Café para los muy cafeteros.

Con ese batiburrillo en la cabeza, opté por crear el supuesto videojuego oficial del film de Andrzej Zulawski como si hubiera sido lanzado en algún momento a mediados de los 80 para las máquinas de la época. Esta elección no es baladí, ya que la creación de sprites y fondos 2D con una paleta de colores limitada y una resolución baja es la mejor forma de reducir el tiempo dedicado a la elaboración del apartado gráfico. Y precisamente por ahí ahí llegó la primera decisión importante: ¿qué resolución elijo?

Dado que no iba a tener tiempo de crear un sistema de cámara adaptable a cada una de las resoluciones habituales posibles, opté por encontrar la más versátil. Teniendo en cuenta que la relación de aspecto más habitual en PC es 16:9, el objetivo era encontrar unas dimensiones de pantalla que encajasen con los principales estándares. Y aquí viene la magia: si multiplicamos las dos magnitudes de 320×180 por 4 nos da la resolución nativa de 720p (1280×720), por 6 1080p (1920×1080), por 8 1440p (2560×1440) y por 12 el mismísimo 4K (3840×2160). Es decir, que se vería bien en cualquiera de estos escenarios. ¿Quién me iba a decir que el máximo común divisor y la descomposición en factores primos me iba a servir a estas alturas? Ojalá le diera salida también a saberme de carrerilla los afluentes del Ebro.

El siguiente paso era decidir cómo iba a dividir la pantalla en bloques cuadrados para crear un tileset que me ahorrase trabajo con el fondo. Como primer acercamiento, dibujé una plantilla con una posible composición del área de juego a un lado y las puntuaciones y artes fijos a la derecha simulando lo que que hacían infinidad de juegos de la época. Tras algunas pruebas, decidí quedarme con un tamaño para el tile de 10×10 pixeles que me dejaría 16 cuadros de ancho y 9 de alto.

Antes de ponerme a ejercitar el túnel carpiano pintando monigotes a boleo hice algunos esbozos en una libreta de cuadros para tener claro desde el principio la proporción de los sprites y, sobre todo, cuántos iba a necesitar. El proceso creativo es muy puñetero si no se deja contancia en alguna parte del basurero conceptual que se nos va montando en la cabeza sobre la marcha. Plasmar las ideas en papel es una buena forma de filtrar los espasmos creativos y tejer un plan firme. Tener siempre un bloc en la mesita de noche junto al móvil y la botellita de agua forma parte del 101 de cualquier creativo.

Lo gracioso del asunto es que mientras hacía todo esto aún no había decidido qué entorno de desarrollo iba a utilizar, por lo que para colmo de males, este tour de force iba a requerir cierta labor de aprendizaje. Dado que los fundamentos básicos de programación no se olvidan nunca, cualquier lenguaje de scripting utilizado en los principales entornos de desarrollo de videojuegos puede aprenderse fácilmente, así que opté por GameMaker Studio 2 para recurrir a su lenguaje GML y, si la cosa se alargaba demasiado, tirar del drag & drop. Al final no fue así por pura cabeconería, pero queda patente que no es necesasio ser un curtido desarrollador para meterse en esto: con unas nociones básicas sobre tipos de datos y estructuras de control puede sacarse adelante cualquier proyecto iniciático.

Sprint 2: Sprites, animaciones y tilesets

Desde el principio tenía claro que los gráficos era lo que más tiempo me iba a llevar. Solo quienes hayan trabajado a destajo en la creación de pixel art saben el sumidero de horas que lleva la elaboración de sprites «a ratón alzado». Por ello, desde el principio acoté el número de elementos dinámicos que usaría a tres: el protagonista y dos enemigos. Tras dibujar algunas siluetas planteé dejarlas monocromo, pero fue llevarme la paleta de colores del ZX Spectrum a Photoshop y recordar viejos juegos para MS-DOS con gráficos CGA y sprites moldeados con un par de colores planos. Sí, Photoshop es tan válido como cualquier otro software para trabajar con pixel art, aunque existen herramientas dedicadas que pueden agilizar algo las cosas a la hora de crear tiles o elaborar fácilmente geometrías espejadas: Piskel, Slate, GrafX2 o herramientas online como Pixilart son algunas de las muchas buenas opciones que existen. De hecho, por poder puedes usar hasta el Paint, amén del propio editor que incluye GameMaker. Por opciones no va a ser.

Para los fondos tampoco me quería complicar, así que creé unas cuantas baldosas con la intención dibujar un trasunto del túnel de metro en el que se desarrolla una de las escenas más icónicas del film. También dibujé el marco que delimitaría la zona de acción y ya vería si pongo alguna filigrana estética fija si me sobra hueco. Gracias a que GameMaker también integra su propio sistema para gestionar tiles no hubo mucho problema para crear el escenario en el que se desarrollaría la acción, descartando de paso un posible scroll porque el tiempo apremiaba. Con tan solo 16 tiles de 10×10 la cosa parecía estar resuelta.

Aunque se puede trabajar en la elaboración del prototipo utilizando tan solo cuadrados de colorines, prefiero apoyarme en una guía visual para ir empapándome del look & feel mientras lo voy montando. De ahí que al final acabase coloreando los sprites básicos de los personajes y creando algunas animaciones clave para el protagonista. No estoy nada orgulloso de la transición al caminar, pero ya no había marcha atrás.

Sprint 3: Implementación

GameMaker Studio 2 posee un equilibrio perfecto con respecto a otros entornos en cuanto a su curva de aprendizaje. Es totalmente apto a la hora de desarrollar proyectos sin picar ni una sola línea de código, pero potentísimo si queremos sacarle provecho al lenguaje de scripting en el que se basa. De hecho, el propio entorno nos pregunta en todo momento si queremos usar su editor visual de arrastrar y soltar o escribir directamente código. ¡Hay mundo más allá de Unity!

Obviando el hecho de que existen varios elementos definidos para catalogar los diferentes recursos que componen nuestro proyecto, en GameMaker todo gira en torno a los objetos y las interacciones entre ellos. El personaje protagonista es un objeto formado por sprites cuyo comportamiento puede variar según detecte una serie de estímulos externos. Aquí va un ejemplo:

El objeto oMark está asociado al sprite sMark, que es uno de los que dibujé en el sprint anterior. A la derecha puede verse la ventana de eventos, que son los mencionados estímulos que dispararán una reación concreta. Lo que hay dentro del evento «Crear» solo se ejecutará una vez durante la vida del objeto, concretamente cuando se genera. En mi caso, ahí reinicio la cantidad de salud del personaje. El contenido de «Paso» se repetirá en cada frame, por lo que si el juego lo hemos definido a 60fps, sudederá 60 veces, cosa que es ideal, entre otras cosas, para definir el input de los controles, aunque también podemos hacer que un evento sea la propia pulsación de un botón, pero mejor no ahondo, que me lío.

Después hay tres elementos con flechas enfrentadas, que son las colisiones que tienen lugar entre objetos, y que por defecto no usa cajas de colisión, sino la propia siluetea del sprite. El que está marcado en la imagen es oAnna, uno de los dos enemigos, por lo que dentro de ese evento tocará definir qué sucede cuando toca a nuestro personaje, cosa que puede verse a la derecha: restar un punto a la variable que controla las vidas, cambiar el color del sprite del personaje para indicar que está sufriendo daño y reproducir un sonido. Bueno, pues como esto, TODO.

El comportamiento de oMark es tan simple como moverse de izquierda a derecha con los cursores y disparar cuando pulsamos la barra espaciadora. Hay un objeto de control superpuesto al tile que hace de límite transitable por el personaje cuyo evento también puede verse en la imagen de arriba. Al chocar oMark con un objeto oSolido (un cuadrado rojo de 10×10 invisible durante el juego) cambia la velocidad a cero, por lo que su radio de acción queda perfectamente acotado y no se nos va a ir el monigote de cañas al salir por los lados.

En cuanto a los enemigos tampoco me iba a andar con muchas sofisticaciones, por lo que su comportamiento consiste en caminar de forma inexorable hacia el personaje horizontalmente y, cuando se produzca una colisión entre ambos, detenerse y drenarle vida constantemente hasta que vuelvan a separarse. Los enemigos son eliminados cuando una bala les alcanza (dos si es el bicho tentacular). Llegados a este punto y apurando este sprint, hice unas cuantas animaciones para los enemigos al caer derrotados, añadiendo algunos fotogramas vacíos para que simule el añejo efecto de parpadeo en los sprites de las víctimas antes de desaparecer.

Sprint 4: Ciclo de juego, música y efectos

¿Cómo? ¿Que ya han pasado ocho horas? Pues habrá que correr. Como me iba a ser imposible crear un ciclo de aparición de enemigos definido manualmente, opté por usar una dinámica más vieja que el hilo negro para la progresión en el juego. Los enemigos aparecen de uno en uno fuera de los límites de la pantalla. En cada llamada, hay un 75% de que aparezca oAnna y un 25% que lo haga el otro bicho, y no aparece uno nuevo hasta que es eliminado el anterior. Pero aquí viene el truco de la progresión: cada vez que se elimina a un enemigo, la velocidad de movimiento del siguiente que aparece aumenta ligeramente, por lo que de forma paulatina se van complicando las cosas par evitar tumbar a los bichos antes de que nos alcancen. Lo testeo y funciona. Pues otra cosa hecha.

Todo esto está muy bonito, ¿pero cuándo termina la partida? ¿Cuál es el objetivo? En vez de vidas o barras, he usado un sistema de vitalidad numérica al estilo de lo que hacía la saga Gauntlet. oMark empieza con 500 puntos de «Esperanza» que se van reduciendo progresivamente cada vez que recibe un impacto. Cuando llega a cero, se acabó. Dado que el juego solo tiene un escenario, el objetivo es alcanzar la mayor puntuación posible, por lo que cada vez que nos carguemos a un enemigo, sumaremos diez puntitos al marcador. Con estas magnitudes presentes ya tenía claro qué poner a la derecha de la pantalla: las vidas, la puntuación en la partida y el record a superar. Como me seguía sobrando hueco, dibujé el logo a partir de la tipografía original del poster del film, que siempre quedan cucos estos detalles.

Llegados a este punto, el juego lucía así:

Me quedaba menos de una hora para resolver todo lo relacionado con el audio, así que había que ser práctico. Para los efectos opté por el lafantabuloso sfxr, una herramienta web que permite generar y exportar blips y blops con formas de ondas básicas para simular los chips de sonido.

En cambio, con la música había que esmerarse un poquito más, así que eché mano de FamiTracker, un viejo tracker descontinuado desdede 2015 pensado para simular pistas musicales de NES/Famicom, pero que me venía de perlas para hacer una anacrónica piececita chiptune. Me escuché un par de veces el tema principal de la película y, tras desentumecer un poquito la práctica que cogí de chavalín haciendo música MOD para PCManía, salió esta peregrina tonadilla que recuerda al mencionado theme.

Pongo la música, añado un paso extra a modo de menú principal y una pantalla de Game Over, retiro del fuego, hago un emplatado curiosón, ¡y se acabó el tiempo, aspirantes! En doce horas clavadas, con importantes recortes de sueño durante el fin de semana y la sensación de haber sufrido un crunch en CDProjekt, puedo afirmar que ya está disponible la primera versión preliminar de Possession: The Unofficial Video Game.

Moraleja

Podéis descargarlo en Itchio y en Uptodown. Obviamente no esperéis la obra magna del desarrollo independiente, tan solo un prototipo realizado en tiempo record sin un esbozo preliminar y con la irrefrenable necesidad de demostrar que cualquier aspiración y/o circunstancia es buena para dar un primer paso hacia el gamedev. De hecho, he optado intencionadamente por GameMaker Studio ya que su curva de dificultad es de las más llevaderas que te puedes encontrar y escala de maravilla a medida que vas conociendo sus funcionalidades, amén de existir muchísima documentación que va desde la ayuda oficial hasta su canal de Reddit, pasando por incontables vídeos en YouTube y recursos gratuitos en su (innecesario) marketplace.

Si el muro de entrada es el tema audiovisual y no la programación tampoco hay que preocuparse. Existen cantidades ingentes de material de libre distribución en la red, por no hablar de que hasta un juego hecho con muñecos de palo puede ser jugado por cientos de millones de personas. LITERALMENTE.

Obviamente no es nada sano ser un one-man-army y marcarse un Eric Barone a la hora de intentar meterse en un proyecto grande, pero para curtirse en esto de diseñar y desarrollar juegos hay que sudar la camiseta, y para ello nada mejor que sacar prototipos como churros. El otro día leí este revelador comentario de Tyler Glaiel:

If you're trying to get into game design my advice is stop fucking thinking about "game design", stop watching video essays and game design analysis videos, and just fucking make a ton of little games with the design based on nothing but gut instinct.

— Tyler Glaiel (@TylerGlaiel) August 4, 2022

¡Cread, cread, malditos!