Bienvenido nuevamente a este tu blog de programación. Este es el primero de una serie de publicaciones en el que hablaré de la herramienta AGK Studio y las tareas de programación relacionadas con la nueva versión de mi juego.
En el pasado post AppGameKit Studio – Iniciemos comenté que para renovar mi juego, había decidido no comenzar desde cero, sino retomar la base de código con la que cuento, organizarlo, estructurarlo, eliminar lo que no sirve y mantener lo que sí.
En esta ocasión me enfocaré en contarte qué encontré al revisar detalladamente mi código y qué actividades se derivaron de mis hallazgos.
A sacudir el polvo
Basta ver tres archivos de código fuente para encontrarme con muchas faltas, propias de un desarrollador novato y que ha trabajado sin guía, carente de orden y a las prisas… y en noches de insomnio (que así fue como se creó el juego).
Nomenclatura de archivos
Al momento de nombrar los archivos de código fuente hice una mezcla entre idiomas. Algunos tienen nombres en Español y otros en Inglés.
Algunos archivos tienen nombres explícitos y completos (pantalla_principal) y otros son abreviaturas (config).
Se me hizo muy «original» etiquetar como «soporte» a los archivo que contienen funciones, que son simple y llanamente bibliotecas.
Aunque tengo archivos que contienen funciones que dan soporte al programa, para algunas de ellas me pareció que no cabrían en ellos y se me hizo fácil crear un nuevo archivo al que alegremente nombré «util«.
Signatura de funciones
Todas las funciones deberían tener una signtura como la que se muestra en esta imagen.
La signatura debe indicar el nombre de la función, los parámetros que recibe y qué significa cada uno, así como una descripción de qué hace.
Sin causar sorpresa alguna, hay funciones que no la tienen. ¿Y adivina qué? Sin ver el código, no sé qué hacen esas funciones.
Además de eso, los nombres de las funciones cuentan con variados inconvenientes:
- Algunos comienzan con f_ y otros con fn_
- Hay mezcla entre Español e Inglés
- El nombre de la función no siempre dice qué hace. Por ejemplo esta: «f_mensaje_tutorial» podría entenderse que obtiene o hace algo con una cadena de texto, pero en realidad es para abrir un diálogo y mostrar un mensaje dentro.
Declaración y nomenclatura de constantes y variables globales
Las variables globales no siguen un estándar. Decidí usar una g al inicio del nombre de la variable para saber que se trata de una global. No todas las variables tienen la «g» y además, a veces están declaradas en letras mayúsculas o minúsculas, según me pareció en el momento.
Tengo delaraciones de constantes y variables globales en un archivo donde se supone solo debe haber variables globales, y hay variables globales creadas en otros archivos.
Por si no fuera suficiente, además de la mezcla de constantes y globales, puse declaraciones de tipos de datos personalizados en la declaración de variables globales. La declaración de tipos personalizados no sigue el estándar tampoco.
Nomenclatura de variables
En este apartado encontré dos prácticas. La buena, es que mantuve en todo momento un estándar usando guiones bajos para dar nombre a las variables, por ejemplo:
- nombre_archivo
- lb_archivo_existe
La mala práctica, es que mezclé dos estilos. Así como para las variables globales usé una g al inicio del nombre de las mismas, usar una l (L minúscula) indica que se trata de una variable local. Encuentro variables locales con y sin la L inicial.
Probablemente en algún momento pensé que no tenía caso agregar la ,L ya que todas las variables que no eran globales, eran locales y tener la L resultaría redundante. Cualquiera que haya sido el motivo, después de cambiar el estándar no ajusté el código.
Extensión y responsabilidades de funciones
En el libro «Becoming a Better Programmer: A Handbook for People Who Care About Code» del que pronto te hablaré, se menciona en uno de sus capítulos (en lo cual concuerdo totalmente) que en principio, las funciones dentro de los programas deben hacer una sola cosa, y hacerla bien. Es una mala práctica que una función haga dos o más tareas. Adicionalmente, respecto de la longitud de estas, también sugiere que no sean muy extensas, para facilitar la legibilidad y su mantenimiento. En el código de catastrophe hice lo opuesto.
Esta captura de pantalla muestra partes de la función principal que se encarga de una partida. Observa que inicia en la línea 1055 y termina en la número 2196, más de 1100 líneas de código. No te te miento, tener que modificar esta función siempre fue una tarea que prefería evitar; de hecho, esta función es el motivo de que haya demorado tanto en actualizar o agregar funcionalidad al juego.
Esta función es sumamente extensa justo porque ejecuta muchas tareas. Aunque se trata del motor de juego, me pareció buena idea que esta se encargara de mostrar el menú de selección de reto según el modo de juego. Observa esto en la captura de pantalla a la derecha.
Además de mostrar el menú de juego, la función también prepara el tablero y las variables de control que se usarán para darle vida al juego.
La función además arma y anima el tablero de juego en pantalla.
Para cerrar como la campeona dentro del código, la función valida si el juego finalizó en una victoria o derrota del jugador, muestra en pantalla el mensaje correspondiente y libera los recursos utilizados para armar el tablero.
Manejo de datos del juego
Como otros juegos de destreza por niveles, Catastrophe lleva también un registro de avance en el juego. Esto se hace mediante archivos de texto donde se va registrando qué niveles han sido concluidos, y como parte de los datos grabados, están el número de movimientos y el tiempo en el que se resolvieron los retos.
Aunque van ligados, el número de movimientos y el tiempo de resolución se encuentran en archivos separados.
En 2013 cuando generé la primera versión del juego, hasta donde yo sabía, solo había posibilidad de leer y escribir archivos de texto planos, sin estructura como un xml o un json. Esto y la falta de experiencia con la herramienta derivaron en que yo manejara archivos separados para datos que están interrelacionados.
¿Qué sigue y en dónde entra AGK Studio?
Luego de haber dado un recorrido por todo el código fuente, para usar el código existente como base de la siguiente versión, las primeras tareas son sin duda:
- Renombrar archivos de código fuente
- Reubicar variables, constantes globales y tipos de dato personalizados en archivos de código fuente correspondientes, uno por cada rubro.
- Organizar las funciones en los archivos que correspoden. Renombrarlas para que reflejen lo que hacen.
Para estos tres aspectos en particular, AGK Studio brinda las siguientes herramientas:
El IDE
Como cualquier IDE moderno, nos muestra un gestor de componentes de la solución, desde la cual podemos agregar, eliminar y renombrar archivos de código fuente.
De igual manera, al estar dentro del cuerpo de una función, podemos apreciar desde el IDE qué variables y qué constantes se declararon en dicha función. Esto es de suma utilidad para hacer la depuración y restructuración que hace falta, ya que podemos identificar variables y constantes repetidas.
En el caso de los activos y archivos de soporte, también podemos verlos desde el ID sin necesidad de salir del programa para apreciarlos en el administrador de archivos:
Acceso a JSON
Con esta versión del producto, es posible leer y escribir archivos json. Esto da una flexibilidad muy grande a la herramienta.
De inicio, el seguimiento y la configuración del juego ya se pueden realizar en archivos de texto estructurados.
El acceso a JSON, permite interactuar también con web services que realicen el intercambio de datos con esa estructura.
Ya he realizado algunas pruebas para leer y escribir JSON y funciona perfectamente.
Acceso a objetos y espacio en 3D
De momento no está en mis planes hacer que Catastrophe entre en este particular, pero si en su momento hubiera la necesidad, AGK Studio proprociona más y mejores herramientas para trabajo con entornos 3D. Ya hice una prueba de cargar y texturizar un objeto creado en Blockblench. Esto no es exclusivo de AGK Studio, estaba presente desde AGK V2, pero sí veo más y mejores extensiones del lenguaje en este rubro.
Para concluir, como puedes apreciar, hay mucho trabajo por hacer. En los días venideros reorganizaré el código y publicaré un artículo en este tu blog de confianza para contarte cómo va.
¡Nos leemos pronto!
Deja un comentario