Ha estado lenta la bitácora de khpx, apenas 35 días de trabajo en lo que va de 2022, eso es alrededor de 230 horas, quizás menos.

Pero tenemos un hito: el pasado 8 de marzo terminé una cadena de quests que estaba programando desde el 19 de julio de 2018. Tiene todas las características que va a tener mi engine de quests: voy a tratar de no agregar más nada: recolección de objetos en la superficie, recolección de habitantes, selección de habitantes basado en su adn utilizando el sensor de adn, etc. No parece complicado pero si lo es. Estos 4 años estuve no solamente implementando los quests en sí, sino considerando todas las posibilidades.

Un ejemplo: descubrí que se puede usar el sensor de adn para detectar los ciudadanos infectados estando el robot en el depósito de la nave. Se supone que este sensor solamente se puede usar una vez que el robot está en la superficie del planeta, en el área de la ciudad donde están los habitantes. Para implementar esto, estuve agregando scripts y código c++ durante unas 2 horas más otras 2 horas pensando cómo hacerlo porque estos son el tipo de cambios difíciles de implementar. ¿Se coloca en el script de la misión o en el script del objeto (del sensor)? ¿o en el script del robot? Al final quedó en el script del sensor, pues hace más sentido. El script ahora indica que este objeto solamente se puede ejecutar si el robot está activado (en manos del jugador) y si el robot está en la superficie del planeta. Todo muy obvio pero toma tiempo de implementar. Así por el estilo cientos de consideraciones, cientos de decisiones. Lo que me lleva a…

¿Cuál es la peor decisión que he tomado en el desarrollo de khpx?

Difícil de decidir cuál es peor, porque he tomado varias decisiones malas en estos últimos 4 años. Pero definitivamente sin pensarlo mucho, lo peor ha sido no con khpx en si mismo, sino con Summa, el editor. Summa (que espero escribir un post dedicado a él (o ella)) es un editor que permite manejar todos los datos del juego en forma consistente, unificada y tiene el objetivo de poner orden en el caos. Las misiones quedan todas organizadas en un solo sitio, se pueden visualizar, editar, modificar etc..

Yo no tengo idea de cómo hacen otros programadores para controlar toda la data persistente, pero mi solución es colocarlo todo en una base de datos, y crear una aplicación que maneje toda la data. Entonces el juego es como un visor de esa data . Lo único que el juego guarda es el estado: qu´é se ha hecho, donde se ha estado, etc.

Mi aplicación que maneja toda la data se llama Summa (como la Summa Teológica). Fue desarrollado usando Qt y aquí está el problema: si lo hiciera desde cero hoy, utilizaría Imgui, sin lugar a dudas. Qt es grande, pesado, complicado y grande y pesado. Está desarrollado con la versión de Qt 5.6 (creo que ahorita van por la versión 6.2, luego de llegar hasta 5.15), es open source, pero no hay distribución de librerías sino solamente el código fuente. Tarda 2 horas en compilar en mi máquina.

Es extremadamente fácil de usar, tiene un editor de gui, Qt Creator que permite posicionar los elementos de tu aplicación (texto, botones, drop down menus, etc.).

El problema es que al abrir una página dentro de la aplicación (Summa tiene 20 páginas) en windows aparece un nuevo ícono en la barra de tareas, es como si estuvieras abriendo una aplicación nueva. Sucede algo así como esto:

Cada aplicación ocupa un espacio en la barra de tareas, pero Saeta, una aplicación desarrollada en Qt (es una herramienta desarrollada por mi) tiene tres íconos porque cada ventana es como si fuera una aplicación diferente: el primer ícono es la aplicación en si misma, el segundo de la pantalla de configuración, el tercero la pantalla de “acerca de”.

Yo no quería eso para Summa porque es una app que voy a estar usando todo el tiempo (6 horas al día al parecer), y porque en mi trabajo de freelancer debo tener otras aplicaciones abiertas (Notepad++ para editar php, excel, putty, la cónsola con cygwin, otras). Tener la barra de tareas full de íconos afeta mi TOC (o OCD en inglés (“OCD often centres on themes such as … need to arrange objects in a specific manner“), así que me fui a Stackoverflow y busqué cómo se hace para que una aplicación Qt abra todas las ventanas pero usando un solo ícono: la respuesta es usar un StackedWidget. Así luce en QTCreator:

Y efectivamente la aplicación abre cualquier cantidad de ventanas y utiliza un solo ícono en la barra tarea. Pero hay un problema, consecuencias David, el tiempo de compilación de una aplicación con un stacked widget de 20 ventanas es 10x el tiempo normal. Cuando hago un rebuild, puede tardar 8 minutos en vez de menos de un minuto, que es lo normal. Eso fue un error, y por supuesto eventualmente voy a tener que eliminar el stacked widget. No se si el problema se resuelve con las versiones nuevas porque yo trabajo en windows 7 y VS2013 y Qt 5.8 requiere Visual Studio 2017 y eso requiere Windows 10. Este cambio tendrá que esperar a mi nueva máquina que si todo sale bien será en algún momento de este año.