Hace mucho que no escribía un post en el blog (demasiado tiempo!). Lo cierto que he estado demasiado inactivo estos 3 últimos años tanto en el blog como en las redes sociales. En el blog me he limitado hacer los resúmenes anuales del Freakend y a publicar mis galerías de Flickr que voy subiendo (he estado más activo en fotografía que en desarrollo de juegos). En las redes sociales, Twitter y la pagina del blog en Facebook (y cuando me acuerdo en Google+), retuitear y compartir noticias o artículos interesantes que voy encontrando.

En general prácticamente no he publicado contenido propio sobre desarrollo de juegos, ya que he estado la mayor parte de este tiempo alejado en cuanto a proyectos personales se refiere en mis ratos libres. Falta de motivación y problemas personales han sido las principales razones que me han mantenido alejado del que durante 15 años ha sido mi hobbie principal y en los últimos años mi meta profesional. Y lo peor de todo es, tras tanto tiempo inactivo, volver a intentar retomar el habito de hacer cosas en casa en mi tiempo libre es tarea harta difícil. De todos modos no he estado totalmente alejado del mundo del desarrollo de juegos en estos últimos años, aunque tampoco ha sido como a mi me hubiera gustado. Así que siguiendo el consejo de un amigo, voy aprovechar para hacer un resumen de esta etapa y contaros en que he estado metido.

Mi etapa en Virtual Toys (2014-2016)

En Octubre de 2014, tras llevar un año trabajando de nuevo consultoria tras mi excedencia voluntaria de dos años (2011-2013), tuve, digamos la «suerte», de entrar a trabajar en la extinta Virtual Toys, en el proyecto de Action-MOBA Pirates: Treasure Hunters, en el equipo de programadores que estaban desarrollando el backend del juego. Un proyecto enorme y con mucho trabajo detrás:

Allí tuve la oportunidad de conocer a grandes profesionales en ese estudio, gente con larga experiencia, algunos que vienen de la antigua Pyro Studios u otros que han pasado por Mercury Steam. Gracias a varios de ellos, con quien mantenía un contacto a diario aun siendo gente fuera de mi departamento, indirectamente pude aprender mucho sobre desarrollo de juegos y conocer de cerca los pormenores de desarrollar proyectos Triple-A como se hacían allí (proyectos para consolas como PS Vita, PS4 y XBox One y el mencionado MOBA para PC/Consola).

Lo malo de esta experiencia (sin contar el ERE, por supuesto) ha sido, sin duda, el estar dos años desempeñando labores como técnico de sistemas en vez de programador (me contrataron como programador), aprendiendo a montar servidores Linux, gestionar bases de datos MySQL, Cassandra, MongoDB, gestionar maquinas virtuales Citrix y la nube y servicios de Amazon. Tareas ajenas a la programación que, salvo Python, que también me toco aprenderlo, no me aportaron demasiado como programador a mi carrera profesional. De cara a futuros trabajos tratare a evitar este tipo de cosas, desempeñar tareas ajenas a mi perfil profesional. Lo bueno de todo esto, al menos, es que puedo decir que he podido trabajar en un proyecto Triple-A.

Proyectos personales estos dos últimos años

Aunque no he publicado prácticamente nada sobre proyectos personales en estos últimos años, si que he estado en la sombra intentando algunas cosillas, entre ellas ponerme en serio de una vez por todas con Unity3D, y tratando de recuperar el habito de programar en casa. Unos proyectos abandonados, otros aparcados y otros en desarrollo actualmente. El asunto es que no me parecía buena idea al principio hablar de estos proyectos hasta que estuvieran en una etapa más estable, pero quizás ha sido una mala idea no hacerlo.

Proyecto Star Ranger

• Genero: Plataformas 2D cinemático de acción estilo retro-pixelart
• Periodo: Enero – Abril (2015)
• Tecnología: BASIC (QB64, GW-BASIC, QuickBASIC)
• Plataformas: PC (MS-DOS, Windows, Linux, Mac), MSX 2 (posible port)

Aviso ya de primeras que este proyecto fue una «pequeña» ida de olla fruto del aburrimiento :P A raíz de una conversación un tanto friki con un colega, hablando sobre recuerdos del Quick BASIC de Microsoft y esas yerbas, salio a la luz un proyecto llamado QB64, que no es más que un «remake» del Quick BASIC 4.5 (1988) pero con soporte adicional de 64bits, multiplataforma (Windows, Linux, Mac y Android), aceleración gráfica vía SDL y OpenGL, compilacion a código C++… todo esto ademas de soportar prácticamente la totalidad del código legacy del Quick Basic 4.5 (lo que quiere decir que permite programar en el como si fuese casi el Quick BASIC original). Así que el aburrimiento y desmotivación constante de mi trabajo como de técnico de sistemas en Virtual Toys me llevo a la brillante idea de llevarme a desempolvar mi viejo manual de GW-BASIC (1988) que tenia del viejo 8086 de mi tío y volver a estudiarme las funciones gráficas para trabajar en EGA y demás tripas del lenguaje con el objetivo de intentar hacer un mini-plataformas de disparos retro escrito en BASIC. Esto principalmente, por que en su momento me hubiera gustado haber aprendido hacer algún mini juego cuando aprendía a programar con este interprete BASIC pero mis conocimientos no daban para tanto.

Sin estar contento de que funcionase en QB64 y tener el juego corriendo en Windows, Linux y Mac con aire «retro», me puse de objetivo hacerlo retro de verdad y de correr en GW-BASIC (un interprete más limitado y antiguo que el QBASIC, el típico interprete BASIC incluido en la mayoría de los ordenadores en los 80), y así poder tenerlo también en formato MS-DOS, con la idea de que ello lo pudiese mover como mínimo un 286 real, aunque la locura final fue plantearme que lo mínimo fuese un ¡8086 a 4.77Mhz!. Si conseguía hacerlo correr a esa velocidad, tenia la posibilidad de hacerlo correr en un MSX 2 (ZiLog Z80 a 3.58MHz), dado que su BASIC es muy similar al GW-BASIC, lo que en teoría debería facilitar el portar código entre ambos sistemas. Como decía, mucho aburrimiento y una ida de olla bien grande :P

Lo cierto es que este proyecto fue divertido. Siempre me han gustado los ordenadores y consolas antiguos, la sintaxis de los interpretes BASIC de los 80 (programar listados de código mediante saltos GOSUB, sin poder estructurar el código en métodos o funciones, clases ni tan siquiera separar el código en varios archivos. Hacer un código limpio era todo un reto) y estudiar la arquitectura de aquellas maquinas para hacer trucos para obtener más memoria de la que te daba el interprete de GW-BASIC (menos de 64K a repartir entre código y datos) y acceso directo a la memoria de vídeo para poder pintar más rápido (las funciones gráficas de BASIC son hyper-lentas para hacer algo decente y fluido en comparación a leer y escribir directamente en la memoria de vídeo en modo 13 o VGA) e incluso tratar de almacenar gráficos en ella en vez de la RAM (usando las paginas adicionales de la memoria de vídeo).

Fue un reto interesante pero que se me escapo de las manos. Por temas de rendimiento (GW-BASIC es muy lento al ser un interprete y no un compilador como QBASIC) y uso de memoria (solo las capas de representación de la pantalla, front y back, ya ocupaban cada una 72KB), tras varias pruebas, finalmente pase a QBASIC 4.5 para programar la versión MS-DOS del juego (pero manteniendo la sintaxis de programacion de GW-BASIC, sin estructurar el codigo en metodos o funciones), subiendo el limite de hardware a un 286, pero al final, con el cambio y demás, no resulto tan viable. Para aprovechar bien las capacidades graficas via BASIC en maquinas tan limitadas no te queda más remedio que tirar de código ensamblador para optimizar partes criticas del código, y eso ya se me escapaba demasiado lo que buscaba hacer (ademas, no he programado ensamblador en mi vida). Así que tras varios intentos de implementar el render gráfico (un render multicapa para separar elementos estáticos de los sprites), un conversor BMP a EGA bytearray en C# y tras lograr hacer pruebas con el mixer de audio propio que me hice, decidí aparcar el proyecto, que a fecha de hoy, no lo he continuado, por lo que prácticamente esta abandonado. Hubiera estado bonito el haber podido decir que habría hecho un juego para Windows, Linux, Mac, MS-DOS y MSX, pero me temo que sera en otra vida ;) (y de hecho, es más probable que antes de volver a BASIC me de por mirar de programar para mi vieja Game Boy con C y GBDK).

Proyecto Jupiter (codename)

• Genero: Plataformas 2.5D cinemático de acción de estilo retro
• Periodo: Agosto – Octubre (2015), Enero – Marzo (2016)
• Tecnología: Unity3D
• Plataformas: PC (Windows, Linux, Mac)

Por finales de verano del 2015, tras una apuesta con mi jefe de equipo, decido intentar sacar adelante un prototipo de un juego de plataformas 2.5D en Unity3D. Mi experiencia con este motor era muy limitada por entonces. Ha sido un motor que he estado tocando esporádicamente desde su primera versión para Windows, Unity3D 3.0 o 2.6 creo (fue cuando hice un curso intensivo de 14 días en CICE en 2010, con el premio de la gamejam de Campus Party que mi equipo y yo ganamos aquel año). Hasta verano del 2015, solo había hecho pruebas y algún prototipo 2D en PC y móvil (Android), usando un plugin gratuito llamado RagePixel (por entonces, aun no había salido el soporte 2D nativo de Unity3D) pero ningún proyecto como tal.

La apuesta en si fue una buena forma de forzarme a ponerme de una vez por todas con Unity3D (que ya iba siendo hora) y tratar de aprender por mi cuenta. En cosa de un mes digamos que logre tener algo cercano a un prototipo del plataformas 2.5D, usando un par de assets gratuitos de la tienda (como este modelo animado para el personaje):

Seguí un tiempo trabajando en el proyecto, añadí los assets de la demo de AngryBots de Unity3D 4 para tener algo más de variedad para los escenarios y enemigos, y me centre en mejorar lo que tenia del prototipo (casi todo el trabajo era del personaje principal, sus mecánicas) pero encontré demasiados problemas con los assets que me dificultaban más que facilitar la tarea. Por un lado, no podía usar Mecanim (o no encontré la forma correcta de hacer funcionar los modelos y sus animaciones). El asset gratuito que usaba para el personaje principal era demasiado antiguo para usarse en Mecanim, al igual que los assets de la demo de AngryBots de Unity3D 4. Por otro lado los materiales y texturas de la demo de AngryBots daban muchos problemas en Unity3D 5 (sobre todo con la iluminación), y por otro lado, tuve problemas con PlayMaker. Dicho plugin lo estuve usando para crear las maquinas de estado. Hasta ahí bien, pero por algún problema que desconozco (algo estaría haciendo mal) PlayMaker me daba problemas con el repositorio git. Cada vez que recuperaba el proyecto del repositorio, todo lo que estaba hecho con PlayMaker se rompía por completo y ni reimportando el plugin se solucionaba. El interés en usar PlayMaker era por recomendación de algunos colegas de gremio y por que algunas ofertas de trabajo lo pedían como requisito opcional.

Entre eso y la suma de otros problemas técnicos (muchos por error mio al desconocer la forma de hacerlo, como el sistema casero y muy limitado de IKs que me hice para las poses del personaje principal) me hicieron abandonar el proyecto para volver a empezarlo desde cero con assets más modernos y compatibles con Unity3D 5.

WIP: 2.5D, 256 colores, #Unity3D, #Retro, #LowRes, #Pixel pic.twitter.com/rnbw0zkxiw

— José Miguel Sánchez Fernández – EX3 (@ex3_tlsa) October 27, 2015

Proyecto Star Ranger 2.0

• Genero: Plataformas 2D cinemático de acción retro-pixelart
• Periodo: Abril 2016 (#LOWREZJAM)
• Tecnología: Unity3D
• Plataformas: Web (HTML5)

Puestos ya con Unity3D decidí intentar participar en una gamejam que en teoría me venia como anillo al dedo, la #LOWREZJAM de itch.io. Se trataba de una gamejam internacional de 4 semanas en la que el objetivo era desarrollar un juego con una única restricción: solo se podía usar una resolución máxima de 64×64 pixeles. Me pareció suficientemente atractivo como para intentar rescatar la idea del juego que intente hacer en BASIC y como vía para probar 2D Toolkit, un plugin 2D para Unity3D que compre poco antes de salir el soporte nativo de Unity3D (y que se integra y extiende el propio sistema 2D actual de Unity3D).

No se si me dará tiempo al final, pero voy a intentar participar en la #LOWREZJAM con un pequeño plataformas :) pic.twitter.com/03y1M4QOqj

— José Miguel Sánchez Fernández – EX3 (@ex3_tlsa) April 10, 2016

Aunque me apunté con una semana de retraso intente ponerme con ello. La parte gráfica no supuso problema más allá de lograr hacer algo «reconocible» a tan baja resolución, todo un reto pero también parte de la diversión para mi :) Tenia claro el estilo gráfico y logre hacer los sprites de los personajes. Estuve haciendo pruebas y aprendiendo un poco a la carrera a usar 2D Toolkit (ya había tenido una primera toma de contacto en la Global Game Jam de 2014) pero al final me pillo el toro y para cuando logre tener un prototipo básico del juego me quede sin tiempo para poder llevar a cabo el proyecto.

Más adelante me gustaría retomar este pequeño proyecto, sigo pensado que como practica para aprender a manejar el 2D de Unity3D me viene de perlas por su sencillez.

Proyecto Jupiter (codename) 2.0

• Genero: Plataformas 2.5D cinemático de acción
• Periodo: Septiembre 2016 – 2017 (actualmente)
• Tecnología: Unity3D
• Plataformas: PC (Windows, Linux, Mac), posible port para Microsoft Store (Windows + XBox One, vía UWP)

A principios de verano (poco antes de que se anunciara el ERE en Virtual Toys) empece de nuevo el proyecto del plataformas 2.5D. Aprovechando rebajas en la Asset Store de Unity3D me hice con mucho material en mente para este y otros posibles proyectos (plugins y modelos 3D). Trabajando a ratos me puse la meta de tratar de hacer un plataformas inspirado en juegos como Shadow Complex (salvando las distancias) en cuanto a control del personaje y diversidad de cámaras, algo mucho más avanzado que la versión anterior, que era más plataformas cinemático de la vieja escuela.

En esta versión he prescindido completamente de PlayMaker para las maquinas de estado. Para las IKs he estado usando Final IK, plugin que me ha encantado por lo fácil que es de usar una vez que entiendes como funciona, aunque requiere mucho tiempo y esfuerzo afinar correctamente las configuraciones necesarias (y hacer ciertas «ñapas» por código para que no rompan entre si las animaciones en ciertos casos).

Tras un par de meses trabajando en este prototipo, me encontré con ciertos problemas, que no tengo claro si estoy resolviendo correctamente, como ciertas animaciones que no funcionan como deben al mezclarse (la animación de carrera y disparo, por ejemplo, la animación de disparo se descuadra mucho y no consigo corregirlo mediante las IKs), poses del modelo original que estoy usando que hacen cosas raras al aplicar algunas IKs (por la pose en si, no por que el modelo este mal, aparentemente, ni nada parecido, simplemente que no esta diseñado para ciertas posturas). Un pequeño cumulo de problemas que al final puede desembocar en problemas similares a la versión 1.0 del proyecto (la versión mencionada más arriba) y que al final hacen que dedique más tiempo a temas secundarios y no al desarrollo del juego en si, que es el objetivo que busco con estos proyectos. Esto me llevo tras pensarlo con calma, y siguiendo el consejo de varios colegas que han estado siguiendo el desarrollo de este proyecto, en plantearme hacer algo más sencillo, sin meterme en hacer cosas complejas como las IKs cosas por el estilo.

En las ultimas semanas decidí empezar de cero de nuevo y plantear el desarrollo de un plataformas más sencillo, con un control y unas mecánicas más típico de los plataformas de los 90, parecidas a las de  juegos como Another World (1991) o Flashback (1991), centrado más en la parte de plataformas que de shooter. En resumen, volver un poco a las raíces del concepto de la versión 1.0:

Proyecto TLSA.Engine (codename Renovatio)

• Genero: Motor de juegos 2D pixelart
• Periodo: Octubre 2016 – 2017 (Actualmente)
• Tecnología: .NET, C#, dx_lib32
• Plataformas: PC (Windows. Linux y Mac vía Wine)

Vuelta a un clásico y otra «ida de olla» a la lista :P Sin tener suficiente con andar haciendo y rehaciendo el anterior proyecto en Unity3D ¿por que decido volver a meterme hacer un motor propio de juegos?. Bueno, lo primero explicar que este proyecto es totalmente secundario y es a lo que menos horas le estoy dedicando.

Este proyecto, en el que llevo trabajando a ratos sueltos desde finales de octubre, nace por una situación que llevo viviendo desde hace tiempo con mi viejo Macbook del 2007, un portátil que a día de hoy esta como nuevo para el tiempo y uso que tiene (ampliación de RAM, disco duro SSD, carcasa y teclado nuevo reemplazados por política de garantía de Apple hará unos 5 años, batería en perfecto estado y duración). Un equipo, que si bien funciona sin problemas, es cierto que a nivel de hardware se ha quedado un poco desfasado (Intel Core 2 Duo a 2.66GHz, 3GB RAM, Intel GMA 950), pero según mi punto de vista debería ser suficiente hoy día para poder desarrollar juegos 2D de calidad (de hecho en el he trabajado sin problemas con XNA 4.0 e incluso en el desarrollamos GreyInfection para XBox360) pero al parecer tanto Unity3D como Xamarin o MonoGame y otras tecnologías actuales no opinan lo mismo, de hecho mucho software ha dejado literalmente de soportar mi Macbook desde OS X Lion (2011), la ultima versión que soporta del S.O. de la manzana, y me refiero inclusive software para hacer juegos para Amstrad CPC 464 (aunque QB64 funciona todavía :P).

Un poco triste, la verdad, que un equipo como este lo limiten por software de esta manera tan cruel. Sin embargo este equipo sigue corriendo Windows, vía BootCamp, con extrema fluidez, y soportando software que no soporta en OS X como el caso de MonoGame. He llegado a correr Windows 10 64bits en el (aunque Apple no me da soporte de drivers para esta versión en mi Macbook), actualmente corre Visual Studio 2015, e incluso versiones de Unity3D que ya no instalan en OS X Lion (aunque con limitaciones por el hardware gráfico).

Por otro lado, tras dos años trabajando principalmente entre servidores, terminales Linux y backups de bases de datos, sin programar apenas, tenia mucho mono de programar (el proyecto de MS-DOS del principio es un ejemplo de ello). Tenia muchas ganas de volver a programar algo propio desde cero, por simple diversión. Así que me propuse intentar desarrollar, una vez más, un pequeño motor de juegos 2D para orientado al pixelart, tomando ideas de lo aprendido estos años de la arquitectura de motores como Unity3D, mejorando lo implementado en versiones anteriores del TLSA.Engine, desarrollarlo usando .NET con C# y usando de base dx_lib32.

¿El por que usar dx_lib32? dx_lib32 es un framework que desarrolle a medida en muchos aspectos con todo lo que considero que necesito para trabajar en 2D, y aunque a día de hoy esta muy desfasado (lo diseñe inicialmente para funcionar en Windows 98 y Windows XP con DirectX 8.1, pero funciona sin problemas en Windows actuales), utilizar otro framework como MonoGame o SharpDX me obligaría, como me paso antaño con XNA, a volver a programar características y funcionalidades muy concretas que ya tengo implementadas en dx_lib32. El otro motivo es precisamente que dx_lib32 no exige un hardware potente para funcionar, podría usarlo sin problemas en mi viejo netbook del 2009 (Intel Atom 1.6GHz, 1.5GB RAM, Intel GMA 945) por lo que es idóneo para trabajar en el Macbook.

De momento el proyecto esta en una etapa muy temprana. Tengo implementada la mayor parte de la base del motor, sobre todo la capa de objetos que conectan con dx_lib32 y transforman muchas de sus llamadas en objetos listos para usarse en C# (tipos base como vectores, rectángulos o estructuras de color, texturas, primitivas gráficas, render targets, renderizadores de texto, efectos de iluminación básicos, etc…), capa IO (serialización de datos a XML y binario, gestión de archivos ZIP), soporte para XInput y parte de la base de la arquitectura de entidades y escena (como los GameObjects de Unity3D) así como una maquina de estados básica (prácticamente la misma que estoy usando actualmente en mis proyectos de Unity3D).

Como decía antes, es un proyecto secundario al que le dedico algunas horas cuando no estoy con Unity3D o con otras tareas más importantes o prioritarias, y de momento debo decir que me alegro de haber empezado este proyecto (luego llorare cuando explote por mil sitios por posibles bugs de la dx_lib32 :P), ya que estoy disfrutando con el lo que no disfrutaba en años como programador. Lo cierto es que echaba de menos volver a este tipo de proyectos. De momento el proyecto lo estoy llevando en un repositorio privado, pero más adelante, si no se tuercen las cosas, iré liberando versiones en un repositorio publico en gitHub para el que le interese.

Planes de futuro

Tras el ERE de Virtual Toys y mi experiencia trabajando allí, me estuve planteando a finales de verano si tirar la toalla en seguir intentando moverme en la industria del videojuego y volver al mundo de la consultoria y desarrollo de software general, donde lo tengo más fácil para trabajar de lo mio como programador (y donde tengo más experiencia, más facilidad para encontrar trabajo y por ende más estabilidad). Yendo por ese camino me estaba planteando si ponerme al día en ciertas tecnologías de .NET como la web y Azure y me había decidido hacer de nuevo el master en .NET que 10 años atrás hice en CICE, con la idea de prepararme también las certificaciones (MCSD).

Caprichos del destino, dicho master lo pospusieron para abril de este año y me surgió la opción de hacerme el master de desarrollo de juegos con Unity3D que llevan años impartiendo este centro (y con los descuentos entre antiguo alumno y por cancelación del otro master, me salia casi igual de precio), así que finalmente, y tras consultarlo con colegas del gremio e informarme con detalle del temario y profesores, decidí intentarlo una vez más y actualmente, desde el 30 de Noviembre, me encuentro cursando dicho master, y de momento debo decir que me alegra haber tomado esta decisión por todo lo que puedo aprender, y estoy aprendiendo, la experiencia en si y todo lo que me puede aportar a futuro a mi carrera profesional. De aquí a verano veremos a ver si me ha merecido la pena tomar esta decisión, por que lo cierto es que desde hace un tiempo ando un poco escéptico en lo de encontrar trabajo en videojuegos tal y como esta el panorama actual, pero al menos se que si no es en videojuegos, trabajo de programador en general tengo asegurado.

Mientras dure el master estaré ocupado con varias practicas que nos irán mandando (pequeños proyectos y el proyecto final de master en verano), por lo que seguramente no pueda dedicarle mucho tiempo a proyectos como el plataformas 2.5D (del que por otro lado, se beneficiara con los nuevos conocimientos adquiridos) ni al TLSA.Engine.

Pues hasta aquí, nada más que resumir. Con este post queda claro que al menos no he estado tan parado como mi ausencia en las redes sociales parecía mostrar (tengo la tarea pendiente de intentar volver a estar más activo por Twitter para evitar esto). De aquí a un mes toca ya la próxima edición del Freakend, de la que como en veces anteriores, intentare dejar testimonio por aquí.

De temas de viajes, del que hablo poco por el blog (aunque si subo fotos y añadí hace poco una sección de mapas con lugares visitados) y debería más adelante poner un poco al día mi perfil en Minube (con viajes como el de Amsterdam en 2014 o las escapadas a Asturias en 2014 y 2015). Para futuros viajes tocara esperar a volver a trabajar para tener sueldo con el que pagarlos.

Salu2… :)