Esto iba a ser un enlace en la lista de enlaces de junio, pero se fue extendiendo demasiado y se convirtió en un post. Mis discusiones de fin de mes se supone que deben ser breves reflexiones alrededor de algún post o suceso interesante, pero a veces cobran vida propia y se transforman en algo difícil de precisar. Algunos simplemente desaparecen y se convierten en nada, otros se transforman en un post, como este.

El enlace viene de gamasutra, A producer’s guide to decision-making (Guía del productor sobre la toma de decisiones).

El artículo hace un excepcional resumen de todo lo que viene alrededor de las malas y buenas decisiones y las consecuencias o beneficios que pueden ocasionar. Estuve envuelto en una de estas decisiones este mes, así que me vino como anillo al dedo el artículo. No porque yo tenga problema tomando decisiones, sino que como dice el artículo, no las debemos tomar tan a la ligera. Pienso que luego de sopesar correctamente los pro y contras no queda más remedio, hay que proceder y tomar la decisión que en nuestra opinión es la más apropiada.

Pero hay decisiones que debemos tomar casi con los ojos cerrados. Como un ciego en un gallinero. En mi luna miel, en mi otra vida, nos fuimos manejando hasta Mérida. Resulta ser que la via hacia Barinitas tiene un tramo de alrededor 100 kilómetros sin ningún tipo de señalización. Hasta que llegamos a la ciudad realmente yo no estaba seguro que era la via correcta. Ciertamente iba más o menos en el sentido correcto (sur-oeste) pero había momentos en que la carretera cruzaba hacia el oeste e inclusive hacia el noreste.

Muchas decisiones son así. No hay señalización. Tomas una decisión y solamente vas a saber el resultado cuando llegas a la meta, no antes. Ni siquiera hay una buena pista que te dé alguna orientación. Solamente tu intuición y sentido común te pueden ayudar.

En este mes mi plan era trabajar tiempo completo con las misiones  y diálogos de mi juego espacial, khpx. Todo estaba almacenado en estructuras C++, inicializadas a través de las nuevas funcionalidades de c++11, todo en un archivo llamado db_init.cpp. Luego un proceso se encargaba de guardar estas estructuras en tablas de sqlite para ser leidas por el juego a tiempo de ejecución. Cuando el juego pase a producción la base de datos sqlite será eliminada y un sistema de archivos altamente optimizado tomará su lugar. Se supone.

El punto es que con 10 misiones, 10 npcs, 10 items, 10 recompensas, las estructuras de c++ se convierten en un código escrito en sánscrito encriptado en antiguas claves macedónicas.

Algo tenía que hacer, y todo apuntaba en una dirección que yo conozco perfectamente: hacer un editor tipo GameMaker que maneje la data del juego, y la almacene en una base de datos para que la lea posteriormente el juego. El problema de este enfoque es que contradice todas las reglas que he venido aplicando hasta ahora con khpx: debe ser simple, rápido, y lo que sea que se haga debe facilitar y acelerar la publicación del juego: un editor de la data y metadata de los objetos del juego ni es simple, ni es fácil, y es una enorme desviación en el objetivo de publicar el juego.

El riesgo es  que implementar este sistema puede tardar semanas, más de un mes quizás, y no sabemos si eso va a funcionar o cómo va a afectar al juego y su publicación. Históricamente (me refiero a mis otros desarrollos, taisec y psyblast) me he perdido en interminables desarrollo de características en este tipo de editores, y para cuando ya está casi listo he perdido interés en el proyecto en sí.

Claro que ahí vienen los argumentos y contra argumentos: esto va a ayudar a largo plazo el desarrollo, organiza lo que a todas luces es algo de por sí complicado, de todas formas hay que hacerlo porque parte de estos datos deben ser accesibles por el jugador para consulta, como si fuera una enciclopedia.  Y es una mejor practica (best practices). Al fin y al cabo no hay que ser como el herrero que trabaja en su casa con cuchillo de palo, blah, blah, blah.

Desde taisec (mi primer juego, tipo aventura, nunca publicado) he estado haciendo este tipo de editores. Este es un screenshot de lo que yo llamaba scredit porque se suponía que iba a implementar un script para controlar las acciones del juego:

Y en psyblast (otro zombie del baul de los zombies) hice un superprocesador del documento maestro para pasar la info al juego, es decir, hice un mega GDD (de 60 páginas) con un lenguaje que un procesador interpreta, y extrae para pasarlo a una base de datos. Lo cual por supuesto, es una inmensa locura. ¿Cuánto tiempo estuve trabajando en eso? Semanas.

Y para khpx lo que tengo que hacer es el super definitivo editor de worldbuilding. Que puede tomar meses.

El plan es hacer un editor, al que llamo summa, implementado en Qt, es un visor/editor de la base de datos del juego. Es decir, al mismo tiempo sirve para el juego y se puede visualizar en forma de wiki desde otro programa. Genial. ¿Cuánto tiempo le he dedicado a esto en este momento? 2 semanas y el plan es terminar en una semana más.

Así luce la pantalla que se encarga de la información de los planetas:

Ya reportaré de nuevo en julio si llegué a Barinitas o me perdí.