A falta de un editor de vídeo que permita mezclar animaciones sobre fondos y moverlas, me puse con pyhton-pygame a crear un vídeo musical.
Es todo parecido a crear un juego, con la diferencia de que no hay control externo.
Como ha de sincronizarse con una pista musical, tengo una serie de variables que me van diciendo en qué punto de la canción estoy, de acuerdo con la base musical en MIDI.
Así hay una variable tiempo que va corriendo hacia adelante en décimas de segundo.
Cada 16 tiempos sube un valor la variable tiempo_cuarto, que sería aproximadamente el tiempo transcurrido entre un bombo y una caja en ritmo simple,
y cada dos tiempo_cuarto sube un valor la variable tiempo_measure.
El "measure" es la unidad de medida de mi secuenciador, y podría asimilarse a hojas de partitura. Cuando termina un measure aparece otro con nuevas notas.
Normalmente relleno los measures con 4 bombos y cajas a ritmo simple, aunque este es de los pocos casos en los que el measure contiene la mitad de información (y lógicamente tocado al doble de velocidad): bombo-caja-bombo-caja, fín del measure.
Con estas variables, empiezo a lanzar las animaciones:
En la segunda mitad del octavo measure empieza a cantar, entonces:
if tiempo_measure==8 and tiempo_cuarta==2:
Player.accion_cabeza=1
Player.accion=2
Player.escala=2
Player.x=200
Player.vx=4
La cabeza está separada del cuerpo, y tiene cuatro tipos de acciones:
0. callao
1. mueve la boca abriéndola bastante, prononciando aes, o como gritando.
2. mueve la boca con proliferación de dientes apretados, como pronunciando eses.
3. mueve la boca con proliferación de "morritos", oes o plosivas.
El cuerpo tiene 8 tipos de animaciones, depende del que seleccione se pone a bailar de una forma o de otra, o bate una espada, se pone a saltar... así sin parar hasta que le de otra orden con otro tipo de movimiento
Vx es el desplazamiento horizontal en pixels que hará el personaje cada fracción de tiempo, hasta que le mande otro valor o le pare, con Vx=0.
La escala determina el factor de escala, valga la redundancia, por el que se multiplicará el tamaño del cuerpo y la cabeza, recalculando la posición. Para hacer primeros planos.
En fín, que con la partitura MIDI de la canción, es como si le dieses un guión al protagonista de lo que tiene que hacer en cada momento... y hasta nueva orden.
Ponte a saltar... ahora mueve la boca... ahora cállate, ahora por el fondo de la cueva. Ahora colócate a la derecha y avanza hacia la izquierda levantando las piernas, ahora acércate, ahora aléjate y pon el fondo del bosque...
Con la canción sonando al lado hay que ajustar el metrónomo de Pygame para que vaya acompasado.. y aquí está el único problema.
El tiempo de python no es exacto, cada vez que cargas el programa su velocidad de ejecución varía ligeramente, sin importancia para un juego, pero un desastre cuando todo tiene que ir sincronizado. Si antes te iba más o menos bien ese metrónomo, ahora descubres que el video adelanta a la música...o que se queda atrás.
Por lo que al final habrá que reajustar el tiempo de todo el vídeo, con algún programa que te permita algo del tipo "convertir la duración de 2 minutos a 1:58:32"
Si el vídeo corriera al tiempo con la música, se podría meter un control de la boca mediante teclado, de forma que mientras canta le vas indicando al muñeco por golpes de teclado cómo ha de abrir la boca, clavándolo con la letra. Y grabando el vídeo en vivo... sería como un directo XD
La canción del vídeo es ésta, una parodia de David el gnomo, David el orco, con un orco como protagonista. Aunque para el vídeo sonará en versión revolucionada, a más velocidad y con el pitch agudo cuatro tonos subido, que queda más hilarante, sin llegar a sonar a "pitufos maquineros".
Aún no la he terminado porque me falta meterle a los orcos coristas.
Rectificación: Hoy lo he probado varias veces y va clavado con la música, de modo que no necesitaré ningún programa externo para mezclarlo. Igual tiene que ver con la librería time que le metí a última hora para dejar un lapso antes de que empezara el vídeo.
Llevo cosa de un mes usando Inkscape, a la par que Urbatain (lo cual habrán notado por su serie de pruebas de concepto de El Anillo).
Haciendo los gráficos para "La venganza de Yan", empecé con un estilo sencillo para poder ir rápido. El caso es que cuando vas cogiendo destreza, puedes hacerlo menos sencillo sin perder velocidad. He usado mucho del reciclaje de siluetas para abarcar las diferentes localidades de una misma zona. Por ejemplo, para dibujar un bosque pinto unos pocos modelos de follaje, ramas y troncos, y lo que sigue es un copy-paste a lo bestia. Una vez compuesta la escena, se copia y se reordena todo para hacer otra localidad.
Y no todo es Inkscape. Aunque es ideal para dibujar las siluetas y calcar de imágenes... para los retoques finales o para dibujar las sombras de los personajes es preferible usar un programa de retoque fotográfico, a base de máscaras. Así lo estoy haciendo finalmente, tras una fase incial de intentar obtener el acabado definitivo con el propio Inkscape.
El nivel de calidad ha ido in-cresccendo, y eso se nota comparando los primeros dibujos con los últimos. Las primeras localidades voy a tener que redibujarlas porque se han quedado muy atrás.
En este post del foro del CAAD se habla de las portadas, y sale el tema de las pechugas como reclamo publicitario en numerosos juegos de los 80. Y me he permitido la licencia de hacer este pequeño fake para un juego actual de Jhames:
**ADVERTENCIA** **AMANTES DEL SÓLO-TEXTO NO LEER**
Cuando hago una foto, tengo un dilema: si se hace con ojo artístico normalmente no vale para ilustrar una aventura conversacional, tal como yo pretendo hacerlo con cierta uniformidad de perspectiva (ni tampoco como foto documental de esa zona) Si buscas el contraluz, el escorzo, el detalle, la parte sin su contexto... esa imagen no sirve luego para describir una localidad o un lugar globalmente, sino una particularidad de él, un efecto... la anécdota y no el conjunto. El atardecer puede quedar precioso, pero o toda la aventura se desarrolla en un perpétuo atardecer, o cada vez que pasas por esa localidad casualmente está atardeciendo aunque en la siguiente el sol esté a las 12, o te preparas todas las localidades para las distintas luces del día.
Las que suelen cuadrar son las tomadas desde la altura de la cabeza y de frente, ni hacia arriba ni hacia abajo, y con el sol arriba, sin excesivas sombras hacia poniente o naciente. De este modo las fotos son más fácilmente editables para darles la luz adecuada o las sombras que queramos llegado el caso. Más fácil es emborronar lo que sobra que sacar a la luz lo que no existe. De hecho lo ideal es un día nublado, sin sombras fuertes y con luz uniforme. Estas fotos son la mejor base para componer decorados.
Es un criterio sólamente, todo vale si queremos, podemos entrar en un salón y poner como ilustración principal su maravilloso techo pintado por Michelángelo Buonarotti; o usar la foto de una botella de vino para ilustrar una bodega; o usar éstas cuando miramos al techo o miramos una botella. Pero para la entrada en la localidad queda extraña la focalización directa en uno de sus elementos, o un punto de vista retorcido como si el protagonista si hubiera tirado al suelo o apretado contra una pared. No obstante, a base de partes también se puede componer un buen conjunto global.
Vistas las carátulas que ha hecho Planseldon en su blog. Se me ha antojado hacer lo mismo :D
Los disquettes ya los tenía hechos, también inspirados, por las simulaciones de cajas de Sarganar en este caso. El segundo sale en las curiosidades del final. Los screenshots del fake de Las Llaves del Tiempo son imágenes descartadas de Regreso al Edén.
Tengo dos proyectos abiertos donde juego con el movimiento masivo de PSIS. Cada uno tiene una peculiaridad distinta.
El proyecto A, para la Xcomp seguramente, es una malla bastante regular, con un cuello de botella cuyo paso se regula un poco a lo bruto, redirigiendo a los PSIS cuando su meta requiere atravesarlo. Los límites de la malla se detectan de la misma forma bruta: a mano. Los PSIS se mueven por objetivos. Una vez definidos los límites del mapa y la redirección por el cuello de botella, basta con asignar a cada PSI un valor en su propiedades objetivox y objetivoy, y éste realizará el trayecto automáticamente. Cuando se cumple un objetivo se reasigna otro, y así mismo existen acontecimientos masivos que afectan a bastantes PSIS: relevos de guardias, reuniones, accesos a edificios...
Los PSIS están contínuamente moviéndose por la malla de la ciudad, deteniéndose de vez en cuando unos turnos, con bastante autonomía.
Los PSIS cuentan con un generador pseudoaleatorio de rostros (con varios tipos de ojos, cejas, narices, rostros, pelos, complexiones, distancias entre los rasgos...) y nombres. Antes de comenzar cada partida se define aleatoriamente una "semilla del kaos", y en base a ese valor se determinarán las cosas que son diferentes en cada partida, pero que permanecerán constantes en el transcurso de la misma. Incluso el jugador será diferente: su rostro, su nombre y su género.
En el proyecto B los movimientos son más burdos, se basan en detectar como objetivo al jugador (cosa factible también en el proyecto A, aunque no vaya a cuento con la historia), olfateándole para converger hasta él y atacarle. El típico movimiento del Minotauro en su laberinto. Su punto fuerte es la automatización de los límites. En este caso la malla no es regular, sino que es un laberinto de libre diseño. Usando la librería Newflags.h, reservo 10x10=100 flags para crear una máscara con la forma del minilaberinto: 0=vacío, 1=sólido. De este modo, tanto en los movimientos del jugador como en los de los PSIS se puede saber automáticamente las salidas disponibles en cada casilla, hacia dónde se puede pasar y hacia dónde hay pared.
Cada PSI es una unidad-horda de enemigos compuesta por un número de ellos. Debido a la anchura de los túneles del laberinto, no cabe más de una horda en cada casilla, o en cada frente (cuatro frentes posibles) desde el que se aborde al jugador, por lo que unas hordas así mismo hacen de obstáculo a otras hordas, que aguardarán detrás para atacar. No obstante, según liquidemos enemigos y a medida que quede espacio, se producirán transvases de indivíduos de las hordas que esperan detrás hacia las hordas en primera fila. Aunque tengo que reconocer que desde el punto de vista conversacional este proyecto es un coñazo de jugar, por lo que está orientado a una parodia. Los mapas son para testeo, no salen en la perspectiva del juego. Aunque en el primer proyecto incluiré un acceso al mapa, porque merece la pena poder observar el deambular de los ciudadanos.
Voy a poner una brújula gráfica que indique las salidas de cada localidad. Para aligerar en la medida de lo posible la aparición de vocabulario repetitivo en las descripciones: cosas como "puedes ir hacia el Norte..." o un listado de salidas no requerido por el jugador con el comando pertinente.
Aunque en muchos casos será inevitable que aparezcan puntos cardinales en la descripción. De otro modo, si por ejemplo a lo lejos vemos un molino, sin más, podríamos tener que pasar por otros sitios antes de -por descarte- saber que la dirección que conduce a él es noroeste.
Para lugares sin referencias lejanas ni caminos, como un bosque cerrado, funcionará bien. -Ahorra texto repetitivo en la descripción. -Ahorra tener que escribir el comando salidas. -Ahorra jugar a los coches de choque para buscar salidas.
Primero hice un par de diseños que se basaban en dibujar un centro y en torno a él las diversas ramas de las direcciones, una a una en función de que existieran esas salidas. Pero finalmente he optado por poner un gráfico con la brújula entera, con todos los puntos cardinales, arriba y abajo, y entrar y salir; y oscurecer con PNG transparentes las salidas no disponibles. Es más sencillo y me permite cambiar los colores de la brújula editando un único gráfico. Para ello creo una ventana gráfica nueva en un lateral: gg_ventana2, y aprovecho la librería NewFlags.h, que por otro lado voy a utilizar para más cosas. La función que dibuja la brújula será llamada cada vez que se repinten los gráficos, al cambiar de localidad, o manualmente cuando un evento modifique las salidas.
[dibujabrujula i loc; loc = location;
!dibujo la brújula entera: glk_image_draw(gg_ventana2,GRAF_brujula_base,5,15);
!pongo a 0 los flags que almacenarán las salidas viables: for(i=10:i<22:i++)ClearFlag(i);
!busco direcciones viables... y VISIBLES, !parte de código copiado de la rutina de listado de salidas de la librería en español: if(location~=TheDark) objectloop (i in compass) { if (loc provides (i.door_dir) && metaclass (loc.(i.door_dir)) ~= nothing or string) { switch(i){!sw nw_obj: setflag(15); ne_obj: setflag(14); sw_obj: setflag(17); se_obj: setflag(16);
!sombreo las direcciones no disponibles con diversos PNG trasnparentes !ajustados a las formas de cada parte de la brújula: for(i=10:i<22:i++){ if(Flagoff(i))switch (i){!sww 10: glk_image_draw(gg_ventana2,GRAF_brujula_sombra0,65,14); 11: glk_image_draw(gg_ventana2,GRAF_brujula_sombra0,65,94); 12: glk_image_draw(gg_ventana2,GRAF_brujula_sombra90,4,75); 13: glk_image_draw(gg_ventana2,GRAF_brujula_sombra90,84,75);
Ectocomp 2026: 63 trabajos publicados
-
Hace no más de media hora ha concluido el período de creación de trabajos
para la edición 2026 de la Ectocomp, dando como resultado la publicación de
7 t...
Traspaso a Substack.
-
Os aviso por aquí que aunque voy a seguir manteniendo de momento este blog
por razones históricas, estoy moviendo mi actividad de bloguera a Substack.
Aq...
Dialogue Expressiveness in Mask of the Rose
-
Mask of the Rose is a dating-and-murder-mystery virtual novel set in
Failbetter’s Fallen London universe. In line with that genre, it typically
gives the p...
Repertorio de acciones en Inform
-
[image: Captura de pantalla de la FI Alien: La aventura]
*Alien: La aventura* (Alpha Aventuras 2008−2018)
El analizador de comandos de toda ficción inter...
Abandonada
-
...¡y por fin he publicado "Abandonada"!
Ficha en la web del CAAD
Esta aventura se me resistía, la verdad. La escribí desde el principio como
ejercicio par...
I7 6M62 edición de mantenimiento
-
A finales del año pasado, vio la luz una nueva edición de mantenimiento de
I7 (6M62); corrigiendo cerca de 300 bugs reportados.
Los traductores nos topamos...
A Tuenti le molan los developers yonkis
-
Esto viene a ser en cierto modo un epílogo a mi serie de entradas sobre *mi
participación en el concurso Tuenti Challenge*. Si las leíste,
probablemente pe...
YO TENÍA UN JUEGO - La Aventura
-
Bueno,
Pues estamos de vuelta para anunciar que mi nueva aventura ya forma parte
del anuario en DVD de la revista YO TENIA UN JUEGO.
Se trata de una brev...
La Aventura Original -La novela-
-
Como todos sabéis Andrés Samudio presentó recientemente la novelización de La
Aventura Original, posiblemente el juego conversacional que más aficionados
...
Sorcery para iOS
-
Me entero vía Masquedados de la última genialidad de los chicos de Inkle:
la adaptación de los librojuegos de Brujería de Steve Jackson para iOS.
Diente...
Akbarr, el autor y su obra.
-
Hola, gente: Soy nuevo en la lista, así que empiezo contando mi historia. A
mi este tipo de aventuras me gustaban bastante en los tiempos del Spectrum
(ha...
The Humble Bundle
-
English version below. Me encanta esto: tres videojuegos de calidad
(Anomaly, EDGE y Osmos), pagas por ellos lo que quieras, y tendrás
disponibles las vers...
Estación acuario
-
Farmer, tu jefe, y tú viajás despreocupados en vuestra nave de carga
interplanetaria. Sin embargo, un accidente comprometerá la felicidad de
vuestro viaje:...
Ahora que me acuerdo…
-
Este hilo del CAAD con la sempiterna discusión entre parsers me ha
recordado un par de desarrollos que hice hace algún tiempo de cara a mis
proyectos (ejem...
ZMPP viento en popa a toda vela
-
El proyecto de permitir que ZMPP soporte aventuras en formato Glulx de
Wei-ju Wu va viento en popa a toda vela, pronto podrán juagarse todas las
aventuras ...
Dr. Van Halen: Las Ruedas de Ezequiel
-
Suiza, Otoño de 1903
- Aquí lo tienen. Lo encontraron por casualidad más arriba, en las cumbres.
Como pueden ver está congelado desde quien sabe cuándo.- d...