Audiogames

From Medialab Prado
Jump to: navigation, search

Contents

Resumen del proyecto

Resumen del proyecto:

El primer prototipo de AudioGame que pretendemos desarrollar en PlayLab consiste en un espacio sonificado interactivo. Procederemos en primer lugar a generar uno, o varios, mundos 3D en Blender, Open Simulator o cualquier programa similar de software libre, contando con un espacio real vacío de dimensiones aproximadas de 3x3 metros en el que se desplazará el usuario. La posición del usuario en el espacio será recogida mediante Open CV y será comunicada al mundo 3D, de modo que el usuario esté interactuando con ese mundo 3D, pero sin verlo. Para que esto sea posible crearemos un programa de sonificación basado en principios sinestésicos visión/sonido que sonificará a tiempo real el mundo 3D dependiendo de la posición y movimientos del usuario en el espacio real. El usuario, que puede ser invidente, se desplaza de este modo por un espacio virtual sonificado, mientras que los espectadores, pueden ver en una pantalla (a la que el usuario no tiene acceso), la interacción del usuario en el mundo 3D.

Memoria del proyecto

AUDIOGAMES'


Idea original:


Proyecto: Utilizar The vOICe para crear Audiogames o como un sistema de realidad aumetada.

The vOICe es un sistema de visión para ciegos consistente en un programa que traduce las imágenes y las convierte en sonidos para que los ciegos puedan “ver con sus oídos” permitiendo que ciegos (incluso ciegos de nacimiento que nunca han visto) perciban imágenes en el cerebro. “Los ciegos familiarizados con la tecnología hablan de 'escuchar un cuadro o de oír un paisaje' ya que la computadora se encarga de traducir para ellos las ondas visuales en ondas de sonido. Un paisaje suena como una melodía, pero no una balada linda sino más bien como alguna canción moderna. Por varios años hemos intentado que los ciegos utilicen estas ondas sonoras para escuchar los obstáculos y evitarlos". Este sistema está obteniendo asombrosos resultados, a la par que muestra la gran capacidad que tiene el cerebro humano de adaptarse a los cambios, siendo capaz de emplear sus recursos de varias formas. Es decir, poco importa el modo en que los datos lleguen al cerebro (en este caso, el sonido), sino que lo realmente importante es el contenido de la información. “Es lo que ha ocurrido con el vOICe, las personas comienzan escuchando sonidos y terminan percibiendo imágenes" Este programa puede ser empleado de forma lúdica. Puede crearse la sonificación de entornos ficticios, de modo que tendríamos una novedosa técnica para generar audiogames, que podrían ser utilizados tanto por personas ciegas, como por personas sin ningún tipo de problema visual (que deberían, eso si, emplearlo con los ojos cerrados). Incluso, esto sí, sólo para personas videntes, podríamos experimentar con la posibilidad de superponer la información visual recibida a través del oído, a la información visual recibida a través de los ojos, con lo que tendríamos un novedoso sistema de realidad aumentada.

Pasos o Tareas: 1. Ponernos en contacto con asociaciones de invidentes en nuestro país para saber si están utilizando ya esta tecnología. - En caso de que ya la estén utilizando recoger datos de usuarios experimentados mediante un cuestionario o grupos de discusión. - En caso de que no la estén utilizando podemos proponer a las asociaciones de invidentes que empiecen a trabajar con The vOICe (al ser una tecnología que puede descargarse gratuitamente y cuyos resultados prometen ser espectaculares, es de esperar que acepten) y así no sólo podemos recoger información de un gran grupo de personas, sino también seguir el proceso de entrenamiento. 2.- Trabajar sobre las sensaciones de los videntes. Experimentar con la tecnología, y hacer experimentar a un número amplio de personas videntes para recopilar información. Para ello podemos solicitar voluntarios videntes para experimentar con el programa. Esto nos permitiría seguir el entrenamiento y los resultados de ambos grupos a la vez, lo que nos dará una maravillosa oportunidad de comparar la evolución de ambos grupos y ver sus similitudes y diferencias. 3. - Si los resultados son los esperados: 3.1. Generar "audiogames" empleando esta técnología, para ello sería muy interesante explorar la posibilidad de sonificar entornos ficticios, aunque para empezar puede resultar más sencillo trabajar con entornos reales que no sean demasiado amplios. Grabar todas las posibles interacciones con el entorno y programar el audiogame con los datos recogidos. Pese a las enormes posibilidades que puede tener el empleo de esta tecnología en la generación de audiogames (como tener en el salón de tu casa, un bosque, o una gran ciudad), presenta una clara limitación con la que debemos contar. Esta es, el espacio sonificado puede ser bastante amplio, pero el espacio real en que nos movemos seguramente sea muy limitado, por lo que es básico, a la hora de generar los audiogames, limitar los movimientos en el mundo sonificado a un espacio reducido, si no queremos chocar contra la pared de nuestra habitación mientras estemos jugando.

3.2. Trabajar la posibilidad de emplear esta tecnología como un sistema de realidad aumentada, superponiendo las imágenes sonificadas a la realidad.


Reuniones previas a PlayLab:

Participantes: Eurídice Cabañes, Luca Carrubba, Oscar Martín.

Al unirse Luca Carruba y Oscar Martín al proyecto, empezamos a estudiar las posibilidades técnicas de llevarlo a cabo. Decidimos, en primer lugar que todo el proyecto se desarrollará con software libre. Esta decisión supone no utilizar The vOICe, sino desarrollar nuestro propio software de sonificación.

Empezamos a trabajar con la idea que nos parecía más sencilla: sonificar un espacio real limitado. Lo que supondría: grabar la sonificación de todos los posibles movimientos de el usuario en el “Espacio 1” (lo llamaremos así, para diferenciarlo del que llamaremos “Espacio real” que sería cualquier espacio vacío en el que se juegue al audiogame) y programarlo de tal modo que las diferentes sonificaciones grabadas se vayan disparando dependiendo de los movimientos del usuario en el espacio real.

El principal problema con el que nos encontramos es el traqueo del usuario en el espacio real en referencia al Espacio 1. Pensamos varias posibilidades: Situar cuatro objetos diferentes, reconocibles por OpenCV (triángulo, círculo, etc. ) tanto en los ángulos del Espacio 1, como en las ángulos del espacio real; Utilizar tecnología Rfid para la localización del usuario en el espacio, etc. Pero no encontramos ninguna de ellas factible. Finalmente, frente al obvio estancamiento en el que nos encontarmos, Oscar propone un cambio de perspectiva, porqué no sonificamos un espacio 3D generado por ordenador, en lugar de tratar de sonificar un espacio real. Esta idea, además de solucionarnos gran parte de los problemas técnicos, concuerda más con la idea original del proyecto (estudiar la posibilidad de sonificar entornos ficticios).

Empezamos a trabajar sobre esta idea y establecemos una nueva descripción del proyecto:

El primer prototipo de AudioGame que pretendemos desarrollar en PlayLab consiste en un espacio sonificado interactivo. Procederemos en primer lugar a generar uno, o varios mundos 3D de dimensiones 3 x 3 m en Blender, Open Simulator o cualquier programa similar de software libre, contando con un espacio real vacío de similares dimensiones en el que se desplazará el usuario. La posición del usuario en el espacio será recogida mediante Open CV y dos acelerómetros y será comunicada al mundo 3D, de modo que el usuario esté interactuando con ese mundo 3D, pero sin verlo. Para que esto sea posible crearemos un programa de sonificación basado en principios sinestésicos visión/sonido que sonificará a tiempo real el mundo 3D dependiendo de la posición y movimientos del usuario en el espacio real. El usuario, que puede ser invidente, se desplaza de este modo por un espacio virtual sonificado, mientras que los espectadores, pueden ver en una pantalla (a la que el usuario no tiene acceso), la interacción del usuario en el mundo 3D. Y establecemos el perfil de los colaboradores que necesitaremos:

Se necesitan 3 grupos diferentes de colaboradores: Para el espacio 3D: Personas con conocimiento de Blender, Open Simulator o cualquier programa similar de software libre, los colaboradores que integren este grupo se encargarán también de la comunicación del trakeo entre el espacio 3D y el espacio real. Para el espacio real: Personas con conocimientos en OpenCV y acelerómetros. Para el espacio sonoro: Personas con conocimientos en OpenCV y PureData.

Planteamos, para hacer la interacción con el mundo sonoro más interesante y que el usuario no se limite a pasear por un entorno sonoro estático, utilizar esferas que tengan una físicas determinadas, y se muevan dependiendo de los movimientos del usuario en el espacio. Oscar empieza a trabajar con la idea y propone un pequeño ejemplo, que encuentra dentro de la librería ANN, de redes neuronales. El ejemplo nos parece muy factible como primer prototipo o como punto de partida, dado que el mundo 3D ya esta creado y sólo tendríamos que modificarlo a nuestro gusto, al igual que el mapeo del audio, aunque en este caso habría que mejorarlo con sonido cuadrafónico para obtener una percepción espacial mas completa. El ejemplo consiste en una esfera mayor (que es la que podemos controlar con el ratón, o que, en nuestro caso sería el usuario4) y seis mas pequeñas, que tienen cierta atracción entre sus masas, y pueden ser desplazadas mediante “choques”. En este ejemplo, la visión exterior sería desde el punto de vista desde arriba igual que la cámara tracking, en lugar de ser en primera persona. Esto supone que se trate de un espacio 3D el movimiento sólo sería en 2D, lo que haría más sencilla la parte técnica. Planteamos emplear este ejemplo como punto de partida.


PlayLab:

'Día 1: Presentación del proyecto (21-Enero-2010)

Día 2: Primer día de trabajo colaborativo (22-Enero-2010)'

Participantes: Eurídice Cabañes, Luca Carrubba, Jaume Castells, Oscar Martín, Antonio Jesús Sánchez Padial, Carlos Sánchez Padial.


Inicio:

Revisamos la idea del proyecto, para localizar los puntos que pueden resultar problemáticos, encontramos problemas en:

1.Sistema de trakeo:

1.1. El sistema de trakeo con la cámara puede fallar. Solución propuesta: Crear un sistema de trakeo alternativo por si no funciona la cámara: Alfombra táctil.

1.2. Calcular la dirección u orientación de la mirada con acelerómetros puede dar errores de resolución que sumados pueden dar lugar a una desorientación total si no establecemos un punto de inicio. Solución propuesta: En lugar de los acelerómetros usar una línea de leds sobre la cabeza del usuario. Nuevo problema: no permitiría diferenciar hacia donde mira realmente, ya que indicaría 2 posibles direcciones. Solución: en lugar de una línea de leds, situar dos en la parte trasera de la cabeza y uno en la delantera.

1.3. Sistema a utilizar para el trakeo: Se debate entre PD Grill y OpenCV. Ventajas de PD Grill son: es parte de la librería PD hecho específicamente para esto. Desventajas: Sólo te da el punto en el que se encuentra el usuario en cada momento. Ventajas de OpenCV: da muchos más parámetros: dirección, velocidad... Desventajas: Es una librería externa, es muy grande para lo que pretendemos. Decisión: Probar con ambos

2. Mecánica del juego:

Tras las críticas recibidas en la presentación, decidimos replanteamos la idea original de generar un entorno sonificado interactivo, y convertirlo en un juego con objetivos.

Lluvia de ideas: Añadir jugabilidad con los acelerómetros añadiendo movimientos corporales específicos que constituyan nuevas acciones posibles, por ejemplo, permitiendo pasar de un espacio a otro dando un giro de 360º Hacer un tipo de arcanoid con 4 paredes. Simular el juego infantil de juntar formas análogas, es decir colocar objetos de formas concretas en agujeros con su misma forma. Añadir un objetivo al mundo sonificado con esferas planteado: Hacer que las bolas desaparezcan cuando toquen una pared concreta. Simular la dinámica de PacMan, añadiendo un bonus y un malus, de modo que el contacto con malus te mate y el bonus te permita “comerte” las bolas, es decir, que desaparezcan al contacto con el usuario.

Solución decidida: Usaremos la última idea, PacMan sonoro.

Dinámica de Juego:

Decidimos finalmente la idea de hacer el Pacman sonoro, entre otras cosas porque soluciona la disyuntiva entre hacer un espacio interactivo sonificado y hacer un juego con objetivos, ya que incluye las dos. En un primer momento el usuario se relaciona con el entorno sonoro, y con su propia interacción con las bolas, que simplemente rebotan en el. En un segundo momento, posterior al contacto con el bonus, se convierte en un juego cuyo objetivo es hacer desaparecer las bolas (que desaparecen al contacto con el usuario).

Elementos del AudioGame:

- Bolas objetivos: rebotan en el usuario (sin no se encuentra en estado “bonus”) / desaparecen al contacto con el usuario (durante los 20 segundos posteriores al contacto del usuario con el bonus)

- Bola malus: elimina al usuario al contacto con él (si no se encuentra en estado “bonus”) / hace perder el bonus al usuario al contacto con él (durante los 20 segundos posteriores al contacto del usuario con el bonus)

- Bola bonus: te permite “comer” bolas, hacer que las bolas desaparezcan al contactar con el usuario, y no morir (sólo perder el estado “bonus”) en el caso de contacto con la bola malus.

Posibles sucesos de los elementos descritos:

Bolas objetivo: Se mueven Chocan: contra el usuario, contra las paredes, entre sí. Desaparecen (son “comidas” por el usuario)

Bola bonus:

Desaparece (es “comida” por el usuario) Vuelve a aparecer (cuando desaparece el estado “bonus”) Es estática (al menos en el primer nivel que pretendemos desarrollar en el contexto del PlayLab, se plantea que en niveles posteriores adquieran movimiento que se acelera en cada nivel para añadir dificultad).

Bola malus:

Desaparece (es “comida” por el usuario) Vuelve a aparecer (tras desaparecer al contacto con el usuario que se encuentra en estado bonus, ya que si el usuario no está en este estado simplemente termina el juego). Es estática (al menos en el primer nivel que pretendemos desarrollar en el contexto del PlayLab, se plantea que en niveles posteriores adquieran movimiento que se acelera en cada nivel para añadir dificultad).

Jugador:

Choca con las bolas Sale del área del juego Entra en estado “bonus” Finaliza el nivel (en el primer prototipo gana el juego, en los posibles desarrollos posteriores pasa al siguiente nivel)

Se plantea que el AudioGame va a tener dos tipos de sonidos: Sonificación del espacio Sonidos añadidos (efectos especiales)

Y planteamos cuáles de los posibles sucesos de los elementos del juego deben tener asociados efectos especiales y cuáles.

Comer bonus: Sonido especial. Definir cual. Estado “bonus”: cambio de pitch a los sonidos espaciales Comer malus: Sonido especial. Definir cual. Comer bola: Sonido especial. Definir cual.

Choque bola: Con la pared: sonido especial. Definir cual Con el usuario: vibración de los acelerómetros que el usuario lleva en la cintura Entre ellas: sonido especial. Definir cual.

Planteamiento del desarrollo técnico: Arquitectura.

Elementos de entrada: Imagen cenital de la cámara Elementos de salida: Imagen tridimensional, Audio sobre cuatro altavoces

Alternativas para la captura de imagen: OpenCV, PD Grill

Alternativas de renderizado 3D: Blender, seleccionado por su mayor calidad, GEM (módulo de PureData)

Alternativas de salida de audio: Pure Data

Alternativas de motor de física (“Physics engine”) Blender, requiere que Blender reciba los datos del trackeo, procese los movimienntos y devuelva esta información a PureData para que procese el audio. Un módulo de PureData, en este caso al estar todo centralizado en PureData solo hay comunicación hacia Blender para indicarle la posición de los elementos del juego en cada frame. Se escoge la segunda opción que simplifica las comunicaciones entre distintas plataformas de desarrollo.

Alternativas de comunicación entre módulos: OSC (Open Sound Controller)

Experimentamos con PureData enviando el color de un elemento a Blender de forma satisfactoria. Sin embargo, parece que mientras Blender está procesando la información de entrada de OSC el rendimiento del sistema baja a 2 frames por segundo (fps)

Días 3 y 4: Desarrollo técnico (23/24-Enero-2010)'

Surgen los primeros problemas:

Tarjeta de sonido: La tarjeta de sonido proprocionada por MediaLab no funciona para Linux con 4 canales, no conseguimos configurar la salida de audio para cuatro altavoces (sólo funcionan 2 canales, lo que no permite el sonido estereofónico que necesitamos). Solución: Solicitar una tarjeta de sonido de 4 canales que estemos seguros que funcione con Linux.

Cámara para trackeo: La cámara que nos proporcionan en MediaLAb, una Unibrain Firefly, es un camcoder IIDC, da problemas en Linux. Solución: Para utilizar Unibrain Firefly (un camcoder IIDC) en Linux necesitas del programa Coriander. Para poder utilizar el stream de la cámara con otros programas necesitas enviar el flujo desde el Coriander pasando por un Device vistual Video for Linux.(V4L) (V4L2 no es válido). Para hacer esto se necesita de un módulo del Kernel que se llama VloopBack. Problemas de este módulo: ya no se desarrolla oficialmente y hay una versión para cada Kernel. Es muy importante usar la versión del módulo para tu Kernel, ya que sino no funciona. Una vez cargado el módulo (Modprobe vloopback) hay que darle los permisos a todos los device vídeo (Chmod 777 /dev/video*) , después se abre el Coriander, se arranca la cámara y en el Tab V4L se pone el device virtual de entrada que ha generado el módulo vloopback (mira dmesg para conocer el device virtual generado). Si todo ha salido bien utilizarás el device virtual de output como cualquier device V4L (el módulo vloopback genera, de hecho dos devices virtuales, uno de entrada y uno de salida).

Nota: Si tienes una webcam integrada V4L2 fuerza el uso del protocolo V4L a través del mando V4L-conf.


Mapa de comunicaciones OSC:

Identidad: track [SEND TO 10.0.0.2 to port 9999], render [is 10.0.0.2 receive to port 9999, send to 10.0.0.3 to port 9998], audio [is 10.0.0.3 receive to port 9998]

flux1: track2render

flux2:render2audio


flux1:

/player/x

/player/y

/player/orientation


flux2:

/player/x

/player/y

/player/orientation

/bola1/x

/bola1/y

/bola2/x

/bola2/y

/bola3/x

/bola3/y

/malus/x

/malus/y

/bous/x

/bonux/y

/choca/pared [bang]

/choca/bolas [bang]

/choca/malus [bang]

/choca/bonus [bang]



Reuniones entre talleres (27-Enero-2010 y 3-Febrero-2010)'


Las comunicaciones parecen resueltas.


Sobre la visualización

Los problemas que arrojaban al Game Engine hasta los 2 fps eran suma de un primer caotico uso de los puertos OSC y de una falta de control de la frecuencia de envios.

Esta es la libreria utilizada para establecer comunicaciones OSC en blender.

Open SoundControl for Python
Copyright (C) 2002 Daniel Holth, Clinton McChesney
GNU Lesser General Public License

Dado que en Blender todo se almacena en bases de datos de objetos relacionados, se puede interactuar con el bloque logico del engine a traves de scripts en python, pero respetando sus convenciones. El jugador, siempre es referido por un enlace al objeto OBjugador. Para enviar las posiciones y colisiones, se recurre a solicitar un informe al GameLogic, empaquetando los datos y creando automaticamente los Address con el nombre del objeto vinculado.

OSC permite el envio de varios mensajes empaquetados en "bundles". Una de las ventajas es que todos los mensajes llegan a la vez, con una etiqueta de tiempo.

Dado que queremos un refresco controlado de los datos en los tres ordenadores, optamos por enviar a 25 fps. Para evitar que el game engine se demore abriendo y cerrando puertos se creara un unico script "de funcionamiento perpetuo" que envie todo lo que sucede, a ser posible, 25 veces por segundo.

Por todo lo cual, se requiere una RMCOSC.


Revision del Mapa de Comunicaciones OSC: ---

Identidad: track [SEND TO 10.0.0.1 to port 9999], render [is 10.0.0.2 receive to port 9999, send to 10.0.0.3 to port 9998], audio [is 10.0.0.3 receive to port 9998]

flux1: track2render

/OBjugador [ x , y , orientacion ]


flux2:render2audio

/OBjugador [ x , y , orientacion , colision ]

/OBbola1 [ x , y , colision ]

/OBbola2 [ x , y , colision ]

/OBbola3 [ x , y , colision ]

/OBmalus [ x , y , colision ]

/OBbonus [ x , y , colision ]

/eventos [ vivo , bonus , comebola , dentro ]

---

Todas las coordenadas son Float y todos los eventos Booleanos, bangs.

Aun no sabemos que metodo utilizaremos para la orientacion, pero seguramente sea un vector.

colision es cualquier colision, ya sea contra otro objeto , contra la pared o contra el jugador. Se me hace complicado para el game-engine (no digo que no se pueda) que la pared emita la localizacion en la que es chocada, ya que todo lo calculado aqui se basa en los centros de los objetos, y no en el punto real donde chocan. El centro del la pared es el centro del tablero... Cuando la colision es contra el jugador, a veces se desata un evento.

vivo, es true mientras dura el juego y la bola malus no te mata.

bonus, es false hasta que te comes la bola bonus. Dura 20 seg o hasta que te comes la bola negra. Hace que varie el sonido y que pueda haber comebola-true

comebola es true cuando el jugador se come una bola, el sonido obviamente siempre sucede alrededor de la posicion del jugador.

track lee la camara, calcula la posicion y hace un solo envio cada 1/25 render recibe un envio, calcula fisicas y eventos, y realiza un envio cada 1/25 audio recibe el envio, espacializa el sonido y lo emite.

--- Sobre los colores de los sonidos

Dado que los sonidos se mezclan en el espacio antes de llegar a nosotros, dando lugar a nuevos sonidos, se podria simular este hecho con el de las longitudes de onda de la luz, haciendo que cada bola emita luz en una frecuencia y que esas luces puedan sumarse (para dar nuevos colores). Lo ideal en este caso, una bola roja, una verde y una azul.

Siguiendo este modelo asigno negro para la bola malus y blanco para la bola bonus. La bonus tiene un foco de luz blanca que lo destaca hasta que nos comemos la bola, momento en el que para indicar que estamos en estado "bonus", la bola desaparece y el foco nos sigue a nosotros, protagonistas ultimos del pacman audible.

Cada vez que nos comemos una de las bolas, estas desaparecen y nosotros pasamos a obtener el foco de color que lo ilumina. De este modo el jugador gana intensidad de luz cada vez que gana puntos.

Ademas de estas cuestiones de color, he probado una sinestesia de lo que me imagino que es el equilibrio del jugador. Cuando uno esta en un borde del tablero, todo es mas facil, ya que todos los sonidos estan a un solo lado... Cuando vamos al centro es de esperar que los sonidos nos envuelven y aislan mas de la realidad.

Para simular esto (o tal vez solo para marear al espectador un tanto de lo que se marea el jugador) he definido el tablero como flotante, de modo que cuanto mas se adentra el jugador en el tablero, este se eleva del suelo. Cuando el jugador se acerca al borde el tablero baja y el jugador puede abandonar el tablero.

Ademas, como al salir del tablero se apaga todo sonido virtual, la imagen se vuelve monocroma y todos los focos de cada bola se apagan.

Por desgracia estas cosas hacen que el frame rate baje a 10fps


Problemas actuales en el Game-engine de blender

cuando se come alguna bola, esta deja de existir... y la lista de objetos para enviar (el for) da un error con la bola en cuestion.

Como me puse artistico en la visualizacion el frame-rate ha bajado muchisimo. He incluido un control para activar/desactivar las florituras. Se ve en la imagen "0-configuracion".

La velocidad viene siendo de 10 a 12 fps, tanto en pequeño como en full screen (por culpa de los efectos visuales añadidos, aunque es posible que todo ese script se pueda optimizar.)

Si desactivamos el suelo flotante y las luces que se encienden cuando el jugador se sale, el juego recupera hasta los 45 fps en ventana pequeña y unos 17 fps en fullscreen.


Parte sonora:

La tarjeta nueva funciona bien con Linux.

El módulo para la espacialización y sonido de juego lo estamos construyendo en el entorno de programación PureData (PD). Para la especialización trabajamos a partir del material que se generó en el workshop realizado por Georg Holzmann en Linux Audio Conference 2007 “Sound spatialization in PD”

Utilizaremos dos algoritmos de decodificación “Ambisonic” que nos permiten reproducir un sonido situado en un espacio 3D y desplazarlo en ese mismo espacio y rotarlo, etc. en relación con un oyente.

Para la reproducción utilizaremos también el equipo de sonido multicanal de 4 altavoces: Ambisonic 2nd orden.

Resultados

A lo largo del taller conseguimos tener un primer sistema de trackeo (algo limitado pero funcional), un mundo 3D con las dinámicas del juego (con algunos problemas a solucionar), y un mundo sonoro. La comunicación osc entre trackeo y mundo 3D funcionó bien, pero debemos solucionar algunos problemas en la comunicación entre este y el mundo sonoro.

descargar libros gratis

Documentación (gráficos, fotos y vídeos) / Documentation (graphics, pictures and videos)

1-P1030567.JPG

2-P1030574.JPG

3-P1030571.JPG

DSC 1873.JPG

0-audiog-configuracion.jpg

1-audiog-comienza.jpg

2-audiog-cochanbolas.jpg

Si te sales del tablero...

3-audiog-estas fuera.jpg

Si coges el Bonus...

4-audiog-cogeUP.jpg

Si te comes la roja...

5-audiog-secomelaroja.jpg

...y luego la verde, luces de amarillo.

6-audiog-secomelaverde.jpg

Si te comes la negra el Bonus aparece de nuevo

7-audiog-secomelanegra.jpg

8-audiog-gana.jpg



Mientras probabamos el tablero movil sucedio un tragico accidente.

Suponemos que es por miedo a estos percances por lo que las bolas van mas lentas cuando la plataforma flota. Audiog-terribleaccidente.jpg Necesitaremos muchas bolas.

Miembros del grupo de trabajo

Eurídice Cabañes: euridice.cabanes at arsgames.net

Luca Carrubba: husk00 at gmail.com

Jaume Castells: zamme at svmres.org zamme at jabberes.org(only instant messages)

Oscar Martin: noishx at gmail.com

Links

friv

friv 4 school

Bankruptcy Attorney Tulsa OK

Chapter 7 Bankruptcy Oklahoma

Oklahoma Bankruptcy Laws

Criminal Attorney Tulsa OK

Oklahoma Expungement Laws

Oklahoma Felony

Misdemeanor Charges in Oklahoma

Oklahoma Governor Pardon

Immigration Attorney Tulsa

Oklahoma Lawyer

Tulsa Divorce Lawyer

accident injury settlement

купить курительные миксы в Омске

Discount Furniture stores in Phoenix

Furniture Stores in Mesa AZ