El RPG que hice en Python durante SMX y lo que aprendí de sus límites

El RPG que hice en Python durante SMX y lo que aprendí de sus límites

Cuando estaba estudiando Sistemas Microinformáticos y Redes (SMX) en Cataluña, una de las asignaturas que más tarde me acabaría dejando algo que recordar fue programación.

No era, ni mucho menos, la programación que uno se encuentra cuando empieza a desarrollar proyectos más grandes. En clase aprendíamos los conceptos básicos: variables, funciones, condiciones, bucles y, sobre todo, la lógica que hay detrás de un programa.

Y creo que esa parte es bastante más importante de lo que parece.

Puedes aprender Java, Python o cualquier otro lenguaje, pero si no entiendes qué estás intentando hacer con el código, da igual el lenguaje que utilices.

Java y Python: dos formas muy diferentes de empezar

En mi caso, durante aquella etapa tuve contacto con varios lenguajes, aunque principalmente recuerdo Java y Python.

Java me parecía —y me sigue pareciendo— un lenguaje muy completo. Es de esos lenguajes que puedes encontrar prácticamente en cualquier sitio y que, una vez empiezas a profundizar, parece tener una cantidad enorme de posibilidades.

Además, es difícil hablar de Java sin acordarse de que Minecraft nació utilizando Java.

Python, en cambio, me parecía mucho más sencillo de utilizar.

Y precisamente esa sencillez era una de sus mayores ventajas.

Podías escribir algo relativamente rápido, instalar una librería y conseguir que tu programa hiciera cosas para las que, con otros lenguajes, probablemente tendrías que trabajar bastante más.

El problema llegó cuando empecé a intentar hacer cosas un poco más grandes.

Pero antes de eso tuve que hacer un videojuego.

El proyecto que no tenía por qué estar tan currado

La práctica consistía en hacer un videojuego en Python.

No era necesario crear el próximo RPG del año. De hecho, el proyecto podía ser bastante sencillo.

Yo decidí hacer un RPG de consola.

Y, como aparentemente hacer un RPG de consola no era suficiente, decidí llenarlo de colores, arte ASCII y caracteres Unicode.

El resultado terminó siendo PyRPG.

El proyecto nació como una evolución de otro juego anterior que había hecho llamado kill-the-boss. Con el tiempo fui añadiendo cosas y terminé publicando una versión más completa en GitHub.

El propio repositorio explica bastante bien cuál era mi situación en aquel momento: era un proyecto de aprendizaje, hecho principalmente por mí con ayuda de un compañero, y estaba abierto a que otras personas señalaran errores o propusieran mejoras.

Y viendo el código ahora, queda bastante claro que era un proyecto de alguien que estaba aprendiendo.

El sistema de combate era bastante simple

La estructura del juego era sencilla.

Tú tenías tu personaje y delante tenías un jefe.

Combatías.

Después venía otro jefe.

Y después otro.

Básicamente:

tú → jefe → tú → jefe → repetir.

Las estadísticas iban aumentando progresivamente y el jugador podía elegir qué estadísticas mejorar.

También había pociones de vida y de maná para darle algo más de profundidad al combate.

Sobre el papel era un RPG.

En la práctica, era un RPG bastante fácil de romper.

Si conseguías mejorar determinadas estadísticas por encima de las demás, el combate prácticamente quedaba decidido.

De hecho, recuerdo que si conseguías superar las primeras cinco rondas era bastante difícil perder después. El sistema de progresión no estaba suficientemente equilibrado como para conseguir que el juego siguiera siendo realmente desafiante.

Pero eso también forma parte de hacer un primer videojuego.

No tenía experiencia diseñando videojuegos y tampoco iba a convertirme de repente en diseñador de sistemas de combate.

Mi prioridad era conseguir que funcionara.

Y funcionaba.

También intenté hacer una especie de inteligencia artificial

Una de las cosas que más me llamaban la atención era conseguir que los enemigos no se limitaran a atacar sin pensar.

Así que hice una especie de sistema de "inteligencia" basado en condiciones.

Realmente no era inteligencia artificial como tal.

Eran parámetros y condiciones que decidían cuándo el enemigo debía atacar o curarse.

Por ejemplo, la idea era que el enemigo no gastase una poción de curación hasta que realmente la necesitara.

Para alguien que estaba empezando, aquello ya parecía bastante sofisticado.

Ahora probablemente lo definiría simplemente como una serie de condiciones bien colocadas.

También existía un sistema de autoplay que utilizaba una lógica similar.

Y aquí apareció uno de los grandes problemas del diseño del juego: si habías conseguido mejorar suficientemente tus estadísticas, el sistema estaba prácticamente decidido antes de empezar.

No había una verdadera adaptación entre el jugador y el enemigo.

Si tenías suficiente vida y daño, ganabas.

Y punto.

Y sí, también hice una versión con "hacks"

No sé exactamente qué me llevó a hacerlo.

El juego ya era fácil.

Pero recuerdo haber hecho una versión modificada en la que las estadísticas eran absurdamente altas.

Si ya era difícil perder en la versión normal, en aquella versión directamente parecía que estaba haciendo trampas contra mi propio juego.

Probablemente no sea la mejor característica que destacar de un proyecto de programación.

Pero es una de esas cosas que ahora me hace gracia recordar.

Porque también demuestra cómo programaba entonces: primero hacía que algo funcionase y después experimentaba con ello hasta ver qué podía romper.

El código funcionaba, pero no era precisamente bonito

Aquí es donde el proyecto se vuelve más interesante para mí ahora que ha pasado el tiempo.

En aquel momento había cosas que simplemente no sabía hacer de otra manera.

Por ejemplo, tenía problemas para trabajar con variables dentro de determinadas funciones y después acceder a esa información desde otras partes del programa.

Mi solución fue crear variables secundarias, copiar información y pasarla de un sitio a otro hasta conseguir que funcionase.

No era necesariamente la mejor solución.

Pero funcionaba.

Y cuando estás aprendiendo, que algo funcione es un paso importante.

En el propio README del proyecto llegué a reconocerlo directamente: algunas variables eran copias de otras porque no había conseguido hacerlo funcionar de otra manera y preferí no tocarlo mientras el juego siguiera funcionando.

Hoy probablemente lo refactorizaría.

En aquel momento, ni siquiera sabía que esa palabra iba a acabar siendo tan importante.

Python también empezó a mostrarme sus límites

Aquí tengo que hacer una aclaración.

No creo que Python sea un lenguaje inútil.

De hecho, sería absurdo decirlo.

Python es extremadamente útil para automatización, scripting, prototipos, ciencia de datos, inteligencia artificial y muchas otras cosas.

Mi problema con Python viene de mi experiencia personal con él.

Cuanto más intentaba hacer, más complicada se volvía la gestión de todo.

En algunos proyectos posteriores empecé a encontrarme con situaciones en las que tenía que manejar más información simultáneamente y mantener datos entre diferentes partes del programa.

Y ahí fue cuando empecé a notar una diferencia respecto a lo que había experimentado con otros lenguajes.

Quizá algunos de esos problemas fueran simplemente errores míos.

De hecho, probablemente varios lo fueran.

Pero esa experiencia me hizo sacar una conclusión bastante concreta:

Que un lenguaje sea sencillo de utilizar no significa que sea el lenguaje adecuado para cualquier proyecto.

Python me parece fantástico cuando tienes claro qué quieres hacer y quieres llegar rápido a una solución.

Pero si el proyecto empieza a crecer mucho, necesitas tener muy clara la arquitectura, la estructura del código y las herramientas que estás utilizando.

De lo contrario, la facilidad inicial puede convertirse en un problema cuando el proyecto empieza a acumular piezas.

Incluso intenté añadir traducciones

Una de las cosas más curiosas del proyecto es que también intenté añadir traducciones.

El idioma principal era el español, pero quería que el juego pudiera mostrar el texto en otros idiomas.

Para conseguirlo utilicé una librería que se conectaba a Google Translator y traducía el texto.

El problema era evidente: si había que traducir muchas líneas, el proceso podía volverse extremadamente lento porque dependía de conexiones externas.

También probé otra librería, pero no conseguí que funcionase como necesitaba.

En el README incluso dejé explicado el problema y pedí alternativas a otros usuarios.

Era otra pequeña muestra de algo que ahora veo constantemente cuando programo:

hacer que algo funcione es solo el primer paso.

Después vienen el rendimiento, la mantenibilidad, la arquitectura, los errores y todos esos problemas que no aparecen cuando estás haciendo un pequeño programa para clase.

Lo subí a GitHub esperando críticas

Una vez terminé el proyecto decidí publicarlo en GitHub.

No quería simplemente guardarlo en mi ordenador y olvidarme de él.

Mi intención era que alguien pudiera verlo, detectar errores y decirme qué podía mejorar.

Incluso hice alguna publicación en Reddit buscando precisamente eso: críticas de gente que supiera más que yo.

No ocurrió gran cosa.

Nadie apareció para decirme que estaba haciendo todo mal.

Nadie hizo una revisión profunda del código.

Y tampoco recibí ese feedback que esperaba.

Es una de las cosas que más me sorprendió.

Cuando estás aprendiendo a programar, muchas veces tienes la sensación de que internet está lleno de gente dispuesta a ayudarte.

La realidad es un poco diferente.

A veces publicas algo, esperas comentarios y simplemente no pasa nada.

El repositorio sigue ahí, eso sí. Tiene licencia CC0 y actualmente conserva la versión que publiqué del proyecto.

Viendo PyRPG años después

Lo interesante de este proyecto no es que sea un buen RPG.

No lo es.

Tampoco es un ejemplo de cómo debería estructurarse un proyecto de Python.

Probablemente sea justamente lo contrario.

Pero sí es un buen ejemplo de cómo aprendí.

Era un trabajo obligatorio de clase, pero terminé dedicándole aproximadamente dos meses durante las horas lectivas.

Lo hice prácticamente línea por línea, con ayuda puntual de un compañero y buscando recursos externos cuando los necesitaba, especialmente para el arte ASCII.

Empecé con algo bastante sencillo y terminé añadiendo colores, caracteres Unicode, traducciones, sistemas de combate, mejoras, pociones, enemigos con cierta lógica y hasta una versión modificada del juego.

Y todo eso partiendo de los conocimientos básicos de programación que estaba aprendiendo en SMX.

Eso es probablemente lo que más valoro del proyecto.

No era un buen juego. Pero sí fue un buen proyecto para aprender

Con el tiempo he cambiado bastante mi forma de ver Python y también mi forma de programar.

Ya no pienso tanto en si un lenguaje es "bueno" o "malo".

Pienso más en para qué estoy utilizando ese lenguaje.

Python es una herramienta fantástica cuando encaja con el problema.

Java tiene otras ventajas.

Y existen muchísimos lenguajes y tecnologías que tienen sentido dependiendo de lo que quieras construir.

Mi error, probablemente, fue pensar que si algo era fácil de empezar también tenía que ser fácil de mantener cuando empezase a crecer.

PyRPG me enseñó precisamente lo contrario.

Primero aprendí a hacer que el código funcionara.

Después aprendí que conseguir que funcione es solo una pequeña parte del trabajo.

Y quizá esa sea una de las mejores cosas que puede darte un proyecto de clase.

No necesariamente enseñarte a hacer un producto perfecto.

Sino darte un proyecto suficientemente imperfecto como para que, unos años después, puedas mirar atrás y entender exactamente cuánto has aprendido desde entonces.

PyRPG sigue en GitHub.

Y, sinceramente, viendo el código ahora, me da más ganas de arreglarlo que de borrarlo.