Mostrando entradas con la etiqueta gráficos. Mostrar todas las entradas
Mostrando entradas con la etiqueta gráficos. Mostrar todas las entradas

sábado, 20 de marzo de 2010

Trofeo Orcoscomp

Esta mañana Planseldon me ha hecho entrega de mi trofeo de la Orcoscomp, por El Cristal Rojo:

sábado, 26 de diciembre de 2009

Videos musicales con Pyhton

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.

Aquí está:

miércoles, 29 de abril de 2009

Gráficos con Inkscape

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.






El tamaño de los gráficos es de 720 x 195 px

lunes, 16 de febrero de 2009

portadas estilo años 80

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:


La portada original es del Barbarian.

miércoles, 21 de mayo de 2008

fotografías para ilustraciones

**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.


Lo' pogramas d'oy en día hacen de tó.

martes, 29 de abril de 2008

viernes, 18 de abril de 2008

carátulas (fake)

De la unión de ésta y ésta, sale esta otra:

miércoles, 16 de abril de 2008

carátulas 4






lunes, 14 de abril de 2008

carátulas 3











carátulas 2




repositorio

Eliuk está preparando un "Repositorio de Cover-Art"...

¡¡¡qué puñetas es eso!!!

Una galería de carátulas.

¡Ahhh!

Actualización:
La galería se traslada aquí.

martes, 8 de abril de 2008

carátulas

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.

miércoles, 2 de abril de 2008

PSIS en mallas

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.

(Pulsa aquí para ver el movimiento en vídeo)

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.

domingo, 10 de febrero de 2008

brújula

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);

n_obj: setflag(10);
s_obj: setflag(11);
e_obj: setflag(12);
w_obj: setflag(13);

in_obj: setflag(18);
out_obj: setflag(19);
u_obj: setflag(20);
d_obj: setflag(21);
}!sw
}
}

!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);

14: glk_image_draw(gg_ventana2,GRAF_brujula_sombra45,83,34);
15: glk_image_draw(gg_ventana2,GRAF_brujula_sombra135,25,34);
16: glk_image_draw(gg_ventana2,GRAF_brujula_sombra135,83,93);
17: glk_image_draw(gg_ventana2,GRAF_brujula_sombra45,25,91);

18: glk_image_draw(gg_ventana2,GRAF_brujula_sombracuad,162,95);
19: glk_image_draw(gg_ventana2,GRAF_brujula_sombracuad,162,132);
20: glk_image_draw(gg_ventana2,GRAF_brujula_sombracuad,162,16);
21: glk_image_draw(gg_ventana2,GRAF_brujula_sombracuad,162,55);
}!sww
}
rtrue;
];