Esta entrada da para vídeo, sí, lo sé, y probablemente lo haga. 

El 23 de enero de 2017 abrí el canal de GomvoTutoriales, sin ningún tipo de experiencia (creando vídeos en youtube). Todo fue porque desde hacía bastante tiempo me había adentrado de lleno en el mundo de la programación enfocada a videojuegos y había estado utilizando últimamente el motor Unreal Engine 4. Cuando iba a buscar algún videotutorial que me enseñase o guiase sobre algo que no entendía (y que en la documentación oficial no aparecía) no encontraba absolutamente nada.

Y es por ello que, a base de aprendizaje, cursos, talleres, másters y a través de mucho trabajo (y ensayo/error) fui autoformándome en el uso del motor. Como siempre he abogado por una enseñanza libre y gratuita (con excepciones), decidí subir todo aquello que sabía de manera gratuita a youtube, sin peros, sin pagos, sin nada, gratis. He utilizado mi experiencia como profesor para enseñar de la manera que considero yo adecuada: todo al grano, siguiendo un orden lógico (en la medida de lo posible) y no haciendo perder el tiempo a los usuarios que ven mis vídeos.

Claro que muchos pensaréis que con esto de youtube se cobra bien. Con 10.000 suscriptores a mis espaldas y más de 700.000 visualizaciones os puedo asegurar que no, por tanto, el contenido que se sube es casi del todo gratuito (digo casi del todo por la poca retribución que generan mis vídeos a través de anuncios).

Es curioso cómo de cada vídeo que subo hay un montón de comentarios (los que más abundan, de agradecimiento), pero también los hay de exigencias, críticas y problemas. Problemas que se solucionan, en su gran mayoría, siguiendo el tutorial al pie de la letra o repitiéndolo para ver qué hemos podido saltarnos, una mínima variable, un conector en algún blueprint, algún valor, etc. Críticas como "¡Vaya mierda! Quiero aprender a hacer un Fortnite en 15 minutos y el vídeo que has subido dura una hora y va sólo sobre inventario."

Exigencias como "haz un tour para un museo". Lo que el usuario ha querido decir realmente es "enséñame gratis que luego lo voy a vender por ahí". Nunca he tenido ningún problema es que se use lo aprendido en mis vídeos para que cualquier usuario saque sus juegos/proyectos, reciba cualquier retribución económica y ni siquiera se me mencione (no es sarcasmo). Pero, si necesita cualquier profundización en cuanto a los contenidos que enseño, adaptaciones, soluciones personales y demás considero normal cobrar por mi tiempo (y más cuando vas a recibir dinero por ello).

También me he encontrado con personas que me conocían por youtube y he tenido el placer de conocerles en persona. Es increíble el empujón que te dan cuando te valoran y valoran tu trabajo. Yo no me considero un genio en programación/desarrollo. Siempre aprendo de cualquier persona, aunque tenga menos experiencia que yo y valoro muchísimo recibir formación de cualquiera.

Y entre trabajo con la empresa y el poco tiempo libre que tengo, mucho lo dedico a generar contenido de valor para el canal, diverso y variado. No es de extrañar que me encontrase con "copias" de mis vídeos en otros youtubers. El conocimiento no se puede registrar como propio, por tanto, que se basen en mis vídeos para crear los suyos propios me parece genial. Hay veces que la sorpresa ha sido inversa, ver que alguien había subido (aunque sea la base) un vídeo mucho antes que yo.

Doblar los vídeos al inglés también me lo he planteado, pero supondría hacer un canal paralelo y empezar de cero otra vez, llevando dos cuentas, cosa que, a día de hoy, me es imposible.

Así que, ¿Por cuánto seguiré subiendo vídeos al canal?. Espero, que por mucho tiempo, siempre y cuando mi trabajo y mi tiempo me lo permita.

Y como siempre, me enrollo, mucho. ¡Un saludo!


De eso que tienes una reunión con un cliente sobre un proyecto, te hace firmar una serie de documentos (que suelen ser acuerdos de confidencialidad) y de repente lees... "se entregará el código fuente del proyecto".

No. Básico y sencillo. No con excepciones; a no ser que trabajes para una empresa en el que todos compartáis el mismo código. El código fuente es tuyo, personal, único. Es tu firma. Es posible que, por contrato, te favorezcan las cláusulas como para poder entregar el código y que no te importe en absoluto, en este caso genial. En el resto de casos mi consejo es, no lo entregues.

El código del proyecto es el trabajo, tanto de formación y aprendizaje, como de creatividad y descubrimiento, para poder conseguir completar los objetivos. 

Imaginémonos que empresa X me pide el código fuente del proyecto que le he realizado específicamente para ellos. En la mayoría de proyectos para los que he trabajado hemos tenido que sacar actualizaciones del mismo presupuestándolas (por supuesto). De tener el código la empresa X, no requeriría de mis servicios (ya que ellos podrían editar el código o contratar los servicios de un desarrollador más económico para trastear mi código) y, por tanto, ellos mismos sacarían sus actualizaciones del producto por lo que, mi servicio para la empresa X terminaría justo ahí. 

¿Entonces?. Soluciones hay varias. Ofrecer por contrato soporte y actualizaciones durante un período de tiempo (y cuando exceda ese tiempo, presupuestarlo). Ofrecer licencias por uso (y no la venta del proyecto en sí). Ofrecer un contrato Escrow (la parte desarrolladora del código deposita ante notario o tercero de confianza dichas llaves informáticas para cubrir casos de desaparición societaria o conflicto entre las partes). 

Es muy importante expresar que no vas a entregar el código fuente, sea por contrato oral o escrito, ya que pueden reclamarte el código vía judicial por ejemplo si "el comprador queda dependiente del programador para la realización de todo tipo de actualizaciones" (Pablo F. Burgueño).

"Establece que, en el caso de que los usuarios lo necesiten en determinadas circunstancias, deben tener el derecho a acceder a él. Las circunstancias son: que acceder al código fuente resulte necesario para la finalidad del programa, que sea para la transformación del programa dentro de un uso razonable y siempre que no se diga lo contrario en el contrato." (Adolfo Estalella, El País 2003). 

He jugado a videojuegos desde los 4 años con una Atari 2600. Aún recuerdo jugar en casa de mis abuelos a oscuras, con los chirriantes efectos de sonido de la Atari jugando hasta que cayera la noche. He pasado por muchas videoconsolas (aún las conservo todas) pero el género al que más horas he echado ha sido el de aventura gráfica.

Antes no había internet, o bueno, al menos no tan extenso como lo está actualmente, y las conexiones de 28kbps no ayudaban demasiado para buscar guías sobre algún juego. Si querías completarlo tenías que hacerlo por tus propios medios, topándote con un rompecabezas sin solución durante horas y días. 

El primer juego de aventura gráfica que jugué fue el Maniac Mansion del gran Ron Gilbert. Un meteorito, una chica en apuros y tres valientes al rescate en la mansión de un científico loco. El sistema SCUMM marcaría a todos los juegos posteriores del mismo género. 

¿Cuál situación fue la más complicada? Tratando de salir del calabozo cuando te pillaban.


Después me enamoré de Monkey Island. ¿El mejor para mí? El dos. Un simpático personajillo que quiere ser pirata. El universo Monkey Island fue muy grande y amplio, saliendo en PC y diversas consolas (aunque ya no de la mano de Ron Gilbert). El Monkey Island 3 (o más bien, The Curse of Monkey Island) fue criticado en su momento pero, en cuanto a dificultad, duración e historia, muy recomendable. ¿Los peores? Todos los 3D que salieron posteriormente. ¿Cuál situación fue la más complicada en Monkey Island 2? Utilizar el mono como llave inglesa. (Problemas de traducción). 


Las segundas partes pueden superar a la original y más viniendo de Gilbert. Day of the Tentacle, con su humor ácido, sus enrevesados rompecabezas y una historia muy muy muy divertida. Tres amigos visitan al doctor Fred (del primer Maniac Mansion) y viajan en distintos momentos del tiempo. ¿Cuál situación fue la más complicada? Eso. Pasar por las letrinas objetos entre los personajes (manejas tres) para poder solucionar los rompecabezas.


Sam & Max: Hit the Road. Si no lo has jugado, estás tardando. Un perro y un conejo haciendo de detectives en donde la violencia gratuita y el humor está más que asegurado. Steve Purcell es el creador de estos simpáticos personajes. ¿Hicieron secuelas? Sí, en 3D y no recomiendo ninguna. ¿Cuál situación fue la más complicada? La parte de la bola de cuerda más grande del mundo.


¡Indiana Jones! Sí, el mismo. Y tuvo dos juegos bastante buenos, The Fate of Atlantis y The Last Crusade. El héroe de Spielberg descubriendo secretos y resolviendo puzzles. Fue tremendo (sobre todo, el primero mencionado). ¿Cuál situación fue la más complicada?. La parte de las exvacaciones del desierto (justo la foto de abajo).


Y nos vamos al reino de los magos. No hablaré de Loom porque, realmente, nunca lo he jugado, pero sí a Simon The Sorcerer. Por alguna extraña razón, en la época, el juego me iba demasiado lento y a veces era desesperante ver caminar al personaje, pero aún así lo disfruté. Es sencillo y entretenido. ¿La parte más complicada?. Ninguna.


Broken Sword. Un turista vive en sus propias carnes un atentado. A partir de ahí la trama se complica. He jugado a todos (hasta los 3D) y recomiendo el primero y segundo (2D). Doblado perfectamente al castellano, escuchar los diálogos es una pasada. ¿Complicado? No tanto. Quizá sí que puede ser un problema en que, a mi parecer, son demasiado cortos.


Hollywood Monsters. En más de una ocasión tuve que llamar a las oficinas de Péndulo Studios para que me guiasen. Aventura gráfica con mucho humor y algún que otro puzzle complicado, y de aquí, de España. Muy lograda e interesante. Una periodista desaparece y su amigo tiene que investigar a todos los actores (monstruos) de Hollywood. ¡Recomendadísima!



The Dig. Ya está. No hay más. Un peliculón hecho juego. Una trama impresionante de ciencia ficción en el que tendrás que evitar que un asteroide choque contra la tierra (¿Será el mismo que cae en Maniac Mansion?). ¿Cuál fue la parte más complicada?. Todo. Es excesivamente difícil.




Y de ciencia ficción a otro de ciencia ficción Beneath a Steel Sky. Te secuestran, sufres un accidente en helicóptero y el resto es tratar de escapar. Una trama complicada e interesante. Me recordó mucho a 1984. ¿Cuál fue la parte más complicada?. Que yo recuerde, ninguna.


Y hasta aquí todas las que jugué (en su momento) en 2D. Aún las puedes jugar con el emulador Scummvm. He seguido y sigo jugando a aventuras gráficas (Grim Fandando, Botanicula, Machinarium, Thimbleweed Park que está gratuito en el bazar de Epic Games, Runaway, Life is Strange, Another Code, y más que me dejo en el tintero). 


Muchos me preguntáis a través de diversos canales, aunque ya lo he dicho varias veces, que a qué me dedico. Desde hace 2 años (2 años y poco) soy Chief Developer en Last Monkey Studio, una empresa de diseño 3D y VR enfocada a soluciones empresariales de Alicante.

¿Una carrera me va a asegurar un empleo? Respuesta corta, no. La formación debe ser continua, nadie sale de la universidad siendo un pro en X lenguaje de programación o utilizando Y programa de desarrollo. Si bien la formación universitaria asienta unas bases fundamentales para, después, adquirir más fácilmente los procesos lógicos de los lenguajes de programación y programas de desarrollo, no es del todo necesario.

Con las nuevas tecnologías la formación institucional se está quedando obsoleta. Existen muchísimas personas con capacidades increíbles que se han formado de manera autodidacta, a través de manuales, vídeos formativos en diversas plataformas, y dedicación. Malcolm Gladwell afirmaba que "reaching the 10,000-Hour Rule, which he considers the key to success in any field" (Blink, Inteligencia Intuitiva. Malcolm Gladwell). Lo que viene siendo que practicar durante 10.000 horas una materia te asegura la clave para el éxito en cualquier campo.

Si bien es cierto que se ha desmitificado y que no basta solo con la práctica sino que también influye la formación, incrementa un 12% la capacidad. (Deliberate Practice and Performance in Music, Games, Sports, Education, and Professions: A Meta-Analysis. Brooke N. Macnamara, David Z. Hambrick, Frederick L. Oswald. 2014).

Además de desarrollador, soy pianista y en estos dos últimos meses he sido pianista acompañante en dos recitales de poesía y música. También me dedico, de manera amateur, a la producción y masterización, realizando masterizaciones, de manera cotidiana, a diversos cantantes de renombre en youtube.

Antes de seguir desviando demasiado el tema central, en el trabajo nos han salido varios clientes potentes y, a nivel de desarrollo, está siendo cada vez más difícil (e interesante). La organización de la programación es muy importante ya que, lo óptimo, no es desarrollar y adaptar X solución para X cliente, sino poder aplicar X solución para todos aquellos clientes que, aunque presenten casos diferentes, tengan un planteamiento de órdenes lógicas similar. De aquí recomiendo el libro "Design Patterns" de Erich Gamma, John Vlissides, Ralph Johnson y Richard Helm.

Del mismo modo, tanto la organización de las ideas como del tiempo es fundamental. En este apartado recomiendo "Scrum and Extreme programming" de Eugenia Bahit. Es de licencia Creative Commons y de descarga gratuita. 

¡Y horarios de descanso! No sería la primera vez que dedico de entre 12 y 14 horas al día a un proyecto, no pudiendo ser óptimo ni eficaz en mi trabajo y, gracias al descanso, arreglar un bug del que no podía encontrar su ubicación en un simple minuto. El descanso es importante, importantísimo.