The ZoninRun finiquitado

Acabo de subir la primera versión de The ZoninRun (el clon del QIX programado con Pygame)
http://sites.google.com/site/venenariusverborum/programas-1

La he terminado un tanto bruscamente pues se me habían quitado las ganas de seguir, y conociéndome, si no lo remataba ya, se podía quedar años paralizado o no llegar a salir nunca.

Los niveles no están demasiado bien calibrados en dificultad, espero arreglarlo en una futura segunda versión.

QIX

Estaba tratando de recordar un juego de hace un porrón de años que jugué en el ordenador PC de unos vecinos.
Lo expuse gráficamente en StripGenerator y rápidamente llegó la respuesta, del juego base: QIX

El que yo recordaba sin duda estaba basado en QIX, pero era un clon diseñado para multijugador. De modo que entre 2 y 4 jugadores competían apiñados en torno al teclado, cada cual con su propio vector, cerrando sus áreas y tratando de no ser pillados por los rivales con un área sin cerrar.

O al menos esa es la idea que tengo y lo que estoy programando con Pygame. Lo más difícil ya lo tengo hecho, el relleno de las áreas, que me dió varios quebraderos de cabeza este domingo... hasta que dí con la maldita línea que estaba estropeando el invento, la pulga que hacía que la máquina cascase.

El resultado es éste:

Cuando se prevee el relleno de un área porque un jugador ha realizado un cierre, se ejecuta un rastreo en busca del contorno, o mejor dicho, de los dos contornos posibles.
Desde la cabeza del vector hasta el punto de despegue sólo hay un camino, pero una vez llegamos ahí...¿bordeamos el contorno en sentido horario o antihorario?
Tomamos ambos caminos, calculamos las áreas encerradas -aproximadamente mediante un algoritmo rápido que encontré googleando-, y elegimos el que encierre un área menor (de lo contrario la partida podría quedar decidida nada más empezar).
A continuación, rellenando una matriz con las coordenadas de los puntos recogidos a lo largo del contorno donde éste hace quiebro, se rellena el polígono resultante.
Si se superase el tamaño de la matriz definida el relleno quedaría incompleto. Le he puesto 250 (por ejemplo) coordenadas de límite, que creo que raramente se alcanzarán en un juego real por muchas revueltas que logre dar un jugador.

En el juego competirán hasta 4 jugadores, que parten de los 4 lados del campo de juego cuadrado.Ganará el que más halla rellenado de su color al final de la partida, debiendo para ello ir cerrando rastros de su propia cola con los bordes del campo o con los nuevos bordes creados que delimitan las zonas coloreadas por cualquier jugador (aquí líneas naranjas).

Hay tres formas de fipiarla:
1. Autoatrapamiento

2. Ser rellenado por otro jugador

3. Ser alcanzado en la cola por otro jugador antes de haber cerrado contorno.

Estas pifias te dejarán fuera de juego, pero no te quitarán los rellenos conseguidos, de modo que la partida no está necesariamente perdida.

Estaría bien poder jugar esto en red, pero al igual que ocurre el Armagetron, el lag es todo un problema, cuando tú ves que has cerrado a un rival... y luego resulta que a quien han cerrado es a tí.
Aunque el mayor problema es que ni si quiera sé hacer funcionar esto en red.

Enlaces:

Versión online del QIX original

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á:

El Wargame y la Aventura 2D en acción

Unas capturas subidas a Youtube:

pythoneando

Empecé a primeros de Julio a investigar Python+Pygame, y la verdad es que ha cundido la cosa. Este blog que al principio pretendía ser de programación de Inform, y luego pasó a ser de programación y chismorreos caadianos, va a terminar por ampliarse a blog de videoaventuras en general. Esto es: videoaventuras conversacionales, videoaventuras de plataformas, videoaventuras de mesa...

Empecé realizando el proyecto que tantos años deseaba hacer y no pude por mi falta de conocimientos de programación: una aventura 2D tipo Another World, que cumpla ciertos aspectos que considero importantes:
-Gravedad e inercias reales, velocidad, nada de saltos fantasma en plasma líquido. Puedes controlar los saltos mientras en la animación el personaje tenga algún pie en el suelo; una vez en el aire, éste sigue una trayectoria invariable salvo que se estampe con alguna masa.
-Transiciones entre acciones: no puedes pasar de correr a andar así sin más, ni cambiar de dirección sin amortiguar la inercia. Mismamente, si vas corriendo y pulsas para salto de longitud, el comando no se ejecutará instantáneamente sino en el momento en el que termines la zancada, para tomar impulso, como lo antes dicho.

Para esto las acciones van por pilas: accion_actual y accion_siguiente, la cual salta cuando el frame de transición sea el correcto.

Más o menos he conseguido el motor, más o menos porque se podría mejorar con más fidelidad, pero es un coñazo dibujar tantos frames.
Grabación en video->volcado->selección de fotogramas->calco en vectorial->conversión en bitmap->edición->"amontonamiento" en capas->grabación en PNG

...

Como me estaba saturando de este proyecto, y no estaba inspirado para un buen guión, carpetazo y quise hacer un juego de mesa tipo risk.
31 territorios y 8 emperadores rivales por conquistarlos.

El sistema de lucha será sencillo: 2 contra 3 = mueren dos de cada ejército y gana el segundo con una tropa viva; con algunos modificadores: los que atacan tienen un porcentaje de desventaja; también se acumula un portentaje negativo si atacan una ciudad fortificada (hasta tres niveles de fortificación); o si atacan un reino montañoso, donde mismamente los que ya están ahí esperando tienen ventaja posicional sobre los que llegan.
El sistema se irá calibrando cuando funcione.

También barajo -utópicamente- hacer los combates jugables, de forma que el 2 contra 3 ganan los segundos sea más relativo (aunque 2 contra 4 ni de coña), adquiriendo la piel del general que da las órdenes, las cuales son transmitidas por los músicos con códigos de trompetiles, y con muchas animaciones "jolgoriosas" de fondo (si no, no mola):
¡arqueros!, ¡primera línea avance!, ¡atrás!... tipo Patapón-pon-pata-pon.

El proyecto 1: Las criaturas humanoides, llamadas naar, tienen cada una un rostro diferente y personal, aunque no se aprecie mucho. Superpongo una máscara translúcida con los matices... y, anden, corran o salten, la cabeza siempre horizontal :D La máscara es de boca para arriba, para hacer comunes los frames de cuando muevan la boca para hablar.

El war-game, en el que de momento no se puede hacer nada más que pasear el ratón por el mapa y curiosear.
El menú de la derecha son las acciones básicas (sin implantar):
-Mover tropas
-Fortificar un sitio
-Reclutar hombres.
Faltan:
-Trasladar la capital del Imperio ( si cae una capital el conquistador se queda con todo, aunque para conquistar una capital, además de enfrentarse a las fortificaciones y tropas que allí se hallen, hay una guardia pretoriana fija, y de regalo, que vale como 3 o 4 tropas)
-Enviar órdenes (las acciones no se ejecutarán hasta que envíes las palomas mensajeras a tus generales repartidos por el imperio). Una vez enviadas, correrá el turno (el mes), se verán los resultados, y los movimientos que han hecho los emperadores rivales.

En fin, lo más importante de Python es esto:

# -*- coding: iso-8859-1 -*-

¡¡¡Sin esta línea mágica no se pueden escribir acentos ni eñññññññes!!!