Takayuki “Jemini” Hirono – Diseñador
—Has estado usando el nombre “Jemini Hiroshi” desde tus primeros días en Compile.
Hirono: Todos los desarrolladores de Compile utilizaron sus nombres de entradas de partituras arcade, como PAC, Moo, etc. Adopté Gemini (que significa gemelo) porque me gustaba su sonido, pero los japoneses probablemente pronunciaban mal la G dura, así que la cambié a “Jemini”. También me gustó cómo tenía la palabra “gem”.
—Cuéntanos cómo te involucraste en la industria de los juegos.
Hirono: Me interesaban las computadoras desde que las computadoras personales (“pasokon” y “maikon”, como se las llamaba en japonés) estuvieron disponibles por primera vez en el mercado. Pero entonces eran muy caros, así que por un tiempo sólo pude admirarlos desde lejos y ocasionalmente meterme con los modelos de piso en las tiendas. En ese momento, en Hiroshima, las tiendas de renombre tenían “esquinas de computadora”, y allí era libre de usar las máquinas. Tenían todos los modelos más nuevos alineados y todos los llamados “Nai-kon kids”
se reunía allí para jugar con las computadoras todo el día. Era un semillero de emoción y entusiasmo, como sólo se ve al comienzo de cosas nuevas. Todas las ciudades de Japón tenían una tienda como ésta en aquel entonces.
Compré mi propia computadora en 1981, una PC-8001 (el precio había bajado un poco) con una expansión de RAM de 16 kb. Para los juegos, al principio simplemente copié sin pensar el código que estaba impreso en las revistas, sin saber realmente lo que estaba haciendo, pero después de 3 o 4 meses, de repente me di cuenta, “Espera, así es como se hacen los juegos de computadora…?” Por supuesto, no comencé a crear mis propios juegos. Comencé mejorando el código de otras personas y poco a poco aprendí por mi cuenta a programar—. El primer juego que hice fue el típico juego “snake”.
Entonces seguí haciendo cosas en BASIC por un tiempo, pero un día alguien se burló de mis programas por estar escritos en BASIC. “Qué idiota,” pensé para mis adentros, pero aun así intenté estudiar este libro en lenguaje de máquina que tenía. Tuve que intentar leerlo antes y no pude entender ni una pizca, pero por alguna razón misteriosa, esta vez lo entendí. Supongo que la gente realmente tiene un potencial ilimitado, como dicen. (risas) Después de eso, poco a poco comencé a aprender programación más complicada y completé mi propio juego original, Monster Panic. Lo envié a la revista I/O y lo publicaron en uno de sus números complementarios. Esta fue la única vez, antes o después, que se publicó alguna de mis presentaciones. Satoshi “PAC” Fujishima, un colega con el que trabajé más tarde en Compile, ya era famoso por sus numerosas presentaciones a estas revistas, publicadas bajo su seudónimo Pakkuman.
Además de las tiendas de renombre en Hiroshima, también había lugares como Matsumoto Musen y Auburn Denshi, tiendas dedicadas a la venta de ordenadores, que también se convirtieron en lugares de reunión para los aficionados interesados. Masamitsu Niitani, quien más tarde fundó Compile, en realidad trabajaba en Auburn Denshi. Cada una de estas tiendas tenía sus diferentes clientes habituales, pero Fujishima solía ir mucho a Auburn Denshi. Mi principal refugio eran las grandes tiendas minoristas, pero también visité los lugares más pequeños. Recuerdo que una vez hablé con este tipo en Auburn Denshi y dije “. Escuché que el propio Pakkuman vive en Hiroshima,” y respondió: “. Sí, ¡ese es él ahí mismo!” (risas) Así fue como conocí a Fujishima.
De todos modos, en 1982 se fundó Compile y comenzaron a explorar personas de la zona, viendo si alguien estaba interesado en probar suerte en un trabajo a tiempo parcial haciendo juegos. Fujishima y yo aprovechamos la oportunidad y portamos Tranquilizer Gun al SC-3000/SG-1000, como “Safari Hunting”. Hice la programación y Fujishima hizo el pixel art. Ahora ¿cuál de nosotros hizo el sonido…? No lo recuerdo del todo.
—El SC-3000 usó el mismo chip z80 que el PC-8001, así que imagino que fue relativamente fácil de portar, pero ¿tuviste problemas con el chip de sonido dedicado de la consola o la falta de soporte de sprites de hardware?
Hirono: Al principio simplemente usábamos el chip de sonido sin saber lo que estábamos haciendo. En cuanto al chip z80… al principio, no tenía un ensamblador para compilar el código. Entonces, sin saber qué más hacer, saqué un bloc de notas y escribí laboriosamente el código en hexadecimal (simulando cómo actuaría en mi cabeza), y luego, después de llegar a cierto punto, escribía ese código a mano. ensamblador codificado, como lo llamaban. Los programas todavía eran muy pequeños en aquel entonces, por lo que no era tan doloroso como parece. Después de Safari Hunting, finalmente obtuvimos un compilador real y codificamos en el lenguaje ensamblador adecuado.
La primera computadora que utilicé en aquellos primeros días para codificar los juegos SC-3000/SG-1000 fue esta enorme máquina equipada con una unidad de disquete “Mr Logic” de 8 pulgadas. Tenía un emulador en circuito (ICE), que creo que podría usarse para depurar la CPU SG-1000. Sin embargo, solo teníamos una de estas computadoras, por lo que al principio todos primero codificaban en sus propias computadoras personales y luego la transferían a través de la unidad de disquete Mr. Logic. Posteriormente utilizamos el emulador NICE-Z80, que era más económico y podía conectarse a un ordenador personal normal. Eso fue lo que más usamos. Creo que terminamos teniendo entre 6 y 7 unidades en la oficina. Para nuestro desarrollo de MSX también utilizamos inicialmente una placa de desarrollo de MSX con una unidad NICE-Z80 adjunta.
Para mi ambiente de trabajo personal, después del PC-8001, ¿creo que usé un Sharp MZ? Mi memoria es un poco inestable allí, pero como recompensa por completar Safari Hunting, compré una FM-NEW7, una tarjeta z80 y una unidad de disco de 5 pulgadas, que usé durante mucho tiempo, ejecutando el disquete CP/M. unidad de sistema operativo. Creo que usé eso hasta el desarrollo de Lunar Ball.
En ese momento trabajaba en Denden Kousha y el trabajo a tiempo parcial en Compile era un segundo trabajo para mí. En gran parte por esa razón, mi siguiente juego, C-SO!, no salió tan bien. Solía ir en bicicleta a las oficinas de Compile después del trabajo, cincelar el código allí por un tiempo y finalmente regresar a casa a altas horas de la noche. Seguí así por un tiempo y finalmente tardé unos 2 años en terminarlo. Cuando lo terminé, me había convertido en empleado de tiempo completo en Compile.
—En el lapso de tiempo entre Safari Hunting y C-SO!, Compile lanzó varios otros juegos. ¿Estuviste involucrado en eso en algún grado particular?
Hirono: Me hablaron de ellos y hice algunas pruebas de juego, pero eso fue todo. Aunque en algún momento me involucré en la programación de sonido, creo que probablemente haya algunos en los que trabajé en esa capacidad.
—¿Cómo terminaste entrando en la programación de sonido?
Hirono: Existía una técnica clásica para hacer música en el PC-8001 controlando el encendido/apagado del sonido del altavoz del PC (bip). El sonido es un elemento indispensable para hacer un videojuego, así que cuando aprendí lenguaje de máquina, intenté aprender esa técnica de programación. Tenías que detener la pantalla si querías reproducir la música limpiamente… había grandes limitaciones como esa, pero en Sharp MZ y PC-6001 que compré más tarde, fue mucho más fácil y me divertí creando más música. sonidos en esas máquinas.
Al poco tiempo, tuve la oportunidad de trabajar con los controladores de sonido SC-3000/SG-1000 de Sega. Los analicé, modificando el código hasta que finalmente pude portarlos para usarlos en MSX. Después de eso, poco a poco comencé a que me asignaran más trabajo de sonido hasta que básicamente me convertí en el controlador de sonido de Compile. Nunca tuve ninguna formación musical y, para ser honesto, probablemente hubiera sido mejor si hubiera podido pasarle el testigo a alguien que fuera más especialista en sonido que yo, pero tampoco había nadie. ¡Quién dio un paso al frente para el trabajo tampoco! Técnicamente, cuando estábamos haciendo Musha Aleste, alguien más hacía la programación de sonido, pero lamentablemente lo dejaron poco después. Ah, y los controladores de sonido PC-9801 también fueron escritos por otra persona.
En los primeros días, los compositores de sonido tenían las manos ocupadas escribiendo la música, por lo que yo mismo creaba los efectos de sonido. De hecho, en casi todos los primeros juegos de Compile, incluido Zanac, los efectos de sonido los hacía yo.
Para nuestro entorno de desarrollo de sonido, creé un editor de sonido que se ejecutaba en MSX-BASIC y secuenciamos la música allí. El controlador de sonido en sí estaba escrito en ensamblador y se ejecutaba en segundo plano con la interfaz BASIC. Ingresaste notas en el familiar formato “MML”. Independientemente de los controladores de sonido particulares de una consola, compartían un formato de datos de secuenciación casi idéntico, por lo que también podía escribir música para Famicom en MSX. Por supuesto, el hardware de sonido de Famicom tenía un sonido diferente al MSX PSG, por lo que los ajustes finales y el ajuste siempre se realizarían en la consola de destino.
A petición de composers’, finalmente agregué muchas características diferentes a los controladores. Más tarde, alguien también creó un conversor de MIDI a TXT, que permitía reproducir archivos MIDI en un formato que nuestro controlador de sonido pudiera entender. En comparación con el resto de la industria, creo que fuimos una de las primeras empresas en tener ese tipo de funciones de sonido disponibles.
—Con Lunar Ball, comenzaste a programar para Famicom. ¿Las diferencias en la CPU dificultaron la transición?
Hirono: Tenía un Commodore VIC-1001 (que compartía el chip Famicom 6502), así que estaba bien allí. Anteriormente había programado una demostración simple para el VIC-1001, nuevamente usando un ensamblador codificado a mano, y resultó ser una buena práctica. Pero no teníamos mucha documentación para Famicom. Sólo teníamos un libro sobre el ensamblaje del 6502 (escrito para ingenieros) y recuerdo que algunos de los ejemplos eran terriblemente difíciles de entender. En cualquier caso, no creo que me pusieran a cargo de la programación de Famicom debido a mi experiencia previa con el VIC… fue más bien que, basándose simplemente en la antigüedad en Compile, ahora era mi turno de liderar un equipo.
Para el desarrollo de Lunar Ball, utilizamos una máquina de desarrollo dedicada que nos regaló Nintendo llamada PROS80. Estaba conectado a esta caja que parecía un bento blanco y albergaba el uso de desarrollo Famicom, al que transmitíamos nuestros programas directamente. El teclado era realmente pequeño y difícil de escribir, así que creo que primero hicimos gran parte de la codificación fuente en un FM-7 y luego transferimos los archivos a través de una unidad de disquete de 5 pulgadas que habíamos conectado a él.
Cuando estábamos fabricando Zanac, salió el modelo sucesor PROS86. Tenía prácticamente las mismas características. También estuvo el PROS80F que vino después de eso, pero no todos podían usar mega ROM. El dispositivo oficial de Nintendo que se suponía que admitía mega ROM finalmente nunca llegó, por lo que más tarde usamos un DICE-6502 (un ICE que podía conectarse a una computadora normal). En cuanto a otro hardware de desarrollo oficial, para diseñar pixel art conectamos un digitalizador a un Fujitsu FMR.
—El siguiente juego en el que trabajaste como desarrollador principal fue Zanac para MSX.
Hirono: Fue Masamitsu Niitani quien supervisó el proyecto en su conjunto. No creo que haya tenido mucha participación directa en el desarrollo del juego, pero él es quien fue responsable de guiarlo hasta la línea de meta. El pixel art fue realizado por Koji “JANUS” Teramoto, y Masatomo Miyamoto hizo la música. La versión Famicom también fue desarrollada por casi el mismo equipo.
—En el folleto de instrucciones, hay una nota que dice “Este juego tardó más de tres años en Make”. Parece que el desarrollo tenía un camino largo y sinuoso…?
Hirono: En realidad, no sé exactamente cómo ni en qué circunstancias comenzó el proyecto Zanac. Había un desarrollador que había realizado una codificación inicial y por alguna razón no pudo continuar, y fue entonces cuando Fujishima asumió las riendas. Sinceramente, Fujishima es una especie de genio, así que de inmediato entró y agregó la mecánica basada en el aire: eso incluía el sistema de encendido donde se recolectan los chips de energía, y creo que también había agregado los Landers. Había escrito notas detalladas sobre ellos en sus documentos de planificación, pero no decía nada acerca de dispararles para que se pusieran rojos. Eso fue algo que agregué por mi cuenta, y como Fujishima no se enojó ni dijo nada, ¡supongo que estuvo de acuerdo! (risas)
En ese momento empezaba a parecer un juego real, pero por varias razones, Fujishima acabó teniendo que trabajar en otro proyecto, así que me llamaron a la acción. Creé el resto del juego, las características del terreno y los enemigos, los jefes y todas las armas especiales (armas secundarias). También agregué los enemigos voladores adicionales para la versión Famicom.
Así que sí, déjame contarte más, empezando por las armas especiales. Cuando heredé el proyecto, tu nave tenía cuatro tipos diferentes de tomas. Los primeros tres eran formas diferentes del disparo estándar (que tiene tres grados a medida que lo enciendes), y el cuarto disparo fue un disparo estilo torpedo que se disparaba de forma intermitente. Sospecho que el disparo del torpedo fue pensado originalmente como un ataque aire-tierra, pero como tu disparo normal podía destruir enemigos tanto aéreos como terrestres, ahora parecía un poco inútil.
Así que pude pensar en qué armas diferentes y extrañas podría agregar y, si era posible, quería agregar una gran variedad. En mi opinión, era una especie de fan service para los jugadores tener tantas tomas diferentes. Así que seguí agregando uno tras otro y finalmente llegué al sistema de armas secundarias que ves hoy. Por cierto, las diferentes armas secundarias de la versión MSX se distinguen por diferentes colores, pero ahora desearía poder volver atrás y preguntarme si no había una manera un poco mejor. (risas) Como mínimo debería haber usado colores más fáciles de distinguir.
La mayoría de los sprites del terreno se habían terminado antes de que yo tomara el control, pero esos sprites se habían dispuesto uno por uno en simples mapas de mosaicos para formar los niveles. Sabía que hacer los mapas de esta manera ocuparía demasiada memoria y prohibiría cualquier nivel expansivo, así que reescribí por completo el sistema de mapeo del terreno. Decidí apropiarme del método que habíamos utilizado para generar las funciones en el aire: en lugar de colocar el terreno en un mapa de mosaicos, se generaría mediante un script algorítmico. Tomemos, por ejemplo, el terreno de la primera etapa, que tiene duendes forestales con un río que pasa por el medio. Todo lo que el algoritmo tendría que hacer para generar ese terreno era delinear los puntos límite (en lugar de mapearlos individualmente a mano). Luego, el área dentro de los límites se completaría automáticamente con los sprites apropiados. Era un poco monótono, pero permitía que los mapas evolucionaran con el tiempo y fueran muy expansivos.
—Sí, fue sorprendente lo grandes que eran, incluso demasiado grandes para publicarlos en guías de estrategia.
Hirono: Los mapas más largos significaban que también había que desplazarlos a mayor velocidad, así que lo hicimos rápido. El MSX solo podía desplazarse en incrementos de 8 píxeles, por lo que el desplazamiento más lento parecía muy entrecortado, pero si ibas lo suficientemente rápido parecía fluido, y esa era otra consideración en mente para Zanac.
La forma en que el desplazamiento se detendrá ocasionalmente cuando luches contra un jefe, parte de eso fue la influencia de Xevious, como puedes imaginar. Pero la forma en que los jefes se componen de partes individuales que destruyes, en realidad se inspiró en Exed Exes. También tenía la intención de que los jefes murieran en una explosión limpia y agradable, con sus partes volando en la explosión. Pude lograrlo en la versión MSX, pero resultó imposible replicarlo en Famicom, así que finalmente tomé la decisión (para ambas versiones) de que las ruinas del jefe permanecieran así en pantalla después de ser derrotadas. Creo que este enfoque tiene además su propio atractivo.
Por cierto, en las primeras etapas de su desarrollo, Zanac tenía un nombre diferente, Le Colonium.
Más adelante en el desarrollo se cambió a “AI” Supongo que por ese título, los desarrolladores pensaron “oye, ya sabes, ya que se llama AI, ¿crees que deberíamos instalar algún tipo de sistema de inteligencia artificial?” Y luego, cuando Fujishima se unió al desarrollo, fue cuando se agregó el sistema “Automatic Level Control”, o “ALC”. El nivel enemigo seguiría aumentando dependiendo de la cantidad de enemigos que hayas destruido, la cantidad de enemigos que dejes escapar, la cantidad de disparos que hayas realizado, etc. En este sentido, se sentía como un sistema de inteligencia artificial, pero creo que aquí también probablemente fueron influenciados por Xevious. Cada STG en aquel entonces estaba influenciado por Xevious—it y era casi imposible de ignorar.
De todos modos, más tarde el nombre volvió a cambiar a Zanac, pero no sé exactamente cómo pasó eso. Una explicación bastante probable es que Teramoto la escribió, ya que él también escribió la historia, si mal no recuerdo. Agregué varios pequeños detalles a la historia aquí y allá también.
—¿Hubo otros STG que te inspiraron? Por ejemplo, el hecho de que puedas disparar a enemigos terrestres y aéreos con tu tiro normal me recuerda a Star Force. Y ASO fue otro predecesor, en términos de la forma en que enciendes tus armas.
Hirono: No conocía muy bien Star Force. La popularidad de ese juego coincidió con un período en el que no iba mucho al centro de juegos. Si tuviera que señalar otra influencia directa sobre Zanac, sería Majou Densetsu de Konami (Caballero). En ese juego, si tomas la misma arma secundaria dos veces seguidas, la enciende y me inspiré en ella para Zanac. Hablando de los potenciadores, probablemente no pueda decir de buena fe que Gradius no fue también una influencia, pero es es cierto que no conocía ASO en absoluto.
Ah, y para la versión Famicom de Zanac, agregué la función donde el arma secundaria 5 se convierte en un láser con máxima fuerza, y eso fue influenciado por Star Soldier. No jugué mucho a Star Soldier, pero me dio ganas de hacer un láser igualmente bonito para Zanac. La razón por la que la versión MSX tampoco tenía láser fue que simplemente no lo había pensado entonces.
—Zanac encarna un alto grado de experiencia técnica en programación. ¿Crees que esto fue fruto de toda la investigación y el estudio en profundidad de hardware que habías realizado?
Hirono: Creo que investigué mucho sobre el MSX. Desafortunadamente, las técnicas de programación no documentadas que descubrí en el MSX a menudo no funcionaban en todos los modelos. Y sabía que si no se podía garantizar la coherencia entonces no tenía sentido. Por esa razón, realmente no invertí mucho tiempo aprendiendo el mismo tipo de trucos para Famicom. En cambio, fueron los propios Nintendo quienes a veces compartían técnicas de programación ocultas con nosotros. Como empresa hicieron todo lo posible para reconocer y difundir ese tipo de información. Y como vinieron directamente de Nintendo, los adoptamos fácilmente sin preocupaciones.
—Es sorprendente que hayas podido programar algo tan sofisticado utilizando únicamente la documentación oficial estándar.
Hirono: Bueno, más que eso, fue que al menos en comparación con el MSX1, las capacidades gráficas de Famicom eran divinas. ¡desplazamiento suave! ¡sprites de color! Y también teníamos mucha más libertad sobre cómo dibujar los fondos. Alguien que vino de programar el MSX1, sintió que podías hacerlo cualquier cosa en la Famicom. Eso nos llenó con un “si lo conseguías, úsalo como arrogancia y metimos todo lo que sabíamos en nuestros juegos. “Agreguemos tanto servicio de fans como podamos, ese era nuestro espíritu.
—Si bien la versión Famicom de Zanac agregó muchas más funciones, también fue considerablemente más fácil. La versión MSX tenía, en general, un nivel de dificultad muy alto y la pantalla más estrecha significaba que siempre tenías que estar alerta.
Hirono: La orientación de la pantalla de la versión MSX nos permitió matar dos pájaros de un tiro. El campo de juego más estrecho significaba que había menos sprites para volver a dibujar, y separar la visualización de la puntuación de la capa de fondo también reducía la carga de procesamiento. A pesar de ser un hardware más potente, Famicom no podía dividir la pantalla verticalmente de esa manera.
Así, Zanac se convirtió en un yokotate (desplazador vertical orientado horizontalmente) en Famicom, con más espacio para maniobrar, lo que en consecuencia redujo un poco la dificultad. Sin embargo, eso no fue algo que nos propusiéramos hacer conscientemente. Pero no me sentí mal porque fuera un poco más fácil, así que lo dejamos así.
Lo único que hicimos intencionalmente más fácil fue la dificultad de la etapa inicial. La gente definitivamente se había quejado de que la versión MSX era demasiado difícil y yo mismo sentía lo mismo. La propia consola Famicom también estaba dirigida más a las masas, por lo que tenía sentido reducir un poco la dificultad.
La mecánica que agregamos para la versión de Famicom, donde si chocas con una caja con un chip, tu toma principal obtiene un power-up— completo que quedó como otro servicio de fans, pero originalmente fue una especie de feliz accidente. Verás, en la versión MSX, las cajas eran todas blancas, pero al dispararlas podías cambiar su color a rojo, verde o azul, lo que te permitía saber lo que contenían. En Famicom, sin embargo, cambiar el color de sprites individuales como ese sobre la marcha fue muy difícil debido a la forma en que Famicom manejaba el color a través de paletas. Así que lo cambiamos para que la caja parpadeara cuando se disparara, y mientras parpadeaba se podía ver el chip que había dentro.
El problema se solucionó… ¡o eso pensábamos! El nuevo problema era que, cuando había demasiados sprites en la pantalla, los sprites parpadeaban y eso alteraba el efecto de parpadeo de la caja.
Digamos que disparaste a una caja y empezó a parpadear, mostrándote que había un chip dentro. El parpadeo del sprite tuvo el desafortunado efecto de hacer que esa caja desapareciera por completo, por lo que el jugador pensó que había una ficha lista para ser tomada, pero cuando iba a buscarla moriría por la colisión con la caja. Estábamos enloquecidos, pero entonces se nos ocurrió una solución poco probable. ¿Por qué no hacerlo para que el jugador pueda simplemente recoger las fichas de una caja parpadeante (sin necesidad de destruirla por completo)? Eso solucionaría el problema, pero luego surgió otra idea: ¿y si lo hiciéramos para que estuviera bien chocar con él cualquiera cajas que contenían fichas, independientemente de si habían sido disparadas (estaban parpadeando) o no…? Eso lo convertiría en una apuesta, por supuesto, pero si ganaste la apuesta, podríamos recompensar al jugador. Recibir un solo chip haría que la apuesta careciera de sentido, por lo que hicimos que te diera 5 chips (un valor total de potenciador) a la vez. De todos modos, así fue como se nos ocurrió eso, iterando cada idea de manera lógica.
—La mecánica “instant power-up” fue de gran ayuda para recuperarse después de una muerte. Ese tipo de salvavidas “era muy raro para los STG en ese momento. A continuación quería preguntar sobre una de las características más llamativas de Zanac para la época: su desplazamiento de alta velocidad. Cuando los fondos se desplazan tan rápido, más allá de cierta velocidad se produce un efecto similar a una luz estroboscópica, que crea la apariencia de desplazamiento de paralaje. Todo el mundo quedó asombrado por eso.
Hirono: Durante el desarrollo de MSX hicimos muchas pruebas diferentes y nos topamos con ese efecto. Olvido quién lo notó primero, yo o el diseñador, pero alguien dijo, “¡Oye, eso parece paralaje!” Luego trabajé con ese diseñador y le pedí que dibujara una serie de sprites de fondo para la etapa final que se verían naturales con ese efecto de pseudoparalaje.
También tenía muchas ganas de replicar el impacto visual de esa última etapa en Famicom, pero cuando intenté hacer desplazamiento de sprites 8×8 en Famicom, se veía feo. La Famicom se trataba de desplazamiento de una sola línea, por lo que no se podía evitar. Hicimos algunos cálculos sobre cuántos datos gráficos necesitaríamos enviar y a qué velocidad para lograr el mismo desplazamiento rápido en Famicom. Después de muchas optimizaciones, finalmente pudimos desplazarnos 8 líneas de datos de píxeles en un cuadro. También utilizamos la misma rutina de desplazamiento de alta velocidad en Gunhed. Gunhed no se planeó originalmente como un juego de alta velocidad, pero al final del desarrollo se nos pidió que incluyéramos más aceleración, por lo que trasladamos esa rutina de desplazamiento.
Preguntas y respuestas de Zanac
—¿Cuáles son tus armas secundarias favoritas?
Hirono: En el MSX, 7 fue el más fuerte. Pero debido a la pantalla más grande de Famicom, no golpeó a tantos enemigos allí. En Famicom personalmente soy fanático del arma 3. Defensa, ¡se trata de la defensa! Sin embargo, es bastante raro morir con él al más alto nivel y, a veces, me pregunto si sería prudente incluir un arma que permitiera un juego tan seguro… (risas)
—¿Tú también tienes enemigos favoritos?
Hirono: Me gustan los enemigos Raster, esos barcos morados que se abalanzan sobre ti rápidamente desde un lado. Por alguna razón los llamo “Kitarou”. Me gusta el arco de su movimiento; También utilicé el mismo tipo de movimiento para los enemigos en Gunhed. Sus ataques no son especialmente feroces ni tienen mucha vida, pero de alguna manera aún pueden matarte muy fácilmente. Me gustan enemigos como esos—ones que no parecen particularmente imponentes pero que por alguna razón son muy difíciles.
—El enemigo Karura (el que es invulnerable a todos tus disparos, pero puedes destruirlo chocando con él) también se sintió fresco. No recuerdo haber visto un enemigo así en ningún STG que no fuera Zanac.
Hirono: Queríamos crear enemigos que tuvieras que destruir de alguna manera creativa, así como enemigos que pudieran anular tus ataques. Y queríamos enemigos que te hicieran desperdiciar tus armas secundarias.
En términos de anular tus ataques, más que los enemigos Karura, creo que los enemigos midboss voladores más grandes cumplen ese papel. De hecho, el láser es el único disparo que no rebota en ellos… pero la razón no es porque quisiéramos que el láser fuera tan fuerte, sino porque no pudimos programar con un buen efecto gráfico para mostrar el láser. reflejando. (risas)
—Zanac tiene lugar en un entorno de ciencia ficción, entonces, ¿qué pasa con el hada que acude en tu ayuda…?
Hirono: Dibujé el pixel art para eso, pero no creo que estuviera pensando en el mundo o el escenario de Zanac de ninguna manera. No aparece en la versión MSX… así que probablemente estaba jugando en el editor de sprites de Famicom. Una cosa que sí recuerdo es cómo, en aquel entonces, existía esta tonta tendencia con juegos en los que “el piloto es en realidad una niña!” No me gustó eso. Quería que el piloto de Zanac fuera un viejo malhumorado, así que el hada probablemente era yo tratando de poner algo de atractivo sexual “(…¿Supongo?) en otro lugar del juego o algo así.
También dibujé las marionetas que arrojas Toque, por cierto. (risas) Hubo otros juegos en los que hice el arte de Too—in Lunar Ball, por ejemplo, dibujé casi todo, incluida la fuente de texto. Sin embargo, el cráter de fondo fue un buen trabajo de Teramoto. Ahora que lo pienso, creo que mi pixel art solo aparece en los juegos anteriores de Compile. Más tarde nuestros estándares de calidad subieron mucho y no pude competir.
Durante Lunar Ball, utilicé un editor oficial de pixel art, donde ingresabas los datos de pixel con un controlador Famicom. Creo que Zanac nos dio una herramienta más fácil de usar.
Los descendientes de Zanac
—Parece que los shmups de Compile siempre tuvieron etapas muy largas.
Hirono: Eso es en gran medida culpa mía. (risas) La responsabilidad final de equilibrar el juego recayó en mí, ¿sabes. En cuanto a la versión Famicom de Zanac, si consideras que el juego tiene 12 etapas en total, en ese sentido no creo que la primera etapa sea demasiado larga, pero… en cualquier caso, tengo tendencia con el diseño de etapas a ir e incluir todo en mi cabeza. Cuando estás en medio de la creación, a veces puedes perder la perspectiva y desensibilizarte sobre cómo son realmente las cosas. Es un mal hábito.
—Para bien o para mal, después de finales de los 80, había una tendencia a que los juegos STG se volvieran cada vez más difíciles. Con el tiempo llegó a un punto en el que los juegos STG se consideraban problemáticos porque su dificultad en realidad ahuyentaba a los clientes. ¿qué piensas de los juegos danmaku (infierno de balas)?
Hirono: Entiendo que algunos jugadores exigen juegos como este, pero hablando como desarrollador, no me gustan mucho. No me gustan los juegos que tratan de crear estrés y presión implacables sin tiempo de inactividad. Esa fue una comprensión que hice cuando estaba desarrollando un determinado STG, cuando experimentamos poniendo más balas en pantalla que antes con Zanac. Se sentía demasiado restrictivo y claustrofóbico. Cuando hice Zanac, verás, todavía no sabía qué tipo de STG me gustaban personalmente.
Las balas enemigas en Zanac sólo pueden disparar en 16 direcciones. Lo hicimos para conservar la potencia de procesamiento. Esto significaba que durante las peleas contra los jefes de las fortalezas, podías encontrar espacios seguros donde evitar morir, pero de todos modos nos quedamos con los tiros de 16 vías en su mayor parte. Fueron juegos posteriores en los que intentamos actualizar a tiros de 32 vías, ya que las demandas de procesamiento de hardware habían disminuido un poco. Probamos algunos ataques con disparos extendidos y sí… simplemente se sentía claustrofóbico. Luego, cuando jugué después de que terminó el desarrollo, me di cuenta de que los enemigos tenían demasiada vida y sus otros ataques eran demasiado fuertes, y todo me pareció demasiado difícil. Pero sólo me di cuenta de eso después del desarrollo. Mientras lo hacíamos, nunca pensé que “esto fuera demasiado difícil o ” nos estamos excediendo. De hecho, ¡inicialmente fui la mayor animadora de esas incorporaciones!
No quiero que me malinterpreten: no se trata de si los juegos difíciles son más o menos divertidos. Hay muchos jugadores que piensan que algunas de ellas también son las obras maestras más importantes. Sólo me refiero a la dificultad en sí. A menudo, lo que los desarrolladores consideran una dificultad fácil o media, para la persona promedio, ya es bastante más que difícil. Eso se me ocurrió más adelante en mi carrera de desarrollo de juegos, pero cuando estaba creando Zanac, no era consciente de ello en absoluto. Para la versión MSX1 de Zanac, realmente no estaba tratando conscientemente de ponérmelo difícil, pero después la gente me dijo que era bastante difícil, así que ahora miro hacia atrás y es como… gracias a Dios no lo hice deliberadamente ¡intenta ponértelo difícil entonces!
Como yo no era consciente de la dificultad, mis juegos comenzaban a acercarse cada vez más a danmaku, hasta que en algún momento pensé, “si sigo por este camino, conducirá a un callejón sin salida.” Y retrocedí, o al menos lo intenté. Ok, usaremos disparos de 32 direcciones, pero tenemos que asegurarnos de que no haya demasiados patrones de balas densas en la pantalla a la vez. Y si creamos un patrón danmaku, debemos incluir “agujeros” en el patrón u otras formas para que los jugadores escapen. O lo haríamos para que pudieras evitar esos patrones por completo yendo al otro lado de la pantalla. De esta manera intentamos crear una red de seguridad para los jugadores.
Al final, fue en gran parte gracias a mi experiencia haciendo Zanac que nunca fui demasiado lejos en el camino del diseño danmaku. Sin embargo, también hay personas que afirman que Zanac influyó en danmaku STG. Si Zanac realmente influyó en esos juegos, aunque sea un poco, supongo que lo que estoy diciendo no tiene mucho sentido.
Definitivamente tampoco digo que los juegos danmaku sean malos. Sé que a sus fans les encantan. Pero para los recién llegados, parecen completamente inaccesibles. Esa es una realidad de la que toda persona que crea juegos STG es consciente, al 100%. Pero creo que la abrumadora presencia de los juegos danmaku hoy en día se reduce en última instancia al hecho de que las personas que crean STG hoy quieren crear ese tipo de juegos. De todos modos, creo que sería bueno si también viéramos diferentes tipos de STG.
Stg final de la compilación: Zanac x Zanac
—Lanzado en 2001, Zanac x Zanac ciertamente se siente como una especie de contraataque contra el estilo danmaku reinante.
Hirono: No tuve muchas aportaciones cercanas sobre el desarrollo de Zanac Neo, pero creo que fue un juego bastante equilibrado e hicieron un buen trabajo. Puede que no haya recibido excelentes críticas, pero personalmente me encantó el sistema en el que usaste el disparo de carga para provocar explosiones en cadena.
También recuerdo haber quedado impresionado nuevamente por el genio de Teramoto como diseñador. Cuando estaban desarrollando Zanac Neo, en los primeros borradores del pixel art, las balas eran muy difíciles de ver. Ahora se podría imaginar que debido a que Famicom tenía gráficos mucho más simples, la visibilidad de las balas habría sido un problema real en el Zanac original, pero ese no fue el caso. A pesar de las limitaciones de color y la cantidad de sprites, Teramoto logró crear una distinción visual clara entre sprites terrestres y aéreos. Verlos luchar con eso inicialmente en Zanac Neo me hizo darme cuenta, vaya, realmente todo se reduce a la habilidad del diseñador.
—Creo que el puerto Famicom de Zanac incluido en Zanac x Zanac también estuvo increíblemente bien hecho y fue muy preciso. Parece que lo lograste sin emulación…?
Hirono: Se ejecuta de forma nativa en Playstation. Está codificado en ensamblador, lo cual creo que era bastante raro en un juego de Playstation. Los controladores de sonido también se programaron desde cero en el ensamblador, lo que nos permitió leer los datos de sonido de Famicom tal como están. El chip de sonido integrado de Playstation, sin embargo, no pudo reproducir muy bien la onda cuadrada de Famicom. El muestreo era una opción, pero muestrear una onda cuadrada suena feo. Probamos un montón de trucos, incluido muestrear la onda en diferentes intervalos y octavas, pero al final no pudimos lograr que sonara bien. Entonces, lo que hicimos fue reescribir los datos del efecto de sonido por completo y modificarlos hasta que sonamos lo más cerca posible.
A pesar de trabajar tanto, al final los jugadores todavía lo criticaron por sonar diferente. (risas) Supongo que ser súper obsesivo no siempre vale la pena. Si hubiéramos grabado las canciones en su totalidad y las hubiéramos reproducido, la calidad probablemente habría sido mejor, pero habríamos perdido la capacidad de controlar ciertos detalles de esa manera… mirando hacia atrás ahora, me doy cuenta de que estábamos un poco jodidos. forma.
—Hace un momento hablamos de que algunos veían a Zanac como un predecesor de los juegos Bullet Hell, pero el modo de prueba de puntuación en Zanac x Zanac es algo que definitivamente se siente como una versión “Bullet Hell” de Zanac.
Hirono: Para esos modos de bonificación, se nos permitió hacer lo que quisiéramos. En el Zanac original, los límites de la RAM funcional de Famicom eran en realidad una parte clave del equilibrio del juego (especialmente cuando se luchaba contra los jefes de la fortaleza), pero personalmente me preguntaba cómo sería si esa restricción no existiera… como ¿Qué tan locas podrían volverse las cosas sin límites de sprites?! Bueno, lo intentamos y fue tan ridículo como esperaba. Por principio, normalmente no estoy dispuesto a lanzar juegos con una dificultad alta, pero como esto era más bien una ventaja, pensé, eh, ¿por qué no.
—Si tuvieras la oportunidad de hacer otro juego de Zanac hoy, ¿cómo te gustaría que fuera?
Hirono: Algo que me resulta divertido jugar yo mismo y algo con mucho fan service también, naturalmente. Esa ha sido mi política personal desde que hago juegos. Zanac fue el resultado de ese pensamiento, y es por eso que hay tantos enemigos diferentes, patrones de balas y armas llamativas para disfrutar. Pero, como dije antes cuando hablaba de juegos danmaku, como diseñador, si sigues con este vector, creo que eventualmente llegarás a un callejón sin salida. Cuanto más fuertes sean los enemigos, mejor tendrá que ser el jugador. Se convierte en poco más que un sangriento espectáculo de masoquismo. Entonces que es entonces, ¿la dirección correcta para el futuro de Zanac?
Siento que no encontramos una respuesta clara a eso en Zanac x Zanac, pero si tuviera que hacer otro juego de Zanac hoy, creo que probablemente intentaría volver a sus raíces: un nivel de dificultad/rango que el El jugador puede controlar claramente a través de sus acciones, y una clara distinción entre los aspectos “peligroso” y “seguro” del juego… Me gustaría centrarme especialmente en esos dos aspectos. Cuando hicimos Zanac, debido a las limitaciones de hardware, muchos elementos del juego eran en realidad productos de necesidad, los lugares seguros y el límite de sprites que causaba que las balas se cortaran durante las peleas de fortaleza son dos ejemplos y me gustaría poder controlar esas cosas. más intencionalmente. Y finalmente, por supuesto, quiero hacerlo divertido. Supongo que si tuviera que resumir quiero hacer algo con cuidado y con respeto… pero solo decir eso hace que suene un poco insulso, ¿verdad? (risas)
