Intro
Este juego ostenta un lugar especial en mi corazón... Fue el primero que empezamos a crear allá por los ochenta mi colega Endika y yo. El como programador y yo como grafista intentamos hacer un shoot´em up cuya peculiaridad estribaba en que podrías chocarte con el escenario. Algo aparentemente muy manido ahora pero que en su día solo habíamos visto en contadas ocasiones.
De aquello solo quedaron algunas hojas con esbozos de los sprites... El juego nunca pasó de volar por encima de unos postes telegráficos contra los que podías chocar...
Tres décadas después, por azares de la vida me encontré emulando el SEUCK y el recuerdo de aquel proyecto se tornó viable...
Barón Rojo o el legado de Von Richtofen
En un principio el avión que dibujé se basaba en el Fokker triplano del Barón Rojo.
Posiblemente porque por aquel entonces estaba de moda el grupo heavy hispano del mismo nombre y gracias también a la película de 1971 del mismo título que vimos en la tele.
Cuando retomé el proyecto a finales del 2014 tenía dos serios problemas. No conocía el programa y no tenía ni idea de como abordar un shoot´m up.
El segundo punto parecía salvable. Desde la perspectiva que dan los años y las horas acumuladas en este genero tendría que haber aprendido algo. Si bien no supiera bien el que.
El primer punto era el más complicado. Si bien parece sencillo, y lo es, el SEUCK exige un planteamiento previo para poder coordinar todas sus funciones.
Pero claro, si nunca antes lo has utilizado (y el inglés se te da tan mal como a mi) te encontrarás con serios problemas.
Luego estaba el tema de si es mejor usar una máquina original con todo lo que supone, joystick, datassette, el SEUCK, una cassette virgen y un C64...
Mis (dos) intentos de trabajar con el SEUCK en un Commodore 64 en modo real acabaron en fracaso.
El sistema de grabación en cinta es un truño.
Me quedó claro que era preferible trabajar en un emulador aunque no supiera como...
En busca de inspiración... o no
Al retomar el Commodore 64 me dio por pensar que para acelerar el proceso de aprendizaje y creación era mejor desconectar con todo lo que hoy nos aportan los videojuegos y alimentarme únicamente con el material propio que conocí entonces. Parece una chorrada pero no lo es. Yo tuve la fortuna de vivir el commodore en su momento. No había nada mejor (excepto los cartuchos de Konami) que el Commodore, bueno si, los arcades....
Resulta difícil zafarse de todos los añadidos y mejoras que ha traído el transcurso del tiempo a los videojuegos. Mi recomendación: reducir el contacto con el presente lo más posible. Pero es una chorrada, es un truco que a mi me ha ido bien, y punto.
Pero mira que soy tonto que también me impuse una moratoria para no caer en la tentación de entrar en TND o the SEUCK Vault a ver lo que hacía la peña, no fuera que me desanimara...
ERROR! Si hubiera mirado otros juegos SEUCK antes de meterme en fregados hubiera descubierto que, por ejemplo, ya se me habían adelantado. Pour le Merité es un juego SEUCK que cumple con lo que teníamos pensado, punto por punto... Es más añadiendo un toque personal que me dejo sorprendió gratamente. Ese es un juego que tranquilamente hubiéramos podido jugar en los 80.
https://www.youtube.com/watch?v=4BCM-Fqx7o0
Pour le Merite, SEUCK Compo 2010
Llegados a este punto yo ya andaba con una versión en marcha de 1914.
https://www.youtube.com/watch?v=GWHGZU3LSe4
1914 en pañales
Habían pasado dos meses desde que empecé con SEUK. Y no sabía nada de lo que hacían los demás.
ERROR!
Me las daba muy felices cuando todo falló..
No había tenido en cuenta las peculiaridades del diseño de fondos y me encontré que al no tener un planteamiento previo me estaba pillando los dedos. Los tiles eran una pesadilla, no respondían a ningún criterio, no casaban unos con otros más que en lo básico. Probé varios modos de hacer montañas y nubes en el horizonte, y todos estaban en la misma retícula, ocupando un espacio vital y montando un caos en los fondos de aupa.
Entonces caí en la cuenta de que realmente no sabía de cuantas fases constaría el juego y que ni siquiera sabía cuanto medirían esas fases
Busqué respuestas viendo videos en You tube. Pero más que aclararme algo me dejaron flipando. Que poderío, que cabrones, que fluido va todo... Tenía que saber más sobre el editor de niveles y su funcionamiento. Eso y pensar un poco en como lo hacían antes a la hora de abordar el diseño con esas limitaciones.
Retro reto
R. Internacional me metió la idea de que no tenemos porque limitarnos a lo que existía y que somos libres (si somos capaces) de aportar algo actual y nuestro al Retro.
Súmale a eso la amistad que tengo con un tal Javier Salaberria, un tipo interesante, que oyó campanas de que estaba haciendo algo sobre la primera guerra mundial y me trajo material para documentarme. Estoy en deuda con el y con los demás... Si no fuera por su insistencia no me hubiera esforzado tanto intentado mejorar la parte estética del juego...
Bueno la cosa es que se me ocurrió que el nivel se dividiría en fases de cinco pantallas de largo. El razonamiento para llegar a este numero se basa en que una fase de un Shoot´em up vertical clásico mide unas diez pantallas de alto. No siempre, pero más o menos...
Teniendo en cuenta que la pantalla se divide en (4+1) x 8 bloques, para desplazarnos 80 bloques en vertical necesitaremos 16 pantallas mientras que si queremos desplazarnos la misma cantidad de bloques horizontalmente necesitaremos solo diez.
Decidido el tamaño de los niveles pensé (acertadamente) que la complejidad gráfica de las fases determinaría la cantidad de niveles de las que dispondría el juego. Que en este caso van a ser cinco.
¿Que ocurre? Que el tiempo que tarda un sprite en cruzar verticalmente la pantalla es casi la mitad de tiempo (realmente la mitad de bloques más uno) de lo que tarda en cruzar horizontalmente.
Y eso es un problema si trabajas en el sideways, que es de desplazamiento horizontal.
El problema estriba en que debemos limitar el numero de sprites en pantalla para asegurar la fluidez del scroll
Aquí un ejemplo de lo que pasa cuando hacemos algo a bulto o documentándonos un mínimo.
Y eso que poco, por no decir que nada, se parecen estos barcos a los destructores de la época.
Pero en ambos la premisa principal funciona, se ve que son barcos. Tampoco busquemos la excelencia, necesitamos cada pixel como si fuera el último. El primero no requiere más de cuatro bloques para su construcción. El segundo en cambio gasta la friolera de 20 bloques para ser representado. Todo un lujo en aras de la belleza.
Lo ideal es que cada pantalla sea un cuadro en si mismo. Pero eso no siempre se puede conseguir...
Tampoco hay que volverse loco con la documentación.
El material gráfico puede servir de fuente de inspiración.
Pero a veces la realidad puede no ser del todo satisfactoria para nuestro cometido.
La foto que acompaña a estas capturas de pantalla es la de un barco de la primera guerra mundial. La pintura de camuflaje que luce estaba pensada para confundir al observador enemigo. Hay que tener en cuenta que estamos en una guerra sin ningún sistema de detección electrónico.
¿Os imagináis si en vez de un buque convencional hubiese tratado de representar este otro?
Un problemón tanto técnica como conceptualmente. Al margen de la dificultad de hacerlo, que se podría intentar, el auténtico problema se deriva de que nadie ha visto un barco así en 100 años. y nadie lo reconocería como tal, a excepción de los aficionados del tema claro está.
Meses después...
El juego sigue en barbecho.
Es normal que mientras vas descubriendo las herramientas y su funcionamiento, empiecen a surgir nuevas ideas y las ganas de aplicarlas sean mayores que enfrentarse al reto de resolver las cagadas realizadas.