Limbo

Han publicado el trabajo final en Mosaic. En el siguiente enlace podéis ver el estado actual, ya con un nombre (Limbo) y una estética más definida:

http://mosaic.uoc.edu/tfc/eduardoblancoarribas/index.html

Aunque se puede jugar todavía faltan muchas cosas, más efectos de sonido, guardar puntuaciones, mayor interactividad con el servidor de música (ccMixter actualmente), y, sobre todo, unas mejores instrucciones porque no sé si queda demasiado claro el mecanismo de juego.

Todos los comentarios son bienvenidos.

El ritmo

Una de las cosas que he comprobado a la hora de ir montando el juego (experimento, más bien) es la importancia del ritmo: la necesidad de marcar la velocidad a la que pasan los eventos.

En los videjouegos clásicos el ritmo suele ser rápido para evitar que las partidas se alarguen en exceso, aunque cada juego tiene su propio ritmo; en el Tetris, por ejemplo, va muy ligado a la dificultad creciente del juego: al principio las piezas caen lentamente, dejando tiempo para colocarlas adecuadamente, pero en poco tiempo el ritmo se acelera hasta volverse frenético. En los niveles más avanzados apenas vemos las piezas caer.

El ritmo es, por tanto, uno de los factores con el que se manipula el grado de dificultad: al ir avanzando niveles se puede ir reduciendo el intérvalo para colocar la ficha, aumentando el ritmo y la dificultad, ya que el jugador dispone de menos tiempo para buscar la mejor jugada y se puede equivocar más fácilmente.

Hay que compaginar la velocidad del juego a la velocidad de percepción del jugador; si por ejemplo, cuando desaparecen las fichas del tablero al juntar dos estrellas no inserto una pausa y la siguiente pieza aparece inmediatamente, la experiencia se resiente, porque no vemos (no recibimos) una gratificación por el éxito de la acción. Igual pasa cuando cambiamos de nivel, el usuario espera que le demos un respiro.

El ritmo se debe acompañar de sensaciones que lo potencien: musica y efectos visuales. La música, sobre todo, debe funcionar como un metrónomo de lo que pasa en el juego, puede ser relajante o excitante, pero siempre en sintonía con lo que está pasando.

Dentro de Adobe Flash tenemos dos maneras principales para marcar y controlar el ritmo: la velocidad de fotogramas y los intérvalos.

• Con la velocidad de fotogramas (FPS) especificamos la velocidad de redibujo de el juego, por lo que de cara a las animaciones debemos tener en cuenta este factor; por ejemplo, yo utilizo eventos onEnterFrame para crear animaciones al vuelo en Actionscript, si la velocidad de la película es 12 FPS, este evento se producirá doce veces por segundo.


• Los intérvalos (setInterval) se encargan de ejecutar una función cada cierto tiempo. Yo los utilizo para espaciar eventos y ajustar a la velocidad de percepción del jugador: aparición de una nueva ficha, colocación, redondeamiento, bonus, etc.

El objetivo es conseguir un ritmo de juego lo suficientemente rápido para capturar totalmente la atención del jugador pero sin agobiarlo con una dificultad excesiva.

Proyecto 0.3

Concepto del juego (80%)

Montada (a nivel de código) una estructura de niveles con variables independientes (colores, dificultad, fondo, etc).

Realización (60%)

Corregido el "flood fill", ahora funciona correctamente.

Añadido el control con el ratón, ahora el cursor se puede manejar indistintamente con las flechas o con el ratón. Eso facilita el control con una PSP (aunque, por ahora, funciona muy lento para ser jugable).

Modificado el aspecto visual, ahora las uniones entre las piezas se ven más claras porque se redondean las esquinas; para ello he dividido cada pieza en cuatro clips (uno por esquina) con diferentes estados en función de las casillas circundantes.

Fondo con imagen (para la ocasión he puesto un motivo navideño :)

Modificada la animación que mostraba el tiempo restante para colocar la pieza; en vez de un zoom de la siguiente pieza hay una pequeña animación en las líneas interiores del cursor.

Música: muy preliminar, pero tenía curiosidad por ver como quedaba; descarga una lista de reproducción desde ccMixter y pone las urls de los mp3 en una matriz para reproducirlos.

Advertencia: los colores y la mayor parte de la presentación del juego es provisional y cambiará cuando toda la mecánica del juego esté bien definida.

Arkanoid

Aunque he escogido Arkanoid como ejemplo más conocido, el concepto original del genero "rompeladrillos" se remonta al Breakout de Atari, a principios de los 70, que a su vez era una evolución del primer videojuego de la historia, el Pong. Manejamos una "pala" (una barra deslizante) en la zona inferior de la pantalla, se desliza sobre el eje horizontal, y tenemos el objetivo de romper unos "ladrillos" utilizando la pala para hacer rebotar una bola, siempre impidiendo que se escape por la parte inferior (lo que nos haría perder una vida).

Taito cogió el concepto original y lo refinó para lanzar en 1986 Arkanoid, un gran éxito que tuvo una secuela al año siguiente, Arkanoid 2, the Revenge of Doh. Respecto al Breakout se añadían las siguientes novedades:

• Estructura de niveles, con patrones diferenciados y dificultad creciente.
• Enemigos, pequeños "aliens" que revolotean por la pantalla modificando la trayectoria de la bola.
• Bonus, al eliminar algunos ladrillos caían bonificaciones que proporcionaban alguna ventajas, como longitud extra de la pala, enlentecer la bola, "pegar" la bola a la pala, bolas múltiples o un laser, el más deseado, con el que podíamos disparar.
• Una historia (poco creible) sobre una invasión extraterrestre y una nave legendaria, la Vaus.
• Un enemigo final, en el nivel 33.
  

Arkanoid seguía utilizando un método de control indispensable en estos juegos, un dial, un botón giratorio que nos permitía un control exacto de la pala y que se podía simular con otros controles analógicos (como un ratón) pero no con una joystick o pad digital.

Además de las dos secuelas de la propia Taito, la influencia de Arkanoid es tan grande que no hay plataforma de juegos que no cuente con una o varias versiones de este rompeladrillos.

Las claves:

• Concepto de juego muy sencillo, impedir que la bola salga de la pantalla dirigiéndola para romper los ladrillos.
• Requerimientos sencillos, Breakout funcionaba sin transistores.
• Dificultad creciente (aunque es difícil de entrada para los jugadores poco experimentados).
  
• Juego arcade, se requieren habilidad y reflejos.
• Estructura de niveles con patrones de ladrillos diferenciados para evitar la monotonía.
• Muy dependiente del sistema de control (dial).

Para saber más:

• Artículo sobre Arkanoid en la Wikipedia (inglés)
  

Proyecto 0.2

Concepto del juego (75%)

Preparado para la posibilidad de añadir más colores.

Realización (40%)

Menú básico para iniciar la partida (y para activar los controles).

Incorporada rutina para limpiar el tablero cuando 2 estrellas o más se comunican. Está basado en el algoritmo 4-Way Flood Fill, que debido a las pocas casillas del tablero funciona bien a pesar de la recursividad; para que funcione utilizo 3 matrices bidimensionales a modo de sistemas de coordenadas: tablero, que guarda los colores situados en el tablero, stars, que guarda el color de las estrellas situadas en el tablero y flood, una matriz temporal usada por la rutina del "Flood Fill" para comprobar si una zona de un único color tiene más de dos estrellas. El funcionamiento es el siguiente:

• Cuando se sitúa una cruz en el tablero se oculta el cursor y se lanza la rutina floodFill(color de la estrella) por cada estrella que haya en la matriz stars.
• Si al lanzar floodFill() la casilla en flood ya está pintada es que ya hay una estrella en la zona; hacemos el floodFill() con un valor específico para poder eliminar todas las casillas posteriormente.
• Reiniciamos la matriz flood y limpiamos tablero y stars de las casillas eliminadas
• Si se han eliminado casillas mostramos la puntuación (casillas eliminadas en la jugada).
• Lanzamos nueva cruz.

Funciona bastante bien pero en algunos casos se duplica el lanzamiento de nueva cruz, por lo que falla algunas veces.

Advertencia: los colores y la mayor parte de la presentación del juego es provisional y cambiará cuando toda la mecánica del juego esté bien definida.

El reto

El reto es el objetivo a conseguir en el juego, el ingrediente más importante que empuja al jugador a intentarlo una y otra vez. Finalizar el juego es el reto prioritario, pero no todos los juegos tienen un final, o el final es inalcanzable debido a la dificultad, por lo que en todos los juegos interviene el reto del jugador: conseguir avanzar y mejorar la partida anterior, para ello el juego ofrece unos marcadores de progreso:

• Niveles. Aunque no todos los juegos los utilizan es un recurso muy utilizado para estructurar y proporcionar retos secundarios al jugador: los "final bosses", cambios de escenarios, nuevos puzzles, etc.
• Puntuación. La puntuación conseguida permite observar con facilidad nuestro progreso, e incluso compararlo con el de otros jugadores. Es habitual que el juego proporcione mecanismos para mejorar la puntuación (bonus, multiplicadores, secretos, etc.).
• Tiempo. La duración de la partida, cuando se juega a cambio de una moneda, es un factor básico que tienen en cuenta muchos arcades clásicos. La ecuación entre la dificultad del juego y la duración de la partida ha sido muy utilizado por los empresarios de tragaperras, que podían balancear la dificultad para obtener un rendimiento óptimo de las máquinas. En juegos donde no hay niveles o un final definido durar lo máximo posible es el reto.

Sin reto no hay juego, pero nuestra experiencia nos dice que más importante que el reto es el camino que seguimos para conseguirlo; en otras palabras, disfrutar de una buena experiencia de juego es más importante que conseguir el objetivo propuesto.

Proyecto 0.1

Concepto del juego (70%)

Debemos colocar las piezas (cruces, signos +) sobre el tablero de juego de manera que comuniquemos zonas del mismo color; cuando en la misma zona conviven dos estrellas toda la zona desaparece. El juego termina cuando se acaba el tiempo de que disponemos para colocar la pieza en el tablero.

Las piezas se componen de cinco cuadrados de dos posibles colores y para poder colocar la pieza el espacio debe estar libre o ser del mismo color que el cuadrado que se superpone; si los cinco cuadrados del tablero coinciden con los de la pieza aparece una estrella.

Realización (20%)

Definido el formato de flash: 480 x 272 puntos (aspecto 16:9, misma resolución que una PSP ;)) y 12 FPS. La cuadrícula base del tablero esta formada por unidades de 34x34 puntos (14 de ancho por 8 de alto, sobran 4 puntos del ancho que utilizaré para mostrar un contador de tiempo restante.

Creadas los objetos y variables más basicos, así como los clips de las 6 piezas base (que con cuatro posibles ángulos de rotación forman 24 combinaciones).

Montados los eventos de teclado para los controles del juego, por ahora son las flechas para manejar el cursor en las cuatro direcciones básicas, el espacio para depositar la pieza en el tablero y "escape" para salir de la partida.

La piezas aparecen con un zoom lento que permite ver el tablero; cuando el zoom acaba o el usuario presiona Espacio se lanza la función que deposita las piezas sobre el tablero según unas reglas:

• Si la casilla es gris -> K.O., fin de la partida
  
• Si la casilla está vacía o es del mismo color -> bien, se pinta con el color de la pieza
• Si la casilla es de otro color -> mal, se pinta de color gris

Esta comprobación se hace son las cinco piezas que lleva el cursor (la cruz).

Advertencia: los colores y la mayor parte de la presentación del juego es provisional y cambiará cuando toda la mecánica del juego esté bien definida.