Algunos avances

 Buen, señores, este país se va a la verga a una velocidad de espanto. Cuesta abajo y sin frenos. No es por machacar en lo mismo, pero solo tengo tres horas al día para trabajar, casi siempre bien tarde en la noche. A pesar de eso, he logrado estudiar un poco de O3DE. Les dejo otra muestra:

 

 

Esa es la versión preliminar, anoche logré implementar el cambio de material. A propósito, aparte de la invaluable ayuda de la comunidad en Discord, tengo que decir que Claude es la única IA que domina O3DE al nivel de poder dar consejos y código útil. 

Malas noticias: no habrá nuevos modelos

 Nuestro artista 3d no ha hecho el trabajo como se esperaba, así que han sido seis meses de espera por gusto. Ni hablemos del costo. 

En teoría, alguien que ha sido el artista conceptual del proyecto, además del animador, debería saber exactamente qué necesitaba el proyecto, pero no. Resulta que ahora es que se entera que su trabajo era hacer seis modelos. Tres razas, dos sexos cada una. Incluso creó las shape keys para algunas piezas de equipo. Si la conversación inicial que tuvimos cuando le solicité el trabajo no aclaró todas las dudas, eso debería haberle dado una pista, ¿no? Pues no. 

 En concreto, ahora tenemos un modelo y medio, porque el cuerpo femenino no está completo. Las texturas tampoco se han terminado. El material aprovechable, por ahora, se reduce a las animaciones y algunas armaduras. Esto nos deja una buena lección para todos los que dirigimos proyectos: todo por escrito y detallado, dividido en fases. No asumas que porque el artista pertenezca al proyecto, sepa lo que tiene que hacer. Solo se paga la fase terminada, una vez que se haya revisado y aprobado. Supervisión frecuente del progreso, a ver qué se está haciendo, cuando el trabajo se estira a lo largo de meses, es normal que la memoria falle. Y busca gente confiable, si es posible.

Por qué no tenemos un sistema de ítems aleatorios

 Hace unos días vi un video (no lo encuentro ahora) sobre el sistema implementado en Diablo para generar objetos completamente aleatorios. Una de las funcionalidades más interesantes del juego y sus clones. Viéndolo así, la idea parecía genial, y armado con la explicación me dispuse a adaptarla a mi proyecto. Sin embargo, no llegué a poner ni una línea.

Luego de analizar la idea, me di cuenta de que The Key of the World no había sido diseñado para eso. Su sistema de objetos apunta más bien hacia The Witcher. Si recuerdan, la saga del brujo no se caracteriza por su abundancia de ítems diferentes. Así, abusando de mi memoria, hay 4-5 espadas comunes, algunas espadas únicas, y lo mismo para las armaduras. En especial, lo que más complica nuestro caso, es que muchos objetos tienen descripciones hechas a la medida. Sí, puede ser una espada normalita, pero también puedes tener alguna por ahí con una descripción medio humorística. 

¿Podría implementarse un sistema de objetos construidos aleatoriamente? Pues sí, combinando ambas cosas en un sistema híbrido. Después de todo, Diablo no deja de tener ítems únicos. Esta opción no está completamente descartada. Pero... eso demanda una ampliación del sistema de salva/carga de partidas, y del sistema de objetos, en primer lugar. Luego vendría crear un generador de ítems, que no crean que es sencillo, ¡para nada!

Yo preferiría invertir ese tiempo en algo más útil, como mejorar el sistema con un nuevo enfoque que vi en un grupo de Unreal. Esta nueva solución arma los objetos a partir de bloques de funcionalidad, en vez de utilizar clases para cada tipo de objetos. ¿Quieres una poción que puedas arrojar? Pues le agregas un comportamiento Lanzar. Igual, se requiere una reescritura casi completa del sistema actual y el tiempo no abunda.

Les recuerdo que el pre-alfa está disponible para descarga, prueben y dejen su opinión aquí o en itch.io. 

The Key of the World, primer prototipo de acceso público (al fin)

Disclaimer: esta es una versión muy pre alpha, que no he podido probar a fondo. Puede, o mejor dicho, les aseguro que contiene bugs y cosas incompletas. Pueden descargarlo de itch.io.

Como debo haber mencionado en algún momento, y si no lo hice, ahora lo hago, el arte está en proceso de reemplazo total. Se agradece cualquier donación que puedan hacer, porque el presupuesto inicial se ha invertido solo en los personajes del jugador y el equipamiento inicial.

A la caza del bug

 Cualquier software de cierta complejidad tendrá bugs. Con suerte, serán fáciles de encontrar, el problema es que la suerte es inversamente proporcional a lo complejo que sea. Un juego, aún en estado de prototipo, es casi un plato de espaguetis: hay muchos subsistemas en acción a la vez.

He tenido que dedicar tres días a resolver un bug bastante escurridizo, que había pasado desapercibido porque es muy difícil desarrollar y probar a fondo a la vez. Como casi todo, se produjo cuando solucioné un problema. Puede parecer tonto, pero manejar el estado de muerte de un personaje es... muy jodido. El personaje debe desaparecer del mapa (si es un NPC) o finalizar el juego (si es el del jugador), pero no puede ser de golpe. Hay que ejecutar una animación, y en dependencia de si es un NPC, hay que guardar su estado para que no vuelva a aparecer cuando restaures la partida o regreses a esa escena y dejar algún botín o no. 

Había logrado que todo esto funcionara bien, excepto en un lugar crítico. La primera pelea del jugador es una batalla grupal. Por desgracia, para probarla hay que iniciar la partida desde el principio y jugar unos dos minutos. Tampoco es una pelea que puedas ganar, es una batalla de equipo donde un NPC carga el peso de casi todo el combate. Justo ahí estaba el problema. Todos los combates funcionaban bien, pero en esta pelea específica, de los tres NPCs, dos morían y dejaban de reaccionar, pero no desaparecían. El último en morir siempre funcionaba como debe ser. Lo cual llevaba a un segundo problema: tu NPC acompañante se quedaba bloqueado ahí. A pesar de que la quest se registraba como cumplida, el NPC no salía del combate y era imposible continuar el juego. 

¿Por qué nunca llegaba a completarse la animación de muerte, y por tanto, no se disparaba la desaparición? ¿Por qué el sistema funcionaba bien cuando peleaba contra un solo oponente, e incluso, contra dos? Me tomó tres noches de trabajo (digamos que siete u ocho horas) rastrear todas las posibles causas. Algo estaba interrumpiendo la animación de muerte, y encima, estaba devolviendo el NPC al estado combate, a pesar de estar marcado como muerto. ¿Era el AnimationTree? ¿Acaso los tres NPCs era una misma instancia de la escena o algo así?

Bien, el error no estaba ahí. Se trataba de un bug en la IA, que solo podía darse en ese caso específico, porque era una batalla de grupo. En concreto: la IA al entrar en combate puede llamar a los miembros de su grupo para que acudan a pelear, pero esto no estaba verificando si el NPC estaba muerto, solo si no estaba ya en el estado combate. Por tanto, apenas morían, los NPCs eran llamados otra vez a la batalla, devolviéndolos al estado combate. Aunque, al estar marcados como muertos, no podían hacer nada salvo estar ahí parados.

La solución óptima y que cortaría de raíz el problema es que la máquina de estados del personaje no cambie si ya está muerto, porque hay muchas otras formas en que el estado combate se activa: al recibir un ataque de cualquier tipo, por ejemplo. De todas formas, he rastreado muchas de esas vías de entrada y agregado verificaciones. 

Por esa razón es que los equipos de beta testing son tan grandes: veinte personas, por lo menos, muchas más para proyectos grandes. En el caso de este proyecto, dos beta testers han encontrado una buena parte de los errores, pero no todos. Como siempre les digo, la fase de pruebas es más complicada de lo que parece.

Estamos en pruebas

 El proyecto ha iniciado su segunda prueba, esta vez un poco más abierta. Y sí, he estado ausente por un buen tiempo. Más de lo normal. La situación del país empeora cada día que pasa y estamos viviendo en un mundo post-apocalíptico y distópico. Por tanto, no alcanza el tiempo para blogs: hay que dedicar cada minuto con electricidad a trabajar.

Luego de esta fase de pruebas estoy planeando una primera salida en itch.io, como una especie de crowdfunding o early access con menos pretensiones y compromisos. Así que nos veremos por allá.

De vuelta a Linux Mint

 Luego de una muy mala experiencia con Ubuntu 24.04, me he vuelto a Linux Mint. Esta vez, por suerte, Godot funciona bien, no hay fallos raros con el teclado y puedo programar sin problemas. He tenido que corregir montones de líneas de diálogos que en Ubuntu se tuvieron que quedar sin tildes ni ñ, lo cual ha sido un trabajo pesado y que seguramente está incompleto. También puedo reportar que O3DE funciona bastante bien.

Las únicas quejas hasta ahora son dos: el soporte de Cinnamon para Wayland todavía es experimental y Synaptic no tiene la opción Marcar todas las actualizaciones. En general, estaba trabajando más fuera de Wayland que dentro, porque muchas aplicaciones no lo soportan bien (OBS, por ejemplo, y algunas herramientas de O3DE), así que eso... como que no es tan crítico. Démosle un par de años para ponerse al día.

No es la primera ocasión en que uso Ubuntu, pero sí la primera en que la experiencia es tan mala. A cada rato saltaba una notificación de error, la configuración del teclado ha cambiado y no logré configurar un teclado inglés como siempre lo he hecho (como decía, adiós a caracteres españoles, a menos que usara AltGr y cosas así), por no hablar del proceso de instalación, que falló un montón de veces sin dar explicaciones. 

Vamos ahora a las malas noticias, que no tienen nada que ver con Linux. Hemos pasado a un régimen de 6-7 horas de electricidad al día. A veces, algunas de esas horas son durante la madrugada, lo que las hace imposibles de aprovechar. Es difícil llevar un horario preciso, o ni siquiera aproximado de cuándo tocan esas escasas horas. Por tanto, el trabajo se resiente mucho. A pesar de eso, he logrado corregir algunos señalamientos que se le hicieron a la primera demo cerrada. De momento, he tenido que reducir el ritmo de trabajo, por otros compromisos, así que no agregaré mucho contenido por ahora. También hay ciertos aspectos de Godot con los que no estoy muy conforme, sobre todo en rendimiento, por lo que considero que para futuros proyectos de más envergadura, tendrá que ser con otro motor.

Y ya que hablamos de motores, ¡he completado el cuarteto! Ya tengo un mínimo de conocimientos en Unity, Godot, Unreal y O3DE, que son los 4 que están un poquito más en boca de todos (que no en uso). Me faltarían Unigine y CryEngine, aunque el primero lo trabajé hace años, siendo el primer motor comercial con el que tuve contacto. En cuanto a CryEngine, parece que algunos miembros de su comunidad se están pasando a O3DE, por inconformidades que no me quedan muy claras.

Quizás en otro momento escriba un poco sobre las diferencias entre los cuatro motores.

Al fin, primer demo alcanzado

 Ayer completé una primera ronda de pruebas, rectificando y agregando contenido hasta donde fue posible. Con eso he alcanzado la hora y media de juego, distribuidas (no muy bien) a lo largo de tres escenarios con dos locaciones subordinadas adicionales. La introducción a la historia principal del juego está ahí, aunque podrían haber cambios, claro. O sea, al fin estamos listos para un demo cerrado.

El contenido actual incluye las susodichas escenas, casi 300 líneas de diálogo, unas trece misiones, cuarenta ítems, unas cuantas peleas (se agregarán algunas más, aparte de los dos puntos de respawn actuales) y mucho territorio por explorar. Sobre todo eso, les recomiendo explorar. El sistema de combate funciona, aunque estamos escasos de habilidades en ciertas clases, y estoy planificando un refactorizado. Hay una carencia relativamente importante: no es posible reparar los objetos todavía, pero a menos que abuses de ellos, deberían aguantar la hora y media de juego, en especial las armas, que son las que más uso reciben.

Durante los últimos tiempos, he ido chocando con pequeñas limitaciones de Godot. Se echa de menos un sistema de cinemáticas, aunque por ahora se ha ido supliendo eso. El sistema de navegación es, por decirlo de forma amable, una mierda. He tenido que mantener la complejidad de la escena bajo control, porque en cierta ocasión, encontré crasheos del motor al calcular una malla muy extensa. La búsqueda de caminos puede devolver resultados jodidamente ridículos, lamentablemente tendremos que apechugar con eso, porque es lo que hay. Con el nuevo kitbash, el rendimiento se ha ido al carajo, aún cuando ahora tenemos menos polígonos por cada edificio. Godot sigue reportando entre 2 y 3 millones de primitivas en la escena, o varios miles de primitivas en objetos que solo tienen 300 polígonos, no queda claro de dónde saca esa información, o qué entiende Godot por "primitiva". 

Ya veremos qué nos dicen los primeros afortunados (o desgraciados) que prueben el demo.

Más pruebas con O3DE

 Otro video de O3DE. Esta vez reimplemento un sistema traído desde las lejanas tierras de Godot, para ocultar el techo al entrar en las casas y así poder explorar el interior sin problemas.

Reporte de avance

De vuelta con otro reporte de progresos, aunque en realidad no ha sido gran cosa. Mayormente mi trabajo ahora consiste en agregar contenido, y algún que otro bugfix. Al fin se ha integrado al proyecto un primer kitbash para las casas de dos de las escenas. En algún momento debe llegar un segundo. Justamente eso es lo que me está atrasando ahora: el trabajo de rehacer casi todas las edificaciones  suele tomarme muchísimo tiempo. A pesar de que estoy dedicando casi tres horas diarias al trabajo, si los apagones lo permiten, no he conseguido todo el avance que quería para la presentación el día 23.

En cuanto a eso, si estás por la Habana en esa fecha, habrá un encuentro con jugadores en el Joven Club de Plaza. No sé si habrá equipamiento que cumpla los requisitos del juego, pero si lo hay, será posible verlo en acción.

Ahora, vayamos a otra cosa. En concreto, a otro culpable del atraso. En esta semana o la próxima debería salir O3DE 24.09 y he logrado probar el preview en Linux. Ha sido un proceso accidentado, pero de nuevo estoy poniéndome al día con el motor, e incluso hice un reporte de bug. El mes dedicado a estudiar Blueprint me ha servido de base para entender mejor el Script Canvas. Hay grandes diferencias: Script Canvas es orientado a eventos, los get/set están dentro de la línea de ejecución mientras que en BP basta que algún nodo las use, en BP necesitas un Sequence para ejecutar una secuencia de instrucciones y en SC puedes, desde cualquier nodo, conectar hilos de ejecución con varios nodos más, y otras que de momento, no he identificado. Sin embargo, conocer BP me ha abierto un poco la mente a esta forma de programar, y probablemente si hubiera dedicado más tiempo a SC, habría entendido BP mejor desde el principio.

 

Pero volviendo al tema, O3DE ya está casi listo para producción. De hecho, hay varios equipos haciendo cosas comerciales y ha ganado cierto renombre en aplicaciones de robótica. La versión 24.09, tal como esperaba, va a marcar un punto de inflexión, de ahora en adelante marchamos hacia la madurez del motor. Cabe esperar optimización, mejoras de estabilidad, usabilidad y el completamiento de funcionalidades como un sistema de partículas libre (desarrollado por Huawei). Todavía no lo veo como indie friendly, pero para un equipo con varios ingenieros capaces, las posibilidades de personalización de los flujos de trabajo son interesantes.

En cuanto regrese del viaje, pienso dedicar algo de tiempo a dominar Script Canvas y sacar algunos videos cortos con casos de uso básicos, de esos que ayudan más cuando uno está en pañales.

Un RPG sin diálogos no es un RPG

 

Vuelven las pruebas con O3DE

Con el 24.09 a las puertas, he dedicado algo de mi escaso tiempo a O3DE. La comunidad ha mejorado y esta vez he tenido ayuda invaluable de otros. 

 

Hablemos de Solo Writing, ahora que el término está de moda

Si has pasado por aquí antes, sabrás que he escrito varias novelas. De hecho, la primera de ellas, en opinión de un par de personas que respeto mucho, está entre las mejores de la fantsía cubana. Después de esa escribí unas cuantas más. Creo que demasiadas, considerando que no se logra publicar acá en Cuba. He escrito novelas largas, una en dos partes, algunas de ellas con múltiples personajes, cada uno con su historia. Probablemente se pregunten para qué les hago este cuento. ¿Para mencionarles mi primera novela y ver si se animan a comprarla? Algo de eso hay, pero en realidad, hoy hablaremos de otra cosa.

Hablaremos de qué tan complicado es para una sola persona escribir el guión de un juego y por qué deberías buscar ayuda.

The Key of the World tiene una historia bastante lineal si la comparamos con otros títulos similares. La diferencia se debe a que esos otros títulos tenían equipos de escritores (un detalle que suelo mencionar cuando imparto mi conferencia sobre creación de guiones). Incluso una historia semilineal como esta tiene varios personajes, varios villanos y varios arcos argumentales. Si se quiere tener unas misiones de relleno decentes, alguna de ellas debería extenderse hasta casi ser un mini-arco argumental adicional (detalle minúsculo: los diseñadores de misiones son un equipo más de escritores).

El guión del proyecto ha sufrido unos cuantos cambios a lo largo de los años. En algún momento queremos contratar a un escritor profesional para hacerse cargo de mejorar la parte narrativa. Ahora mismo no, porque hay cosas que urgen más y me acaban de recortar el salario a lo bestia. Pero se hará. También necesitaremos alguien para las misiones.

Durante estas reescrituras y adiciones, el guión ha ido evolucionando desde una historia bastante simple y tonta a algo un poco menos simple y tonto, pero lleno de agujeros e inconsistencias. De vez en cuando yo encuentro una. En cierta ocasión recluté a alguien para que ayudara en la tarea, pero en realidad no aportó nada y los problemas de coherencia siguieron ahí. Son el resultado de agregar cosas y quitar otras, todo eso sobre una base que tiene, como les dije, varios años de antiguedad. La simpleza original se ha convertido en la historia de tres facciones que quieren lo mismo por razones diferentes. Facciones que aparecen en diferentes momentos del juego, cada una de ellas con sus cadenas de personajes. Lo jodido del caso es que todo eso es trabajo de una sola persona: el menda. Que además escribe todas las quests. Y los diálogos, en español e inglés, sin ser traductor profesional. Y también programa el 90% del juego.

A primera vista todo parece estar bien, hasta que empiezas a hacerte preguntas. Hace un par de días, conversaba con dos colegas (expertos en UX/UI, si necesitan a alguien, los puedo conectar) y en apenas cinco minutos una de ellos, que tiene un background como escritora, había hecho las preguntas correctas y destapado agujeros de guión que me obligan a corregir varios detalles. Lo más curioso del asunto es que ni siquiera estábamos analizando el guión, solo estábamos discutiendo ideas para la estética de la interfaz. Del carajo, ¿no creen? Hablamos del UI y encontramos agujeros de guión. ¿Qué pasaría si de verdad nos hubiésemos dedicado a revisar la historia del juego?

La enseñanza que deberían sacar de toda esta historia es que si tu juego tiene una trama relativamente complicada o no lineal, te vendrá bien un par de ojos adicionales que te supervisen. No digo que sea totalmente imposible hacerlo solo, pero al menos yo, cada día me convenzo más de que una ayuda es necesaria. Incluso los mejores autores tienen su equipo de lectores cero que revisan los manuscritos recién escritos. Yo, que no soy de los mejores, tengo los míos.

La supervisión te ayudará a descubrir errores de consistencia. También te ayudará a destapar esos fallos en que incurrimos a veces los escritores al pensar que algo está claro y a la vista. Lo estará para ti, que eres el creador, pero para el lector/jugador podría ser oscuro, incomprensible o pasarse por alto.

Hay que saber aceptar la crítica. Mi guión está mal. Antes “lo sabía”. O creía que lo sabía. Ahora sí lo sé, con detalles concretos. Que la historia en general esté bien no quiere decir que su ejecución sea perfecta. Tres facciones. Tres propósitos. ¿Qué los motiva? ¿Por qué quieren lo que quieren? ¿Por qué hacen lo que hacen? Si yo mismo no puedo contestar con exactitud esas preguntas, difícilmente el jugador podrá hallarle sentido a la trama.

Así que ya saben. Aprendan de mis errores. Y si pueden, páguenme por el aprendizaje (me rebajaron el salario, ya les dije).

Nuevo sistema de combate

 Luego de una prueba por parte de alguien externo al grupo, he decidido cambiar un poco el sistema de combate del juego. Ahora en vez de un ataque básico en bucle con el arma equipada tendremos que hacer click para ejecutar cada acción de ataque. La diferencia es mínima, y los cambios necesarios también fueron pocos. No he terminado de pulir, por ejemplo, para evitar que se creen molestas colas de ataques (solo las habilidades deberían encolarse), pero en cuanto el trabajo atrasado me dé un respiro lo implementaré.

Supongo que el sistema continuo también tendría sus fans, pero eso requeriría una prueba muy amplia que no me ha sido posible realizar. Por eso toca asumir que la mayoría preferirá algo más en la línea Action RPG, aunque en general el juego no es un ARPG como Diablo o Last Epoch.Tengan en cuenta eso, por favor. La idea es un combate dinámico, pero no frenético, que no sea un rompemouses, y que pueda pausarse para poner acciones/habilidades en la cola.

Hablando de Last Epoch, me he tomado un rato para echarle un vistazo. No me ha sido especialmente atractivo, igual que me sucedió con Diablo 3. Me resulta raro, porque es un tipo de juegos que solía disfrutar antes. Quizás me estoy poniendo viejo y gruñón. En general, creo que se trata de la falta de los componentes exploración e historia. En esencia, se resumen a ir por ahí dando click encima de todo lo que ves hasta que se muere. No hay una conversación, no hay una quest que te haga pensar...

Aún seguimos sin fecha para tener un demo. Los apagones nos han golpeado tanto que es casi imposible trabajar, sobre todo, si el proyecto no es tu fuente de ingresos (de hecho es más bien una fuente de gastos).

Sí, estoy vivo. Reporte de progreso (o de la falta de él)

 Bien, estoy vivo. Pero la situación de país y la mía propia son críticas y avanzar en el proyecto se ha tornado casi imposible. En lo personal, he tenido que tomar tres empleos diferentes. No es que me esté haciendo rico con eso, pero al menos se garantiza sobrevivir. Eso también me ha hecho replantearme mis prioridades y he salido a buscar mejores ofertas. Hay que lograr sacarle el máximo a las horas de trabajo y eso solo se consigue de una forma: con contratos de desarrollo fuera del país. De momento no he logrado nada, así que toca insistir hasta que algo caiga.

De la situación del país... poco puedo decir que no sepan ya. Apenas tenemos 10 horas de electricidad al día con grandes probabilidades de que se reduzcan mucho más. Se habla de 6 o incluso 3 horas, y además no se prevé estabilidad. Me resistía a considerar a Cuba como un estado fallido, pero debido el asunto electricidad y otros temas he cambiado de opinión. Esto es un estado fallido, definitivamente.

Por todo eso, ha sido inevitable el retraso del demo, que ya casi está listo. No solo eso, sino que todo el juego está prácticamente detenido, porque nos resulta casi imposible dedicarle tiempo. Lo más triste es que para el demo solo necesitamos terminar un modelo (bastante complejo) y la interfaz de usuario. Solo eso.

De todas formas, manténganse en sintonía. Quizás pueda darles alguna buena noticia un día de estos. O un año de estos.

Dónde está el problema?

 Bien, básicamente ya tenemos una escena casi terminada, e incluso podemos entrar en algunas edificaciones! Sin embargo, todo esto está muy lejos de funcionar como debe ser. El problema? La navegación.

Godot utiliza Recast para calcular la malla de navegación. Es una biblioteca open source bastante veterana y confiable, probablemente la única con esta función. No solo Godot, también O3DE la usó para sustituir sus sistema de pathfinding basado en Kythera. Godot genera su malla de navegación a a partir de geometría y objetos de colisión, a diferencia de O3DE, que solo permite el uso de los últimos. El detalle aquí es que si no te pasas primero por la documentación, descubrirás a las malas que usar geometrías es un error mayúsculo. Las geometrías, o cualquier forma de colisión que no sea una primitiva, demoran el cálculo de la malla de navegación. En nuestro caso, hasta 5-6 segundos, mientras que en O3DE un terreno era calculado casi instantáneamente.

Tuve que darme a la tarea de optimizar el asunto. Para empezar, había que sacar las geometrías. Y aquí vino el segundo detalle: las opciones de selección de alcance de cálculo me indujeron a confusión. Había elegido procesar los children of root node, creyendo que solo procesaría los hijos del nodo Region, y realmente estaba procesando absolutamente todo en la escena. Una vez subsanado este error, logré configurar correctamente que solo se usara un grupo de nodos específicos, en este caso, primitivas de colisión. Cada casa, cada sección de terreno, cada objeto, ahora tiene una primitiva (caja o cilindro), que es la única que se utiliza para determinar la navegación. Esto redujo el cálculo de la malla a 1-2 segundo (hasta que se añadió relieve, que tiene colisiones más complicadas).

Y qué sucede en caso de edificaciones complejas? Bueno, aquí ya es necesario un poco de trabajo adicional. Hay que crear una geometría auxiliar para la navegación, y convertir esa geometría en una forma de colisión. Es la parte donde aún persisten errores que no sé si atribuir al motor o a mi ineptitud. En nuestro edificio más complicado, resulta trivial subir la segundo piso, pero bajar la escalera se vuelve un incordio.

Lamentablemente no tengo experiencia con otros motores en este tema, así que no podría decirles si Godot es igual o peor, que Unity, por ejemplo.

Me quedaría un segundo paso de optimización: ver si es posible partir la escena en varias regiones de navegación. Por qué este afán en optimizar algo que en definitiva, se precalcula de antemano en el editor? Pues porque si quiero abrir una puerta en el juego, es necesario actualizar de nuevo la malla de navegación, en tiempo de ejecución. De ahí que sea imprescindible reducir el tiempo.

Reporte de progresos

 Seguimos trabajando! Aunque no lo crean. Estoy escaso de tiempo y no puedo atender el blog. Usar internet en el trabajo es una molestia (mayormente para mi jefe, que le molesta que la use) así que no esperen mucha atención por aquí. 

En fin, si me siguen en X o en LinkedIn, podrán ver lo que estamos haciendo. Las funcionalidades básicas del sistema RPG han sido implementadas, y lo que más problema nos está dando es la parte gráfica. A pesar de eso, hemos avanzado mucho.Ya están listas algunas animaciones adicionales, en general se ha mejorado la calidad, y el AnimationTree fue reimplementado. Al fin hay blending! 

Godot aún no tiene sistema de terreno oficial y hemos tenido que desechar nuestra segunda opción, el addon de Zylann, porque la pérdida de rendimiento se hacía notar en hardware de gama baja. El cambio ha sido para bien: el aspecto visual cambió mucho. En fin, toca esperar que el equipo de Godot decida qué harán con el terreno, pero eso demorará.

Se ha implementado un sistema para entrar y salir a las casas sin necesidad de cargar una escena independiente. No funciona perfectamente, pero la funcionalidad era imprescindible. Para complementarlo, un nuevo lote de casas ha sido agregado al proyecto. 

El contenido del juego como tal está casi completo para la escena de introducción. Se echa muchísimo de menos un editor de cinemáticas, pero ya saben que la filosofía de Godot no es esa. Incluso, es posible completar toda la historia principal y varias misiones secundarias, para después pasar a la escena siguiente. Aproximadamente 20 minutos de juego, si te sabes todos los diálogos de memoria como es mi caso.

Qué nos falta? Sonido, interfaz de usuario, música, y otros detalles.

Unity cambia su modelo de negocios

 Un nuevo anuncio ha cabreado a casi toda la comunidad de usuarios del popular motor de juegos. El modelo de negocios vuelve a cambiar, y aunque lo más llamativo es que el límite de la licencia Personal aumenta a 200k anuales, esto viene con malas noticias: si superas ese límite y además tienes más de 200k instalaciones, tendrás que pagar 20 centavos por cada instalación e inicialización del juego por encima de esas 200k. Incluso, si el mismo usuario reinstala el juego, pagarás dos veces. O tres... o más. Para la licencia Pro, el límite sube a un millón de instalaciones y el fee se reduce a 2 centavos. 

La jugada parece estúpida, y lo es. Esto golpea durísimo a los F2P, a los juegos que monetizan ads y generan unos pocos centavos por instalación (a menos que uses la red de ads de Unity, qué casualidad), a los juegos del Gamepass que también ingresan muy poco por cada copia instalada (y si formateas tu consola o reinstalas tu PC y vuelves a instalar desde el Gamepass...), e incluso te hace vulnerable a ataques de instalación en bulto. Rayos, si alguien piratea tu juego tendrás que pagar por esas instalaciones piratas! El hilo en reddit/gamedev lo explica mejor que yo. Incluso hay jugosos chismes: el Riki vendió sus acciones en la empresa la semana pasada. Ya lo decía yo, casualidades.

Las prestaciones extra que gana la licencia Personal gratis no es que compensen mucho y también hay otro cambio: a partir de noviembre Unity requerirá que inicies sesión y tengas conexión a internet. En caso de cortarse la conexión, podrás usarlo offline durante tres días. Quizásesto no sea un problema para nadie en esta época de conexión abundante, salvo para los cubanos, que aún estamos en la edad de piedra (con grandes probabilidades de retroceder a la edad anterior, si es que hubo alguna).

Aún está por verse si Unity dará marcha atrás a esta monumental metida de pata. El golpe (otro más) a su credibilidad ya está dado y la gente se está planteando seriamente si pasarse a Godot o a Unreal, cuyo 5% en fees es menor y su ritmo de innovación es más rápido, sin necesidad de tantas compras ruinosas y despidos masivos. Por ejemplo: Unity tuvo que comprar Ziva para obtener tecnología de renderizado realista de humanos y equipararse a Unreal. O3DE hizo lo mismo sin comprar a nadie. Luego compraron a Weta Digital... no me queda muy claro para qué la querían.  

Como decía un querido amigo mío: ya nos veremos.

Baldur's Gate 3 rompe los moldes, pero eso ni es nuevo ni es malo

 No recuerdo que un juego isométrico y con combate por turnos haya sido jamás candidato al Game Of The Year. Ni tampoco un título que otros desarrolladores se hayan apresurado a calificarlo como una anomalía, que no debería ser tomado como el estándar a seguir en la industria. El problema es que el trabajo de Larian ha sido tan excepcional que ha opacado juegos tan esperados como Starfield, Zelda o el mismo Diablo IV (alguien habla de Diablo IV a estas alturas).

A ver muchachones. Juegardos excepcionales los han habido antes. Clásicos, les llaman. Lo fue Skyrim, en su momento, y les recuerdo que aún se juega y Bethesda le saca lascas. The Witcher 3 ofreció un mundo bastante bien logrado y fue uno de los mejores RPGs de la década pasada. ¿Alguien recuerda el viejo Fallout 2 y las libertades que permitía? Son juegos hechos con cuidado y tiempo, no un Assassin's Creed que sacas cada dos años. Cosas hechas a toda prisa seguirán saliendo y haciendo dinero, porque eso, señores, no es culpa de la industria, es culpa de los jugadores, que pagan por un nuevo Assassin's Creed, por un nuevo Call of Duty o por un nuevo FIFA, por los DLCs infames que activan contenido que ya está ahí, los pases de batalla, las cajas de botín, y todo lo que sirva para exprimir el bolsillo del cliente.

Que de vez en cuando venga un Baldur's Gate 3 no va a hundir la industria. Para empezar  Tampoco los desarrolladores deberíamos sentirnos preocupados, porque las genialidades pueden provenir de cualquier parte (igual que las mierdas monumentales). Y lo bueno de todo esto es que hay espacio para todos. Hay espacio para que un pequeño estudio nos sorprenda con cositas como Underrail, que cuando miras a tu alrededor te ha robado cientos de horas de tu vida (y es solo un RPG isométrico en 2D) y hay espacio para que los grandes lo intenten. Que no quieran ya es otra cosa. 

Ahí es donde está el problema y el apuro por hacernos creer que Baldur's Gate 3 no es ni debería considerarse como el nuevo estándar. En el miedo al riesgo, en la falta de amor a lo que se hace y el poco respeto al jugador (que repito, es culpa del propio jugador). Sí, es inalcanzable para muchos, pero debería ser la aspiración de todos tratar de aproximarnos algún día a ese logro.

Sistema de misiones casi a punto

 Junto con los diálogos, el sistema de misiones es el otro componente esencial que debía terminar para que las mecánicas de juego estuviesen casi completas. El sistema de misiones (o quests) pasó por manos de dos personas, siendo la segunda iteración la más completa, pero mal documentada y bastante compleja, con un uso intensivo de signals. Me tomó un par de horas entender cómo funcionaba, e incluso hasta ayer descubrí cosas que estaba haciendo mal. No ha sido divertido, pero no suele serlo nunca cuando se trata de programar juegos.

A diferencia de mis ideas iniciales, el sistema de misiones acabó siendo una escena autoload (o sea, que Godot la trata como un singleton) y las quests son escenas hijas. Hay que tener en cuenta que para Godot, una escena puede ser cualquier cosa. Lo mismo es un prefab, que una locación del juego, que el modelo de tu personaje con sus scripts adjuntos... Es muy versátil. En fin, que tenemos una jerarquía de nodos con misiones y sus objetivos. Nada original, de hecho GDQuest usa el mismo enfoque en su videotutorial.

Ahora que las bases están sentadas, faltarían detalles como salvar correctamente el estado de objetivos multi (recoger X objetos, matar X NPCs) y encontrar los casos específicos que requieran la implementación de objetivos únicos. Pero estas bases ya permiten cubrir la mayoría de los casos y gracias a eso es posible jugar, con limitaciones, claro, el 90% de la primera escena.