Entrevista por el lanzamiento de Jet-Paco

blog_entrevista_jetpaco

Aunque aún no puedo dedicarle a la web todo el tiempo que debería, hay un juego homebrew que me ha levantado la curiosidad. Nunca suelo fijarme en este tipo de software, pero por una vez que sale mi provincia natal, no puedo dejar la oportunidad. Este juego se llama Jet-Paco  y esta programado por Mojon Twins. Ahora se ha lanzado un crowdfunding para sacarlo en formato físico gracias a 1985alternativo, yo me he hecho con una copia, y si todo va bien pronto llegarán a la meta.

El mes que viene habrá novedades en la web, pero mientras tanto os dejo con la entrevista:

¿Cómo empezasteis en este mundillo?

Albert (1985 Alternativo): Sobre el año 2008, cuando arrancó la comunidad de Fase Bonus, se comenzó a hablar e intercambiar ideas para poder aportar algo a la escena homebrew, especialmente la española. Existían proyectos y bastante movimiento, pero desgraciadamente la desorganización hacía que embarcarse en proyectos relacionados con consolas, por ejemplo, se hiciese realmente complicado. Más que por la cantidad de desarrolladores y herramientas, por el problema económico que supone afrontar este tipo de proyectos.

Tardamos unos tres años en planificar todo y mover los contactos necesarios para establecer lo que finalmente sería 1985 Alternativo. Finalmente en 2012 pudimos arrancar, asomando tímidamente la cabeza para ver cómo estaba el panorama y comprobando gratamente que la acogida iba a ser estupenda.

¿Como empieza la idea de crear de videojuegos para consolas antiguas?

Amador (El mono respondedor de los Mojon Twins): De los apios. Empezamos cultivando alcachofas de lunares pero de vez en cuando iba y nos crecía un apio. Así, por las buenas. Luego nos daba pena y lo dejábamos estar. Al final todo se llenó de apios. Había tanto que las alcachofas dejaron de crecer y eso nos dejó en la ruina. Teníamos que pensar en otra cosa, pero no se nos ocurría nada. Días más tarde, al caer la noche, estábamos sentados en el porche viendo al viento mover las hojas de los apios… Y de ahí surgió todo. Apio, via Apia, Roma, viejuno, consolas viejunas, hacer juegos… Fue un flashazo. Y ahí empezamos.

También por el hecho de querer superarnos. Tras años con los ordenadores de 8 bits, dijimos: ¿hay huevos? Y los hubo y conseguimos hacer Sir Ababol para NES.

He oído que tenéis varios juegos, ¿nos puedes decir cuales son?

Amador (El mono respondedor de los Mojon Twins): Sí, tenemos varios. Así, de cabeza, me acuerdo de Phantomas Tales #1: Marsport,Nanako Descends to Hell, Nanako in Classic Japanese Monster Castle v.2, Biniax 2,Platformer Medley Block #1, Subacuatic, Subacuatic Reloaded, Sgt. Helmet Zero, Uwol Quest for Money, Lala Prologue Cheril of the Bosque, Viaje al Centro de la Napia, Moggy Adventure, Sir Ababol, Cheril Perils, Zombie Calavera Prologue, Petulant Poogslay Powerful Parade, Robore, Uwol 2, Nanako in Classic Japanese Monster Castle ’81 (ZX81), Fundamentally Loathsome (Playable Sgrizam Crapvaganza), Horace Goes to the Tower, Trabajo Basura (Dire Job), Phantomas Tales #4: Severin Sewers, Mojon Twins Covertape, Maritrini – Freelance Monster Slayer, Uwol Quest For Money ZX81, Phantomas en el Museo, Maritrini Freelance Monster Slayer en «Las increíbles vicisitudes de despertarse resacosa con Fred en la cama y tener que llegar más o menos puntual a la prueba de “Monstruos Vigorosos de Pechos Lustrosos”» featuring Los Fratelli, Cheril Da Goddess, Super Refried Gun Operation, Lala Prologue MS-DOS, El Hobbit (Vah-ka’s Cut), Ramiro El Vampiro, Sir Ababol NES, Mojon Twins Covertape #2, Ubhres Productions 2013, Sgt. Helmet Training Day, Cadàveriön, Tenebra Macabre, Goku Mal, Sgt. Helmet Training Day NES, Ninjajar!, Leovigildo ¿pero qué haces, Leovigildo? ¡¡Leovigildo!!, Sir Ababol 2, Sir Ababol DX y Jet-Paco NES. La verdad es que en estos años hemos hecho unos cuantos, principalmente para ZX Spectrum, pero también para ZX81, Amstrad CPC, PC/DOS, y NES. Y ahora preparamos algo para Megadrive y otra cosita para Mega CD.

¿Alguna anécdota sobre ellos?

Amador (El mono respondedor de los Mojon Twins): La historia de Leovigildo es 100% real. La de Ninjajar! también, pero cambiamos los nombres. La de Ramiro es mentira, porque todos saben que los vampiros no existen. Es una fantasía.

Prácticamente hay unas 100 anécdotas de cada juego, pero así una en general… casi te podemos decir que las mejores anécdotas surgen con juegos que no hemos acabado haciendo. Como el famoso juego PODEWWWR!!! que tiene como 20 páginas de ideas, chistes y chorradas que hicieron que estuviéramos una semana sin hacer nada más que reírnos. Al final, el juego no se ha hecho, pero fuimos felices una semana.

¿Como se llega a pensar en este juego?

Amador (El mono respondedor de los Mojon Twins): A principios de 2013 queríamos sacar nuestro framework para desarrollar juegos para ZX Spectrum y teníamos que probar todas combinaciones de características y motores. De ahí surgió la Covertape #2. Jet Paco es uno de esos juegos, programado para probar el motor de jet-pac (de ahí el nombre).

¿Qué juego os sirvió de inspiración?

Amador (El mono respondedor de los Mojon Twins): Ninguno, que yo sepa. Nos han comentado que el Cybernoid se juega así, pero la verdad es que ninguno lo hemos probado nunca. Habrá que echarle un tiento. También un poco la coña con Jet Pac. Paco es más atractivo para el público extranjero.

Me ha sorprendido que hayáis usado mi provincia natal (Badajoz), de hecho le dais un sistema y un imperio. Personalmente me hizo tanta gracia que por eso lo compre ¿Cómo se os ocurrió?

Amador (El mono respondedor de los Mojon Twins): Todos nuestros juegos están ambientados en la Provincia de Badajoz, bajo la provincia de Badajoz, o en el espacio exterior de la provincia de Badajoz, en el pasado, presente o futuro. No es cuestión de ocurrencias, es que simplemente allí pasan cantidad de cosas. También es el centro exacto de la recta que une Zaragoza, Madrid, Sevilla y Murcia, nuestros lugares de vivienda actual.

¿Cuanto tiempo os llevo programarlo?

Amador (El mono respondedor de los Mojon Twins): El juego usa una ampliación del motor de Sgt. Helmet Training Day que tardó en hacerse aproximadamente 15 minutos (la gravedad y la habilidad de volar). El diseño de la fase 1 bebe mucho de la versión original de Spectrum, que se convirtió rápidamente. La fase 2 tardó más en hacerse por diversos padrastros. Estuvimos haciendo un montón de cambios de última hora y al final se alargó un poquillo más de la cuenta. Y cuando todo parecía que estaba finiquitado, a alguien se le ocurrió la genial idea de meter una fase-huevo-de-pascua-levemente-oculta más y… bueno, pues eso

Sgt. Helmet Training Day fue escrito desde cero basándose en la Churrera de Spectrum durante el transcurso de tres tardes en Navidades de 2013.

¿Y preparar la música y los FX?

Amador (El mono respondedor de los Mojon Twins): Eso son cosas de David Murciano Sánchez, cosas que sólo él sabe. Le pides algo y en 10 minutos lo tienes, no sabes cómo, pero lo tienes. Y encima es perfecto.

¿Es más complicado o menos que otros juegos que hayáis hecho?

Amador (El mono respondedor de los Mojon Twins): De programar, no. Lleva una colisión muy chula y eficiente que ha permitido meter tres fases completas junto con el motor y la música en algo menos de 32K. Y eso mola. De jugar, pues sí. Necesita buen pulso, no es tan asequible como otros de nuestros juegos.

¿Que programas o utilidades habéis usado para llevarlo a cabo?

Amador (El mono respondedor de los Mojon Twins): Solemos escribir nuestros propios conversores y utilidades. Aunque no es tan completo como nuestro framework para Spectrum, MK2, el conjunto de utilidades que hemos escrito para desarrollar con NES facilita mucho el trabajo. Aparte de eso, con Mappy para hacer los mapas, y Photoshop para los gráficos.

Cuando se muere, dice que NO BANANA, ¿es una referencia a los Minions?

Amador (El mono respondedor de los Mojon Twins): ¿Qué son los minions? Cuando muere dice «nice try but no banana», o «buen intento, pero no hay plátano». Es un dicho de algunas partes de U.S.A. que se popularizó hace unos quince años en ciertos foros de programación donde había mucha verdura. Se refería a «no, no cuela», para cachondearse un poco del «rival» en la discusión. Siempre nos hizo mucha gracia. Además, como supuestamente se le dice a un mono, como que pegaba más.

En realidad era para hacer la gracia en Sgt. Helmet: Training Day. Pensábamos cambiarlo para Jet Paco pero, y esto es totalmente cierto, se nos olvidó.

¿Os veis un día con un juego de alto presupuesto para una consola o PC?

Amador (El mono respondedor de los Mojon Twins): No. Eso es un trabajo… y no es nada divertido, la verdad.

¿Qué SDK usáis? ¿Está bien documentado?

Amador (El mono respondedor de los Mojon Twins): Para los juegos de NES usamos el compilador cc65 y la Neslib de Shiru. La Neslib no es más que una biblioteca bastante escueta que abstrae levemente las operaciones con el hardware de la NES. Y digo «abstrae levemente» porque lo único que hace es ofrecer una interfaz cómoda al hardware, sin poner realmente una capa de abstracción real. Eso es genial en un sistema tan sencillo y limitado como la NES. Una de las cosas que trae es una rutina de gestión de la NMI (la interrupción que se ejecuta cada cuadro de juego y que sirve para controlar como se envían las cosas a la PPU, por ejemplo) muy «barebones» que permite ampliarla y adaptarla a tus necesidades. No se puede hacer una biblioteca compleja de propósito general para un sistema como la NES. Por eso Shiru ha hecho la biblioteca perfecta: la que trae lo mínimo para conseguir eliminar el tedio de estar escribiendo valores en registros pero no pone trabas para hacerlo de forma integrada si es necesario.

Y además puedes importar música y efectos del Famitracker… ¿se puede pedir más?

La documentación es poca pero suficiente. En la web de Shiru desde donde puedes bajar la Neslib tienes un breve tutorial con lo básico. Además tienes código fuente de ejemplo con casi todas las cosas que hace la biblioteca, e incluso un juego completo (Chase).

He visto que el juego no tiene scroll, saves, doble player ni otras cosas, ¿ha sido porque os pilla novatos, porque el SDK no da para más, o porque la complicación se multiplica?

Amador (El mono respondedor de los Mojon Twins): Esta pregunta tiene muchas partes:

Primero de todo, este es nuestro tercer juego para NES, con otros dos más en desarrollo. Nuestro primer juego para NES, Sir Ababol, tiene scroll horizontal. La razón por la que Jet Paco no lo tenga es porque está diseñado para ser por pantallas. Si lo piensas, el juego tendría que ser bastante diferente si se plantease con scroll horizontal.

El tema de poder jugar a dobles tampoco tiene sentido en un juego así. Tampoco hay que olvidar que Jet Paco es un port ampliado de un juego que ya publicamos en ZX Spectrum a principios de 2013. No consideramos importante añadir un modo de dos jugadores porque entonces habría que rediseñar el juego para darle otros objetivos.

Implementar saves es otra historia completamente diferente. Como probablemente sabrás, la NES es una consola muy limitada. Por diseño, los cartuchos pueden tener hasta 8K de RAM, 32K de ROM, y 8K de CHR-ROM (patrones usados para pintar fondos y sprites), y nada más. Además, tiene «fijado» el tipo de mirroring de la memoria de tiles de la VRAM, algo que influye directamente en el tipo de scroll que puedes hacer: si el cartucho tiene fijado el mirroring horizontal sólo puedes hacer «sin glitches» un scroll vertical, y viceversa. No puede cambiarse. Si quieres algo más, necesitas añadir circuitería en los cartuchos: un «mapper», que se encarga del comportamiento general de dicha circuitería, y todo lo que necesites de más: más VRAM para tiles para no tener que depender de un mirroring, más ROM paginada para tener más información en el cartucho, RAM, SRAM para partidas grabadas, chips de sonido para mejores músicas, chips gráficos que pre-calculen cosas para tener más planos de scroll…

Hacer un juego con saves implica usar un mapper que soporte saves y el hardware necesario para implementarlo todo. Para nuestro primer juego en formato físico, hemos decidido optar por la opción más sencilla y no emplear mappers. Es lo que se llama «NROM256»: 32K de ROM, 8K de CHR-ROM. Por eso se trata de un juego sencillo y de aspecto más humilde, parecido a los primeros lanzamientos de Nintendo para su consola.

Por supuesto que la complicación se multiplica si quieres implementar juegos que empleen mappers (por ejemplo para implementar Saves, o para tener mejores gráficos, o para poder cambiar el «mirroring» al vuelo). Primeramente, cc65 no soporta mappers, ya que hay docenas de mappers diferentes (de los conocidos) que hacen millones de cosas. cc65 sólo te permite definir zonas de memoria en las que introducir datos fijos (ROM) o usar para variables (RAM). Cualquier otra cosa te la tienes que currar, como nosotros decimos, «engañando al chamán». Por otro lado, Neslib está pensada para juegos NROM muy sencillos. Por suerte, Shiru lo ha hecho estupendamente y la rutina de gestión de NMI es muy fácil de multiplicar, y cc65 además nos permite reservar zonas de memoria en cualquier sitio donde introducir «nuestras trampas».

La NES «pelada» es bastante jodida. La PPU se encarga de generar la imagen en el televisor leyendo una parte de la VRAM, los patrones en CHR-ROM, la posición de los sprites y sus características en la tabla de sprites, y se gobierta por un conjunto de registros internos. El problema es que mientras está generando la imagen (mientras está enviando información a la tele mientras esta mueve el rayo de electrones recorriendo la pantalla) no se le puede tocar nada, o se vuelve tó loca. ¿Qué significa esto? que el único momento en el que podemos cambiar las cosas (mover sprites, modificar el fondo, cambiar los registros de scroll) es durante el leve intervalo en el que la PPU no está dibujando la imagen. ¿Cuándo es eso? pues en el tiempo en el que el rayo de electrones ha llegado al final de la pantalla y la PPU se espera a que se recoloque de nuevo al principio del todo para empezar el siguiente cuadro. Ese período de tiempo (cortísimo) se llama VBLANK.

Cuando la PPU termina de pintar la pantalla genera una NMI. La rutina de gestión de NMI se ejecuta justo entonces y se encarga de, lo más rápido posible, actualizar todo lo relacionado con la imagen antes de que «nos coja el toro» y se empiece a dibujar el siguiente cuadro. Aquí se mueven los sprites, se mandan tiles al fondo, se actualizan los registros de scroll, se lee el mando, y se actualiza la música. Son muchas cosas que hacer para tan poco tiempo.

Esto es lo jodido y bonito de programar una NES.

Para hacer un scroll, sólo puedes modificar esa rutina de gestión de NMI que tan bien ha organizado Shiru para cambiar la posición del scroll y actualizar una tira de tiles al borde de la pantalla. No da tiempo a más, literalmente. Para hacer un juego con scroll hay que diseñarlo específicamente para ello, usando mil trucos. No tiene nada que ver con el desarrollo de juegos con scroll en sistemas más modernos con toneladas de RAM que puede accederse en cualquier momento. Básicamente lo que hay es lo que se ve en la pantalla, no hay mucho más, y hay que diseñar todo acorde a estas limitaciones.

Actualmente tenemos en desarrollo dos nuevos títulos. Uno de ellos comparte gran parte de motor con JetPaco, pero es un arcade de plataformas con saltos: una versión de Cheril Perils que también saldrá para Megadrive. El otro, nuestro proyecto secreto, emplea un mapper sencillo, GNROM, que habrá que resolver cómo fabricar físicamente, y que permite alternar entre cuatro bancos de PRG-ROM de 32K (un total de 128K) y otros cuatro de CHR-ROM de 8K (32K de gráficos). Además tiene scroll y mucha acción. Es un juego diferente.

Y ahora llegamos al proceso de pasarlo a modo físico… ¿cómo se os ocurre esto?

Albert (1985 Alternativo): El placer de recibir un juego, abrirlo como antaño y obligarte a conectar la consola o el ordenador, es algo que no tiene precio. Nos encanta disfrutar de esos detalles y hacer que el máximo número de compañeros posibles lo disfruten con nosotros.

¿Qué más juegos habéis pasado a formato físico?

Albert (1985 Alternativo):  Ya llevamos bastantes: Watman (adaptación del Batman de Ritman) y Another World para Game Boy Advance, Oh Mummy Genesis, Uwol: Quest for Money y Suprakillminds para Mega Drive, Alter Ego, Uwol, Goku Mal y Leovigildo para Spectrum, Uwol 2 para Amstrad…

Podéis ver un listado completo en nuestra web.

¿Creéis que podréis un día vivir de esto?

Albert (1985 Alternativo): Con el apoyo que estamos recibiendo actualmente por parte de la comunidad y haciendo las cosas de otra manera, sí podría ser factible. Sin embargo si cambiamos nuestra manera de hacer las cosas, el proyecto cambiaría drásticamente y una parte de él moriría. Por ello preferimos seguir tomándolo como lo que es, una sana afición, y continuar invirtiendo todo en hacer más cosas que nos diviertan.

En el proyecto decís que tenéis un molde para NES, ¿nos puedes explicar qué es y para que funciona?

Albert (1985 Alternativo): Sí, hemos preparado nuestro propio molde de NES. Básicamente es un molde de inyección de plástico para poder preparar nuestras propias carcasas para la consola. Los moldes son una de las trabas económicas más grandes que nos encontramos, ya que su precio es muy elevado, y tenemos que valorar siempre como amortizarlo con el tiempo para poder embarcarnos en otros sistemas.

La placa que usáis se llama mojo-NES, ¿no creéis que es un poco desafortunado?

Albert (1985 Alternativo): Así fueron bautizadas por su padre, el compañero Doragasu. Y a todo el equipo nos encantó el nombre. Este detalle es un claro ejemplo que diferencia el hacer las cosas para intentar vivir de ello o hacerlas sin ánimo de lucro. Tenemos la libertad de poder hacer lo que nos haga gracia, aunque comercialmente no sea lo más inteligente.

En cualquier caso esta idea surgió para intentar adaptar alguno de los juegos de los Mojon Twins a la consola NES, así que es un nombre muy apropiado. Por otro lado, a pesar de sonar así, estas son las mejores placas que hemos preparado nunca con diferencia. Doragasu ha preparado un diseño estupendo y no se ha escatimado en componentes. Siempre hemos intentado ofrecer los productos de la manera más económica posible, pero bastantes compañeros nos llevan tiempo diciendo que prefieren pagar más por tener productos de mayor calidad, y les hemos escuchado.

¿Podéis contar algún plan que tengáis en mente?

Albert (1985 Alternativo): Actualmente estamos trabajando en una veintena de proyectos interesantes de todo tipo. En cuanto a NES, es la primera vez que tocamos la consola, por lo que ha sido perfecto empezar con una campaña de crowdfunding para valorar el interés. Si hay suficiente es probable que aparezcan más juegos y podamos ir mejorando todo.

Este proyecto viene apoyado por fasebonus, ¿como ha sido apoyarlo?

Ignacio (Fase Bonus): Como Fase Bonus, no es que se apoye a 1985 Alternativo, es que casi se podría decir que son lo mismo, ya que muchos de sus componentes forman parte del conjunto.

Yo definiría más que apoyo, la creación, y en este punto me gustaría dejar claro que todo esto salió de cero y sin ayuda exterior. Ha sido y continúa siendo una aventura continua, esto de meterse en nuevos proyectos y en la creación de juegos para máquinas que nunca se habían tocado en España, aunque toque ir aprendiendo muchas cosas sobre la marcha.

Y ahora hablanos algo de nosotros, ¿a qué os dedicáis cuando no estáis con juegos antiguos?

Albert (1985 Alternativo): Por supuesto cada uno de nosotros tiene sus obligaciones y sus empleos, algunos guardan más relación con estos temas mientras que otros no tienen nada que ver. ¡En el fondo somos gente bastante normal!

¿Cómo veis el mercado actual de los videojuegos?

Albert (1985 Alternativo): Actualmente existen videojuegos con una factura técnica increíble. Sin embargo, en el momento en el que uno coge su vieja consola y conecta cualquier cartucho, pudiéndoselo pasar igual de bien o incluso más que con las últimas novedades, tal vez haya que plantearse si estamos obligados a recorrer este camino.

Las consolas y los ordenadores son cada día más potentes, pero para sacarles un mínimo rendimiento que justifique el salto generacional de cara al usuario, las compañías deben embarcarse en inversiones multimillonarias, haciendo uso de personal artísticamente castrado que en muchas ocasiones ni siquiera sabe si seguirá conservando su empleo una vez finalizado el proyecto. Compañías gigantescas que para poder seguir creciendo devoran a otras más pequeñas, independientemente de las consecuencias. Parece que aquellos tiempos en los que los juegos se hacían con equipos más reducidos que verdaderamente ponían todo su cariño se van quedando atrás.

¿Llegará el día donde no haya físico?

Albert (1985 Alternativo): Todo apunta a que vamos por ese camino. Lo vemos a diario. ¡Qué cómodo es descargarse un juego cómodamente desde casa, nada más salir al mercado! Y qué cómodo es también para las compañías poder ir vendiéndonoslo fraccionado, directamente sin terminar o incluso con errores, que se subsanarán una vez comercializado.

Sin embargo, mientras queden usuarios de nuestras generaciones, siempre habrá quién intente rellenar aquel hueco intentando alimentar plataformas que comercialmente ya no interesan ni a sus propios creadores, independientemente de que se haga a un nivel minoritario.

Aunque las grandes compañías se olviden de este tipo de jugador, “el de toda la vida”, los propios usuarios no lo harán fácilmente.

¿No creéis que se ha masificado el mercado del videojuego mientras que no ha crecido tanto los usuarios? Por tal cada vez más habrá más gente que le guste lo retro, o lo nuevo.

Albert (1985 Alternativo): En primer lugar habría que preguntarse si todo esto del retro es una moda. ¿Lo es? Puede estar de moda, pero seguramente es una moda que ha venido para quedarse. Porque en el momento en el que conectas un antiguo cartucho para la NES y lo disfrutas como hacías años, o incluso pasas un buen rato aún cuando ni siquiera conociste el juego en su momento (sin estar influenciado por el factor nostálgico), quizás es porque realmente divierte. Sin más complicaciones.

¿Acaso una pintura de hace 500 años deja de ser una obra de arte por haber quedado obsoleta? Por supuesto que no. Todo lo contrario, nos permite tener una visión global de la época en la que fue concebido, de las herramientas que se utilizaban en aquel entonces… No hay diferencia, salvo para aquellos que todavía piensen que los videojuegos no son más que un mero pasatiempo. Todo se resume en si nosotros mismos valoramos los videojuegos como lo que realmente son.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.