Proelium es un juego táctico, minimalista, inspirado en clásicos de tablero como las damas o el go, sin más pretensiones que la del aprendizaje y realización personal. Pero por muy humilde que sea una obra, el proceso de realización de la misma, a través de las diferentes fases ―ideación, producción, revisión…― es siempre complejo y deja un poso de satisfacción cuando se finaliza. Al fin y al cabo, como cualquier creador, en cualquier ámbito, ha experimentado, son muchas las ideas que nos surgen, muchas menos a las que empezamos a dar forma y de ellas solo unas pocas las que terminamos por materializar. Proelium no es mi primera obra, pues he finalizado y publicado obras literarias, ni mi primer programa, pero es el primer juego que publico. El proceso de crear un juego es a la vez muy diferente y a la vez muy similar al de escribir un libro o programar una aplicación. En esta entrada quiero compartir el camino que me llevó hasta la idea detrás de Proelium y las motivaciones y propósitos de su creación, a partir de las cuales poder hacer una valoración consecuente del resultado final. Dejaré para otro momento un análisis y reflexión sobre aspectos específicos del diseño del juego.
El camino hacia Proelium
Filólogo clásico de formación y dedicado a la literatura y la docencia en diferentes períodos, mi perfil quizá no parezca el más habitual en el desarrollo de software y de juegos, en que predominan perfiles técnicos o de diseño. Desde niño había sentido interés en los ordenadores y la programación, pero cuando llegué a la adolescencia, me obsesioné con la literatura, tanto desde un punto de vista teórico como creativo. Eso y cierta tendencia al ideal me atrajo al mundo grecorromano y a sus lenguas. ¿Qué podía estudiar que me ayudara a convertirme en un mejor escritor? Filología hispánica o Estudios literarios me parecieron entonces respuestas demasiado rectas, así que opté por algo que me parecía más complicado y original: Filología clásica. El estudio del latín y el griego, así como los primeros pasos en mi producción literaria me mantuvieron intelectualmente estimulado durante unos años, pero poco después de acabar la carrera, empezó a crecer más y más en mí una carencia que arrastraba desde que me había lanzado por completo al humanismo: haber dejado a un lado el placer intelectual de la programación.
Comencé entonces a estudiar programación, como una afición, dedicando una hora o dos al día, de forma autodidáctica, sin más pretensión que la del humanista que busca ampliar su visión del mundo. Cuando me interesé por la didáctica y empecé a ejercer de profesor, encontré, además, en el estudio de la programación una forma de rememorar las dificultades, frustraciones y placeres del proceso de aprendizaje. Cuando uno es profesor se acaba convirtiendo en tan experto de lo que enseña que a menudo se olvida de cómo se sentía aprendiendo algo y estudiando algo que le exige un esfuerzo intenso. Me centré al principio en los fundamentos ―estructuras de datos, algoritmia…―, pero con el tiempo sentí que me había llegado el momento de ir un poco más allá y crear algún programa. Yo había comenzado estudiando los fundamentos en C y C#, pero me había comprado un MacBook cuando inicié el máster para ser profesor, y justamente Apple acababa de presentar Swift, su nuevo lenguaje de programación, así que creí que aprenderlo sería una forma de introducirme en la programación, digamos, más práctica.
Como casi todo aprendiz, mis primeros programas fueron herramientas de uso personal. Después empecé a pensar en ideas para publicar en la AppStore y obligarme así a aprender el proceso de publicación y a utilizar ciertas APIs, pero no conseguía dar con un idea viable y que me motivara lo suficiente. Estaba impartiendo entonces clases de Latín en un instituto y me adjudicaron un trabajo de investigación de bachillerato de una alumna sobre los juegos de mesa en la antigua Roma. Uno de los juegos que trataba en su trabajo era Latrones, una especie de predecesor de las damas que no se sabe exactamente cómo se jugaba y cuyas reglas se han intentado reconstruir a través de diferentes conjeturas. A partir de esas conjeturas se han realizado diferentes versiones, pero ninguna me terminaba de convencer. Aunque divergen en el número de fichas, en la existencia de una fase inicial o en la presencia de una ficha especial que determina la victoria, casi todas las versiones coinciden en las mecánicas básicas: las fichas pueden moverse en línea recta, pueden saltar sobre otras fichas y se eliminan cuando tienen dos fichas del adversario en dos casillas adyacentes.
El resultado es un juego bastante dinámico, con un ritmo semejante al de las damas. Por el nombre y la mecánica del salto, parece evidente que, a diferencia del go o el ajedrez, las reglas probablemente no se desarrollaron como la abstracción de un combate militar. La mecánica que me resultaba más interesante, sin embargo, era una que se insinuaba, pero no se desarrollaba: la del bloqueo, es decir, que una ficha rodeada por dos fichas enemigas no pueda moverse. Me parecía simple e intuitiva, pero que creaba complejidad emergente, y se acabó convirtiendo en la base de Proelium. A ella dedicaré un artículo más adelante. Imbuido en estas reflexiones de diseño de juegos, pensé entonces que, ya que estaba buscando alguna aplicación con la que seguir mi proceso de aprendizaje de programación, ¿por qué no realizar mi versión de Latrones? Con ello podría, además, compaginar mi interés por la programación con el del diseño de juegos y las artes interactivas, que nunca había abandonado.
Objetivos técnicos y lúdicos
Los objetivos principales que me propuse, y que tuve presentes a lo largo del proceso, fueron los siguientes:
- Publicar mi primera aplicación, es este caso un juego.
- Aprender a utilizar SpriteKit, el framework de creación de juegos 2D de Apple.
- Aprender algoritmos de inteligencia artificial.
- Desde el punto de vista del game design , diseñar el juego táctico más minimalista posible.
- No olvidarme de disfrutar del proceso, especialmente en los momentos de mayor dificultad.
Valoración personal
Es fácil infravalorar la complejidad que requiere un programa, especialmente un videojuego. Proelium, a pesar de su sencillez, es el programa más largo y complejo que he programado hasta el momento. Dicha complejidad implica un importante aprendizaje en sí misma: cómo organizar el código, cómo llevar un control de los cambios, cómo comentarlo, etc. Ninguna aproximación teórica a estos problemas te prepara realmente. También la familiaridad con las herramientas, como Xcode o Git, solo se consigue mediante su uso. Lo cual no quiere decir que algunos recursos teóricos no me hayan sido de gran utilidad durante el proceso: quizá el más relevante ha sido A Philosophy of Software Design. Hay también aspectos organizativos y de disciplina, relacionados con el trabajo diario que requiere la creación de un proyecto relativamente complejo, que evidentemente solo se pueden desarrollar a través de la experimentación. En general, y aunque evidentemente hay mucho margen de mejora a todos los niveles, no puedo sino sentirme satisfecho con el proceso llevado a cabo y todo lo que he aprendido relacionado con el mero hecho de acabar un programa de software.
El segundo objetivo que me propuse, más específico, implicaba el aprendizaje de SpriteKit. En su momento valoré la posibilidad de utilizar un game engine como Godot o Unity, pero quería seguir profundizando en Swift, que sentía empezaba a dominar, y el framework de juegos 2D de Apple resultaba suficiente para materializar mi visión. SpritKit es relativamente sencillo de aprender, pero Apple lleva mucho tiempo sin tocarlo y se encuentra en estado de pseudo-abandono, así que no siempre es fácil encontrar ayuda en la comunidad online. Algún bug que Apple no tiene intención de corregir y alguna deficiencia que no tiene intención de mejorar me produjeron algún problema extra, pero en general SpritKit creo que ha sido la apuesta correcta en este caso específico. Su relación con UIKit (el framework de aplicaciones de Apple anterior a SwiftUI) me ha obligado a aprender algunos patrones de diseño diferentes a los de SwiftUI, con los que estaba más familiarizado, y su diseño general basado en nodos y componentes me permitirán, dado el caso, transferir parte del conocimiento adquirido. Utilicé otra librería de Apple, GameKit, para implementar los logros del juego y las partidas online, la cual me resultó más engorrosa que SpriteKit, en parte por problemas con los simuladores. Me he quedado con las ganas de explorar las posibilidades de GameplayKit.
El punto más exigente ha sido sin duda la programación de la inteligencia artificial. Como solo había hecho aplicaciones para iOS y MacOS, no había tenido la oportunidad de tocar este campo, que me ha resultado fascinante. Proelium no utiliza ninguna solución especialmente sofisticada para las partidas contra la máquina: un algoritmo mini-max con algunas adaptaciones a las particularidades de las reglas de Proelium. El juego presenta tres niveles de dificultad que se diferencian básicamente en los niveles de profundidad que recorre en el árbol de tableros. Como la complejidad es exponencial, a pesar de su aparente sencillez o quizá precisamente por ello, los niveles que es capaz de recorrer el algoritmo para encontrar el mejor movimiento están limitados. El nivel más fácil en principio es capaz de retar a un jugador novato; el más difícil debería resultar un reto a jugadores que dominan medianamente el juego. Implementar un cuarto nivel más difícil o estilos de juego más agresivos o defensivos están entre las mejoras que quizá me anime a realizar en un futuro próximo, pero el algoritmo en su diseño actual está al límite y conseguir implementarlas implica aplicar cambios notables.
Los problemas de game design son de índole artística y por ello más difíciles de valorar que los problemas técnicos. Mi objetivo era crear el juego táctico más sencillo y con las reglas más minimalistas que fuera posible, intentando mantener una profundidad suficiente. Como ya he comentado, para mí la mecánica clave del juego es la de bloqueo. Desde las primeras pruebas me pareció evidente que transformaba para bien el sistema, pues creaba profundidad y emergencia sin aumentar la complejidad. Sobre este y otros aspectos hablaré en otra entrada. Durante los primeros pasos experimenté con distintas reglas. Las fichas, por ejemplo, durante un tiempo se podían mover en diagonal. El movimiento en diagonal aumentaba las posibilidades tácticas, pero para entonces yo ya asociaba Proelium con una abstracción del combate hoplítico, posicional y defensivo, y en cierta manera sentía que alteraba el ritmo y afectaba a la metáfora. Otro de los cambios relevantes fue el número y posición de las fichas iniciales: las reduje en cuatro para dejar los columnas de los extremos libres y las adelanté para dejar la fila inicial sin fichas. Con eso pretendía dejar un mayor margen de movimiento en los primeros turnos.
Proelium ha sido para mí sobre todo una experiencia de aprendizaje que me ha obligado a poner en práctica y desarrollar toda una serie de habilidades y conocimientos relacionados con la programación, el desarrollo y el diseño de juegos. Establecer unos objetivos claros, realistas y asumibles, junto a una constancia y disciplina personal, me han permitido llevar a cabo el proyecto con un resultado que considero satisfactorio. Si, además de ayudarme a mejorar mis conocimientos de programación y diseño de juegos, he conseguido que alguien disfrute un rato con mi creación y la considere mínimamente estimulante, el triunfo ya lo consideraré completo.