Si por alguna descabellada razón tienes una instalación solamente con las librerías “Release” y deseas agregar las librerías “Debug“, y estás usando shadow build, el proceso es tan simple como hacer algo así como:

[code]
nmake confclean
configure -debug -opensource -confirm-license -platform win32-msvc2013 -opengl desktop -prefix C:\qt-5.6.2-build
[/code]

Pero

Las nuevas librerías, por ejemplo, qtmaind.lib se van a quedar en qt-5.6.2/lib cuando deberían ir a qt-5.6.2-build/lib

La documentación dice que falta hacer nmake install pero esto no funciona. Hay que copiar las librerias manualmente. No se si esto fue corregido en las versiones posteriores o es una peculiaridad de mi instalación. Pero ahí queda el reporte para las futuras generaciones.

Ya está disponible el pre-patch de Battle for Azeroth (la última expansión de World of Warcraft, el único juego que juego regularmente). Quisiera decir que los resultados son mixtos, tristemente no, son de regulares a malos. Este pre-parche está full de bugs, como nunca había visto en wow, no parecen cosas de Blizzard, la compañia detrás de wow. Luego de 3 días la mayoría han sido resueltos, pero el conjunto de cambios que se hicieron  continúan(cambios en los talentos y en la interfase, las nuevas barras de comando son una desastre de diseño), y la mayoría no son tan buenos. La expansión estará disponible el 14 de agosto, así que no sé que se supone que vamos a hacer este mes. Usualmente hay un conjunto de misiones y una zona especial donde se realiza como un ajuste a la experiencia y al equipo antes de cada expansión, pero en esta ocasión eso solamente va a estar disponible durante la  semana previa. La gente está muy molesta en general, no soy el único. En el Q&A de ayer hay literalmente 100 personas diciendo que este prepatch está bugueado, incluyendo alguien que dijo: “it’s not my job QA your game, sorry” (no es mi trabajo hacer control de calidad de tu juego, lo siento”). Ouch.  Por esto y otras cosas  no voy a renovar la suscripción (pagada con oro, por supuesto). Al menos por ahora.

Me puse creativo entonces y dado que tenía en mi lista de juegos que debería probar  League  of Legends, decidí intentarlo y lo descargué. La gente dice que es una descarga de 13 gb. Falso, en mi caso fueron 5gb. El tutorial es un asco. No hay realmente ninguna ayuda para entender cómo es la mecánica, como se usan los hechizos, cómo es la estrategia, nada, nada, nada. De verdad hice algunos intentos pero no me atrapó en lo absoluto. Frustración. Así que volví a la rutina de lo que hago cuando abandono wow.

Cuando no estoy jugando wow mi juego alternativo es Wizard 101. Lo estoy jugando desde 2009, sin embargo apenas he trabajado 4 mundos. En este momento estoy en Grizzlehein (son 17 zonas y contando. Parece que sacan una zona nueva al año). Este juego tiene sus peculiaridades, incluyendo algunas cosas irritantes que wow no tiene. Por eso a veces lo abandono con rapidez. Por ejemplo en este momento estoy tratando de recoger El Ojo de la Verdad (Eye of Truth) en la cripta que está en Vigrid Roughland. El primer problema es que en este dungeon, antes de enfrentarte al boss que tiene the eye, hay 3 olas de mobs, lo cual te deja sin vida para enfrentarte al boss final. Wizard 101 es un juego por turnos, y las cartas que te salen son seleccionadas en forma aleatoria. Si no te salen cartas de sanación en el último enfrentamiento, mala suerte, tienes que repetir todo desde el comienzo.

Puedes colocar una marca para recuperar tu última ubicación pero en los dungeons no funciona (dice “The dungeon time has ended and the dungeon has been reset” que significa que tienes que comenzar el dungeon desde el comienzo. Hay un timeout que parece ser 20 segundos, casi inútil) (nota: finalmente descubrí que las pociones que venden en la feria no solamente restauran el mana sino tambien te sanan. Me parece que antes solamente restauraban el mana.) Las tres olas de mobs son: 1) Troubled Warriors y Hungry Soul con 310 c/u 2) Forgotten Clansman y Troubled Warrior con 620 y 310 respectivamente, y finalmente Forgotten Clansman y Hungry Soul.

Como si eso no fuera suficiente, luego de eliminar el boss tienes que invocar tres monolitos que supuestamente te darán el ojo de la verdad. Pero eso no sucede. La meta de la misión cambia y dice “Recoger el ojo de la verdad en Vigrid Roughland” lo cual es confuso porque parece que hay que dejar la cripta. Resulta que lo que hay que hacer es conseguir la combinación correcta de invocación de los monolitos. Todo esto dentro de un dungeon que tiene toda la dificultad mencionada. Este tipo de diseño no lo encontramos en Wow. Bueno a veces sí, pero en wow los dungeons no se resetean, así que una vez que has vencido el boss tienes suficiente tiempo para hacer lo que tengas que hacer en el dungeon.

El ojo de la verdad lo que te da es frustración.

• Un año de C. Evitar el gamelote de C++ es algo que cada vez más gente reconoce como una ventaja. Como ya he dicho, mi último proyecto está hecho en C++ pero sin clases, que es mi intento de trabajar en C pero usando algunas bondades de C++ como el STL, y otras cosas. Como dice el artículo “Escribir clases de C++ a menudo implica escribir constructores, destructores, operadores de asignaciones y movimientos, a veces métodos de setter y getter… y así sucesivamente.” (“Writing C++ classes often involves writing constructors, destructors, assignment- and move-operators, sometimes setter- and getter-methods… and so on”). A eso lo llaman “Boilerplate Code” o código gamelote (sic)
• Byteball se hace viral en la USB. Leyendo la página byteball.org encuentro esta perla “El algoritmo de consenso utilizado para proteger contra los gastos dobles se basa en el establecimiento de un orden total dentro del DAG. Esto se logra seleccionando una cadena, llamada cadena principal, que gravita hacia unidades emitidas por usuarios de reputación comúnmente reconocida – testigos. Consulte el documento técnico para obtener más detalles.” (“The consensus algorithm used to protect from double-spends is based on establishing a total order within the DAG. This is achieved by selecting a chain, called main chain, which gravitates towards units issued by commonly recognized reputable users — witnesses. See the white paper for details.”). Define “reputación comúnmente reconocida”. Está raro esto.
• Un bug en MSVC 2017
• Ya antes he hablado de Yandere Simulator y su peculiar programador conocido como Yanderedev. Este mes sacó uno de sus afamados videos (con alrededor de 1m de visualizaciones cada uno, alguien quien dice que esto le genera ingresos por arriba de los $5k que gana en el patreon). En esta ocasión sacó un video donde trata de responder a la pregunta ¿cuánto tarda hacer un video juego?. Digo trata porque opino que es una pregunta que no se puede responder. Tarda lo que tarda, básicamente es infinito porque uno nunca termina un video juego, simplemente lo abandona. El video viene a propósito del drama que se está viviendo en este momento en el subreddit del juego porque la gente se está impacientando y porque cuando la gente le pregunta cosas sobre los features del juego, Yanderedev responde de una forma realmente agresiva porque, bueno él también se está impacientando. Muchos dicen que desde hace mucho tiempo. En relación al mencionado video, mi opinión es que si necesitas argumentar todo eso, es porque el problema es mucho más grave de lo que la gente del subreddit piensa. La gente comienza a especular, como este redditor que dice que él realmente no quiere terminar el juego, sino que quiere ser famoso. Yo creo que eventualmente Yanderedev va a terminar el juego, pero algo que puede ayudar a ese objetivo es dejar el drama y los videos sobre el drama. Pero, el sucio dinero tiene un rol aquí, los videos y el drama le generan dinero. ¿Ven hacia dónde voy con esto? Money.
• php es un ratoncito en comparación al tren cargado con elefantes llamado node.js en nivel de inutilidad sin sentido (php is a mouse compared to node.js’s train of elephants level of bloat nonsense). Esto es reddit siendo reddit: todo comenzó con una discusión sobre las políticas de reddit de eliminar silencionamente mensajes directos que contengan enlaces a ciertos sitios vetados por alguna razón (o por ninguna razón) y la discusión degeneró en ataques como el mencionado a esa inmensa pila de basura llamado Node.js. (Disclaimer: Node.js no es una inmensa pila de basura, lo que pasa es que quedaba muy bien en este párrafo)
• Estoy seguro que ya lo he linkeado antes pero aquí está de nuevo: la cuenta github con todo el código fuente de id software, los creadores de Doom, Wolfenstein 3D y Quake. Reportado este mes, de nuevo, en reddit.
• Un corto ensayo de Stephen King sobre los autores prolíficos. Parece haber una conclusión, o quizás no. “Poco es mejor” está sobrecalificado como una opinión. Si puedes escribir mucho, que bueno, pero la gente le va a prestar atención a tus libros uno por uno. De todas formas, según él, los autores prolíficos lo son, en forma inevitable. A mi lo que me gustó fue la anécdota de los señoras que no se tomaban el vino. Stephen es un escritor genial para crear imágenes provocativas.
• Un dominó de 5 mm de alto y unos gramos de peso tumbando a un dominó de 50 kg. Tomado de 9gag. Interesante para reflexionar sobre las consecuencias de nuestras más insignificantes acciones. O como los grandes cambios comienzan por imperceptibles detalles. En los comentarios discuten que las analogías estúpidas nada significan, y que una demostración de un efecto físico nada tiene que ver con filosofía, psicología del comportamiento y otras menudencias. Cierto. Pero es cuando hacemos una analogía en la forma en que crece la levadura y la forma como nos impactan los cambios: el día anterior a cuando la levadura alcanza el 100% del tamaño esperado, tiene un tamaño de 50%. Es decir, el crecimiento es geométrico: así es el impacto de los cambios, al principio son imperceptibles, pero al final el impacto es total. Yo puedo esto de múltiples formas, pero la metáfora de la levadura es perfecta para explicarlo claramente: ¿me expliqué?
• El principio de Peter dice que todos alcanzamos eventualmente nuestro nivel de incompetencia en una organización jerárquica. Este paper propone y discute estrategias para combatir este hecho comprobado incluyendo que se deben hacer nombramientos random o ascender al mejor y al peor candidato para aumentar la eficiencia. Esto resulta contra intuitivo por decir lo menos, y debería más bien ser sustituido por múltiples criterios (que es lo que usan las organizaciones actualmente), por ejemplo, competencia, desempeño, capacidad para conseguir los logros del equipo de trabajo, etc..
• Interesante lectura sobre los avances de Blizzard con WOW Classic. Esta va a ser una versión de World of Warcraft similar a la que estaba disponible alrededor de 2005, un viejo deseo de la fanaticada de jugar la versión original del juego. Enlace.
• En relación a la Copa Mundial de Futbol 2018: toda la selección de Islandia (Iceland)está formada por personas cuyo apellido termina en “son”: Halldorsson, Runarsson, Arnason, Skulason, Saevarsson, Ingason, Magnusson, Eyjolfsson, Sigurdsson, Gudmundsson, Bjarnason, Traustason, Hallfredsson, Sigurdsson, Skulason, Gislason, Fridjonsson, Gunnarsson. Si el porcentaje de la población cuyo apellido termina en “son” es tan alto ¿por qué siguen usando el “son”?
• Una charla corta sobre Unit testing. Pregunta: ¿Por qué ciertos componentes (métodos estáticos de una clase) no se pueden testear? El orador: porque no se puede. Él explica porque no tiene “costuras”.  Algo asi como que no tiene por dónde agarrarlo. Mi solución: no uses algo que no puedes testear. Este sitio está lleno de videos sobre diversos tópicos de programación. Bien interesante de navegar.
• Fortnite: Battle Royale es el juego con más ganancias en un mes que cualquier otro juego gratis. Ganó $318m en mayo. Según reporte en slashdot. ¿De dónde proviene esta ganancia? Vendiendo artículos no importantes como ropa y movimientos de baile. Cierto.
• Interesante artículo en Gamasutra sobre algunas estadísticas de Steam: Se publican hoy en día 180 juegos con el nuevo sistema Steam Direct (más del doble que con el viejo sistema Greenlight). Hay opiniones como siempre en ambos sentido: es bueno (como dice Valve, porque facilita la publicación y los juegos consiguen su audiencia). Es malo: porque entre tanta maleza y monte, los humildes juegos indie se hacen invisibles. Como me dijo un amigo en facebook: las opiniones son como los traseros, cada quien tiene el suyo. Digo.

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í.