Solicitamos su permiso para obtener datos estadísticos de su navegación en esta web, en cumplimiento del Real Decreto-ley 13/2012. Si continúa navegando consideramos que acepta el uso de cookies. OK | Más información

Entrevistamos a The Mojon Twins

La entrevista de que os traemos hoy es muy especial pues hemos convencido a los prolíficos y desternillantes The Mojon Twins a que se pasen por el blog para ser bombardeados con un buen montón de preguntas acerca de su labor creando juegos y engines. Sin duda, uno de los grupos que más ha animado la escena en los últimos años.

Suele decirse que los programadores o hacen juegos o hacen engines, vosotros hacéis ambas cosas, ¿cómo nace La Churrera?

MK1, que es el motor que oficiosamente se conoce como La Churrera, nació por dos motivos principales: El primero es que hacer los juegos requería un montón de trabajo manual tedioso (cosa que detestamos), por lo que, de una vez, tratamos de definir unos estándares en cuanto a formatos y escribir una serie de utilidades de conversión que automatizasen los procesos coñazo (otra gente tarda tanto tiempo en hacer los juegos porque se tira un montón de rato haciendo procesos coñazo). El segundo es que, en vez de reescribir o copia-pegar las rutinas una y otra vez, pensamos que era más interesante construir un motor modular con todo lo que solíamos usar y que pudiésemos ir activando o desactivando partes. Además, gracias a esta modularidad, añadir nuevas cosas sería relativamente fácil.

Aunque también podríamos decir que MK1 nace ante la necesidad de dar salida a nuestras ideas. Tenemos cierta incontinencia creativa que hace que no dé tiempo a programar todo lo que nos gustaría hacer, y na_th_an no da abasto. Ahí nació Sir Ababol, por ejemplo, un juego en el que por fin na_th_an pudo liberarse.

MK1, y, sobre todo, MK2, están construidos como un Tente. Vas añadiendo piececitas hasta que tienes todo lo que necesitas. Si falta algo, te construyes una pieza nueva. MK1 no tanto, pero MK2 está tan bien modularizado que añadir cosas nuevas o modificar las que ya hay suele ser un juego de niños. La mayoría de las veces que la gente viene al foro a preguntar cómo puede hacer algo, en lugar de decirles ‘eso no lo hace el motor’ podemos decirles ‘toca aquí y allí, añade un poco de queso, y lo tendrás’. Eso mola. El queso, digo.

En un principio también se pensó para que cualquiera del grupo, fuese o no fuese programador, pudiese plasmar las ideas que tuviese de forma sencilla - el problema es que, para cada juego, se nos ocurrían cosas nuevas, con lo que cada juego terminó necesitando un desarrollo propio… Así que ese objetivo se cumplió más bien poco ;-)

En realidad, ninguno de nosotros tiene un perfil de programador puro al uso. Ninguno disfrutamos juntando rutinas y haciéndolas cada vez mejor. Somos todos un poco más diseñadores y creativos. Nos inventamos historias. Nos salen. Tenemos ganas de dibujar tal o cual. Queremos hacer ‘un juego que sea azul y tenga chocos’. Se nos ocurre un spin-off del spin-off que ya teníamos. Necesitábamos una forma fácil de dar salida a esa creatividad. Al final, todas las mejoras y características que tienen nuestros motores se deben a necesidades que hemos tenido que cubrir para plasmar lo que teníamos en mente. No nos sentamos un día y decidimos hacer MK2 mejor que MK1MK2 es mucho mejor que MK1 porque haciendo Ninjajar nos dimos cuenta de que no cabía en MK1 y no se movía lo suficientemente fluido. La versión de MK2 de Leovigildo tiene un motor de scripting el doble de potente que la versión anterior porque Leovigildo necesitaba un script mucho más complejo que Ninjajar. Así funciona.

¿Por qué visteis necesario crear un engine nuevo y qué virtudes tiene?

Como te decimos, para dar escape nuestra incontinencia creativa. ¿Virtudes? Para nosotros todas. Le ha permitido a mucha gente poder hacer su propio juego. Entendemos que los dalefranes del mundo dirán que si eso no es exprimir la plataforma, que son todos iguales, que no está en ASM, que nos estamos cargando la escena, que si tal y cual… pero esa persona tiene su idea y su argumento plasmados en un spectrum gracias a MK1. ¿Qué más se puede pedir? Y alguno está ganando dinero a costa nuestra, así que fíjate.

Realmente, ¿qué es Mk2? ¿Es una Churrera avanzada? ¿Es un motor completamente nuevo elaborado desde cero o sólo un cambio de nombre? ¿Por qué emprender un nuevo camino y no hacer una nueva versión del engine ya existente?

Cuando terminamos el Goku Mal, o muy probablemente antes de terminarlo (y poniendo en peligro el Goku Mal, que eso es algo que nos pasa mucho: tener una idea con otro juego encaminado y fliparnos y dejar el primero compuesto y sin novia), empezamos con la idea de Ninjajar. Queríamos hacer un juego de meter hostias desde hacía tiempo, de estos de puñito gordo que saliese en el lado que fuera del sprite, sin modificarlo por aquello de ahorrar sprites. Como teníamos Sir Ababol 2 por ahí abandonado desde hacía siglos, se nos ocurrió que, cogiendo la rutina de la espada y cambiando la trayectoria, tendríamos puñito.

En un principio teníamos la idea de hacer un juego de Bud Spencer con perspectiva genital [sic] y el puño, pero enseguida se nos antojó más hacer un homenaje de uno de nuestros juegos fetiche: Alex Kidd. En un principio iba a ser un mashup con ideas del Kunio Kun e iba a transcurrir en un instituto; de hecho, el primer tileset que hicimos era un instituto. Luego lo desechamos. Sabíamos que iba a ser un juego grande, de 128K, pero siempre empezamos haciendo demos técnicas en 48K, que es más manejable, para así definir bien el motor, básicamente ver qué podemos aprovechar de lo que ya hay, y ver qué escribir, y tener un entorno sencillo en el que hacerlo y probar. Luego eso se coge y se le mete el gestor de niveles y se empieza a crear contenido.

El motor se construyó sobre MK1 versión 3.99.3, la de Goku Mal, a la que se le adaptó la rutina de ‘hitter’ (que es como le llamamos internamente; una de las reglas de oro para triunfar en la programación de juegos es ponerle nombre a todo) de Sir Ababol 2 convirtiéndola en una rutina de hostiar. Añadimos los tiles que se rompen y dejan un regalito (también CTRL+C/CTRL+V directo de Sir Ababol 2) y tal y cual y lo construimos todo con la réplica de la primera fase de Alex Kidd que terminó apareciendo como tercera fase del juego final.

El problema es que iba lento, no sacaba los suficientes faps [sic]. O sea, no, iba igual que el resto de juegos que habíamos hecho, incluso más rápido que Goku Mal porque no tenía proyectiles. Pero no molaba, no sé, no era como Alex Kidd. Alrededor de Navidades de 2013 estábamos además liados con nuestros primeros juegos de NES y en estos habíamos implementado una forma diferente que detectar las colisiones con el escenario que era mucho más ligera. Así que cogimos MK1 y eliminamos todo el movimiento del jugador y lo programamos desde cero con el nuevo método.

Luego hicimos trizas el código. La base era demasiado antigua, de cuando aún no le habíamos dado mucho Fran [sic]. En C ‘bien’, programas usando estructuras y usas funciones que encapsulan y que cual y tal y Pascual, pero eso, en 8 bits, es la muerte con pelos. Eliminamos todas las estructuras y todas las variables locales. Creamos un montón de arrays estáticos para todo, y un porrón de variables globales que se reutilizan de una forma que harían potar elefantes a cualquier profesor de programación. Nos cargamos un montón de funciones que sólo se llamaban una vez. Hicimos burradas para simular inlines. Reescribimos todo el módulo que pinta los mapas. Le tocamos un montón el totete a MK1 y básicamente lo hicimos todo de nuevo.

El resultado es que ahora Ninjajar sartaba y hostiaba como era debido [sic]. Y por eso decidimos que el motor, que ya no era MK1, iba a ser la base sobre la que trabajaríamos en el futuro, así que le llamamos, en un alarde de originalidad, MK2 (en realidad se llama Mojon Twins Engine Mark II, pero MK2 queda más corto).

MK2 pasó de la 0.0 a la 0.7 en Ninjajar. Normalmente tenemos una versión por juego, pero Ninjajar tenía demasiadas cosas. Quitamos el script de la memoria baja y lo colocamos en RAM extra. Mejoramos todas las utilidades de conversión. Creamos una rutina de empaquetamiento para la tonelada de textos que había.

Luego, en los juegos siguientes, seguimos metiendo más y más cosas. En el que estamos ahora (que, lamentablemente, lleva parado desde Septiembre pasado porque no paramos de fliparnos con otras cosas) también hemos añadido un camión entero de mierda. Y la que cabe aún.

¿Qué tipo de juegos se pueden hacer con Mk2 y qué los diferenciarían de los desarrollados con La Churrera?

Por ahora, Ninjajar te puede dar una idea. Leovigildo te la puede dar mejor. Pero es que desde la última versión que hay disponible (0.89) a la actual en desarrollo (0.90) ya hay un mundo.

Sin embargo, lo mejor es que es mucho más fácilmente modificable y expandible. Si no, pregunta a los amigos que ya lo están usando.

Una cosa que nadie parece haber visto es que MK2 incluye ahora un motor de plataformas con movimiento ‘sobre raíles’, tipo Phantomas o Abu Simbel. ¿Queréis hacer un Abu Simbel 2? ¡MK2 es vuestro motor! Nosotros estamos desarrollando uno, se llama Nicanor el Profanador. Algún día lo terminaremos, porque puede ser divertido y kendroock hizo una portada maravillosa.

Otra cosa que mola es que la gente que se queda sin sitio haciendo un motor en MK1 puede portar sin demasiados problemas a MK2 y terminar sus proyectos. MK2 ocupa menos y está más optimizado. ¿Quieres una prueba directa? Compara Sir Ababol original (versión 2.0 de MK1) con el Sir Ababol DX que acompañó al lanzamiento de Sir Ababol 2. Sir Ababol DX implementa un motor de plataformas más complejo (con la posibilidad de matar a los enemigos tras coger un item), una sección donde se puede ir nadando (cambio de motor en medio del juego), tiene mejor colisión con el escenario, va más rápido, incluye ¡20! pantallas más en el mapa…

Sí, Sir Ababol DX fue una sacada de picha. [sic]

¿Es necesario estar familiarizados con La Churrera para poder desenvolverse con MK2?

Sir. MK2 no tiene un tutorial ni lo tendrá, y es algo más árido a la hora de empezar de cero.

¿El salto de uno al otro engine está al alcance de todos aquellos que sin ser programadores quieran lanzarse a la aventura de crear un videojuego para Spectrum?

Por lo menos deberían saber de qué va MK1 antes de meterse en MK2, y por supuesto tener ciertos conocimientos técnicos que hagan que na_th_an no se muera de asco teniendo que resolver mil cosas. Porque a na_th_an le ha salido un padrastro en er deo y lo tiene flojo. Er deo.

¿Qué consejo le daríais a alguien que quiere lanzarse a crear un juego con vuestros engines?

Tener las cosas muy claras sobre qué se quiere hacer y qué se puede hacer. Nos gustaría hacer un simulador de fútbol en 7 dimensiones y realidad virtual, pero sabemos que con MK1 no se puede. :-)

Y que no se desespere con que está todo inventado y no se le ocurre una idea superoriginal. Porque está todo inventado. Hasta los juegos de curas están inventados y se siguen haciendo y la gente es feliz. Y de ninjas, de coches, de naves, etc… lo importante, es que se divierta haciéndolo, que disfrute. Y si quiere hacer algo comercial, esta no es su herramienta.

Habéis hecho un buen número de juegos y la comunidad ha respondido muy bien creando toda una constelación de ‘juegos mojonos’, ¿creéis que se ha exprimido el motor hasta mostrar sus límites o aún quedan juegos con novedades que nos sorprendan?

MK1 actualmente está exprimido, de hecho puede que juegos como Cadäverion o Sgt. Helmet hayan sido juegos con gameplays distintos a lo que habitualmente se ha hecho. Pero con MK2 sí que hay todavía mucho camino por recorrer. Más que nada porque desde que terminamos Ninjajar! no hacemos tanto eso de pensar un juego para el motor, sino que pensamos un juego, vemos qué hay aprovechable, y escribimos lo que falta. MK2 es una base estupenda sobre la que elaborar cosas.

Nuestro desarrollo actual, del que hemos contado algo por ahí, se llama Mega Meghan and the Key To Time. Sobre MK2 implementa un nuevo módulo de enemigos, una nueva forma de gestionar los mapas, un nuevo motor de movimiento, un nuevo sistema de contenedores de objetos, un gestor de niveles diferentes, un par de módulos custom para un arcón de objetos, viajes en el tiempo, cambios fáciles de tiras de tiles del tileset dentro de la misma fase, y más mierda por el estilo [sic]. Prácticamente todo es nuevo pero va sobre la base de MK2, esa pieza de Tente plana de 6x8 circulitos, donde puedes empezar a construir lo que te da la gana.

¿Qué diríais a alguien que se acerca por primera vez a vuestros engines, se entusiasma y ve la oportunidad de ver realizado el sueño que todos tuvimos en los 80?

Lo dicho, que tenga claro qué quiere y cómo va a hacerlo. Es muy importante conocer las restricciones y si puede superarlas. Las restricciones molan, te dan la posibilidad de estrujarte la cabeza. Por ejemplo, en Sgt. Helmet, el juego se quedó corto… ¿cómo alargarlo? Haciéndole ir y volver. Parece una tontada pero le dió mucho juego al idem.

Vuestro último proyecto es un juego para Nintendo NES que ha tenido muy buena aceptación en el crowdfunding que montásteis. Lo cierto es que pinta genial ¿existe la posibilidad de que tengamos, en el futuro, un engine para NES o para alguna otra consola como los hemos tenido de vuestra parte para el Spectrum?

El código fuente de todos y cada uno de nuestros juegos está disponible para el que lo quiera usar. Aparte de esto, no vamos a hacer ‘otra churrera’, con su tutorial y su aparente accesibilidad. No tenemos tiempo ni ánimos actualmente para hacer algo así, y menos aún tras un par de experiencias desagradables que hemos tenido con gente que pretendía lucrarse con nuestro trabajo.

En NES tenemos nuestros motores base, por supuesto, y los usamos como usamos actualmente MK2: como bases para construir sobre ellos. Desde hace un tiempo programamos de forma que en un juego puedes coger y pegar trozos de otro, si los necesitas. En NES tenemos ahora mismo tres motores base que pueden compartir elementos. En un principio nuestros nuevos juegos de NES saldrán en edición física primero, para luego pasar a estar disponibles para la descarga (por motivos que tienen que ver con la piratería, ¡es muy chungo encontrarte tu juego en AliExpress mientras preparas tu edición física, y ¡nos acaba de ocurrir!) con el código fuente. Cualquiera que se empape un poco de cómo funciona una NES y que conozca cómo solemos montar nuestros motores no debería tener problemas para usarlos.

Vuestros últimos trabajos parecen centrarse más en las consolas clásicas ¿qué diferencias encontráis con lo que es desarrollar para el Spectrum?

A nivel gráfico, muchísimas evidentemente. Nos encontramos muy cómodos con la NES. Tiene restricciones que te hacen estrujarte el cerebro para que las cosas queden mejor.

La NES es maravillosa. Está diseñada con amor para ser tremendamente sencilla pero jodidamente eficiente. Amamos esa mierda [sic]. Ahora estamos a saco con ella, pero ya sabes que somos polígamos y que en breve le seguiremos dando a los cacharros de siempre, que cada uno tiene su aquel. El Spectrum tiene muy buen culo. El CPC es como la niña alta con gafas que se sentaba en la fila de delante en clase, pero sus usuarios nos caen muy bien y no les defraudaremos. Tenemos una tontería para Sega SG-1000 y a la Megadrive en nuestras oraciones.

¿Qué herramientas usáis para para desarrollar para consolas clásicas como NES o Megadrive?

Ahora mismo probando Aseprite, que sirve para pixelar. Tiene un aspecto retro que mola mil, pero además, es que te da muchas posibilidades para trabajar: paletas predefinidas de ordenadores clásicos, grids, papel de cebolla para animar, etc…

Por otro lado, las de siempre. Un buen editor de textos, el bueno y viejo Mappy para crear los mapas, una colección siempre creciente de conversores e importadores, y los compiladores y bibliotecas disponibles.

Por lo general nos gusta crear nuestros propios conversores. En muchos casos hay utilidades cojonudísimas pero somos especialitos y entre que a veces tardamos más en aprender a usar una que en hacer la nuestra, o que los formatos que sacan no nos convencen, o no nos sirven, al final, terminamos guisándonoslo y comiéndonoslo nosotros mismos. Otras veces, hay herramientas de la leche de buenas y completas… pero visuales. Cargas tu PNG en una bonita pantalla y con el ratón pulsas y cambias la paleta, y luego tal y cual… Y eso no nos sirve. Somos diseñadores, somos grafistas. Cambiamos un tile ochocientas veces durante el desarrollo del videojuego. No podemos estar con el ratoncito cada vez. Necesitamos utilidades de linea de comandos que hagan su trabajo automáticamente, cada vez que compilamos.

Cuando adaptamos el código de los amigos Nightwolf y Syx incluido en Pentacorn Quest para integrar Arkos en MK2 escribimos una utilidad que recalculase todos los offsets de forma automática y generase el código fuente en C para que Davidian pudiese cambiar las canciones mil veces. ¿Calcular todo eso a mano? ¿Pero k dise? ¿kiere pelea? (por cierto, si la queréis, silbad el marino).

Si llegamos a tener que estar usando un conversor de estos ‘visuales’ cuando hicimos Ninjajar, aún no terminamos. En concreto, el tileset de la fase del primer poblado creo que lo cambiamos ocho veces; en concreto el tile de fondo de las cavernas cambió unas 28 veces o más. Otras veces no ves si funciona tal o cual cosa si no lo ves en el juego.

La gente se piensa que hacemos tantos juegos porque no tenemos vida. No, nada de eso. Hacemos tantos juegos porque empleamos el tiempo de forma muy eficiente escribiendo conversores e importadores que hacen las cosas automáticamente, y copiando y pegando código de forma obscena. Y metiendo el sprite de la canina en el 90% de los juegos.

En el apartado musical, para conseguir ese sonido tan NES, usamos famitracker, que no tiene ya ningún misterio para el amigo David. En vez de murciano, parece japonés. Y para Megadrive, usamos VGM Music Maker del gran Shiru.

¿Sois muy metódicos desarrollando vuestros juegos o desarrolláis de un modo más emocional?

Somos caóticamente emocionales xD

The Mojon Twins se caracteriza por su acusado y delirante sentido del humor ¿cómo es una sesión de trabajo grupal? ¿Es Vah-Ka quien impone sus designios?

Normalmente, las ideas surgen de conversaciones. Somos amigos que hablamos todos días: Sobre nuestra vida, trabajos, hijos, películas de chinos, etc… a veces pasan días y no hablamos de temas de desarrollo. De hecho, de cualquier cosa de estas que comentamos podría surgir una idea válida para empezar a hablar. Y de ahí, a seguir de ‘brainstorming’ hasta que sale algo, o lo abandonamos porque la estrella tuitera de turno dice alguna chorrada y tenemos tema durante una semana para reirnos.

Pero, eso sí, aun con tanto caos como sabemos que proyectamos, cuando nos ponemos a tope de power de curro, nos ponemos a tope de power y hacemos lo que ya sabéis.

Aprovechando (y abusando de vuestro habitual desenfado)… ¿Hay algo inconfesable que no hayáis contado nunca a la comunidad y os gustaría hacer ahora?

Muchas cosas, por ejemplo una aventura point and click, que ya sabemos que requiere mucho trabajo gráfico, lo cual tampoco es negativo puesto que es lo que nos encanta hacer. También un juego de curas, sobre todo viendo el tirón que tienen en la escena. Y sobre todo, un juego para PC-Engine (Turbografx), que es algo así como una NES con casinos y furcias.

Web oficial | The Mojon Twins
Twitter | @mojon_twins
Facebook | The Mojon Twins
Soporte | Foro de Mojonia

Coméntalo en: Twitter Facebook Google +