Unigine 2.15

 Me llega un mensaje de aviso de que ha sido lanzada la versión 2.15 de Unigine. con un montón de funcionalidades y cambios, como es lo usual. Aunque algunas de esas cosas llegan un poco tarde, como el editor visual de materiales, que ya es obligatorio en cualquier motor que se precie. 

Unigine se caracteriza por un renderizador de alta calidad desde sus inicios, pero su precio de licenciamiento y su mentalidad cerrada evitaron que se extendiera. Aunque eso ha cambiado y ahora permiten acceder al motor sin restricciones, ya es un poco tarde.

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.

Se los dije

 Hace un par de días lo decía, no muy en serio, pero parece que acerté. 


 

Arcane no solo dejó atrás al fenómeno de El Juego del Calamar., sino que también está considerada en IMDB como una de las mejores series de la historia, por encima de Juego de Tronos. Por supuesto, hay algunas que han puntuado mejor, como Chernobyl o The Wire. Y también debemos considerar que el final de Juego de Tronos fue bastante discutido.

Para los que anticipaban que La Rueda del Tiempo podría ser un digno heredero de Juego de Tronos, pues eso no se lo creía ni Amazon. Para empezar, buena parte del éxito de la adaptación de Canción de Hielo y Fuego se debe a que se trata de baja fantasía, con un componente muy alto de violencia y sexo. No veremos mucho de esto último en La Rueda y en cuanto a violencia... no creo que fulminar bichos generados por computadora con hechizos le gane muchos puntos. La gente no está muy dispuesta a darle una oportunidad a este tipo de fantasía. Agreguemos que su desarrollo es más lento (son una docena de libros) y que sus primeros episodios no encganchan mucho y ya podemos incluso dudar de que esta serie logre llegar la final de la historia original.

En cambio, la ambientación steampunk oscura de Arcane es más potable. Explota desde sus tres primeros capítulos y cuando llegas al noveno estás más loco que Jinx porque hay que esperar un año o más por la segunda temporada.

Parece que el relevo ha llegado de donde menos los esperábamos: de los videojuegos en vez de la literatura.


Unity compra Weta Digital

 En el hipotético caso de que no te hayas fijado en los créditos de unas cuantas pelis de éxito de los últimos tiempos, o que ni siquiera hayas visto Lord of the Rings, te diré que Weta es la empresa detrás de los efectos especiales de muchos filmes. Además del mencionado, Weta ha trabajado en Avatar, King Kong, El Planeta de los Simios, etc. Pueden consultar la lista completa en Wikipedia. Fundada por Peter Jackson y un par de amiguitos en 1993, acumula un montón de premios y ha desarrollado un conjunto de herramientas para facilitar el trabajo delos artistas de efectos especiales. 

Por ejemplo, City Builder para generar ciudades, Manuka/Gazebo el par de renderizadores (el primero de alta calidad, para el resultado final, el segundo en tiempo real, para previsualizaciones rápidas) o MASSIVE, para animar multitudes de agentes (como la batalla de los cinco ejércitos, en El Hobbit). 

Estas herramientas en concreto son lo que Unity busca obtener con esta adquisición que ha implicado desembolsar 1600 millones entre efectivo y acciones, y por supuesto, su grupo de desarrollo que suma unos 275 ingenieros. Los artistas visuales serán movidos a una nueva entidad nombrada Weta FX, que continúa siendo propiedad mayoritaria de Peter Jackson, para que siga convirtiendo historias de un solo libro en trilogías de siete horas. La adquisición pondría esta tecnología al alcance de los usuarios de uno de los motores de juegos más populares del mundo, facilitando en gran medida la creación de contenido de alta calidad.  

Creo que habrá que esperar un año al menos a que se concrete la integración de estas nuevas herramientas en el flujo de trabajo de Unity y entonces veremos la repercusión que tendrá la compra de Weta en el desarrollo de juegos. También pienso que esta movida es un intento de ponerse a la par con Unreal Engine, que ha dejado el listón muy alto con su versión 5. O por lo menos, no seguir quedándose atrás. Si lo analizamos bien, es un jugada en cierta forma lógica: apunta a la base de usuarios de Unity (creadores indies, equipos pequeños) y les ofrece, en teoría, la posibilidad de equipararse con los grandes. Así que muchas felicidades a los colegas que usan Unity, auqnue repito, aún está por verse el efecto real.

Un bug resuelto, luego de meses de búsqueda

 Hay veces que uno se sienta a trabajar y dice: hoy sí voy a solucionar este bug. Revisas el código de punta a cabo, pruebas enfoques diferentes, te exprimes el cerebro... y te vas a dormir sin haber resuelto nada. Ayer logré romper la rutina y arreglar un error que me venía estropeando la IA del juego desde que implementé el combate básico. La historia corta: tuve que revisar el código de rotar el personaje hacia una posición y terminar usando el método simple (look_at), pero antes hubo que cambiar la orientación del modelo. 

Por defecto, los modelos se exportan de Blender orientados hacia +Z. En los foros me sugirieron que debían estar orientados hacia -Z, que es la dirección que Godot asume como "frente". Además, en vez de ir directamente a usar look_at, utilicé un código que terminaba sumando más y más grados a la rotación y el NPC saltaba entre dos direcciones en vez de apuntar al jugador y seguirlo en su movimiento. Era un problema molesto que estaba trancando todo el desarrollo de la IA y que me hacía perder mucho tiempo. 

Ahora que está solucionado el asunto de mayor prioridad, me toca sentarme a estudiar el proceso de creación de plugins para Android en Godot. Es la única forma en que puedo integrar el sistema de micropagos desarrollado en Cuba. Eso implica aprender un poco de Java o Kotlin, algo que no estaba en los planes.

De regreso

Ya estoy de vuelta al trabajo, con la billetera vacía, pero contento. La mejora no ha sido sustancial, porque solo he encontrado un i7 7700 (anteriormente tenía el i5 6500), pero considerando que Cuba vive un proceso de inflación desbocada, había que apañárselas con lo que apareciera. En un mes podría costar mucho más. También he saltado a 16 Gb de RAM, que ya me era muy necesario.

He tenido que tomarme un par de días para volver a familiarizarme con el proyecto, al que solo había echado unas esporádicas miradas. Hay montones de problemas de diseño que corregir, errores que cometí al inicio del proyecto y que he ido identificando poco a poco. Se trata de algo que aunque no es muy grande, es un poco mayor que El Laberinto del Saber.

Ahora que el trabajo está encarrilado de nuevo, es momento de poner en marcha otros planes atrasados, para tartar de rentabilizar un poco más el susodicho Laberinto.

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.

Reporte de estado

 Sigo sin PC, así que no tengo tiempo para publicar aquí. Además de eso, la ciudad está sometida a restricciones de movilidad: a mediodía cerramos y me voy a casa. El poco tiempo libre que tengo se lo he dedicado a un proyecto de un amigo.

Se trata de algo para móviles, que parece ser la moda ahora, con Godot. Definitivamente útil para aprender, aunque no era mi intennción involucrarme en proyectos 3D con Godot 3.x. Las dificultades que estamos experimentando me han dado la razón, casi todas relacionadas con pobre rendimiento. Espero poder publicar algún video dentro de unos meses.

Quizás podría decir que la buena noticia es que logré compilar O3DE, crear un proyecto y abrirlo. La documentación es escasa, incluso si buscas la referente a Lumberyard. Eso y la falta de tiempo me impiden hacer poco más que poner objetos en la escena. 

En fin, que puedo dar la mitad de este año por perdida, a menos que considere un logro ponerme al día con series que nunca vi por falta de tiempo.

Nuevo temblor

 Esta mañana tuvimos otro temblor bastante fuerte. Al parecer, su origen fue en Haití, donde fue más fuerte aún. Es muy difícil explicar lo que se siente al escuchar los ladrillos de tus paredes caer y el ruido de la casa al sacudirse, así que no me detendré en eso ahora. 

Lo peor de todo es ver cómo tu vivienda poco a poco se va llenando de grietas y cada día te encuentras un pedacito de pared aquí, y otro allá, que ha caído mientras estabas fuera (porque no solo hay temblores grandes, hay otros menos perceptibles a diario). Y ver que no puedes hacer nada para arreglar esos daños, porque los materiales no existen. O existen a un precio inalcanzable. 

Así que te sientas a esperar, a preguntarte si la próxima vez se caerá la pared completa, junto con el techo (si no se lo ha llevado antes un huracán) y el resto de lo que te queda de casa. A preguntarte si te caerá encima. No te sientas a pensar en soluciones porque no las hay. 

Laberinto del Saber disponible para PC

Ya está casi listo (aún quedan detalles por pulir) el port del nuevo Laberinto del Saber para PC. Pueden jugarlo en Windows o Linux, ya sea con teclado, como en los viejísimos tiempos de principios de los 90 o con un mando. 


 

Disponible para descarga gratis, pero también pueden dejar una donación, que me vendría muy bien para armar una nueva PC.