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.

UI Builder

Dije hace unos días que les comentaría acerca de UI Builder, la nueva herramienta de diseño de interfaz para UI elements. Ahora mismo, si estás usando Unity 2019.2, puedes instalarla desde el Package Manager, pero solo para personalizar el editor. Si entendí bien las conferencias, a partir de la 2019.3 será posible usar UI Elements también en los juegos (esto no me queda muy claro), y en la 2020.1 ya entrará oficialmente como la solución preferida para interfaces de usuario en Unity. Su estado actual es preview, por lo tanto algunas cosas no funcionan.

Sin embargo, aún incompleto y primitivo, el UI Builder es una herramienta utilísima. Ahorra mucho tiempo y permite evitarse el lidiar directamente con UXML y  USS directamente, así que puedes dedicarte al código. En mi caso, en un par de días avancé más en mi editor de diálogos que en una semana de tanteos a mano, llegando a un estado en que resulta utilizable.

Aunque pueda parecer que es casi lo mismo que el inspector, les diré que ese casi marca una diferencia abismal en cuanto a rapidez y comodidad de uso. El inspector no inicializa algunas cosas y no me permite agrupar los elementos similares en seciones desplegables. Por ejemplo, puedo replegar todos los nodos, excepto el que estoy trabajando, o todos los nodos y ver solo las respuestas del jugador, etc. Al agregar un nodo, éste ya viene con sus campos creados, no tengo que decir específicamente que son dos líneas de texto, y así sucesivamente.
Estas pruebas no cubren el uso de UIElements en juegos. Eso ya es un asunto aparte, que pienso probar en cuanto sea posible. De momento he detenido el trabajo en la interfaz de usuario de todos mis proyectos, salvo uno, que ya está en un estado tan avanzado que no puedo dejarlo aparcado.

Addressables

Una de las cosas que eché de menos cuando mis proyectos se volvieron complicados fue la posibilidad de cargar assets directamente. Unity era el primer motor en el que no podía hacerlo, cualquier cosa que quisiese utilizar, tenía que estar debidamente referenciada de antemano, asignándola en el editor. Luego descubrí que existía una forma, pero involucraba la carpeta Resources y cargar el asset usando la ruta y nombre del archivo. Un inconveniente es que dicha carpeta se traslada íntegra al build del proyecto, si olvidaste limpiar algo, se incluirá en el juego aunque no se use. Otro, que no es recomendable usarlo en proyectos que se portarán a consolas. Y si cambia el nombre o ruta, hay que cambiarlo también en el código. En fin, que la carpeta Resources es un mecanismo que está ahí, pero que deberías hacer todo lo posible por evitarlo.
Los Addressables son la solución a esto, que se me había pasado por alto entre todas las cosas nuevas que ha incorporado Unity en los últimos tiempos. En realidad, su objetivo es sustituir los Asset Bundles, que como muchas cosas de Unity, ahora resulta que no eran tan fáciles de utilizar y tenían una buena cantidad de problemas.
Para empezar, la carga de assets marcados como addressables se realiza mediante la etiqueta del objeto, o cargando todo un grupo de una vez mediante la etiqueta del grupo. De momento solo he echado un brevísimo vistazo a lo que puede hacer, quedándome en la parte de cargar cosas. Las posibilidades van más allá, porque como mencioné anteriormente, también sustituyen los Asset Bundles, y esa es otra tarea pendiente que me queda, para un futuro no muy cercano. Ahora mismo, crear contenido adicional descargable no es mi prioridad. Más bien, la prioridad es eliminar el uso de la carpeta Resources, que tampoco es tan fácil, porque los addressables están diseñados para ser cargados en grupo y la función de carga funciona como una corutina (no conozco el término exacto para definirla). Sin embargo, esto es algo que he logrado solucionar, gracias a un pequeño tutorial.
Ya que hablamos de funciones nuevas de Unity, en otro post les comentaré acerca del UI Builder, que estoy utilizando para crear mi editor de diálogos, lo cual sea probablemente mucho más interesante.
 

¿Qué tal envejecen los juegos?

Pues la respuesta es, no muy bien, cuando se trata de juegos de principios de siglo (suena raro eso, pero ya los principios del siglo han quedado atrás), o finales de los 90. Sobre todo, estos últimos, que se lanzaron en una época donde 800x600 parecía ser el non plus ultra, la resolución tope, después de la cual no vendría más nada. Muchos juegos de esa época no podían pasar de ahí, porque seguramente sus creadores no concebían que veinte años después, los tres mosqueteros y D´Artagnan se reunirían otra vez para intentar jugarlos a 1080p. Que dicho sea de paso, en estos tiempos es una resolución a punto de jubilarse ya.
Y a veces costó trabajo que los desarrolladores aprendieran la lección. La mismísima Blizzard, a pesar del éxito duradero de sus títulos, no se preocupó por soportar altas resoluciones en Warcraft 3 hasta mucho después de su lanzamiento. Fallout 2 requiere de un parche extraoficial, igual que Arcanum (imperdonable, siendo mucho más reciente). Sin embargo, yo diría que los gráficos del Fallout 2 no han perdido su encanto a pesar de los años, y viene siendo algo así como una cuarentona de buen ver que va al gimnasio y se mantiene en forma.
Pero para ser justos, hay que considerar que en esa época las tarjetas de video y los monitores apenas evolucionaban. Las tarjetas aceleradoras eran para juegos muy específicos como Quake, todos FPS, y algunas de ellas como las de 3dfx fueron callejones sin salida. Además de su precio elevado, eran artefactos raros que se conectaban a la tarjeta principal y hacía su magia de alguna forma esotérica e incomprensible. Y aunque al final, la evolución se disparó, seguimos estando limitados por las resoluciones de los monitores durante largos años. Hasta que al fin, las resoluciones comenzaron a crecer, y las tarjetas, además de ofrecer mejores gráficos 3D, pudieron también producir imágenes más grandes.
Eso marcó, en cierta forma, el comienzo de la era actual. La resolución Full HD dio paso a 4K, y aunque esta aún no es de uso masivo, ya se está hablando de 8K. Los juegos actuales tienen que lidiar con diversas resoluciones en todo tipo de dispositivos, con la Realidad Virtual, y con la posibilidad de que durante su ciclo de vida, por corto que sea, aparezca una nueva resolución aún más alta. Por eso creo que los títulos recientes envejecen un poco mejor, a pesar de que es inevitable que los gráficos 3D queden desfasados en cuestión de 3-4 años.
También hemos alcanzado una tope, una especie de barrera, en cuanto al realismo de los gráficos 3D, que será muy difícil de superar a corto plazo. El raytracing, por el momento, solo se utiliza para mejorar la iluminación de la escena, mientras que para los modelos seguimos dependiendo del rasterizado de toda la vida, y de aumentar el número de polígonos a lo bestia si queremos modelos más realistas. No estamos haciendo cosas hoy que se vean mucho mejor que las de hace dos años (solo marginalmente mejor), porque la potencia bruta tiene un límite. Es por eso que todavía The Witcher 3 se ve muy bien, porque simplemente, no ha aparecido nada en el mercado que pueda hacerle sombra.
¿Cuándo será el próximo salto de calidad? Es muy difícil de predecir. Quizás ni siquiera sea una salto, sino una mejora gradual. Para empezar, creo que necesitaremos una mejora sustancial de la potencia de cómputo, que permita que el trazado de rayos sustituya por completo al rasterizado. Eso no será en dos días, ni dos años, pero sucederá, me atrevería a decir, a mediano plazo. Con raytracing total tendríamos gráficos 3D fotorrealistas en tiempo real.
Mientras eso llega, hay que seguir tirando con lo que tenemos. La próxima vez que quieras quejarte de la apariencia de un juego, recuerda que en mi época teníamos 4 colores y resoluciones equivalentes a la de tu primer teléfono. Y también tengan en cuenta que no solo de gráficos vive el jugador.

¡Gran error!

En estos días he estado trabajando contra reloj para pulir El Laberinto del Saber. El juego no estaba tan terminado como yo pensaba y faltaban por arreglar un montón de pequeños detalles. Algunos se derivan de cambios en Android, por ejemplo, lo que antes era el botón de Menú, ahora suele activar la lista de aplicaciones. Por tanto, no sirve para pausar el juego. Tuve que escribir a toda prisa una variante. La cual, de paso, introdujo más problemas, esta vez derivados del UI.
El UI en cuestión es el tema que me ha tomado el 90% del tiempo de desarrollo dedicado a pulir. Conseguir que el juego se vea igual, independientemente de la resolución ha sido bastante complicado. Y otra vez, los cambios en los teléfonos, los aumentos de resolución y los cambios de relación de aspecto me han puesto la cosa fea. Aún no estoy seguro de que funcione bien en todos los dispositivos.
Mientras arreglaba lo anterior, rompí el control de movimiento. Y lo peor fue que hice un build y lo repartí a todo el mundo, sin haberlo probado yo antes. Ni siquiera en el editor. El juego era completamente injugable y yo no lo sabía. Un grave error que trataré de no cometer otra vez.
Al final, tuve que sustituirlo por uno que bajé de la Asset Store: el Joystick Pack (genial, lo recomiendo). Lo cual, obviamente, introdujo más problemas. Que por suerte, logré solucionar anoche... solo para encontrarme hoy que había otros. Simplemente, mi sistema no había sido diseñado para los joysticks virtuales del ese asset en concreto.
Conclusión, más de una semana de trabajo, aún cuando casi no introduje funcionalidades nuevas. Solo arreglos de bugs, arreglos del UI, etc. Para más desgracia, cuando actualicé el Unity en casa perdí la posibilidad de compilar proyectos para Android. Durante la primera compilación, Unity descarga algo del gradle, y si actualizas Unity, aunque sea a una versión de la misma rama, eso se pierde. Ahora debo conectar la PC de mi casa a Internet y volver a hacer un build, lo cual no pienso hacer hasta que instale el Unity 2019.3. Según las noticias de hoy, unas 110 mil familias en Cuba ya tienen internet en casas, pero yo no estoy entre esos afortunados.
Ahora estoy en espera de que los dos beta testers encuentren más errores, para seguir en la lucha.

UIElements

Hace unos días hablaba acerca de los constantes cambios de Unity, y una de las cosas que mencionaba era la introducción de UIElements como sistema UI unificado para juegos y personalización del editor. Tener una interfaz de usuario decente ha sido una asignatura pendiente de Unity desde hace tiempo, un apartado que fue mejorado un poco a partir de la versión 4.6. Sin embargo, ese nuevo UI, aunque era un gran cambio, tampoco es que fuera una maravilla. En mi opinión, es la cosa más contraintuitiva que he visto en mi vida. Pero supongo que valen más las opiniones de los expertos y de los propios desarrolladores de Unity, que lo consideran lento e inadecuado.
UIElements llegará en estado casi usable en la 2019.3, incluyendo una herramienta que se ve genial, al menos en video (en la vida real, las cosas tienden a no ser tan simples como se ve en los videos). Recomiendo que vean dicho video para que se lleven una idea, seguramente se quedarán con ganas de tener ya este nuevo sistema a su alcance.

El progreso ha llegado, tenemos 4G

El idilio de Cuba con la 3G ha sido bastante breve. Al parecer, hemos alcanzado el punto de saturación bastante rápido, y aunque en un principio se habló de velocidades de hasta 7 mbps, en los últimos tiempos era casi imposible navegar o incluso acceder al correo vía pop/smtp. En mi opinión, lo lógico hubiese sido saltar directamente a la 4G en vez de usar una tecnología ya obsoleta, pero como pueden imaginarse, mi opinión no le importa a nadie. Además de que hay que considerar que acá aún existe la televisión analógica, que ocupa frecuencias necesarias para la 4G y que debe ir desapareciendo, pero no antes del 2021.
Para los que me leen desde afuera (o sea, no Cuba), cambiar de TV aquí no es tan fácil. De hecho, pese a mi salario privilegiado, me costó una buena dosis de suerte, vender mi TV viejo, y ahorrar mucho, para poder adquirir un TV de 32 pulgadas, con receptor digital integrado. Háganse la idea, señores, hay decenas de miles de jubilados que no pueden cambiar su televisor, gente que no trabaja, y gente que aunque trabaja, apenas le alcanza para llegar a fin de mes.
Un colega, que trabaja en la única empresa telefónica del país, me había hablado en términos muy elogiosos acerca de la 4G, que empezó a desplegarse de forma limitada hace unos meses. No hay comparación, me decía. Pude comprobarlo al fin hace unos días. Luego de algunos problemas debido a que mi teléfono no era validado como 4G, logré que fuese aceptado y se me habilitara el servicio. La cobertura no es muy amplia, pero cerca de mi casa hay un área cubierta y la velocidad es realmente impresionante. Pero más importante, está menos saturado y la conexión se establece mucho más rápido.
No he podido probar el tethering a fondo, porque lamentablemente, el costo de navegar por datos móviles es bastante alto y ahora mismo, no puedo permitirme esos lujos muy a menudo. Sin embargo, creo que podría usarlo para cosas sencillas como revisar el correo y quizás hasta echar una partida breve de Champions of Regnum todos los días, para asegurar los premios diarios. Conclusión, que lo único que me impide disfrutar a fondo de esta maravilla, como siempre, es el finaciamiento.

Elementos para la trama de una novela

Hace algunos meses impartí una conferencia al grupo de aficionados a la CF y Fantasía acá en Santiago de Cuba, en la cual traté el tema de los elementos que componen una buena trama. Había olvidado el asunto, hasta hace unos días, que decidí convertir la conferencia en un artículo para el blog, y aquí está.
Hay un conjunto de detalles que hacen  que una novela sea interesante, pero en esta clase, o tutorial, de hoy, les hablaré solamente de uno. Toda novela de aventuras, ya sea de fantasía, ciencia ficción, o un thriller militar como los del viejo Tom Clancy, está construida alrededor de una cosa: conflicto. Hagan memoria y estudien las mejores novelas que hayan leído. Miren los grandes éxitos de los grandes escritores. El núcleo de la novela más grande y épica de la actualidad (en mi opinión), El Archivo de las Tormentas, escrita por Sanderson, uno de los tipos más originales del mundo, es tan viejo como andar a pie: el conflicto entre el bien y el mal. El núcleo de la novela más grande y épica de finales del siglo pasado, La Rueda del Tiempo (que veremos algún día convertida en serie de TV) de Robert Jordan y concluida por el mismo Sanderson, es conflicto entre el bien y el mal. Y Canción de hielo y Fuego, de George R.R. Martin está construida alrededor de múltiples conflictos entre... un montón de gente que ni es buena ni mala, solo pasan de caerte bien a caerte mal según los designios del autor. Salvo Jon Snow, claro. Ese solamente es imbécil.
Aunque a estas alturas y todos deberían tener una idea de qué es un conflicto, de todas formas voy a dar una definición simple y concreta: dos o más partes quieren algo y solo una puede conseguirlo. Es muy sencillo, como pueden ver, pero extremadamente importante, porque el lector, que es muy chismoso, querrá saber cómo se resolverá el problema. Es que a las personas, por alguna razón, nos gusta ver enfrentamiento, lucha, peleas... siempre y cuando sea otro en implicado. Si olvidamos plantearlo correctamente, ya sea por mala planificación o por otras razones, será mejor que la novela tenga otros puntos fuertes, pero muy fuertes.
El conflicto, aunque simple, debe poder dar suficiente jugo. No puede ser de fácil solución, para garantizar que las partes en pugna pasen por un sinnúmero de dificultades, que son las que al final, ayudan a llenar páginas. No basta plantearlo, hay que desarrollarlo.
En una novela, el conflicto determina en gran medida el público objetivo, el tipo de lector que consumirá tu obra. Cada segmento de mercado está determinado por ciertos factores: edad, sexo, educación, gustos, y otros. Por ejemplo, el 90% de los hombres no ve telenovelas, porque la historia de la jovencita pobre que se enamora del galán rico, mientras la ex-novia malvada le hace la vida imposible les parece tonta. En cambio, les llama la atención que Jack Bauer corra detrás de unos terroristas, matando a diestra y siniestra, para detener una bomba atómica o la dispersión de un virus. Y no me dirán que eso es menos tonto que lo anterior. Por eso hay gente que le encanta una historia de un vampiro que se pasa varios volúmenes zorreando con una imbécil (familia de Jon Snow, probablemente) sin acabar de follársela. U otros a los que les gusta la historia de uno que para follarse a la protagonista, primero tiene que darle unos latigazos o algo así. No quiero ni pensar qué le haría si la comida le queda mal hecha o no lava bien la ropa.
En fin, que hay lectores para todo (hablando de lo cual, me pregunto dónde estarán los míos). Pa concluir, una advertencia: hay una diuferencia muy grande entre saber y hacer. Quizás te hayas leído esto y pienses: "ahora sí voy a escribir la saga que dejará chiquita a Canción de Hielo y Fuego, y Netflix me va a hacer una serie". Pues no. Siempre hay chance a pifiarla en grande, aún sabiendo todo esto. A mí me ha pasado, y tal vez los grandes también tengan sus esqueletos en el armario, o en este caso, sus manuscritos mierderos bien ocultos. Pero tranquilos, que en alguna ocasión les saldrá bien.
Y en otro orden de cosas, les recuerdo que compren la novela. Si no, Jack Bauer irá por ustedes y los torturará haciéndoles cosquillas en los sobacos.

Unity, un blanco en movimiento

A partir de la versión 2020.1 de Unity tendremos UI unificado: el nuevo UIElements que recién acaba de presentarse, podrá ser usado también en juegos. Utilizado inicialmente para personalizar el editor, en sustitución de IMGUI (una mierda infumable y mal hecha), UIElements se llevaría por delante también al sistema que reemplazó IMGUI en los juegos a partir de la versión 4.6 de Unity.
Conocido como el nuevo UI, era un intento por hacer algo más o menos profesional, con una herramienta de diseño integrada en el editor. IMGUI se manejaba a golpe de código y es una sorpresa que un motor de juegos dependiese de una chapuza así durante tanto tiempo. Y más sorprendente aún es que se hiciesen buenos juegos con ella.
UIElements es relativamente simple de entender y he hablado del tema antes. Es muy cómodo usarla ya sea desde el código o mediante un subconjunto de CSS (USS) y XML (UXML), pero además de eso la 2020.1 traerá un editor de interfaz que ahorrará trabajo de hacerlo a mano.
Lo que me resulta un poco molesto en este asunto es que Unity se está convirtiendo un blanco demasiado móvil. El Unity que tendremos al finalizar este año será muy diferente al que teníamos a finales del 2018, y los cambios a principio del 2020 bastan para poner nervioso a cualquiera. Si estás trabajando en un proyecto con fecha de salida, puedes amarrarte a una versión hasta que lo termines y salga a la venta. Pero si estás aprendiendo y haciendo pruebas, creando prototipos o cosas así, te sentirás como si fueras montado en un auto que va a toda velocidad, mientras los mecánicos cambian piezas sin detenerse. Las ruedas de hoy podrían no servir mañana, y las ruedas de mañana podrían ser tan diferentes que impliquen un cambio en el modo de conducir.
El nuevo sistema de paquetes es una especie de ruleta rusa. Es mucho mejor quedarte con lo que sabes que funciona, porque actualizar un paquete preview puede romper algún otro. A fin de cuentas, está marcado como preview. Pero el caso es que el 90% de lo que hace a Unity interesante ahora mismo, es preview. Lo demás, es más o menos lo mismo desde el 2017.
Así que es mejor pecar de conservador y no de audaz, si alguna funcionalidad experimental te funciona, ¡no actualices! Por lo menos hasta que salga de preview.

Cacharreando Jobs

Este asunto de los Jobs requería un poco de estudio, así que acudí a San Google para orientarme al respecto y me bajé un tutorial de Youtube. Resulta que estaba dando palos de ciego, como suele suceder cuando uno se mete en cosas sin estudiar de antemano todos los elementos implicados.
Comienzo con respuesta a mi duda: los Jobs no son hilos. En realidad, son operaciones (o kernels) que se ejecutan en hilos de trabajo. Aparentemente, no son una solución mágica para todo, su verdadero valor se revela cuando necesitas descargar operaciones pesadas del hilo principal, para que éste haga otras cosas. Es recomendable realizar pruebas de rendimiento para ver si en verdad, convertir algo en Job es más rentable que hacerlo en tu Update(), a la manera tradicional.
Existen un montón de tipos diferentes de Jobs. Para mí ahora solo son importantes dos: el normal y el paralelo (IJob/IJobParallelFor). El primero ejecuta una operación, el segundo, trabaja sobre un arreglo, ejecutando una operación en paralelo sobre cada elemento del mismo. O sea, podemos crear un IJobParallelFor que tome un arreglo de conexiones de clientes y envíe o lea datos de cada una de ellas, en paralelo, o hasta donde los permitan los  worker threads de Unity, que supongo dependan de los núcleos disponibles en el CPU.
De los componentes del famoso Data Oriented Technology Stack, quizás los Jobs sean los más fáciles de comprender, aunque no carecen de detalles conflictivos. Estamos hablando de código que se ejecuta concurrentemente, con posibilidades de causar todo tipo de desastres si escribimos en un mismo lugar desde dos operaciones diferentes. Hay margen de sobra para meter la pata, causar race conditions y jodernos la vida con facilidad. Veamos un ejemplo, a modo de mini tutorial:

struct Prueba: IJob
{
  public int ttt;
 
  public void Execute()
  {
     /*  Hacer algo muy complicado con ttt */
  }
}

public class LoQueSea: MonoBehaviour
{
  private JobHandle handle;

  void Update()
  {
    int t;
    var job = new Prueba() {
      ttt = t
    }
    //programar su ejecucion
    handle= job.Schedule(handle);
    /* Hacer otras cosas */
    /* Importante!! Aqui no podemos modificar las variables que el job esta usando */
    handle.Complete(); //completamos el Job
   
  }
}
Sin embargo, si creen que usar Jobs aumenta el rendimiento, esperen a combinarlos con el Burst Compiler. El resultado me hubiera hecho caerme de culo de no haber estado sentado. Basta con agregar el atributo [BurstCompile]:

[BurstCompile]
struct Prueba: IJob

Como ven, nada que un programador no pueda entender con un tutorial básico y una hora de estudio. Usarlo adecuadamente ya es otra cosa.
Para concluir, les recuerdo que pueden comprar la novela en Amazon.  Arriba, que no he logrado una venta este mes y así no podré comprarme el yate.

Cacharreando Transport 2

Ante todo, les recuerdo que mi primera novela está disponible en Amazon (desde hace años, y también la segunda), en digital y físico, incluyendo Kindle Unlimited. Los ingresos serán utilizados para financiar el desarrollo de un RPG, del cual he hablado muchísimo durante los últimos años. Considerada una de las diez mejores novelas cubanas de fantasía, me han dicho que no está tan mala. No dejen de comprarlo, o sugerir a sus amigos lectores que lo hagan. Pueden tomarlo como una especie de campaña de crowdfunding.
Entrando en el tema de hoy, al fin he conseguido un progreso apreciable en mis pruebas de multijugador. Ayer, luego de lidiar durante unos días con errores derivados de los Jobs y cosas así, logré corregir el último problema y enviar un paquete complejo con las coordenadas de un click al servidor. Aún me falta por validar si los valores interpretados en el servidor son correctos, pero no me alcanzó el tiempo para eso, pues también tenía que escribir. Supongo que algunos dirán que el avance no es tan significativo, pero si con el país paralizado, nuestro gobierno dice que creceremos, no veo por qué yo no puedo considerar esto como un gran salto para la humanidad gamer.
Queda por delante reorganziar el servidor para lidiar con múltiples clientes, beneficiándose al mismo tiempo del sistema de Jobs de Unity. Y ya que mencionamos el tema, resulta que todos estos días lo he estado considerando como un sistema de programación multihilos, pero ahora mismo no me queda muy claro. El caso es que los Jobs de Unity se inician y se concluyen con Schedule y Complete. Necesitas hacer un Complete para detenerlos y poder asignarle nuevos valores a sus variables, luego de lo cual puedes volver a echarlos a andar. Si alguien me aclara algo en este asunto le estaría agradecido. La etapa siguiente sería pasar a Netcode, que es el API de alto nvel que saldrá en algún momento de este año.
Y como tema bonus de hoy, fuera de programa, les hablaré de otro problema que me estuvo atormentando durante días. Ni en el foro oficial, ni en reddit logré encontrar la solución, que vino a mí el sábado mientras le mostraba el proyecto al resto del equipo. El lío en cuestión era que los árboles solo se veían correctamente en el centro y borde inferior de la pantalla, el resto de los árboles en el área visible se veía borroso y estático. Suponía que algún parámetro de calidad era el culpable, esto, pero no lo encontraba ni en la cámara, ni en la definición del árbol, ni en las opciones del terreno. Hasta el sábado. El responsable sí estaba en las opciones del terreno, y se trataba de la distancia a la cual los árboles son sustituidos por billboards, los cuales no se animan y se ven horribles. Incrementar el valor resolvió el asunto, y ahora todos los árboles visibles se muestran correctamente y se animan.

Cacharreando Transport

Luego de varios días de estudio y pruebas con Unity Transport, puedo decir que estoy pasando de la fase "No sé nada", a "Ahora sé mucho menos". A eso, en programación, se le llama progreso.
Como había mencionado anteriormente, Unity Transport es una API de redes de muy bajo nivel. Mis experiencias con juegos multijugador son casi nulas, así que no puedo hablar acerca de las diferencias entre una API de bajo nivel y una de alto nivel. De tanto leer por ahí, creo que una de alto nivel debería ofrecer cosas como compresión y predicción, entre otras. Y volviendo a lo mencionado anteriormente, esta nueva API de alto nivel se llama Netcode, y está al caer, pero podemos llevarnos una idea de cómo será si miramos dentro del FPS Sample. 
En conclusión, ¿qué he logrado hacer? Pues bastante poco: conectar el cliente al servidor y enviar números enteros en paquetes separados. El próximo paso es enviar paquetes de datos más complejos, compuestos por diferentes valores, como tres floats (un vector), cadenas, etc.
Técnicamente, Unity Transport no es tan complejo de usar, debido principalmente a que es muy simple. Una vez que logras rastrear los principios básicos dentro de los ejemplos, puedes implementar el envío de paquetes. Lo complicado es armar todo un protocolo a partir de ahí. Ya que hablo de ejemplos, olviden por completo los que están a la vista. Los que de verdad ayudan son los que vienen incluidos en el repo, junto con el código del paquete.

La Guardia de Mundodisco llegará a la TV

Traída por la BBC y Narrativia, esta serie estará basada en los libros de la Guardia de la Ciudad de Ankh-Morpork. El cast también trae sorpresas muy buenas, como Richard Dormer (lo recordarán de Game of Thrones) en el papel de Sam Vimes.

Una elección que me parece excelente. Sin embargo, Lara Rossi no me da la Lady Sibyll de los libros: una solterona grande y gorda.

Juegos conectados con Unity: explicando la situación actual

Hace unos días un amigo me hizo una propuesta de trabajar en un juego multijugador. Yo mismo había estado dándole vueltas a la idea de echarle un vistazo a este asunto, o sea, una masturbación mental en toda regla, y con las dos manos. La propuesta acabó por decidirme a estudiar el tema en serio.
¿Qué podía salir mal? Unity es un motor maduro, con soporte de red desde hace tiempo, con todo lo que debe llevar y esas cosas. Para mi decepción, en este momento solo hay una palabra para definir el estado de la API de conectividad en Unity: cagazón. O mejor dicho, dos palabras: gran cagazón. Vayamos por partes y empecemos con un poco de historia.
En un principio fue Unet. Y vieron los usuarios que Unet era una cagazón que no sería para nada, así que se inventaron Mirror, Photon y otras muchas soluciones que solucionaban, y de paso, le permitían a los desarrolladores alimentar a su familia (y por familia me refiero a cualquier combinacion posible de personas de ambos sexos, animales incluidos, para que no se me ofenda ningún susceptible). Y como ya esto daba un poquito de vergüenza, en Unity decidieron ponerse las pilas y darle la patada a Unet, reemplazándola con una API más joven, más bonita y más potente.
Hasta ahí y en papeles, todo bien. Pero el caso es que la patada a Unet fue demasiado rápida, la declararon obsoleta en el 2018.x, dejando el 2019.x con... nada. En el 2019 solo nos queda Photon Bolt, sin soporte para LAN (hay que pasar por caja y pagar su servicio en la nube), Forge (lo mismo), o fajarnos con Unity Transport Package, que es experimental y de muy bajo nivel. Para el tercer trimestre saldrá la famosa API más bonita y potente, llamada Netcode, también experimental.
Déjenme que les cuente algo sobre las funciones "experimentales" en Unity. Es como un ciego tirándole piedras a un gorrión. Las cosas pueden funcionar o no, o simplemente cambiar de un día para otro. Por algo son experimentales, ¿no? Y ahora les diré algo sobre los trimestres de Unity: son como los plazos que da ETECSA para cumplir sus planes. O sea, que el tercer trimestre es muy largo y Netcode podría presentarse en sociedad a finales de septiembre. O a principios de octubre. O algo así. La respuesta de Unity es que vayan resolviendo con UTP o Photon Bolt.  
Yo, por suerte, no tengo apuro. Voy a sentarme a esperar a Netcode.

Si quieres entender raytracing deberías ver esto

Todo lo que necesitas saber sobre raytracing está en este video, y no digo más.

Coliseum llega a los $40000

En una rara muestra de transparencia, el grupo de desarrollo detrás de Coliseum, ha revelado que sus ingresos han superado los $40 mil CUC, equivalente en cierta forma a 40 mil USD, según como lo mires. Coliseum es una especie de MOBA para móviles, el cual no he podido disfrutar apropiadamente por ser, como todo MOBA, multiplayer. Las ventas dirias han promediado unos  $162 CUC, lo cual es todo un éxito en un país acostumbrado a no pagar por el software y jugar juegos pirateados (aunque algunos sí suelen comprar estos títulos piratas en negocios que se dedican a  venderlos).
En otras circunstancias felicitaría a Vertex y todas las empresas detrás del juego, pero el caso es que tuve la imp[ertinencia de hacer una pregunta clave: de estos miles de dólares, ¿cuánto han percibido los desarrolladores? ¿Esos que están al pie del cañón, picando código? La respuesta de uno que afirma (o por lo menos da a entender) ser desarrollador, es que cero. Y hasta el momento nadie ha desmentido su afirmación.
Supongo que alguno me dirá que ninguna empresa del mundo comparte con sus trabajadores la ganancia de sus juegos, pero aquí el caso es que esos desarrolladores y artistas no ganan más de 100 dólares al mes, y quizás exagero. Si consideramos que la empresa está haciendo unos 3000 dólares al mes, y está pagando, quizás unos 600-700 dólares en salarios, ¿no creen que deberían premiar a sus empleados con algo?

Ha llegado UIElements, mis primeras experiencias

Ayer por fin hice el intento de revisar con seriedad UIElements, el nuevo sistema de interfaz gráfica de Unity que podemos utilizar para personalizar el editor. También es posible que más adelante podams usar en nuestros juegos, así que no está de más echarle un vistazo. En concreto, me urge crear un editor de diálogos para mis RPGs, y hacerlo con el sistema anterior, que data de los inicios de Unity, era una tortura.
UIElements utiliza XML, llamado UXML, y un subconjunto de CSS, llamado USS, para definir elementos y sus propiedades. Eso de por sí es una gran comodidad, pero además podemos utilizar código para crear más elementos visuales o acceder a los creados mediante XML. Dicho así, todo suena muy bien y muy lógico. El gran problema es que la documentación es más escasa que la carne de vacuno en Cuba. Recién ahora hay un par de tutoriales en Youtube que aclaran muy poco, apenas lo mínimo para entender algunas cosas y crear un par de botones.
A pesar de eso, mis inicios no fueron tan difíciles, una vez que me tomé el tiempo para revisar los dos tutoriales. Lo difícil será salir de los inicios, porque mi objetivo es algo tremendamente complejo. De hecho, tan complejo, que me conformaría con solo lograr que editar el diálogo sea un poco más cómodo que hacerlo en el Inspector de Unity.
En este caso, no se trata solo de crear una ventana, sino de personalizar el Inspector de acuerdo al elemento seleccionado para así desplazar el grueso de la edición (texto, audio, restricciones y acciones de cada nodo de diálogo) al panel del Inspector. Aún no sé cómo hacerlo, pero tengo la impresión de que es factible, con un poco de experimentación y mucho tiempo.

Más anuncios del cast de La Rueda del Tiempo

Han sido anunciados varios actores más de la serie basada en La Rueda del Tiempo. En caso de que seas un lector moderno y no tengas idea de qué estoy hablando, La Rueda del Tiempo de Robert Jordan (completada por Brandon Sanderson) era en los 90 la novela que todos los aspirantes a escritores queríamos escribir. Más o menos como Canción de Hielo y Fuego en la actualidad.
Inicialmente se anunció que Rosamund Pike interpretaría a Moiraine y si la memoria no me engaña, creo que daría el tipo. Los nuevos actores seleccionados son estos:

Josha Stradowski, como Rand al'Thor. Si tenía una idea del aspecto de Rand, era esa precisamente. Este tipo y no otro es el Rand que quiero ver, si logra imprimirle al personaje la oscuridad que lo caracteriza en las etapas finales de la historia.

Marcus Rutherford, como Perrin Aybara. Marcus es justo el Perrin que yo me imaginaba. Lo mismo, si logra caracterizar al personaje adecuadamente, no hay que pedir más.

Barney Harris será Matrin Cauthon. Al contrario de lo que dice la noticia original, edfinitivamente este no es el Mat que yo imagino. Demasiado bonitillo. El Mat que tengo en la mente es más personalidad que apariencia.

Zoë Robins interpreta a Nynaeve al'Meara. Poco puedo decir aquí, aunque en realidad, no me da el tipo, y luego veremos por qué.

Madeleine Madden, como Egwene al'Vere, otro de los ta'veren de esta historia. Esta muchacha parece haber estado esforzándose seriamente en su dieta, yo diría que demasiado. Francamente, no tiene el aspecto de una joven aldeana, al igual que la anterior. Mi idea de Egwene es una joven un poco más gordita, al igual que Nynaeve, que quizás sería un poco más baja. Tal vez yo esté equivocado, pero así son las imágenes que se crea un lector. Y  espero que eso me sirva de lección a mí mismo, para ser un poco más detallado en mis descripciones de personajes.

Rememorando viejos tiempos

Mi época de juegos libres pasó hace algún tiempo (unos años o algo así), pero he encontrado una lista increíble que me ha hecho recordar esa época. Unos 500 juegos muy bien clasificados, para que los disfruten.

La solución al problema de ayer era...

Habíamos dejado esta historia más o menos lista para el final de temporada. El protagonista (o sea, yo) se enfrentaba a un terrible enemigo: ¡el error de detección de colisiones!, que se las había arreglado para colarse en mi sistema de IA. Burlándose continuamente de todos y cada uno ed mis esfuerzos, casi había conseguido su objetivo de dominar el mundo. O algo así. Entonces, el héroe (yo mismo), acudió a su intelecto superior, previamente remojado en cerveza de los carnavales, algo que viene a ser como un agua fría, amarillenta y ligeramente amarga. Y como suele suceder en los finales de temporada, el bueno ganó.
Técnicamente, lo que hice fue comparar qué había en el proyecto que funcionaba que no hubiese en el proyecto que no funcionaba. Entonces encontré lo opuesto: algo que no había en el viejo y que sí había en el nuevo. En concreto, un Rigid Body. Ni idea de por qué está interfiriendo en las colisiones, pero así es. Una vez que eliminé el Rigid Body del GameObject del personaje, las colisiones funcionaron todo el tiempo. Tengo pendiente investigar por qué razón sucede esto, y les contaré luego si encuentro alguna respuesta.

Encabronado de verdad verdadera

Pues eso. Tego un encabronamiento, cabreo, empingue, o como quieran llamarlo, de tres pares de cojones. Qué tres pares, de tres pares y medio. He tenido que reescribir todo el sistema de IA para volver a lo mismo, que se dice fácil, pero no lo es.
La cosa es que ayer, luego de terminar de pulir detallitos, me puse a probar la nueva implementación. Para mi sorpresa, el error anterior persistía: un rato después de detectar la primera colisión, simplemente el BoxCast deja de detectar más colisiones. Vuelvo a las aplicación de prueba básica y resulta que funciona todo ok; mientras solo tenga un par de cubos en la escena, el cast detecta o no según corresponda, todo el tiempo necesario. Por tanto, puedo descartar un bug de Unity. Cuando las cosas se ponen un poco más serias, se jode el asunto bien jodido. Digan ustedes si no es como para coger un mosqueo olímpico y cagarse en los 300 mil dioses de la India.
Sería lógico pensar que tengo algún timer o algo que causa el problema, pero no. Eliminé todo lo relacionado con temporizadores y degradé el sistema a lo más básico y cercano a la aplicación de prueba, un simple "te estoy viendo/no te estoy viendo". Aún así, el error sigue.
Conclusión, que estoy metido en un lío que parece no tener solución, sin nadie a quien acudir. Ni en reddit, ni en el foro oficial he podido encontrar respuesta acerca de esto. No es un bug, o al menos no puedo probar que lo sea. Tampoco se me ocurre otra variante para detectar los personajes en el rango "visible", excepto calcular distancias y lanzar rayos a montones hacia los personajes cercanos. En este momento, solo sé a ciencia cierta unas pocas cosas: el cast funciona, lo hace en la aplicación de prueba y lo hace en un proyecto viejo. No es un temporizador en mal lugar, en el proyecto viejo los temporizadores funcionan perfectamente y en el nuevo los eliminé, pero eso no solucionó la cuestión. ¿Podrían ser los modelos? Lo único diferente entre el proyecto viejo, la aplicación de prueba y el proyecto nuevo son los modelos usados. Hoy tendré que hacer pruebas adicionales desactivando animaciones y verificando a fondo los colliders incluidos en cada objeto. A ver si tengo suerte... 

Nuevo sistema de IA

Han sido unos días de terrible calor (récord de temperatura a escasos 100km de aquí, para que luego no digan que el calentamiento global es un cuento) y largos apagones, por lo que tendrán que disculpar mi ausencia y poquísimos deseos de hacer algo. Mayormente he dedicado el tiempo a jugar, corregir la última novela, que no salió del todo buena (más bien mala), y pensar un poco en cómo arreglar el sistema de inteligencia artificial.
Era algo que llegaría tarde o temprano. La IA que implementé basada en e tutorial oficial de Unity se quedaba corta, tenía que arreglar sus carencias en algún momento. Y qué mejor momento que ahora, cuando descubrí que un error casi imposible de rastrear provocaba que los casts dejasen de funcionar un minuto después de detectada la primera colisión. No tenía otra opción.
Cuando puse manos a la obra me percaté de que no había pensado tanto como creía, sino que más bien había estado justificando mi inactividad con la excusa de que "estaba rediseñando el sistema". En mi idea habían muchas cosas sacadas del sistema anterior que ahora no funcionarían, a menos que copiase lo viejo casi por completo. Y en principio, eso no era lo que pretendía. En fin, que toca pensar un poco más, para que el nuevo diseño sea flexible y potente.
En esencia, sigo utilizando ScriptableObjects, pero ahora el gestor de estados tendrá una lista completa de lodos los estados del personaje y podrá cambiar de uno a otro. El subsistema de sensores (porque en teoría, podría tener un sensor para la vista y otro para el oído, por ejemplo) se desplaza del estado como tal a la lógica. Y cada estado podrá contener una o varias lógicas, que serían como los ladrillos que forman la IA como tal, encargándose de la toma de decisiones. Suena un poco confuso porque en realidad es confuso y no pasa de ser una idea sin probar y sin implementar. Supongo que hablar de ella hace que me percate de todos los fallos. Pero creo que una vez que resuelva todos los pequeños detalles, debería funcionar.

Makehuman, un par de consejos

Luego de algunos intentos infructuosos, he conseguido utilizar con cierto éxito los modelos de Makehuman. En mi caso, había experimentado ciertos problemas con la cabeza de los modelos: los ojos no estaban correctamente asignados al esqueleto luego de pasar por blender y ser exportados a FBX. La cabeza iba por un lado y los ojos por otro. La solución drástica es combinar cabeza y ojos en un solo objeto en Blender antes de exportar a Unity. Esto no es una buena opción si quieres animar los ojos.
Sin embargo, esta solución dejó de funcionar cuando empecé a utilizar la última versión de Makehuman. Sí, es un alfa y se supone que tenga problemas. Pues bien, el caso es que si combinaba la cabeza y los ojos, el resultado en Unity era una deformación total de la cabeza. Y estaba yo rascándome la mía cuando se me ocurrió probar a combinar los ojos con todo el cuerpo antes de dividir el modelo en secciones. Aún estoy tratando de adivinar qué era lo que estaba mal en el modelo anterior, pero la experiencia me dice que el proceso de exportar a Blender, y de ahí a FBX, introduce errores en los modelos.
Como siempre, mi consejo es que te busques un modelador, pero eso no siempre es posible. Así que lo mejor que puedo recomendar es hacer varias pruebas, en especial ahora que MH está en fase alfa (aunque tengo que decir que esta versión me funciona muy bien y estable). Si te lanzas a hacer modelos a montones y hay algún fallo, habrás desperdiciado tiempo por gusto.
Hablando de otras cosas, me he visto obligado a aprender un poco más de Blender. No creo que llegue a convertirme en modelador, pero he conseguido aprender un poco de texture painting, lo cual me sirve para pintarrejear los personajes y objetos con cierta facilidad, sin hacer unwrap. En mi caso, el efecto pintado a mano se convierte en embarrado a mano. De no ser por el dolor de muñeca, hubiese sido divertido. Tampoco creo que Blender sea una herramienta excelente e intuitiva en este aspecto, alguien debería mejorar eso y así los fans del software libre no se verían obligados a usar Substance Painter.

¿Podemos crear juegos AAA en Cuba?

En estos días un colega me mostró con muy contento su primer juego terminado: un clon de World of Tanks, con multiplayer y todo. Es su primer juego terminado y lo concluyó solo, o eso me parece, utilizando Unity, que es la herramienta más popular en Cuba entre los desarrolladores. Los arquitectos prefieren Unreal, pero eso es irrelevante para esta historia, así que los dejamos atrás. Casualmente, una hora después me encontré con otro colega y conversamos, entre otros temas, sobre el desarrollo de juegos aquí.
El, como todo el mundo, piensa que es imposible hacer un AAA. Las justificaciones son variadas. No es rentable, dicen algunos. Es muy complicado, dicen otros.
Quiero aclarar que me refiero al desarrollo de juegos por parte de un equipo independiente. No me atrevo a hacer predicciones acerca de la naciente industria, surgida del matrimonio de conveniencia entre la UCI y el ICAIC, porque no tengo una bola de cristal (solo de las normales). Si algún día decidirán hacer algo grande, no lo sé, aunque creo que no es su objetivo.
Como pueden imaginarse, yo soy de la opinión de que sí se puede (por favor, abstenerse de hacer bromas con la frasecita). Existe la gente con el talento, o con la capacidad de adquirirlo. Lo que no existe, parafraseando un chiste que no me atrevo a mencionar porque en esta época políticamente correcta todo ofende, es financiamiento. Son tiempos duros y nadie quiere trabajar gratis en el sueño de otro, y en muchos casos, ni siquiera en el suyo. La lucha del sustento diario es la prioridad entre los cubanos. De ahí que la primera idea que venga a la mente al escuchar sobre proyectos de juegos sea "¿Voy a ganar dinero con esto?" Y lo más importante, "¿Voy a ganar dinero con esto en un mes, o dos?".
Ahí está el segundo detalle. Los cubanos parecemos ser incapaces de planificar a largo plazo. A menos que seas del gobierno, que en ese caso es todo lo contrario, todo se planifica a largo plazo (en el 2030, tendremos internet a 10 megabits y la economía estará recuperada). Un proyecto de dos años suena como algo excesivamente largo, titánico, quimérico. Que al final de esa jornada haya una recompensa no es significativo. Está muy lejos en el futuro, y como les decía, los cubanos no vemos el futuro, somos miopes para cualquier período de tiempo más allá de un mes o dos.
Volviendo al tema, estoy seguro de que sí se puede. Al menos, se puede intentarlo, sin tener ese terror al fracaso que paraliza. Un proyecto AAA. Incluso aquí en Santiago, que como toda ciudad fuera de la Habana es subdesarrollada e incivilizada, es posible reunir un equipo.
El problema, vuelvo y repito, es pagarles para que se queden juntos y trabajen. Porque lo que sí es imposible es encontrar media docena de personas que estén de acuerdo en invertir su tiempo en un proyecto complejo a cambio de nada. Mientras no suceda eso, seguiremos teniendo proyectos pequeños y medianos, hechos para aprender, pero nada grande y serio, pensado para el mercado global.
Y ya que hablamos de proyectos, los que estén de acuerdo con que Elymuria vuelva a tener un proyecto de RPG, que lo expresen levantando la mano (los que no estén de acuerdo, perderán la estimulación del mes).

ECS, a la carga otra vez

Aprender a utilizar ECS es una de esas muchas cosas que tengo pendientes desde hace tiempo, sobre todo porque los proyectos en progreso ya estaban bastante avanzados y también por la dificultad para instalarlo. Se requiere una serie de paquetes que hay que descargar de internet (vía VPN) y eso acá se vuelve un poquito complicado.
Pero como tenía que reiniciar un proyecto (un pequeño prototipo de Elymuria) ahora que me estoy tomando lo de escribir con calma, decidí echarle un vistazo otra vez. Tengo que decir que media hora de estudio no arrojó nada en claro: aún no tengo mucha idea de cómo convertir mi proyecto de RPG a ECS puro. Para empezar, los GameObjects desaparecen y entran en juego otros conceptos. Sí, ya sé que es posible usar GameObjects con Hybrid ECS, pero si vas a romperte la cabeza estudiando, mejor que estudies la solución completa y no una a medias. Otro grandísimo problema es que los tutoriales que descargué hace unos meses ya están desactualizados. Como lo oyen. Eso es lo que significa preview packages, por si no lo sabían: el API del mes pasado puedes ser totalmente diferente este mes.
Hay detallitos adicionales, como por ejemplo, que debes tener cuidado con el Input, que se realiza en el hilo principal, mientras que tu código, gracias al nuevo sistema de Jobs, corre en otros hilos. Como para cagarse en el día en que naciste, oigan. Pero es como la moda: la gente dice que es lo mejor que se ha inventado y que todo va más rápido, por tanto, toca joderse y aprender, aunque solo pienses hacer un clon del Flappy Birds (no se tomen en serio esto, en realidad ECS brilla en ciertas situaciones específicas). Al final, todos sabemos que echándole ganas, se saca adelante cualquier cosa.
Pero bueno, concreto no tengo nada todavía, ni tendré a corto plazo. Los cambios de paradigma suelen ser difíciles en sus comienzos y también hay que considerar si vale la pena. Como decía, ECS está pensado para casos muy especiales donde se forman cuellos de botella, y de esos no he identificado ninguno por el momento. Quizás en batallas de varios personajes con un despliegue enorme de sistemas de partículas, algo que no puedo ni imaginarme.
En fin, ya veremos si se logra o no algún beneficio.

Unity Editor para Linux

Me sorprende este anuncio oficial, publicado hace unos minutos: un nuevo editor de Unity para Linux, que será completamente soportado a partir de la 2019.3. Aunque aún está en preview, suena bastante interesante y quizás me anime a probarlo. Las distros oficiales son Ubuntu 16.04/18.04 y Centos 7.
Me quedaba la duda acerca de qué editor de código sería el más compatible, y parece ser que la respuesta es VS Code. No tengo buenas experiencias con él en Windows, pero habrá que darle una segunda oportunidad.

Novela terminada

Y en tres meses, que no está nada mal. En realidad, no es una novela, sino una noveleta o algo así, porque la hice específicamente para un concurso. Un poco más de 25 mil palabras, unas 60 cuartillas a espacio y medio (según la letra).
Había pensado tomarme unas vacaciones, pero como ya expliqué, Malena me insistió que siguiera escribiendo, y decidí regresar a Elymuria. Dos veces. Y ya el primer regreso está en fase de correcciones, mientras que el segundo avanza poco a poco.
Espero terminar este año y tomarme unas vacaciones hasta el 2020. Dedicarme a programar, jugar, o algo así, que ya son 7 novelas en el bolsillo y sin esperanzas de publicar más o vender las que ya se publicaron.

Análisis del capítulo 6, y terminamos

Anteriormente, en GoT:
Daenerys oye las campanas y está muy molesta. Arya sobrevive la destrucción y está muy molesta. Jon... bueno, sigue con su cara tristona. Ya podemos pasar a la musiquita, por última vez.
Hoy toca el último capítulo. El adiós muchachos.
Tyrion decide hacer un poco de turismo de catástrofe y se encuentra los cuerpos de sus hermanos. Es curioso que aunque les haya caído el techo encima, estén justo encima de la pila de escombros. Al parecer, los cuerpos flotan en los ladrillos. Quizás, solo quizás, le haya pasado por la mente que tal vez debió escuchar a Varys.
La reina pronuncia su primer discurso: quiere llevar la descojonación, digo, la liberación, a todas partes. Tyrion renuncia y admite haber liberado a su hermano, eso le cuesta ir preso. Jon le hace una visita y el enano, que ahora ha cambiado de idea, lo conmina a decidirse. Pero Jon ni se inmuta.
Hace falta una conversación con Daenerys para que Jon entre en caja y se convenza de que la nueva reina está medio Crazy Frog. Y en un inesperado giro, la mata. Sí, seguro que nadie se esperaba eso, creían que iba a ser Arya, ¿no?. Viene un momento de música tristona y gritería del dragón, que derrite el Trono de Espadas con su fuego. Tanta lucha y al final, nadie se va a sentar ahí. Nos despedimos de Daenerys, que se va volando llevada por su último dragón.
Gracias a la magia de la edición, caemos de lleno en una reunión donde se negocia el futuro de Poniente. Como alguien dijo hace unos días en Facebook, todo se ha preparado para que el trono recaiga en un hombre blanco, en vez de una mujer. Al final nos va a salir machista y patriarcal la serie.  Aunque aparentemente, es una decisión difícil, se resuelve bastante fácil, o más bien, Tyrion la resuelve: el nuevo rey será Bran. Supongo que aquí muchos se habrán halado los pelos y gritado más que el dragón. Es de esperarse.
Así pues, Bran el Roto es proclamado monarca de los Seis Reinos (Sansa decide que el norte será un reino independiente), y para calmar a Gusano Gris y sus Inmaculados, Jon es destinado al muro otra vez. Sí, ya no hay nada que cuidar allí, pero al menos está bien lejos y no estorba. Tyrion vuelve a ser la Mano del Rey y el resto del capítulo está ahí para llenar espacio.
Los Inmaculados se marchan a Naath, los clones dothrakis... pues ni idea. Arya decide viajar hacia el oeste, a territorios inexplorados. Sansa es coronada Reina, Brienne es la nueva jefa de la Guardia Dorada, mientras que Podrick, Bronn, Davos y Sam pasan a formar parte del Consejo.  Jon es bastante bien recibido en el norte, casi con cariño, y la serie termina con él llevando a los norteños más allá del muro.
Si todo esto les parece bastante flojo, es porque en verdad es bastante flojo. En mi opinión, no es lo tan flojo, sino las altísimas expectactivas que nos fuimos creando a lo largo de la serie, casi imposibles de cumplir. Les advertí que no habría final feliz y se cumplió. Sé que estaban esperando un final infeliz donde Jon se llevaba el trono, o resucitaba a Daenerys, pero este fue el que nos tocó.
Supongo que toca ahora hacer un recuento de la serie, pero obviamente, no seré yo quien lo haga. Más que nada porque no me acuerdo de las primeras temporadas y también porque se alargaría demasiado este post. Así que lo dejaremos ahí. Si me preguntan si me gustó la serie, pues yo diría que sí, a pesar de sus altibajos (o más bien bajibajos, hacia el final). El que la quiera mejor, es libre de escribir su propia versión y ver si HBO la adapta para la TV. Y con esto, por fin, acaban los análisis de Juego  de Tronos. 

Análisis del cap 5

Anteriormente, en 24, digo, GoT...
Perdimos un dragón, le cortaron la cabeza a Missandei y Varys cree que Daenerys está en Modo Rey Loco (en esos casos, la prudencia aconseja deshacerse de ella y poner a Jon, que es papabile). La pobre Brienne probó el mantecado, pero la dejaron a medias, se ve que la alegría dura poco en casa del pobre. Igual que la comida. El Perro y Arya se fueron a la guerra y no sé cuando vendrán. O si vendrán. Todo ha quedado listo para una batalla donde obviamente, va a perder Cersei. Imperativos de la narrativa, señores.
Abran el Winamp, Aimp o Audacious si usan Linux, lo que prefieran, y pongan a todo volumen en tema de la serie. Vuelvan cuando haya terminado.
Seguimos desechando personajes que sobran y le toca a Varys. Jon no acepta su propuesta, porque le han dado agua de entrepierna de ya sabes ustedes quién y está embobecido. Al final, le toca al pobre Tyrion echarlo para alante y hacer méritos para ganarse el Panda. El infeliz eunuco acaba sirviendo de tiro al blanco para el único dragón que queda, que se aburre una barbaridad ahí solito.
Y hablando de Tyrion, el cabroncete sigue intentando jodernos la serie, mientras todos queremos que le den candela a la ciudad, él hace lo imposible por evitarlo. Además, sin Varys atravesado, es su turno de conspirar, así que libera a Jaime para que convenza a Cersei de irse, y le ofrece una vía de escape. Les juro que estuve a punto de chivatearlo yo mismo.
A continuación viene lo que todos estábamos esperando. En esta ocasión, en vez de ponerse a mariposear con el dragón, Daenerys logra sorprender a la Flota de Hierro y evadir la artillería antiaérea equipada con el nuevo sistema Palo Muy Grande con Punta Mk II. Demasiado fácil, diría yo, igual que todos los escorpiones en la muralla. ¿La Compañía Dorada? Pura decoración. Esperábamos una batalla, pero más bien fue una masacre simplona. Es lo que sucede cuando usas la aviación adecuadamente (y cuando se está acabando la serie y te toca ganar). ¡Si hasta quedaban dothrakis vivos! Quizás los hayan clonado o algo así.
La ciudad se rinde, pero Daenerys no se iba a ir así sin quemar un par de cosas, y arre caballito, o mejor dicho, dracarys dragoncito. Candela como al macao. Ya les decía yo que estaba en Modo Loco. Por supuesto, los stormtroopers grises no se quedan atrás, ni los dothrakis clonados, ni los norteños. Al machete y con la luz apagada.
Arya y el Perro han llegado al palacio, pero él la convence de que olvide su venganza y salga echando. Todo se está viniendo abajo, porque el dragón está usando su rayo láser para cortar paredes, torres, lo que sea. Cuando Sandor encuentra a la reina, la Montaña deja de obedecer e incluso le aplica una estrangulación a lo Darth Vader al pobre Qyburn, que intenta darle órdenes.  Al fin, tenemos el Cleganebowl, pero la Montaña está zombificado total y no se muere con nada. Es otro momento de redención de esos que gustan tanto: el Perro empuja  a su hermano al vacío y caen juntos a las llamas.
Mientras tanto, Jaime trata de llegar a Cersei, pero Euron le da una paliza bestial, sin respeto alguno por su carnet de discapacitado. Hay un buen momento de trabajo en el ne-waza, hasta que Euron le mete una puñalada por la tripa y otra por un lugar suspechoso que creo que fue el glúteo derecho. A pesar de eso, Jaime se las arregla para sobrevivir y ganar la bronca. Aún con una espada clavada en la barriga, Euron es un tipo optimista como pocos, y se consuela pensando que fue él quien mató a Jaime.
Jaime desanda todo el palacio sin morirse, que tiene mérito, logra alcanzar a su hermana, pero la salida está bloqueada y no queda más remedio que sentarse a esperar que les caiga el edificio encima. Y este es el fin de Cersei y Jaime, con lo cual, el capítulo inicia su desaceleración, el dragón se queda sin gas y la masacre termina.
Este es el capítulo que todos estábamos esperando, pero que nos llega antes de tiempo y no de la forma en que lo esperábamos. Han muerto Cersei, la Montaña, hasta el pobre Qyburn, dejándonos sin malos y con un episodio más por llenar con algo.
Como les decía, el conflicto más importante no era derrotar a Cersei. Podemos tirar las siete temporadas anteriores a la basura, porque el final que veremos la semana próxima no tiene nada que ver con ellas. ¿Está Daenerys loca? ¿La cambiaremos por Jon?¿ Acabarán casados los dos? ¡Hagan sus apuestas, señores!

Análisis del capítulo 4 y análisis del capítulo 3.

Capítulo 4, otro análisis casi crítico

Este es un capítulo que todos van a odiar y no soy la excepción. Aunque es tolerable cierta apatía y falta de acción, debido a que este es más bien un episodio de transición, algunos errores de bulto no se pueden perdonar. Parece mentira que a estas alturas de la serie Daenerys no haya aprendido que el progreso ha llegado y ya se inventó la artillería antiaérea. Su desconocimiento de las estrategias y tácticas (creo que son dos cosas distintas) de la guerra moderna le cuestan otro dragón y un barco. La pregunta aquí es, ¿cómo fue que nadie vio la flota, ni siquiera desde el aire? Son unos barcos muy grandes con velas coloreadas. ¿Acaso le pidieron el dispositivo de invisibilidad a los klingon?
Además de derribar un dragón, Euron se las arregla para pescar a Missandei, para después cortarle la cabeza, cabreando a Gusano Gris, la khalesi y a todos los televidentes. Protagonistas que sobran, ¿recuerdan? El destino de la ciudad queda sellado, le van a  dar candela por los cuatro costados, o por lo menos por el costado por donde entre el dragón, que lo veo un poco difícil con la batería de S-300 que protege la plaza.
Por su parte, Jon le revela a Sansa y Arya que es un Targaryen. Les pide que no digan nada, pero Sansa, que es tremenda chismosa, no se puede contener y se lo cuenta a Tyrion, que va y se lo cuenta a Varys. Este tiene una discusión con el enano: Daenerys está medio loca y se le ha subido la fama para la cabeza y ahora mismo si convocamos a elecciones, Jon gana por mayoría. El eunuco no atiende a razones, y deja claro que por sus cojones... o bueno, ustedes me entienden, va a quitar a la reina y poner a Jon, porque es lo que el pueblo necesita y todo eso. Así como lo oyen, nos ha salido todo un socialista el tipo.
Hasta ahí las dos cosas más importantes del capítulo. Obviemos sandeces tales como que Jaime le pasó la cuenta a Brienne, que el pobre Tormund se fue al norte y otras que ni recuerdo. En general, podemos tirarlo a la basura y darle fuego al latón, no sin antes concederle un diploma por el trabajo realizado uniendo el capítulo 3 con el 5. 
Y aquí viene lo bueno. Acudiendo a la bola de cristal, metafóricamente hablando, porque no tengo ninguna bola (de cristal, quiero decir), podemos predecir que en el próximo episodio veremos otra cerrada batalla decidida en los últimos minutos. Será el final de Cersei, la Montaña, Euron y hasta Qyburn va a coger lo suyo (en lo personal, si yo fuese el guionista, Qyburn se escurriría al ver todo perdido y desaparecería en las sombras). Esto nos va a dejar con un sexto capítulo dedicado a resolver el problema de Jon y Daenerys, que podría ser el verdadero final de la serie. Por si acaso, preparen sus pañuelos para un final infeliz.

Mi opinión sobre el capítulo 3

Se han creado dos facciones irreconciliables en Internet relativas al capítulo 3 de GoT.  Una lo considera una tremenda mierda por muchísimas razones, la más importante, que Jon no fuese el salvador del mundo. La otra, que está bastante bueno. Yo en lo particular me inclino por la segunda.
Creo que en primer lugar, un escritor debe evitar ser excesivamente predecible. Sí, ya todas las historias están contadas y sabemos que al final los buenos ganan, pero lo que importa es la forma en que llegamos a ese punto. Suelo tener muy mala opinión de las novelas en que todo lo que puede salir mal, sale mal, para beneficio del héroe, que resuelve todas las dificultades. Lo considero un recurso bastante pobre, precisamente por ser predecible.
Así que me parece una jugada bastante buena crearnos una expectativa: "Ahora Jon llega en el último momento y derrota al Rey de la Noche" o incluso " Bran va a desencadenar un poder inesperado y lo va a achicharrar", pero al final, viene Arya, le empuja el pérfido cortante por la caja del pan y venga, guárdame ahí hasta el día del juicio. Eso se llama jugar con los sentimientos del lector. O espectador. Que es lo que todo escritor debe hacer.  O al menos, es lo que pienso yo, que como no estoy entre los superventas de Amazon, ni me han dado premios, no tengo mucha autoridad para opinar. Es un toque de caos en una trama que ya va entrando en su fase predecible: ya sabemos quiénes son los buenos, que al final van a  triunfar, dejando uno que otro muerto por el camino, sobre todo los que estorban o necesitan redención (Jorah, Theon, etc).
Otro secreto que les voy a revelar es que cuando un malo muy malo muere antes de tiempo, es que hay otro peor detrás. Es una regla básica que todo el que ha visto 24 debería saber. Confieso que me picaba la curiosidad por ver cómo manejarían en una sola temporada estas dos amenazas: Cersei y el Rey de la Noche. Todos creíamos que el segundo era más peligroso. A fin de cuentas, es casi imposible de matar, sus huestes crecen a medida que las de sus oponentes se reducen y además, los zombies molan mucho. Pero no. Acabamos de descubrir que para Martin, Cersei es una maenaza muy superior, y el Rey de la Noche ha sido "un relleno". Su tarea fue dejar a los protagonistas en una situación más desesperada aún.
Por supuesto, todo lo anterior es mi exclusiva y poco autorizada opinión, así que son libres de estar en desacuerdo. Para eso están los comentarios.

Vuelve Elymuria

Como dije hace unos días, Elymuria vuelve en una novela corta, ambientada unas décadas antes. La escribí para un concurso, pero aunque no gane, por lo menos tengo la satisfacción de que ha hecho reír a una de mis lectoras más exigentes. Eso, en apenas un minuto de lectura; algo debo haber hecho bien.
No daré más detalles por el momento, así que los interesados tendrán que esperar. Con suerte, solo será un año o dos. Y si no hay suerte... bueno, siempre queda la opción digital para los interesados.
El primer borrador debería estar listo en unos días (aunque esos días quizás estén en diferentes semanas), pasar una revisión rápida y de ahí pasar a una revisión gramatical y general. Después viene lo complicado: imprimir tres copias y enviarlas a la Habana.
No tenía pensado participar en concursos nacionales, pero aquí, sin premios, es muy difícil publicar y lograr reconocimiento. Ya es bastante cargar con el impedimento de vivir lejos de las editoriales. Por eso, y por insistencia de Malena, que casi me empujó para que participara, decidí echar mano a una idea que venía dándome vueltas en la cabeza y poner manos a la obra.
Tras esta, vendrá otra novela de Elymuria, también corta, destinada a otro concurso que debería convocarse el año próximo. Algo muy tradicional: habrá dragones, princesas raptadas y héroes al rescate. Luego de eso sí me tomaré unas vacaciones.  

Ya esta aquí Unity 2019.1

Bueno, de estar, está desde hace tiempo, pero han sido unos días muy ocupados, precisamente, lidiando con los problemas de la 2019.1. Me interesaba en especial migrar a esta versión, en primer lugar por el nuevo sistema de personalización del editor, que ni siquiera he podido ver. El segundo punto era ver si el ligthmapper progresivo basado en GPU funciona. Sí lo hace, pero pone la PC en un estado casi catatónico. Supongo que tendré que seguir usando el basado en CPU, que se encarga de recordarme todo el tiempo que mi i5 en realidad es una mierda de CPU.
Sin embargo, el gran problema a partir de la 2019.1 es que gradle se convierte en el compilador único para proyectos Android. La cosa se complica, y mucho, porque por alguna razón, en la primera compilación de un proyecto, Unity necesita conectarse a Internet. Dicha razón no he logrado averiguarla. Obviamente, esto no es un problema en el mundo desarrollado, donde todos tienen conectividad permanente. Otro detalle minúsculo, que sí afecta a todos, desarrollados o no, es que gradle es más estricto y lo que antes era una minucia aceptable, ahora es un crimen capital que impide la compilación. Buena suerte intentando dilucidar el origen de los problemas.
Por suerte, la solución que se me ocurrió fue usar UnityHub y mantener el 2018.3 para los proyectos Android, mientras que reservo el 2019.1 para los "grandes". En este momento, no puedo prescindir del primero, ni invertir más tiempo en hacer que el gradle funcione, porque estoy trabajando contra reloj (ya hablaremos de eso luego). Eso, si no encuentro más líos por el camino y decido desechar por completo el 2019.

Mini crónica del Espacio Abierto

Por desgracia, en Cuba carecemos de grandes eventos, como las "Con". Cosas de presupuesto, ya saben. Lo más parecido que tenemos los escritores de fantasía y CF, un par de géneros muy despreciados y considerados poco serios, son el evento Espacio Abierto y el Behíque. Un par de excelentes oportunidades para ver reunidos en un solo lugar a los mejores escritores del género, los ya establecidos y los talentos jóvenes. También van los aficionados al género, que últimamente está de capa caída, y con esto de la escasez de papel quizás el ritmo de publicación vuelva a bajar.
Este año tuve la oportunidad de participar en el Espacio Abierto, celebrado el 31 y 31 de marzo. 
Inicié esta crónica acabado de regresar y aún cansado, para narrar los sucesos mientras todavía estaban frescos en la memoria (esa frase me quedó como para un editorial del periódico Granma), pero al final, la dejé para después y ya ven. Este año tuvo la particularidad de celebrar el décimo aniversario del Taller Espacio Abierto y contar con la presencia de embajadores de reinos lejanos, léase: Cantallops y yo. Me insisten en que debo contar a Raúl Piad también, pero como es de Matanzas, no es tan extranjero como los orientales.
Por supuesto que no todo es ver a las celebridades locales: también puedes disfrutar de excelentes conferencias. Algunas de ellas te harán reír mucho, como La conjetura de Turing-Merlín sobre la computabilidad de la magia, que arroja unas conclusiones interesantísimas y que podrían dar lugar a algunos relatos bastante originales, si alguien se anima. O la de Bacallao, que afirma que solo fue allí a enseñarnos sus cuchillos, pero de paso aprendimos un poco más sobre estas armas. Y otras que te harán llorar, como las de Raúl Piad y Cantallops, porque nos muestran lo poco que hemos leído y los muchos autores que nos faltan por leer, algunos de ellos de rincones del planeta tan lejanos como China. Sí, aunque no lo crean, la copia china de la CF occidental es excelente.
Para mí también fue una oportunidad de reencontrarme con viejos amigos que llevaba años sin ver, porque mi ausencia duraba ya un par de añitos.
Una cita infaltable si estás cerca de la Habana. O no muy cerca, pero puedes pagarte el viaje.

El año del streaming

Si el año pasado fue el año del raytracing, este creo que ha sido el del streaming. Esa es mi modesta opinión. Señores, el futuro de los juegos es esto. Sí, es cierto que hace falta banda ancha, pero a menos que estés viviendo en Cuba o Corea del Norte, la banda ancha no es un problema. O no lo será, en algún momento, al menos tienen esperanzas, que nosotros, ni eso.
Nvidia me sorprendió con su servicio Geforce Now, que no recuerdo haber oído mencionar antes. Sin embargo, Jensen Juan Kenobi no dio muchos detalles, así que no lo que puede hacer o no el servicio ha quedado en el misterio. Más bien, la mención de Geforce Now fue una excusa para restregarnos por la cara los pods de Nvidia: unos racks enormes llenos de tarjetas, así que quizás ni siquiera les interesaba hablar del tema. Nvidia es un proveedor de hardware, no de servicios de conectividad, por eso ha tenido que acudir a alianzas con las empresas de telecomunicaciones para entrar en el mercado, lo cual no deja de ser una debilidad. 
Sin embargo, la presentación de Google Stadia me dejó asombrado. A diferencia de Nvidia, Google tiene todos los recursos para entrar de lleno en el mercado, y lo hará. El harware ha sido proporcionado por AMD, y cada instancia (así llaman a cada servidor) de Stadia tendrá un GPU de 10.7 TFLOP que es más que la suma de potencia de Xobx One X y PS 4 Pro. Stadia también promete escalabilidad: arrancan este año con 1080p y 60 FPS, para alcanzar a mediano plazo los 4K y 120 FPS, y el objetivo es 8K. Y lo que venga después. Podrás jugar cualquier título incluso en un móvil, con tiempos de carga de pocos segundos y sin necesidad de un equipo de alto costo.
Stadia permite cambiar de un dispositivo a otro, continuado el juego donde lo dejaste, de forma transparente. También, algo que me vino a la mente mientras veía la presentación, facilita el multiplayer (de paso, evita las trampas), y de hecho presentaron algunas demos técnicas que llevan el multiplayer más allá de lo tradicional. Aunque resaltaron su alianza con Unity y Unreal, hay un montón de otras empresas metidas en el ajo. Les recomiendo que no se pierdan esta conferencia, que para mí, ha sido lo mejor de este GDC.
Hay que ver las otras ofertas que aparecerán, pues como les decía, el futuro de los videojuegos es esto. Aún no tengo detalles del servicio de streaming de Microsoft, que si no recuerdo mal ya estaba anunciado, y es de esperar que Sony saque algo similar. La posibilidad de sacar los juegos del lado del usuario y así evitar la piratería es muy tentadora como para dejarla pasar. Quizás, igual que ha sucedido con el raytracing, no se imponga en este 2019, pero no dudo que para el 2021 estos servicios ya estarán bien establecidos.

No, Godot no está cambiando la industria

Sé que Francisco probablemente se me eche encima si lee esto, pero ayer un video en youtube me hizo darme una vuelta por el sitio web de Godot, para enterarme de cómo van las cosas. El título del video es bastante clickbait, ya que afirma que Godot está cambiando la industria.

Aunque afirmo y recontra-reafirmo que Godot es probablemente el mejor motor libre que existe actualmente (no sé el estado de Banshee Engine ahora mismo), para nada creo que esté cambiando la industria.
Su última versión, la 3.1, fue lanzada hace unos días. En el 2015 abandoné este motor en favor de Unity, por un conjunto de limitaciones que todavía persisten. Sí, Godot es quizás el mejor motor libre que existe en este momento, pero las decisiones del equipo de desarrollo han conllevado a que en ciertos aspectos esté muy atrasado. Hay que agregar que se han enfocado de una maner excesiva en los dispositivos móviles, en detrimento de la plataforma PC.
No soy un experto en gráficos, pero era de esperarse que la idea de usar un solo backend de renderizado acabara mal y así fue. El año pasado, luego de intentar migrar de GL ES 2 a GL ES 3 y justificarse diciendo que Vulkan no estaba bien soportada en casi ningún dispositivo, etc, se dieron cuenta de que el conjunto de porblemas no compensaba el cambio. Resultó que OpenGL ES 3 tampoco estaba bien soportado y que muchos dispositivos antiguos, por supuesto, no lo soportaban. Al fin, se decidió tener un renderizador basado en GL ES 2 y otro más moderno basado en Vulkan. La versión 3.1 trae de regreso el backend GL ES 2, que ha sido reescrito, y Vulkan queda para la versión 4, el año próximo. Mejor tarde que nunca, digo yo.
Por lo demás, la 3.1 mejora la usabilidad del editor, el lenguaje GDSCript y el soporte para C#, también regresa el editor visual de shaders e introduce los esqueletos 2D (el soporte 2D en este motor es genial, hay que reconocerles eso). Si necesitas una solución que sea software libre, no tengo otra cosa que recomendarte, excepto quizás Banshee Engine, cuyo estado actual desconozco.

No estoy muerto aún

Pues eso, no estoy muerto, sino desconectado, que es casi lo mismo. En caso de que a alguien le interese, la próxima novela de Elymuria avanza paso a paso, y la siguiente va ganando pequeños detalles. Con eso completaría la cuota de libros que quedarán ahí olvidados para lo que queda de año y aún me sobraría, pues en realidad no esperaba escribir nada en este 2019.
Por otra parte, he recibido una oferta para trabajar en proyectos de AR y VR, algo interesante que no esperaba cacharrear por el momento. Me viene muy bien porque tenía la programación abandonada, aunque el comienzo, como es de esperar, no ha sido fácil. Mayormente de trata de romper la inercia.Cuando lo consiga y tenga a mano el hardware, ya les contaré cómo me va con la VR.