jueves, 9 de octubre de 2014

Un salto en el camino

Alto!
El Google Cardboard ha entrado en casa...
Llevo un par de horas trasteando con varias demos y la verdad es que resulta alentador ver lo ocurrente que llega a ser la gente... Una experiencia recomendable y una alegría para los oftalmólogos que van a ver un mayor numero de retinas achicharradas por gracia y efecto de poner unas lentes entre nuestros móviles y nuestros ojos.

miércoles, 8 de octubre de 2014

Atrezzo

Una buena patina transmite una sensación de seguridad, una certeza de que lo que vemos responde a un plan bien orquestado.
En mi caso un ejercicio de estetica...

Guión II

Cual debe ser el motor impulsor de un Shoot Em Up?
La destrucción.
Debemos destruir todo aquello que se mueva o nos parezca destruible. No es una premisa de obligado cumplimiento pero si es algo deseable.
Inicialmente el SEUCK no dispone de música. Esta puede integrarse mediante ensamblador a posteriori.
Tomando como tema principal una canción en formato SID (el formato del C64) he desglosado los cambios de ritmo y los he anotado con la intención de usarlo como banda sonora y determinar la disposición de los elementos y su presentación.

Mier...coles!

De camino a casa he conseguido un recambio de hojas milimétradas que usaré para ilustrar este primer juego. Si bien es cierto que el diseño en caliente resulta más satisfactorio, no es menos importante la planificación previa en papel.
Vehículos y otros elementos, tanto los activos como los meramente decorativos, pueden abocetarse previamente en papel. O en el móvil, que también se puede...
Pero no se debe obviar que lo que funciona en papel, aparentemente, no tiene porque funcionar en pantalla, y viceversa...

martes, 7 de octubre de 2014

Guión

Tiene un shoot m up guión?
Pensad por un momento.
Lo tenéis?
Habéis revisado mentalmente Slap fight, Terra Cresta o Xevious entre otros muchos y la conclusión es que si.
Yo creo que incluso Space Invaders o Galaxian escondían en su interior el anhelo de narrar una épica historia. Moon Cresta, que es de la misma época, es tal vez el mejor exponente de esta idea. Y no fue el único.
Siendo Ikaruga la cima de este genero al retrotraerme a los modelos de los 80 arrastró mi bagaje cultural conmigo y trato de imprimir la impronta de lo conocido en un programa pensado en y para los ochenta.
Tengo un guión... Pero lo que no se es cual es la duración total que me puedo permitir...
XD

Lunes... Martes!!!

Nada, hoy no he avanzado nada...
Bueno... Miento...
Una hora de diseño de tiles me ha reportado una serie de entramados que podré utilizar a posteriori...
Pero el inicio del diseño de la fortaleza se ha ido al carajo...
Apenado me he duchado y me ha venido a la mente una cuestión recurrente que se esgrime cuando se habla de SEUCK.
Adolece, dicen, de ser un programa de plantilla lo que deriva en una uniformidad en los juegos confeccionados con el.
Otra cuestión que se me plantea es un comentario que maltraduje de un foro en inglés... Les falta algo.... O... Tienen algo que delata que son producto de este motor...
Sea como fuere... Lo que estoy haciendo está a la par de los juegos comerciales de los 80... Y me siento complacido con los resultados...
Ahora tengo la idea para una intro... Algo que pocas veces he visto en un C64...

lunes, 6 de octubre de 2014

Work in progress

Parece que mi intentona por salvaguardar el juego funciona...
Dedicaré la semana a fusilar lo ya realizado y a mejorar en la medida de lo posible los elementos que conforman el juego.
El CCS64 me ha permitido configurar un disquete virtual donde estoy copiando los datos del SEUCK... Mis intentos de guardar esta información en una versión previa ha sido un fracaso...
Paciencia y a copiar toca...

Walking around

De camino a casa trato de conciliar mis necesidades con mis obligaciones con resultado incierto.
Es habitual confundir el deseo con la necesidad pero en el caso que me concierne no es este el paradigma que motiva mis movimientos.
La búsqueda de los límites del SEUCK permite perfilar el camino a recorrer.
La pantalla por la que no movemos se presenta como un azulejado de 6*8 bloques.
Estando formado cada bloque por celdas de 6*6 que a su vez se conforman de 4*8 píxeles de los del Commodore 64 (de esos que parecen ladrillos en vez de cubos).
Cada celda realmente es un carácter de una tabla de 253 redibujables. En si deberían ser 255 pero las dos últimas se encuentran anuladas a priori...
Las permutaciones que se pueden realizar vienen limitadas por la cantidad de bloques que se pueden almacenar en el programa. Que si no me equivoco son 32*16 bloques.
Pero aquí surge una pregunta interesante... Cuantas pantallas conforman el juego? Teniendo en cuenta que una pantalla estática consta de 6*8 bloques ignoro cuantas de estas pantallas soporta el programa...
Algo que sin duda descubriré en breve...

256 pantallas se pueden realizar teoricamente con el SEUCK, esto lo descubrí mucho más tarde....

Otro para el armario

Un fantástico HP  C1100 ha cascado entre mis manos... Y todo dentro de mis intentos de hacer algo en C64.
Tengo los drivers pero no la unidad de cd que permitirían su reinstalación. Según veo en la red debo de agenciarme un cable USB para enchufarlo a un PC...
Ancha es Castilla!
Seguiré informando!

domingo, 5 de octubre de 2014

One more time, catastrofic looping

Problemas y más problemas. Tras la cagada de la pasada semana esta vez opté por desarrollar el juego emulado desde PC. La comodidad es grande. Pero al poco de empezar, al día siguiente en realidad, traté de salvar los datos y ver si podría crear una versión .PRG (versión final del juego) en un .D64.
Pues no pude... Tener versiones freezer si pero de salvar los datos nada.
Tras leer y releer, he configurado el emulador y parece que ahora si se ejecuta correctamente... El problema viene de no activar la True drive emulation...
Ya veremos...
Ahora solo tengo que copiar lo ya hecho a esta nueva captura donde si puedo grabar mis avances y disfrutar de lo que vaya sembrando...

Fiebre del sábado noche un domingo por la tarde

Si durante la semana he estado perdiendo el tiempo con el SEUCK el fin de semana no ha sido menor el descalabro...
Al igual que la pasada semana este pasado sábado lo pasé embutido en los ochenta, tal vez en el 86.
Aunando lo aprendido empecé a confeccionar un juego con la intención de descubrir los límites físicos del programa.
El programa dispone de 126 sprites, con ellos contamos para hacer todos los elementos movibles en pantalla.
Desde las balas hasta las explosiones, pasando por tu nave y los enemigos, son sprites.
126 parece un número alto pero se queda en nada cuando tratamos de hacer algo con un mínimo de calidad.
Una peculiaridad de estos sprites estriba en el uso del color.
En si tenemos tres colores para seleccionar de una paleta de cuatro.
El primero es el de transparencia de ahí que este no lo cuente como utilizable.
Los dos colores siguientes son realmente relevantes puesto que afectan al total de los sprites.
Una solución socorrida es usar el blanco y el negro indistintamente.
Pero supongo que esta no es la única solución a esta limitada paleta.
El último color es el que marca la diferencia. Afecta a cada sprite individualmente.
Pero el Commodore arrastra un problema, o mejor dicho una norma insalvable.
Un sprite del C64 mide 24*22 píxels, pero son píxeles de 2*4.  Para entendernos, son ladrillos en vez de los cubos que asociamos  al concepto de píxel.
Esto repercute directamente y todo se nos antoja cuadrado.
Pero no tiene porque afectar. No es excusa para no hacer algo potable.
Una idea que se me ocurre al revisar los sprites que he realizado es que para hacer algo de calidad tenemos que diseñar todos los elementos (vehículos u objetivos) como si todos y cada uno de ellos pudieran protagonizar el papel principal de algún otro videojuego.
De cinco sprites que me he currado solo tres cumplen con este consejo. XD