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.