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.

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.  

Un breve e incompleto vistazo al Olimpo de los escritores de fantasía y CF modernas

Tolkien es el puto Amo y Creador del Universo, que está ahí desde siempre. A su derecha hay una pelea formada entre Brandon Sanderson y George R. R. Martin, que quieren ocupar la silla de ese lado. Por su parte, Joe Abercrombie se ha aprovechado de eso y se ha adueñado de la silla a la izquierda del Maestro, está ahí muy cómodo, viendo como los otros dos se pelean por una simple silla, a fin de cuentas, izquierda o derecha, da lo mismo. Detrás del Amo del Universo están Gaiman y Terry Pratchett, sus secretarios y escribsa personales.
Frente a nuestro Señor Celestial hay un coro de querubines. O algo así. Uno de ellos es un tipo gordo y con barba, llamado Patrick Rothfuss. Lo metieron ahí porque cantaba muy bien, pero a mitad de canción se le olvidó la letra, y ahora solo está ahí, callado y con aire de saber lo que hace, pero la verdad es que no tiene ni esta idea. Muy cerca de Rothfuss podemos ver a un viejo con cara de amargado con un nombre polaco impronunciable. Escribió unos papiros muy interesantes, pero una empresa los convirtió en estampitas de colores que se vendieron muy bien y él no vio ni un céntimo. No lo culpo, yo también tendría mala cara si me sucediera eso. Encima, los mortales en su infinita ignorancia ahora creen que él copió de las estampitas, y no al revés.
Hay un montón de gente más en el coro, como Brent Weeks. O Jim Butcher, que solo se sabe una estrofa de la canción celestial, pero la repita una y otra vez. Todos cantan ante el Dios Terry, y de paso se empujan y pisan unos a otros. En esa trifulca han apartado a un rincón a un señor de cierta edad con barba, llamado Robert Jordan (en realidad, se llamaba de otra forma, pero ese sonaba mejor). En su momento, escribió una canción genial y larguísima, y todos creían que sería el Puto Amo del Universo. En medio del tumulto está R. A. Salvatore, que pergueñó unas historias raras acerca de un habitante de las profundidades, que en vez de ser albino como dictan las buenas costumbres de la biología, es lo totalmente opuesto, quizás por cuestión de camuflaje. Otro que se mantiene a flote es Scalzi, que aunque no le va mucho a la fantasía como al resto de la claque, se defiende creando unas crónicas muy resultonas.
Aplastados por la multitud de querubines cantores hay otros: David Eddings, Terry Goodkind, etc. En su momento cantaron muy bien, pero entre tanto empujón y aleteo celestial, ahora mismo están en el piso, tomándose un descanso.
Tras ellos, hay un señor chino, meditando, ajeno a todo el barullo. Posiblemente esté esperando algún acontecimiento que ocurrirá dentro de mil años: el fin del universo, una invasión de alienígenas, u otra cosa parecida. Más atrás hay otro tipo, Steven Erikson, rodeado por almas perdidas, a las cuales intenta convencer de que escuchen su canción, de diez rollos de largo, la cual dice que es solo la introducción a una historia más grande. Pero las pobres almas perdidas no comprenden de qué va el asunto y están como que... perdidas.
Como de todo tiene que haber en la viña de nuestro señor Tolkien, tenemos a unos siameses muy raros de apellido Corey. Nadie los conocía antes, pero han logrado que otra empresa les haga unas estampitas de colores animadas y ahora todos los mortales están encantados con ellas aunque no se hayan leído el puto libro. Hay también una dama con nombre de hombre: Robin Hobb (no confundir con Robin Hood), que ha cantado unas historias geniales. En otra esquina del cielo hay una señora que se inventó un nombre con muchas letras (si quieres tener éxito, invéntate un seudónimo que parezca las siglas de una organización internacional o algo), que empezó cantando historias para niños, hizo un montón de oro, y ahora está haciendo más estampitas animadas para esos mismos niños en su fase de adultos. Y de paso, haciendo otro montón de oro.
Y así, señores, es nuestro Cielo especial para los escritores de CF y fantasía.

Videojuegos en Cuba, la situación hoy


Para conocer la historia de los videojuegos en Cuba es imprescindible leer Hecho en Casa Historia de los videojuegos en Cuba, y complementarlo con Merchise Arando un sueño en la superficie del sol. Para entender por qué Cuba no es país para desarrolladores de juegos (ni de otras cosas), primero habría que entender Cuba, y eso no es posible. Es que este país se rige por una lógica propia que carece de toda racionalidad. Sin embargo, leyendo ambos libros se puede deducir fácilmente cómo nos convertimos de un candidato a potencia en el desarrollo de videojuegos a un rechazo total, que recién ahora se está despejando.
Como no conozco a fondo el pasado, prefiero hablar del presente, que aunque tampoco lo conozco bien por lo menos lo estoy viviendo. O sufriendo. ¿Es un buen momento para los videojuegos en Cuba? Pues, como diría la tortuga gigante de la Historia sin Fin: podría serlo, o podría no serlo. Desde hace unos años se ha levantado la veda a los videojuegos en las instituciones oficiales, que ahora están lanzando jueguitos casuales y no tan casuales, que por primera vez en la vida no son birrias didácticas infumables. Hay grupos independientes como ConWiro o Empty Head Games, creando sus propios productos, lo que demuestra que talento sobra. Tenemos una plataforma de aplicaciones para Android. Tenemos hasta un intento de MOBA, Coliseum, lastrado por la falta de conectividad que no parece que se resolverá a corto plazo. Lo que no tenemos ahora mismo es la infrastructura necesaria para crear un mercado, donde el cliente le pague al desarrollador, pero eso también viene en camino.
Parece que las cosas no están tan mal, ¿no? Pues las apariencias engañan.
Lo más importante que no tenemos es un marco legal. Las cooperativas están en el limbo y las licencias para programadores vagan por el burocraespacio, de estudio en estudio, en espera de que un día alguien se decida a volver a liberarlas. Y es que la idea de que un adolescente o adolescenta (¡inclusividad ante todo!) con una aplicación hecha  en dos meses de trabajo pueda comer langosta, comprarse casa, moto eléctrica y demás seguramente le pone los pelos de punta a todo el gobierno. El de Donald Trump, por supuesto, recuerden que todo es culpa del embargo.
O sea, que si eres la División de Audiovisuales de la Empresa Nacional de Cultivo de Almejas, no deberías tener problema para desarrollar tu Simulador de Ostra. Pero si eres Chicho el Cojo y tienes una idea genial de un multijugador battle royale, con todas las de la ley, estás muy embarcado. Para empezar no podrás rentar un servidor. Si intentas formar una alianza estratégica con alguna institución estatal te encontrarás que lo mejor que pueden ofrecerte es quedarse con tu juego, cobrar una pasta, ya ti darte una plaza con un salario normalito, como colaborador. Encima, quizás conviertan las facciones de tu juego en mambises contra españoles o algo así.
O sea, señores, que las cosas no están bien. Ni tampoco tan mal. Cuba no ha logrado desarrollar una industria de videojuegos; hablando como libro de texto, estamos en la fase manufacturera y ahí seguiremos por un buen tiempo. Lo lamentable es que se ha demostrado que hay un mercado nacional, que quizás no produzca millones pero que podría darle vida a los creadores locales, independientes o estatales. Y esos creadores locales también podrían abrirse camino en el extranjero. Si el bloqueo nos deja, claro, recuerden que Trump no quiere que los desarrolladores de juegos cubanos coman langosta y etcétera, etcétera.