Estamos en cuarentena

¡Aunque no cerrados! Solo estoy ausente al trabajo la mayor parte del tiempo y desde casa no me es posible usar internet, salvo para lo esencial. O sea, chatear con los colegas escritores y jugar Regnum. Y últimamente ni tanto de Regnum.
Ya el verano está aquí, por eso el horario de mediodía y tarde es de siesta y apartarse de la PC, para evitar calentarla. Ni siquiera estamos en junio y ya hay récord de temperatura en un lugar no muy lejano.
Entonces, ¿qué estoy haciendo? Godot, principalmente. He estado adelantando un poco en el port del  Laberinto, desarrollando un prototipo de juego 3D y experimentando con la rama 4.0. De esto último les advierto que lo eviten, excepto para cosas muy simples. Ahora mismo, la 4.0 no crea proyectos y no los importa. Mi solución fue usar un proyecto que ya estaba en el listado y cambiarle el nombre (ojo, la carpeta sí debe conservar su nombre) para poder trabajar sobre ese. Tampoco se puede arrastrar un archivo hacia el panel de propiedades. A pesar de todo, la estabilidad es sorprendentemente buena.
En cuanto a la 3.2, sigo descubriendo que hay muchas cosas que son muy fáciles de hacer, aunque a decir verdad hay otras que aún faltan y faltarán por un buen tiempo.
En caso de que aún no estés convencido y quieras probar una opción más profesional, Unigine al fin ha decidido lanzar una Community Edition, para que los desarrolladores puedan probar el motor libremente y pagar solo cuando superen un monto específico que no recuerdo ahora. Vale la pena echarle un vistazo.

De gatear a caminar

Ya he alcanzado ese punto de inflexión donde se pasa de tener que dejar todo para después que se hagan preguntas a poder trabajar con más eficiencia. En estos días de encierro he dedicado tiempo a portar El Laberinto del Saber de Unity a Godot, una tarea que tenía abandonada desde hacía un mes. Con un poco más de conocimiento ahora, pude dedicar varias horas seguidas al asunto y ver un avance notable.
En concreto, ya he implementado el uso de las puertas, puntuación, las bonificaciones, y el conteo de tiempo. Se dice fácil, pero eso implica tener que cambiar muchas cosas, porque la forma en que se manejan las colisiones en Unity es diferente a la de Godot. Para empezar, ahora tengo que lidiar con un TileMap, que aunque agiliza la creación de la escena, requiere sus detalles para determinar el tile que estás tocando.
Me queda lo más difícil: mover a los fantasmas persiguiendo al jugador y abandonar cuando ya no esté visible, una IA sencilla, pero que tiene sus cositas. Por suerte, Godot sí ofrece un sistema de navegación en 2D, que Unity no tenía, lo que debe facilitar este tema.
De continuar trabajando así, en un mes podría volver a tener un prototipo y comenzar a pulir otra vez.

Sobre la factibilidad de los virus como armas

Un par de cosas llamaron mi atención sobre este tema en los días recientes y le estaba dando vueltas a escribir sobre el tema, desde el punto de vista de un escritor/guionista. Es factible el uso de virus como armas, ya sea por países o terroristas? En principio, sí, pero en la vida real, la situación tiene sus aristas.
Empecemos por el principio. En la nueva temporada de Strike Back, unos extremistas musulmanes croatas se apoderan de un virus, ya saben con qué propósito. Por suerte, ahí está la Sección 20 para fastidiarlos. En un frenético combate, el virus se libera y de inmediato, los terroristas a su alrededor se contagian y mueren en pocos segundos. Obviando el hecho de que no sé si sea posible que un virus mate a su víctima en segundos, esto de por sí lo convierte en un arma casi inútil, que causaría a lo sumo el mismo daño que una bomba tradicional. Al liquidar al su portador en segundos, el virus no puede propagarse y simplemente mataría a las personas cercanas que no puedan correr lo suficientemente rápido. Además, vamos a suponer que se consigue un ataque o dos con cierto éxito en la cola de Viernes Negro, replicar el virus para realizar otro ataque requeriría de un laboratorio, personal medianamente calificado, materiales no tan accesibles o rastreables por las agencias de seguridad, y quién sabe cuántas otras dificultades.
Es más sencillo y barato forrar de explosivos a un voluntario y llenarle los bolsillos de clavos. Siempre es posible conseguir más explosivos, más clavos y más voluntarios. ¿Significa esto que un virus o bacteria no es una buena arma terrorista? Pues no tan así, y luego lo veremos.
Lo otro que llamó mi atención fue la habitual teoría conspiranoica acerca de origen artificial del virus, creado, por supuesto, por EUA para afectar a nuestros hermanos los chinos, a quienes les debemos tanto (y nunca mejor dicho). Esto, alimentado por ciertas declaraciones de un funcionario norteamericano que reconocía que la epidemia, al afectar la economía china, beneficiaba la americana. Probablemente un tipo tan corto de miras o imbécil como los conspiranoicos, y ahora veremos por qué.
En el mundo actual hay dos cosas muy conectadas: 1- Todo, 2-Todo lo demás. Las distancias se han acortado mucho, puedes estar en algún lugar de Europa, tomar un tren y varias horas después estar en otro país de Europa, a diferencia de Cuba, donde puedes coger un tren y varias horas después no haber salido de la estación. No hablemos de aviones (y no me refiero a que Cubana de Aviación no tenga aviones, sino a todo lo contrario), que pueden transportar la infección y dispersarla por varios continentes a otro en pocos días. Suponiendo que desarrolles un virus, más o menos letal (la idea no es matar, sino incapacitar gente y colapsar el sistema de salud y la economía de un país), con un tiempo de incubación adecuado de varios días que permita su propagación, nada impide que en poco tiempo tengas ese mismo virus en tu propio patio. De hecho, lo tendrás, y es lo que le ha pasado a Estados Unidos. El funcionario imbécil que creía que solo China estaba en problemas ahora tiene que estarse dando cuenta de su error. Las armas bacteriológicas tienen doble filo.
En este caso sí es factible para un grupo terrorista usar un virus como un arma. Por lo general, los terroristas no tienen una economía ni un territorio o población que les preocupe, más bien sería deseable que la epidemia se extendiera lo más posible. Si mueren inocentes entre los míos, es la voluntad de Dios. De hecho, es probable que lo hayan intentado o planeado, pero la práctica debe haberles demostrado que nada supera a una bomba tradicional en un lugar concurrido.
Así que ya sabes, si en algún momento tienes que escribir sobre un virus como arma, evita estos errores. Te harán ver muy estúpido, porque cualquiera con dos dedos de frente se dará cuenta de que no te detuviste a pensar e informarte. Suena muy interesante eso del virus creado por la CIA, financiado por Bill Gates, para derrumbar la economía de los enemigos del imperialismo y de paso que las farmacéuticas (en las que Bill Gates tiene participación) se forren. Pero la vida real no funciona tan así.

Y el problema es la escala

Tal como pensaba, el problema con el espacio de terreno era solucionable con modelos a la medida correcta. Me había dejado llevar por la escala del modelo de personaje, que estaba alterada, lo que me forzaba a escalar hasta 100 veces más el resto de las cosas. Si tienes un hombre de 100 metros, un terreno de 1000x1000 metros es nada. Todos los otros modelos que había generado con MakeHuman se exportaron de la misma forma, así que tuve que crear otro y asegurarme de fijar la unidad de medida en metros.
Lamentablemente, todo el prototipo de escena, el desplazamiento de la cámara y el del personaje están mal y tengo que rehacerlos. Por suerte, aunque hay espacio de sobra, la escena es mucho más manejable y no hay cuelgues al generar la malla del terreno o calcular los datos de navegación.
El lado bueno, porque siempre hay un lado bueno, es que como dice mi jefe, es que se aprendió algo. Durante el proceso de generar el nuevo personaje apliqué un tutorial reciente para transferir las animaciones de un esqueleto a otro y resulta que también me encontré con problemas de escala en ese asunto. Pero este venía por otro lado.
Para prototipar rápido utilizo animaciones de Mixamo, como he explicado, pero estas animaciones, según me aclara el autor del tutorial, están escaladas por debajo, en vez de por encima, si no ando muy equivocado. Conclusión, que para poderlas utilizar tengo que descargar el esqueleto con su malla o la geometría se deforma. Nada, que eso no es peo que rompa calzoncillos, como se dice vulgarmente. Aunque no en la forma óptima (cosas de Godot, que me obliga a replicar cada animación en cada modelo), ahora puedo utilizar las animaciones de Mixamo otra vez.
Me quedan varios días de trabajo rehaciendo escenas, regenerando y volviendo a cortar los modelos, en fin, trabajo aburrido. Todo eso luchando con un mouse defectuoso, o quizás sea la falta de una superficie adecuada.

Nueva tarjeta

Al fin me ha llegado mi nueva AMD RX 5500 XT. Probabemente esté conmigo un buen tiempo, porque no sé cuándo habrá otra oportunidad de conseguir una tarjeta de video con tantas facilidades. Sin embargo, llegó con una mala noticia: Linux Mint 19.1 no la soportaba. De mi consulta en el foro no me quedó claro si actualizarme solucionaría el problema, pero peor era no hacerlo, así que hoy me gasté dos horas de internet (ojo, que cuestan lo suyo acá en Cuba) intentando subir a la 19.3 Tricia. Sin embargo, resultó ser que Tricia no quiso venir conmigo ni atrás ni alante, por mucho que lo intenté. Pero como dice ese feo reguetón que anda por ahí, si no me quieres tú, me quiere la otra, y dio la casualidad que Tina sí funcionó. Y además, logré instalarle el controlador amdgpu 19.50, que incluye soporte para la familia 5500/5700. Ténganlo en cuenta si deciden comprar una 5600.
Para compensarme el desperdicio de horas, el código de hoy del repositorio de Godot compiló sin problemas, aunque de momento de poco sirve. El plugin de terrenos no funciona y en esencia, cualquier cosa que implementes hoy pronto podría dejar de funcionar, pues se vienen ciertos cambios, el más drástico, que los nodos Spatial pasarán a llamarse Node3d. Por eso he tenido que seguir trabajando con la 3.2 y ahora que he recuperado mi entorno de desarrollo natural, he podido hacer ciertas pruebas con el terreno.
En concreto, he estado probando los límites del plugin en cuanto a tamaño. En Windows, me resultaba imposible generar la malla de un terreno de tamaño 2049, a menos que subiera el LOD a 2. Eso reducía el conteo de polígonos de 8 millones a unos 2 millones, ago un poco más manejable. Sin embargo, crear datos de navegación con esa malla no funcionaba y no me he molestado en averiguar por qué. En cambio, en Linux sí es posible generar la malla, incluso con 8 millones de polígonos. Quizás sea cosa de manejo de la RAM por parte del sistema operativo. Pero no todo es color de rosa: Godot no logra calcular datos de navegación con tantos polígonos (recuerden que además hay otras cosas en la escena y la gestión de memoria de Godot es prehistórica).
Pero les tengo buenas noticias: un terreno de 1025 debería bastar, en dependencia de la escala de sus modelos. En mi caso, las escalas están alteradas y el personaje es diez veces más grande de lo que debería. En una escala 1 unidad=1 metro, me hubiese alcanzado perfectamente el terreno de 1025 para la escena de mi guión. Habría que ver el desempeño del nuevo NavigationServer en situaciones de escenas muy grandes, apoyado además con el nuevo gestor de memoria.
Volviendo a la nueva tarjeta de video, no he podido calcular cuánto he ganado en Linux, porque acabo de darme cuenta de que no tengo benchmarks con la RX 560, solo de la viejísima R7 250. Además, las pruebas de Unigine no funcionan porque falta alguna librería, que no se si es posible instalar o si simplemente ya quedó obsoleta. En Windows sí he podido sacar algunas conclusiones, gracias a Afternurner y al nuevo panel de control de AMD que guarda una estadística de los FPS de algunos juegos. La ganancia es generalmente de unos 10 FPS, excepto en Divinity Original Sin 2, que casi duplica los FPS anteriores. La 5500 XT de 4 Gb consigue acercarse los 60 FPS a 1080p en todos los juegos que tengo, incluso en Greedfall que es un poco pesado. Mantenerse en 60 o sobrepasar esa cifra sí le resulta un poco difícil, por eso yo recomiendo que si tienes dinero, te vayas por la 5700 o la 5600 recién salida, o quizás aguna RTX de Nvidia. Pero no se puede pedir más a un hardware que cuesta entre 170 y 200 dólares, más impuestos.

Videojuegos en Cuba

Una lista muy mínima de videojuegos cubanos.

Unity 2019.3.1, Godot 3.2

Justo con el sismo que casi me echa la casa abajo, han salido Unity 2019.3 y Godot 3.2. No voy a detenerme en los cambios, porque ya otros han abundado a lo largo de los últimos meses al respecto. Unity, en mi opinión, se ha hecho esperar más de la cuenta, tanto, que ni siquiera he tenido mucho interés en probarlo. Esperaré a la 2019.3.1. En esta versión vienen cosas interesantes, como UIElements, pero la 2020.1 en mi opinión traerá mejoras más importantes, como la nueva API de redes. Como viene siendo habitual, debería salir en marzo o abril.
A pesar de los muchísimos cambios interesantes que trae Godot 3.2, tampoco es la versión que estoy esperando. Esa sería la 4.0, con el nuevo renderizador basado en Vulkan, por ahora bastante inestable. La rama Vulkan aún está en una etapa bastante temprana, según el último reporte de Juan Linietsky, en febrero debería completarse el proceso de portar las funcionalidades del 3.2 (ojo, muchas de las cuales han quedado mejor que antes, evidencia de que el cambio a Vulkan fue una decisión acertadísima), para entonces pasar a las nuevas. Aquí sí es más difícil hacer predicciones, ya saben que no tengo una bola de cristal (solo dos de las normales), pero según el calendario, entre mediados y fin de año es la fecha de lanzamiento oficial. Y no esperen estabilidad antes de mayo, cuando todo lo que funcionaba antes funcione correctamente en la nueva rama. Aunque según tengo entendido, hay valientes que se han atrevido a hacer juegos completos con la 4.0. No digo que no se pueda, si te tomas el trabajo de salvar cada vez que hagas un cambio.
De momento, pienso ir moviéndome a la 3.2 con los dos proyectos serios que tengo entre manos (portar el Laberinto del Saber a Godot es uno de ellos), en espera de que la 4 mejore lo suficiente como para ser usable.

No puedo hacer retargeting en Godot, pero sí otras cosas

Ayer tenía planificado dedicar un rato a escribir, pero primero quise quitarme la duda de una vez por todas. Se ve que soy un poco testarudo a veces, pues según mis consultas, el retargeting, en la forma en que yo quería hacerlo, no es posible en Godot. Para entrar en contexto, lo que pretendía era utilizar una animación descargada de Mixamo en un modelo exportado sin animaciones, con el propósito final de compartir las animaciones entre todos los modelos con el mismo esqueleto. 
Luego de echarle un vistazo al editor, probé el enfoque más obvio: exportar el modelo desde Blender e importar la animación en el editor. Eso, claro, no sirve de nada, no hay forma de hacer que el modelo utilice esa animación. Pero resulta que si abres la animación como una escena, la puedes guardar y desde el modelo, la puedes cargar. Había encontrado el Santo Grial! Pero no. Eso tampoco funciona. Lo intenté exportando a todos los formatos compatibles y nada. A propósito, los modelos importados desde FBX no incluyen un AnimationPlayer si no contienen animaciones, en cambio, los importados desde Collada sí lo tienen. En general, el exportador BetterCollada que provee Godot funciona mucho mejor en todos los aspectos.
Lo único que logré fue que el modelo se sacudiera un poco, pero la animación no funciona. Incluso probé usando la rama Vulkan, pero nada. ¿Por qué mi insistencia en conseguir esto? No es esencial para hacer un juego, pero creo que es más óptimo tener una sola animación y reutilizarla que tenerla repetida en todos los modelos.
Una vez que me había convencido de la imposibilidad de hacerlo, me pregunté si podría equipar items en el modelo del personaje. Y a esta duda sí encontré respuesta positiva casi de inmediato. Exportando el objeto, en este caso unos guantes, con su esqueleto (igual que lo hacía en Unity), y salvando la malla de su MeshInstance:

Hice otra copia de la malla de las manos, que en este caso serían las reemplazadas siguiendo el mismo procedimiento. Atentos, para que sea más simple, no abran el archivo importado como escena heredada o les dará un error al guardar diciendo que el objeto debe ser único. El cambio de uno por otro es simple: miren este script que añadí al nodo raíz del modelo del personaje:

extends Spatial

var gloves = "res://Models/male-alejandro-dae/iron_gloves_anim.tres"
var hands = "res://Models/male-alejandro-dae/male-hands.tres"
var equip:bool

# Called when the node enters the scene tree for the first time.
func _ready():
    equip=false


# Called every frame. 'delta' is the elapsed time since the previous frame.
func _process(delta):
    if Input.is_key_pressed(KEY_SPACE):
        if !equip:
            var res = load(gloves)
            get_node("varsoi_male/Skeleton/varsoiM_hands").mesh = res
            equip = true
        else:
            var res = load(hands)
            get_node("varsoi_male/Skeleton/varsoiM_hands").mesh = res
            equip = false

No es para nada lo más civilizado, pero consideren que soy bastante nuevo en esto. Presionando Espacio, se montan y desmontan los guantes, los cuales siguen la animación del modelo correctamente.

A continuación me surgió la duda de si podría hacer lo mismo con un objeto sin animar, montado encima del cuerpo del personaje, por ejemplo, una armadura. ¿Seguiría la animación del personaje? La respuesta es sí. Utilizando un BoneAttachment, logré equipar la armadura más o menos donde debía ir. Aquí me encontré con dificultades, a diferencia de los guantes, la armadura no tenía la escala y rotación correctas. Raro, porque ambos provenían del mismo archivo blend (que si no recuerdo mal, pueden encontrar en OpenGameArt, cortesía del viejo equipo de The Key of the World), quizás se deba a la prsencia o falta del esqueleto. Pero la prueba demostró que es factible, pese a los detalles que surgieron. La armadura seguía los movimientos de traslación y rotación del torso del personaje bastante bien.
Aunque utilicé para casi todas las pruebas la rama 4.0, estoy seguro de que funcionaría todo igual en la 3.2 pues ahora mismo son muy parecidas. Excepto que la 4.0 es bastante inestable.
Supongo que después de todo valió la pena no trabajar en mi novela anoche (después de todo, ¿quién necesita la literatura?).

The road so far (aunque no estamos a final de temporada aún)

Es genial cuando todas las cosas te salen bien a la primera: creas código que funciona y las cosas se ven como debe ser. No es mi caso ahora, claro. No obstante, tengo que reconocer que algo he logrado avanzar en estos días de lidiar con Godot.
Luego de rastrear tutoriales por todo Youtube y preguntar mucho, he conseguido resolver algunos problemas y ganar experiencias. Por ejemplo, si quieren ver cómo usar raycasting en una escena 3D para desplazar el personaje, definitivamente lo mejor es el demo Navmesh oficial. De paso, ese mismo demo les ayudará en la parte de usar el camino calculado para mover al personaje. En cambio, no le presten mucha atención a la escena. Es cierto que funciona, pero la forma más correcta de hacerlo es crear un nodo de tipo Navigation y colgar de él todos los elementos (en el demo, la cosa está invertida, el Navigation cuelga de la malla que funge como escena).
A pesar de que la mayoría de los tutoriales y demos están orientados a juegos 2D, siempre aparecen algunas perlas. Evidentemente, que Godot tenga una comunidad de cierta envergadura ayuda muchísimo a encontrar alguien que haya intentado con anterioridad lo mismo que tú y haya sobrevivido para documentarlo. Yo mismo estoy pensando crear mi tutorial acerca de la vista isométrica en 3D, porque ya saben que no sé hacer otra cosa. Pero en comparación con lo que falta, esto es nada.
Uno de los experimentos que tengo pendientes es probar el soporte de red, crer un sistema de inventario y habilidades (pospuesto hasta que aprenda más GDScript) y cacharrear la rama Vulkan. Esto último sí podría probarlo pronto, en cuanto habilite los drivers Vulkan en Linux, porque el código fuente ya está descargado y compilado. Es más una cuestión de curiosidad que para uso real, porque no sé en qué estado estará esa rama, donde los cambios son drásticos. En caso de que no lo sepan, la rama Vulkan, o 4.0, debería venir detrás de la 3.2, a mediados o finales de año. Si no he entendido mal, en ella se reimplementa el gestor de memoria, viene el nuevo renderizador basado en Vulkan (obvio), nuevo método de iluminación global, y se arreglan (o arreglarán) muchas cosas.
Conclusión: lento, pero seguro, se van haciendo cosas. Recuerden que en casa yo no puedo acudir a Google, tengo que esperar a la mañana siguiente para consultar internet. Si tengo suerte, en la tarde ya tengo respuesta. Si no, hay que esperar al otro día. Veremos si para fines de este año ya tengo un mejor dominio de Godot o si la paciencia se me ha agotado y me he ido con otro (con otro motor dejuegos, no sean mal pensados).

Cacharreando 3d en Godot

Primer post del año, que espero que haya empezado por todo lo alto para ustedes, con mucha prosperidad y dinero. A ver si así al fin se deciden a gastarse unos dólares en comprar mi novela.
Aunque me tomé unos días de descanso no planificados para terminar de ver The Boys y The Witcher, ya he vuelto al trabajo. Más o menos. Sigo experimentando con Godot, aprendiendo y chocando con dificultades. El gran problema es venir de un motor profesional con un excelente soporte 3d, donde puedes hacer casi cualquier cosa que se te ocurra. Algo tan trivial como guardar la animación en un archivo y utilizarla en un modelo exportado a otro archivo es un lío complicado. Tanto, que justo ahora no sé decirles a ciencia cierta si es posible o no.
Solo ayer conseguí entenderme con las animaciones de los modelos, aunque en el caso específico en que las mismas están todas incluidas dentro del archivo exportado desde Blender. Y ya que hablamos de exportar e importar, tal como me esperaba, el importador basado en Assimp funciona bastante bien, pero no perfecto. Lo usual es que cuando falle, se lleve por delante al editor completo. Como todo software, incluso en los comerciales, la solución está en esperar a que mejore. Comparada con la de hace unos años, la biblioteca Assimp de hoy es una maravilla, créanme.
En cambio, mi experiencia exportando a glFT no fue tan buena. Había pequeñas deformaciones en el modelo y otros detalles que ahora mismo no recuerdo. Al final, el formato FBX producido por Blender probó ser un poco más confiable.
A continuación pienso dedicarme a mover el modelo por un mapa sencillo, quizás probar la navegación, para terminar con algunas pruebas de red. En la parte 2D, pienso hacer una prueba simple portando un nivel del Laberinto, en cuanto salga Godot 3.2. Al menos en 2D Godot no está tan atrasado, lo cual no quita que haya un montón de código que reescribir y otro montón de cosas que aprender.

Feliz lo que sea y hasta luego

Un post muy breve para despedir el año y desearles feliz navidad, o lo que sea. He tenido unos días bastante ocupados, como suele suceder: mucho Godot, mucho trabajo, y luego mucho The Witcher. Me reservo las opiniones por ahora, excepto que las historias entremecladas me han como que mareado.
Nos veremos el año próximo.

Tirando el dinero por la ventana: Champions of Regnum vía datos móviles

Como se pueden imaginar, internet aún demora en llegar a mi casa. Recién esta semana solicité el traslado del teléfono de mi padre, y mi barrio ya no tiene capacidades. Por tanto, podría demorar años en recibir mi línea fija. En cambio, lo que sí tengo es 4G. Solo arriba, en mi cuarto, pero algo es algo. En ocasiones anteriores había utilizado el móvil para conectar la PC, durante un tiempo descargué mi correo por esa vía, pero esto dejó de funcionar al entrar la 3D. Esta semana volví a intentarlo a través de 4G y el resultado, aunque caro, fue bastante prometedor.
Hace pocos días, ETECSA lanzó una nueva oferta para clientes 4G: unos paquetes relativamente baratos que además ofrecen un bono si navegas bajo cobertura LTE. En total, serían unos 800 Mb por solo 5 dolares, que deben consumirse en 30 días. ¿Qué tanto rinde eso, en mi caso? Como verán a continuación, no mucho.
Para empezar, un poco de historia. Empecé con Champions of Regnum cuando aún se llamaba Regnum Online, hace tanto tiempo que ya he perdido la cuenta. Luego de abandonarlo lo retomé, conisguiendo llevar un personaje hasta el nivel 50 aproximadamente. En ese momento, perdí la posibilidad de jugarlo, durante varios años más. Regresé hace poco, pero no para jugar a full, porque con el servicio doméstico de internet en Cuba es imposible, esas 30 horas hay que utilizarlas con cuidado.
Otro gran problema es que Champions of Regnum ya no está accesible para Cuba, ni ellos mismos saben por qué. Es necesario usar una VPN. En un principio intenté con Psiphon, pero no funcionó. Luego de investigar un poco, probé ProtonVPN y este sí fue de maravilla. Entonces, ¿ya puedo jugar Regnum?
La respuesta es no. En apenas unos minutos de conexión consumí unos 40 Mb. El tráfico oscila, claro, en dependencia de la carga de usuarios en la zona y otras cosas. También hay que estar muy pendiente a desactivar las actualizaciones de Windows. Quizás en Linux el tráfico sea menor, pero no tengo la versión del juego para ese SO.
Sin embargo, la idea no era tanto jugar, si no más bien entrar a diario para asegurar las recompensas, sobre todo el ximerin, que solo se otorga luego de 7 días consecutivos. Para eso solo necesito unos minutos de conexión. Tendrá que bastarme por un par de años, supongo.

Godot, mi valoración hoy

Hace unos 4 años que valoré seriamente Godot para el desarrollo de juegos. En ese momento pasaba por una excelente racha mediática, aunque era poco más que un buen renderizador 2D. Mi decepción final vino cuando descartaron Vulkan, una decisión que tuvieron que echar atrás y sobre lo cual he hablado en otra ocasión. Decidí que si iba a aprender una herramienta de desarrollo, entonces aprendería la mejor. Y así me metí de lleno en Unity3d.
Hace poco recibí una propuesta para trabajar en un juego 2D de plataformas. Es algo que nunca he hecho y no está de más que lo intente. Sin embargo, luego de contactar a Unity, el otro miembro del grupo me informó que por ser cubanos no podíamos crear un producto comercial con el mismo. Casi de inmediato escogió Godot para sustituirlo.
Entre los motores de juegos libres, Godot es una especie de niño mimado. Tiene sus cosas buenas, que veremos más adelante, pero tiene también una serie de problemas que no han solucionado en los tres años que llevo sin mirarlo. Si alguien quiere tomarse en serio el asunto de desarrollar con herramientas open source, debería valorar también Urho3D y Banshee3D.
A punto de entrar en el 2020, Godot aún adolece de muchos problemas:

• Un renderizador 3D pésimo, basado en GL ES 2/3. No sé si tenga deferred rendering (no lo dice en ningún lado) pero por suerte sí tiene PBR. El renderizador basado en Vulkan, descartado hace tiempo, recién ahora se está implementando y lo tendremos en la versión 4.0.
• La parte 3D abarca mucho más que el renderizador, aunque en este caso esa parte que no incluye el renderizado es mínima. Godot tiene muy pocas herramientas y funcionalidades para proyectos 3D. Ni siquiera tiene editor de terreno. Quizás para la 4.0 hayan más cosas.
• El flujo de trabajo 3D es deficiente. Aún se basa en el formato OBJ para modelos estáticos y Collada para mallas animadas. En la próxima versión 3.2 podremos usar glTF y FBX gracias a su nuevo importador basado en AssImp. Sin embargo, recuerdo que AssImp tenía su propia cuota de problemas hace unos cuatro años, precisamente con archivos FBX y .blend (supuestamente podía importar un archivo de Blender, pero nunca lo hacía).
• Ni hablar de herramientas adicionales como un secuenciador.
• El build no parece estar muy optimizado. Un nivel sencillo con un par de imágenes ocupa casi 60 mb. No logré hacer la prueba para Android.

Las ventajas de usar Godot no llegan a opacar esos problemas, pero son significativas:

• Es un motor muy noble y fácil de usar. Incluso ofrece scripting visual. Su lenguaje script es fácil de aprender y además está muy bien integrado en el motor.
• Licencia MIT. No hay limitaciones de embargo a tu país ni nada de eso.
• Si tienes en mente un proyecto 2D, es un excelente motor. Hace años tenía ya funcionalidades como luz y sombras en 2D que Unity recién agrega ahora.
• Es posible publicar en consolas, a través de un tercero. La documentación te remite a Lone Wolf Technologies, una empresa de uno de los creadores de Godot, que da el servicio de portar tu proyecto a Xbox One y PS4. En ese caso, quizás las leyes de embargo sí apliquen, porque estarás tratando con empresas norteamericanas.
• Es pequeño y correrá en hardware limitado.
• Abunda la documentación. Quizás no haya tanto como para Unity, pero recuerden que aquí hay mucho menos funcionalidades que documentar. En todo caso, bastará para arrancar.

Saque usted sus propias conclusiones. Las esperanzas están puestas en la rama 4.0, que no será estable, o al menos beta, hasta dentro de un año. Mientras, hay que tirar con la 3.2 no parece ser muy diferente de la 3.1, y una posible 3.3. Si quieres experimentar, es una buena opción, aunque repito, hay otras cosas por ahí menos divulgadas y que podrían sorprender. Si pretendes hacer un proyecto 3D sencillo, Godot podría servir. Si tu objetivo es un proyecto 2D, o incluso con elementos 3D, que se vea excepcionalmente bien, Godot es la mejor opción. Ya saben, la decisión es suya.