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.

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. 

 

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.

O3DE 23.10

 De alguna forma olvidé que estamos en el mes 10 y que tocaba ración de Open 3D Engine. Ayer (o antier, ya no recuerdo), se lanzó la versión 23.01, la última de este año. El anuncio es demasiado escueto para mi gusto y no logro sacar nada en claro, salvo que se ha facilitado el proceso de generar el build de los proyectos.

Lamentablemente esta vez no tendré tiempo de probarlo. Estamos en una fase bastante crítica del proyecto, implementando cosas a toda prisa con vistas al festival de noviembre. Todo eso en medio de una crisis energética total, con apagones de 10 horas diarias o más. Pero no se preocupen, que según el gobierno, no estamos tan mal. Creo que esperaré a la primera versión del 2024 a ver si hay cambios llamativos.

Probando O3DE 2305

 Luego de un mes de dejarlo para otro día, al fin me he dispuesto y he instalado O3DE 23.05. Les hago la historia desde el principio. Saben que en casa no tengo internet, y O3DE requiere conexión para instalarse, sí o sí. La única solución era conectarme a través del teléfono y usar los datos móviles, lo cual tiene un costo que si bien no es exorbitante, es significativo. Esa no es la única dificultad, también tenemos que la velocidad de conexión por 4G en Cuba es más o menos la mitad: 4G/2=2G. Con suerte sacas 10-15 kb/s de descarga. Por tanto, hay que dejarlo para la madrugada, que tiene la ventaja adicional de que el tráfico se cobra a la mitad. Como ven, la tarea no era sencilla, de ahí que la fuese posponiendo desde que salió O3DE.

Tampoco ayudaba que la lista de cambios no refleje nada impresionante. A diferencia de la 22.10, que fue un salto cualitativo, la 23.05 es más bien sosilla. Me planteé varias veces saltarla y esperar a la de finales de año, pero me picaba la curiosidad y esta madrugada al fin me desperté y decidí que lo iba a intentar. No fue rápido, y ahora me caigo de sueño. 

La primera prueba fue decepcionante. Por alguna razón, ni siquiera pude usar el motor cinco minutos seguidos: el editor iba lento e inestable, en dos o tres clicks ya dejaba de responder. Cerré el proyecto y volví a abrir y ya estaba todo funcionando un poco más normal. De todas formas, el motor sigue siendo bastante incómodo. Aún hay que tenerlas animaciones separadas, es como si hubiesen diseñado el sistema para que modeles el personaje y te bajes las animaciones de Mixamo. El retargeting parece sencillo, sin embargo no me acaba de funcionar. No hay forma simple de hacer un build, el proceso aún es esotérico e involucra modificar archivos de cmake y compilar el fuente del motor.

Por eso mantengo mi proyección: no será muy cómodo de utilizar al menos hasta la 24.10, y podría equivocarme.

Nuevo video: implementando el manejo básico de armaduras

 

Godot 4.0 estable

 Tal como esperábamos, hoy se ha lanzado la versión 4.0 de Godot. No más Release Candidates. Salvo por una prueba rápida del proyecto, no le he dedicado tiempo, eso queda para por la noche. No me he actualizado desde la RC2, así que no sé si algunos bugs molestos fueron resueltos entre las RC 3 y la 6. En concreto, me estaba fastidiando mucho un fallo al presionar Ctrl-S o Ctrl-K. Pero en general, el resto del proyecto iba muy bien ya en la RC2.

Pensaba hacer un video, pero no creo que el proyecto, en su etapa actual, esté como para mostrarlo.

ültimos cambios y estado actual del prototipo

 Ante todo mis disculpas, en el día de ayer el repo del prototipo estuvo en muy mal estado. Se rompió mi fuente de alimentación (la de la PC, no la mía) y muchos cambios se quedaron pendientes. Cuando logré poner el disco duro en otra PC, no me percaté de que faltaban archivos por agregar. Y cuando agregué esos archivos, no me percaté que una escena se había dañado cuando mi fuente falló y se apagó la PC. Es un problema que ya veo es habitual en Godot.

En fin, esos errores han sido eliminados. Y sustituidos por otros. Pero me place informarles, queridos compañeros de este sindicato, que el prototipo está casi terminado. O al menos, ahora es posible combatir. Lo que queda por delante es el proceso de pulir, refinar bien el sistema, y quizás agregar un par de cosillas. Los planes eran tener todo listo para enero, pero como nuevamente estoy sin estación de trabajo, creo que no podré cumplir a tiempo.

Pasando a algo nuevo

 Bueno, ya concluido y lanzado Battle Gear, toca moverse a otra cosa, que ya íbamos atrasados. Luego de muchas discusiones y de golpear con el látigo al resto del equipo para hacerles ver su falta de ambición, hemos iniciado un pequeño prototipo. El objetivo no es hacer un juego completo, ni iniciarlo, sino crear un banco de pruebas para el sistema de combate.

En este prototipo solo trabajaremos en eso. Nada de gráficos, interacción/exploración solo la justa, y detalles los estrictamente necesarios. Luego de más o menos un mes, ya hemos identificado unos cuantos problemas y descubierto algunas cosillas. 

Por ejemplo, el animation retargeting nos ha salido casi a la primera, aunque tiene sus fallitos. Solo funcionó bien cuando hice el mapeo de los huesos empezando por los pies y hacia arriba. Lo natural es que empieces de arriba hacia abajo, pero al llegar a la cintura, las cosas empezaban a dar problemas. Quizás tenga que ver con la estructura de huesos creada por Blender. 

Sin embargo, el nuevo sistema de pathfinding ha demostrado ser problemático. El personaje sigue flotando sobre el terreno y en reddit me dicen "que así es como debe ser". El segundo programador del equipo lleva varios días enfrascado en la solución de ese problema.

La jugabilidad ha sido relativamente trivial de implementar, porque muchas ideas ya estaban probadas (o al menos, pensadas) con anterioridad. Eso aún sigue y seguirá siendo un blanco móvil, porque es donde probaremos y romperemos más cosas, en busca de un combate en tiempo real dinámico, pero sin caer en lo frenético. Que para machacar botones ya tenemos el Diablo o DOTA (si te apetece un combate sazonado con el mejor menú de insultos internacionales).

Y en caso de que sientas curiosidad por cómo se arma todo este muñeco, el repo donde estamos trabajando es público.

Creando una cámara isométrica con O3DE

Decir que este ha sido un video complicado es quedarse corto. A mitad de trabajo se rompió mi PC y me tomó unas semanas recuperarme. Tuve que hacer la parte final en otra PC, y editar en la mía, ya recuperada. A esas alturas había olvidado el orden del video, no tenía tiempo para tratar el sonido, y ha sido un desastre total.

No obstante, no podía dejar perder el trabajo ya hecho.

Espero que les sirva para que al menos se formen una idea de cómo funciona O3DE, un motor que a pesar de sus probelmas, no se ve tan mal. De hecho, espero poder migrar en próximos proyectos, cuando él resto del equipo mejore en experiencia y hardware.

Huelga decir que esto no es un tutorial, solo es una prueba rápida, muy incompleta y con un dominio casi nulo del lenguaje script (Lua) y de O3DE en general.

O3DE 22.10, algunas conclusiones adelantadas

 PArece una tontería,pero me ha alegrado mucho haber conseguido instalar O3DE 22.10. Una tarea trivial en otro país aquí se vuelve un rosario de dificultades. No tienes internet en casa, o la que tienes es de poca velocidad y con tiempo limitado, y así... Había estado esperando este lanzamiento para hacer el esfuerzo de cargar la PC hasta mi trabajo y hace dos días lo hice. 

A ver, este no es el motor que puedes usar en Cuba con facilidad. De hecho, se está volviendo cada vez más difícil usar otros motores que antes eran más simples, como Unity. O3DE carece casi por completo de documentación adicional, y la oficial está disponible solo online. No existen tutoriales y punto. Los videos demostrativos de Amazon ignoran por completo la programación con Lua y se centran exclusivamente en el scripting visual. La gente que lo usa es porque ya tienen experiencia con Lumberyard o quizás CryEngine. Conseguir una respuesta en reddit toma tiempo y a veces ni siquiera la consigues, porque la comunidad aún es escasa.

Muchos detalles requieren pulido. Por ejemplo: el incómodo proceso de crear un proyecto, que demanda hacer una compilación inicial. Eso obliga a que los artistas necesiten un Visual Studio reciente (de nuevo, casi imposible de conseguir en Cuba). Y si eso les parece un engorro (se está trabajando en arreglarlo), no es ni siquiera lo peor. El build de un proyecto no puede hacerse con la versión precompilada del motor: es obligatorio tener el repo y compilar el motor. Pruébenlo un día y me cuentan.

Todo esto es lamentable, porque este es el motor que necesito, o el que tú necesitas, si piensas escalar y desarrollar proyectos de envergadura, con equipos medianos o grandes, donde Godot se queda corto. Es una herramienta pensada para títulos AAA, solo que aún le falta muchísimo. Supongo que toca sentarse y esperar un par de años.

Probando Godot 4 beta 1

 Podría decir "la espera ha terminado", pero no es así. He esperado dos años por el beta o por algo mínimamente usable (el proceso de  desarrollo tomó tres años y medio) y este beta 1 al menos ofrece un feature freeze. Sin embargo, para la versión definitiva aún faltan... yo diría que 9 betas más, seguidos por tres o cuatro Release Candidates.

De momento les dejo esto, para que se rían con el susto que pasé.

Me he enamorado

 No, no es de una mujer. De esas me enamoro a cada rato, así que no es noticia. Tampoco de un hombre, todavía no me da por eso. Me he enamorado de los diccionarios, y no me refiero a esos libracos que tienen todas las palabras. Estoy hablando  de los diccionarios de GDScript. No fue amor a primera vista, claro, pero ahora me son tan necesarios que no me sentiría igual en un lenguaje que no los tenga.

Y a propósito, hemos alcanzado las 3900 descargas. Nada mal. 

Pequeña prueba de navegación 3d

 

¿Y cómo le va a O3DE? Bien, gracias

 Parece que luego de un lanzamiento medio incompleto, pero con muchísima promoción, O3DE ha entrado en la fase en que casi nadie se interesa por él. No han salido muchos tutoriales en Youtube, ni reacciones, e incluso las noticias han decaído. Lo último que supimos esta semana fue de la inclusión de Cesium, que es una herramienta muy, pero muy específica para asuntos que la mayoría de los desarrolladores no pensamos ni mirar.
No he podido seguir las pruebas porque como ya les dije, es muy complicado usar O3DE si no tienes una conexión rápida y permamente, algo tan escaso acá como... bueno, como todo. Pero no desesperen. O3DE es simplemente un caso raro dentro de los motores libres. Es una herramienta AAA que acaba de venir al mundo como Atenea, toda crecidita y armada, por lo que es un poco difícil que sume desarrolladores que hagan grandes aportes. Aparte del equipo de Amazon, dudo mucho que alguien entienda lo que tiene dentro.
Considerando que New World lo utiliza, no deberíamos temer por su futuro. Quizás no vaya rápido y haya que esperar un año antes de tener una versión más amigable, pero abandonado no va a qeudar, mientras Amazon lo necesite. Sin olvidarnos de que Deadhaus Sonata también lo usa y Star Citizen debería haber migrado desde Lumberyard.
O sea, que mejor nos olvidamos de él por unos meses y retomamos el tema más adelante. Hay cosas más interesantes a corto plazo, como el primer beta de Godot 4, que posiblemente nos llegue antes.

Mi última experiencia con O3DE

 Unos días antes de que se lanzara la primera versión oficial ya había descargado O3DE con su instalador, pero probarlo se me había vuelto casi imposible. Para empezar, el motor instalado debe transportarse a otra PC respetando la ruta donde se instaló. Existe el requerimiento adicional de tener instalado Visual Studio 19.9 (me dicen que las Build Tools también bastan para el proceso de compilar el proyecto). Y lo último y más trabajoso, es que al crear un proyecto es necesario una descarga de dependencias de más de 1 gb.

Al fin logré reunir todos estos requisitos en casa, de los cuales el más difícil era el de las dependencias. Me costó bastante caro bajarlas todas por datos móviles, incluso descubrí cómo guardarlas en un lugar específico y no en el perfil de usuario, para evitar llenar mi unidad C. Sin embargo, el proceso inicial de compilación reescribe mis cambios y vuelve a buscar las dependencias en C. La solución en este caso es joderse y copiar la descarga al sitio donde él las quiere, pero no fue tan fácil. Solo Qt ocupaba más de 6Gb al descomprimirse, llenando mi disco y haciendo fallar la compilación inicial.

Hasta ahí pude llegar. Lo gracioso del caso es que me era más fácil usarlo antes, cuando tenía que compilar el motor. Mi opinión, por el momento, es que O3DE no es el típico motor que puedas montar y poner a funcionar a menos que seas un estudio con personal bien capacitado. Eso, en cierto punto, es su fortaleza (o lo será), porque se aproxima más a Unreal, o su progenitor CryEngine, que a Unity o Godot. Quizás es un poco categórico y absoluto decir que no es para indies, así que vamos a dejarlo en que necesitas recursos y experiencia para lidiar con sus requerimientos y problemas actuales. 

Hace 65 millones de años que lo estábamos esperando O3DE 21.11

 Primer release de Open 3D Engine, para que puedan probarlo sin necesidad de compilar todo el motor. Además, han tenido la gentileza de publicar un conjunto de tutoriales (para hacer un Pong) que pueden servir de punto de partida.

La aventura del multijugador en Godot 4

 Cuando digo aventura, no es esa de las de Disney, con final feliz y canciones. De hecho, aún no se ve el final por ningún lado. Es más bien una aventura tipo Juego del Calamar (que está de moda), donde no sabes lo que viene a continuación y hay mucho ensayo y error contra reloj. Sobre todo error.

Empecemos por el principio, que es donde empieza a principiar todo. Ya está saliendo el pre alfa de Godot. No he tenido tiempo de hablar del asunto, pero lo he estado usando desde hace un mes aproximadamente. Mi próximo objetvo es hacer algo multijugador, por eso volví a echar mano del tutorial sobre servidor dedicado de Game Dev Center, invertí un rato en ver los videos iniciales con calma, hasta que al fin pude encontrar algo de tiempo para implementar una prueba. El problema es que el sistema de redes cambia muchísimo en Godot 4. La documentación no lo dice, la gente aún no lo sabe (salvo los que lo programaron), así que toca joderse.

Aunque el tutorial aún puede darte una cierta idea general, he tenido que descubrir a las malas cómo se hacen las llamadas RPC. Antes simplemente declarabas una función remote del otro lado. Ahora la función debe estar declarada en ambos lados de la conexión, con los mismos parámetros y marcada con @rpc. Además, de un día para otro, el parámetro any de la anotación @rpc se convirtió en any_peer. Por suerte, un amable mensaje de error me lo explicó en detalle. 

Supongamos que en el cliente creas un singleton llamado server, que entre otras cosas debe enviar un valor al servidor:

server.gd
@rpc(any_peer)
func test_value(val):
    rpc_id(1,StringName("test_value",val)

En el lado del servidor, necesitaremos una clase o script llamado server también, porque la ruta de la función debe ser igual:

server.gd
@rpc(any_peer)
func test_value(val):
    print(val)

 Así, a grosso modo. Si empiezas a ver errores en el debug de que el checksum no coincide y que la ruta del nodo no existe, quiere decir que hay una diferencia entre la función de un extremo y la del otro. Aún me queda mucho por delante, pues ni siquiera he pasado de la parte de login, usando un servidor de autentificación. He decidido, de momento, no enredarme con un gateway, porque ya eso serían cuatro proyectos diferentes. No me parece que se justifique en un entorno donde a lo más, habrían dos o tres servidores, uno para autenticación y los otros sirviendo mundos o regiones del juego.

Con un poco de suerte, en diciembre habré conseguido entender la replicación del estado de los jugadores.