Páginas

martes, 15 de abril de 2014

Bike Assault - Lanzamiento y detalles sobre el desarrollo

¡Buenas!

Ha pasado más o menos un mes desde que Firemen Rush fuera publicado en la App Store, y aquí estamos ya dando la vara con otro minijuego gratis y universal para iOS al que hemos titulado Bike Assault:



REFERENCIAS


Pues sí. La gente que nos haya seguido durante nuestra etapa en RPG Maker habrá reconocido perfectamente que Bike Assault está basado en otro minijuego que ideamos para Resident Ibol, nuestro fan-game de Resident Evil 2. En aquel minijuego manejabas a Claire en moto durante un rato esquivando tráfico. Si además cogías muchos tíos amarillos (que son Chiyo-chichi de Azumanga Daioh), al final del trayecto obtenías una pistola para comenzar la aventura con un poco de ventaja.

GAMEPLAY


Bike Assault ofrece una jugabilidad similar al citado minijuego, pero mejorada y adaptada a dispositivos táctiles. Manejas a una chavala en moto cuyo parecido con Claire de Resident Evil es pura coincidencia (inserte aquí un careto mirando al tendido). La chica necesita dinero urgente para sus propios menesteres y la solución más lógica es atracar un furgón blindado. Por tanto, se inicia una persecución por la autopista donde tu objetivo es disparar a las puertas traseras del furgón para abrirlas y coger toda la pasta posible. Los peligros a los que te enfrentas son vehículos de diversa índole y manchas de aceite en el asfalto. También puedes perder la partida si te quedas sin combustible, pero hemos tenido el detalle de poner algún que otro bidón de gasolina por ahí. Y ya sabéis, consiste en coger más "dineros" que nadie. El juego es una metáfora en sí mismo, que cada uno saque sus conclusiones.

Ah, manejas la moto con el acelerómetro, es decir, balanceando el dispositivo. Creemos que es la forma de manejar vehículos (sean juegos de conducción, de navecillas, etc) que más implica al jugador de un dispositivo táctil, pues la moto siempre está en movimiento y tú has de mantenerla estable. El acelerómetro se calibra automáticamente cada vez que le das a jugar para ajustarse a la posición en la que sostienes el dispositivo en ese instante. Además, siempre podrás pausar y continuar el juego y se volverá a calibrar.

DISEÑO DEL JUEGO

Normalmente el diseño de estos minijuegos consiste en el ligero esbozo de una idea (conducir y esquivar vehículos), y sobre ella definir los elementos jugables. Algo muy importante es definir bajo qué condiciones pierdes la partida. Bike Assault era sencillamente un juego de conducción y supervivencia en su etapa más temprana (esquivar coches hasta que se acabara la gasolina). Luego se añadió el componente arcade al introducir el furgón blindado y el dinero (puntos). En un principio, éste sólo se movía por el extremo derecho de la pantalla y soltaba billetes periódicamente. Finalmente se le permitió moverse por toda la pantalla y además se nos ocurrió que hubiera que disparar a las puertas para abrirlas y propiciar la caída de "los dineros", lo que dio lugar al componente acción.

Para desmitificar un poco el asunto, aquí os mostramos algunos esbozos de sublime calidad e importancia, hechos mientras pensábamos el juego (no es muy diferente de lo que enseñaríamos en una campaña de Kickstarter):


GRÁFICOS

Apreciamos muchísimo el pixel art y pretendemos hacer de ello una marca de la casa. Suponemos que llegará un momento en el que el apartado visual de nuestros juegos hablará por nosotros, y eso es bueno. Que se sepa que una obra es de cierto autor sólo con verla puede que sea uno de los objetivos de todo artista. Nos gusta remarcar que en nuestros proyectos nunca vais a encontrar gore, violencia extrema y gratuita, ni nada desagradable. Difícilmente puede ocurrir esto porque los juegos indie (temática, gráficos, música) son un reflejo de sus autores, y lo cierto es que ese rollo no nos va. A nosotros no nos gustaba Resident Evil 2 por el gore, ni mucho menos, sino porque era un diseño de juego de calidad indiscutible. Y en definitiva, esos detalles de cuestionable gusto no hacen a un videojuego mejor. De nosotros cabe esperar humor y sarcasmo, sobre todo en estas parrafadas blogueras.


Aclarado esto, prácticamente todos los gráficos de este juego están chulos salvo la puñetera furgoneta rosa que Alberto no quiere modificar bajo el cutre pretexto de que así también jugarán las niñas (la realidad es que se trata de un cambio de paleta hecho a la bulla, valga la expresión andaluza). Se ha hecho especial hincapié en la prota y su moto, los vehículos (el que más nos gusta es el jeep) y los edificios de fondo. También íbamos a meter un dirigible como en Scarface con un mensaje algo polémico, pero lo cierto es que tampoco había demasiado espacio con tanto edificio y los condenados maravillosos anuncios. Tampoco hemos metido (aún) el camión de bomberos del Firemen Rush porque sus medidas son algo diferentes a las de los vehículos que aparecen en Bike Assault (es un pelín más pequeño). Nos atrae la idea de compartir referencias y cameos de unos minijuegos a otros, e incluso cameos de juegos de otros desarrolladores indie (previo consentimiento), pero esto ya lo veremos más adelante.


Eso de ahí es el sprite sheet completo del juego. En lo que respecta a presentación, menús y demás, vamos a intentar mantener una misma línea de estilo de un minijuego a otro. Nos gustan las pantallas de título sencillas (fondo oscuro, logo, opciones y créditos) en un claro homenaje a los juegos de SNES y Mega Drive.

PROGRAMACIÓN

El juego es una aplicación universal y funciona en todos los dispositivos y tamaños de pantalla. Como ya se anunció, estamos reutilizando un montón de cosas que ya se programaron en Firemen Rush para acelerar los futuros desarrollos. En cualquier caso, con cada nuevo proyecto, la base siempre mejora y se corrigen cosas, a la par que se añaden nuevas funcionalidades. Para los despistados, usamos cocos2d-iphone como render engine.

No nos gusta mucho la parte técnica del desarrollo de videojuegos, la verdad. Así, por comentar algo, en esta ocasión ha habido dos cosas que han resultado un pelín complejas.

La primera de ellas es la calibración del acelerómetro, mucha chusta matemática que por suerte otros desarrolladores ya habían investigado y amablemente decidieron compartir en su blog. Bastaba con entenderlo, adaptarlo a nuestro proyecto en cuestión e implementarlo. Lo cierto es que esto ya lo habíamos investigado e implementado en el proyecto "Shooter II", pero se ha programado de nuevo desde cero utilizando CoreMotion en lugar de UIAccelerometer, y haciendo uso sólo de las operaciones de vectores necesarias. En fin, chominadas informáticas que lo único que hacen es poner barreras a gente creativa con ganas de hacer juegos.


La otra traba ha sido la colisión entre vehículos, que al principio era muy tosca e incluso ocurrían teletransportaciones dignas de un show de magia. Había que tener varios factores en cuenta, ya que el furgón blindado se mueve a su aire por la pantalla y embiste a los demás, lo cual puede provocar colisiones en cadena. Los juegos, cuando funcionan sin problemas, parecen cosa de niños pero, ¡ay amigo, la cantidad de horas de sufrimiento que hay ahí detrás!

MÚSICA Y SONIDO

Ya sabéis que usamos Logic Pro 9 para este asunto y que nos gusta la música de SNES. Hemos utilizado samples de audio extraídos del juego Macross: Scrambled Valkyrie, aunque esta vez no se trata de un tributo sino que tan sólo hemos utilizado ciertos instrumentos que nos gustaron, es decir, las canciones que hemos hecho no guardan tanto parecido con las originales. En concreto, se han usado instrumentos de los temas Organic Base y Cave. Como siempre, se ha tratado de recuperar el brillo perdido en los samples de baja calidad y además se ha intentado espaciar la mezcla mediante un buen panning de canales y la ecualización individual de instrumentos. El resultado nos gusta, aunque se aleja un poco del sonido SNES. Podríamos llamarlo "estilo SNES remasterizado". La verdad es que para nosotros, que no somos compositores ni músicos, trabajar con un conjunto de instrumentos reducido ya predefinido nos facilita un montón la labor.


En cuanto a los efectos sonoros, casi todos han sido generados con el plugin EFM1, un sistetizador FM, salvo los más complejos como el disparo y el frenazo, que son ediciones de samples de audio con licencia "Dominio Público" descargados de FreeSound. El disparo sí se consiguió medio sintetizar con el EFM1, pero no nos convencía porque sonaba algo "arenoso". El frenazo, por sus características (una señal repetitiva de corta duración), se podría decir que es fácil de sintetizar, pero no hubo manera de obtener algo aceptable. Finalmente se usó un loop muy breve extraído de un frenazo real. Ah, bueno, y las voces las grabamos nosotros claro, hasta el grito de la prota cuando muere. Maravillas del pitch.

CONCLUSIÓN

Para este proyecto no tenemos muy claro el tiempo que se ha necesitado porque, mientras se programaba el Firemen Rush, ya se comenzó con el desarrollo de los gráficos de Bike Assault, por tanto ambos proyectos se solaparon en el tiempo y se perdió la cuenta. Pero seguro que ronda los 20-25 días.

Nuestra intención, por ahora, es sacar un minijuego al mes. Firemen Rush se subió el 5 de Marzo y se aprobó el 13 de Marzo. Bike Assault se subió el día 8 de Abril y se aprobó el 14 de Abril. Así que, más o menos, el plazo se ha cumplido.

Ya sabéis, descargad Bike Assault y pulsad los anuncios varias veces, que nos queremos comprar un yate y aparcarlo en el garage del supermercado.


¿Y AHORA QUÉ?

Lo siguiente que vamos a hacer es un remake de nuestro minijuego del mosquito (Mosquito's Insomnia) para que no se quede ahí criando moho, pero cambiando el gameplay por algo más elaborado en cierta manera (tampoco tanto, preferimos hacer cosas nuevas). No nos debería llevar más de dos semanas.

¡Saludos!

jueves, 20 de marzo de 2014

Firemen Rush NO está basado en "Fire" de Game & Watch

Antes que nada, un poco de publi:

FIREMEN RUSH (Free, Universal, iOS): Firemen Rush en iTunes App Store

Bueno, sobre el tema, tampoco es que nos importe mucho la comparación, ¿eh? pero la realidad es que nuestro mini-juego Firemen Rush no está inspirado en el juego "Fire" de Game & Watch, principalmente porque hasta hace unos días desconocíamos su existencia.


Nosotros, en concreto, siempre vamos con la verdad por delante y nos gusta aclarar lo más posible el desarrollo de nuestros proyectos, sobre todo antes, cuando no eran 100% originales, sino fan-games y cosas así. Para Firemen Rush, por ejemplo, hemos aclarado desde el día uno que la música es un tributo a The Ninja Warriors y que hemos usado samples de audio extraídos de un par de temas. Todo lo relevante sobre el desarrollo quedó dicho desde el principio, y si no se mencionaba nada sobre Game & Watch y Fire es porque no tiene nada que ver.

Al igual que tampoco tiene nada que ver con este juego:


Su propio autor nos envió un mensaje para enseñárnoslo, tras ver una captura de nuestro juego en PixelJoint, y se sorprendía de la coincidencia. Sólo es eso, una coincidencia, y obviamente también desconocíamos su existencia. Podéis probar "Pixel Rescue" on-line aquí.

Mirad, así es, más o menos, cómo surgió Firemen Rush:
  • D: Oye, vamos a hacer un mini-juego simple, de estos que caen cosas y las recoges, como el mini-juego del cura que recogía frutas, aquel que hicimos en RPG Maker.
  • A: ¿Por qué?
  • D: Porque lo del Flappy Bird es la gota que colma el vaso, sinceramente...
  • A: Vale, pero lo de las frutas otra vez no.
  • D: ¿Y entonces qué hacemos? Algo tendrá que caer del cielo...
  • A: Bueno, pues hacemos que... que caigan personas de un edificio.
  • D: Uumm, vale, pero ¿por qué? ¿están hartos de la vida?
  • A: Podría ser, pero mejor que haya un incendio y tú tengas que salvarlos.
  • D: Ah, valeeeee... y ponemos unos bomberos abajo ¿no?
  • A: Sí, eso mismo, con una colchoneta o algo así.
  • D: Pues ya está todo dicho. Venga, manos a la obra.
  • A: Pero hacemos el mínimo posible, ¿eh? Nada de si luego ampliamos esto o lo otro. Yo hago gráficos, tú te callas y no los criticas, y programas lo que yo te pase.
  • D: Vale, vale... pero ¿y si...?
  • A: PORTAZO.

Y este es el magnífico documento de diseño elaborado durante la conversación anterior:


Se ven la pantalla de título y la pantalla de juego. El esbozo se hizo en el espacio sobrante de una hojita donde previamente se estaban apuntando los números de los temas más chulos del juego Dragon Knight 4 de SNES, una banda sonora que tenemos ahí pendiente de remasterizar y subir a nuestro canal de Youtube.

En definitiva, el proceso de creación de un minijuego, para nosotros, consiste en lo siguiente:
  1. Pensar una idea muy básica (Ej: recoger gente que cae del cielo).
  2. Ambientar esa idea y darle un porqué (Ej: recoger gente que se tira de un edificio en llamas).
  3. Convertir la idea en una mecánica de juego (Ej: si la gente se estampa en el suelo, game over).
  4. Agregar otros elementos jugables (Ej: hay explosiones, caen rocas y se puede romper la lona elástica).
El resto es trabajo y esfuerzo.

FIREMEN RUSH (Free, Universal, iOS): Firemen Rush en iTunes App Store
¡Saludos!

jueves, 13 de marzo de 2014

Firemen Rush - Minijuego gratis para iOS

Bueno, gente, en estas últimas semanas hemos terminado este minijuego gratuito para iOS:



Lo de gratis es relativo, porque ya se sabe que no somos muy amigos de regalar nuestro trabajo. Eso significa que hemos incluido anuncios en la parte superior de la pantalla. No molestan para jugar, aunque afean un poco el conjunto si uno se pone muy sibarita, y lo que es peor, condicionan un poco el diseño del juego y el posicionamiento de los elementos. Pero bueno, de esta forma los usuarios pueden disfrutar de nuestro trabajo sin excusas y nosotros vemos algo de pasta: todos contentos.

GAMEPLAY


Más vale que hayáis reproducido ese vídeo a pantalla completa para ver algo. La mecánica es muy sencilla. Hay un edificio en llamas y la gente se está tirando por las ventanas. Tú, como buen bombero que eres, has de amortiguar la caída con una lona elástica. El problema es que a veces hay explosiones y caen rocas, y debes evitar que éstas rompan la lona (si le dan a los bomberos no pasa ná, pa eso llevan casco). A medida que pasa el tiempo, hay más explosiones y más gente harta de la vida, hasta un punto que la situación se vuelve insostenible y pierdes la partida a la fuerza. El objetivo es rescatar al mayor número de gente posible, es decir, conseguir la mayor puntuación. Un objetivo muy arcade, la verdad. Las altas puntuaciones se almacenan a través de Game Center (también hay un ranking local de altas puntuaciones, pero eso no tiene gracia).

GRÁFICOS

Nosotros no hacemos juegos retro, sencillamente usamos pixel art porque nos gusta, ni más ni menos. Como se ha visto en las imágenes anteriores, los gráficos son coloridos, con sombreado semi-plano y con bordes oscuros, en pos de conseguir un apartado visual resultón y legible en pantalla. El juego se ha trabajado a la mayor resolución necesaria (384 x 568 pixels) para que pueda jugarse en todos los tamaños de pantalla, es decir, es una aplicación universal que vale para todos los dispositivos iOS (iPhone, iPod Touch, iPad) y no usa frames para rellenar el espacio sobrante en mayores resoluciones.


Os vamos a explicar en qué consiste el sprite sheet de una persona, por gusto. En total, cada persona cuenta con siete tipos de animación. Las cuatro primeras para caminar, y las restantes para caer, impactar en el suelo y saltar. La pose de caminar hacia arriba no se utiliza nunca en la gente que se tira por la ventana, pero se ha hecho por completar el conjunto. Hay un total de 16 tipos de personas, pero 8 de ellos son duplicados cambiados de color (que no está el horno pa bollos). También se han hecho sprite sheets para personajes no jugables (polis y bomberos), pero éstos sólo con las poses de caminar.

El resto, igualmente trabajados, lo completan el logo, los backgrounds, los vehículos, los fuegos, los efectos de animación (explosiones, humo), fuentes de letra, etc.

En realidad, lo anterior es el sprite sheet que el grafista principal (Alberto) le suministra el programador (Dani), quién se encargará de extraer todos los frames de todos los sprite sheets del juego (en un proceso automatizado, lógicamente) para generar un único sprite sheet global que será la textura usada por el juego. Ese sprite sheet final se crea con Texture Packer, y tiene el siguiente aspecto:



PROGRAMACIÓN

Como ya se ha mencionado, el juego es una aplicación universal, por tanto, lo descargas una vez y funciona en cualquier dispositivo iOS (compatible con OpenGL ES 2.0), y lo que es mejor, en cualquier tamaño de pantalla, sea 3.5 pulgadas (iPhone 3GS, 4, 4S), 4 pulgadas (iPhone 5 y derivados) o iPad. Ha sido programado usando la librería cocos2d-iPhone v3.0 RC3.

Se ha invertido un tiempo extra en la programación de una base reutilizable para futuros minijuegos. Es decir, hay ciertas cosas que normalmente son comunes a todo juego 2D de los que solemos hacer, pero no vienen de serie en cocos2d y conviene crearlas lo más versátiles posible. Por ejemplo, animación de sprites, object pools (a saber cómo se pone esto en español), movimiento y física simple, partículas, inteligencia artificial, etc. Hay que tener en cuenta que usamos cocos2d sólo como rendering engine, y prescindimos de los sistemas de física o partículas que vienen integrados, por diversos motivos.

Otro tiempo extra se ha invertido en integrar servicios que, para nosotros, son ajenos a los videojuegos en sí, como es el tema de la red de anuncios iAd de Apple o las redes sociales. Hemos permitido que la gente pueda compartir su puntuación en Facebook y Twitter adjuntando una captura de pantalla, lo cual es interesante de cara al marketing viral, así como para tener pruebas fehacientes de la puntuación conseguida.

MÚSICA Y SONIDO

A nosotros nos gusta mucho la música de los juegos de la era de los 16-bits, entre otras, la música que se hacía para Super Nintendo. Esta música era especial porque realmente no se trataba de instrumentos sintetizados por un chip de sonido, sino que se utilizaban samples de audio y se le aplicaban efectos como echo, reverb, panning, etc.

No somos expertos en la materia pero, según hemos entendido tras investigar un poco, dichos samples de audio eran, por lo general, loops muy cortos (algunos de décimas de segundo) y las diferentes notas se conseguían acelerando o ralentizando el sample, es decir, cambiando el pitch (lo cual no parece muy ortodoxo musicalmente hablando). Además de cortos, los samples eran de baja calidad para ahorrar espacio en memoria (viéndose especialmente afectadas las frecuencias altas). Se disponía de 8 canales de audio (o voces) a utilizar como uno quisiera, pero las notas no se solapaban. Para simular polifonía (tocar dos o más notas a la vez en un mismo instrumento) se debían usar varios canales que lanzasen el mismo sample (por ejemplo, se puede simular un acorde de dos notas de piano usando los canales 0 y 1). Ya sabéis, todo en conjunto confería un sonido muy característico e inolvidable, impuesto por las limitaciones de la época. Repetimos, no somos expertos en la materia, hemos contado todo esto a título informativo. Si algún dato no es correcto, corregidnos.

La cuestión es que para este juego se han creado dos temas que son un tributo a The Ninja Warriors, uno de nuestros juegos favoritos de SNES. Hemos usado los samples de un par de temas (Opening y Boss 1), aunque la mezcla final se ha ecualizado para recuperar el brillo de las frecuencias altas. Nuestros temas no son iguales, obviamente, pero mantienen un aire y cierta similitud en la estructura. En definitiva, para no ser músicos ni compositores, más o menos se ha conseguido el objetivo, que es volver a escuchar este tipo de sonido y composiciones. No debería haber ningún problema legal por usar samples de SNES (que a su vez seguramente fueron extraídos de algún hardware de la época), pero si lo hubiera, bastaría con cambiar los samples por otros similares creados por nosotros.

Los efectos sonoros son originales, creados con un sintetizador FM que tiene Logic Pro llamado, valga la redundancia, EFM1. El botoncito Randomize os ayudará a aproximaros rápidamente al tipo de sonido que estéis buscando y luego, toqueteando los parámetros, puede que consigáis justo lo que necesitáis. Para ciertos sonidos hay que echar un rato hasta encontrar lo que buscas. Aquí dejamos una captura con los parámetros del sonido del saltito por la ventana, por ejemplo:


Al principio íbamos a usar el conocido sfxr, pero el sonido era demasiado tipo 8-bits "estridente" y no es lo que se buscaba. En cualquier caso, siempre se pueden usar diferentes programas y mezclar sonidos para generar cosas curiosas. Podéis trastear el sfxr vía web aquí: as3sfxr.

CONCLUSIÓN

En hacer este "simple" minijuego se han invertido 20 días, que bajo nuestro punto de vista y experiencias anteriores, es un tiempo récord. Se incluyen diseño universal, gráficos, programación y creación de una base reutilizable, música, sonido, testeo en todos los dispositivos, configuración de la aplicación en iTunes y subida.

Sobre el proceso de revisión de Apple, decir que el juego se envió el Miércoles día 5, y ha sido aceptado hoy Jueves 13, es decir, la espera ha durado una semana arriba o abajo, que es lo normal. El proceso de revisión se inició hoy a las 17:46 y el juego fue aprobado a las 19:04, por tanto, en una horita o así se lo han ventilado. Se lo hemos puesto fácil, que conste.

No lo dudéis y descargadlo, y pulsad los anuncios varias veces, que ese simple gesto nos permitirá comprar cereales de marca.


Ah, y tenemos otra sorpresa reservada para dentro de unas semanas.

¡Saludos!

domingo, 12 de enero de 2014

"Project V" - Dev Log 08

Buf, vamos a ir recapitulando lo último que se ha hecho, y se está haciendo, para nuestro actual proyecto. Pero a partir de ahora prescindiremos del insulso desglose minucioso, y sólo nos detendremos a explicar los avances o cambios más importantes. No os olvidéis de traducir todo el rollo que se cuenta en el diario de desarrollo a su correspondiente carga gráfica y de programación.


Nuevo power-up para el héroe. Se ha agregado una nueva habilidad, si así queréis denominarlo, que utiliza el fuego como base. Con este poder se deja un rastro de fuego sobre el suelo que desaparece al poco tiempo. Si un enemigo toca el fuego, lo dañas.

Personaje secundario. Un amiguete alado te acompaña durante la aventura. Su presencia es importante porque, precisamente, es él quién nos proporciona los power-ups y objetos. Y mucho más importante es su presencia para el desarrollo de los diálogos y el humor.

Ampliación de la IA de los enemigos. Antes de comenzar con la programación de jefes, se ha decidido ampliar la IA de algunos enemigos que no hacían nada útil, sólo pasearse por el escenario. Que oye, está bien darse un garbeo por ahí, pero se trata de un juego. Esto ha dado lugar a 11 comportamientos nuevos y más variedad.

Estados alterados. Si bien el sistema de juego, por sus raíces, no deja mucho lugar a estar fastidiando al héroe con estados alterados, las nuevas IAs han propiciado su aparición. Los estados alterados no son muchos (lento, veneno, etc.) y desaparecen al cabo de poco tiempo. Son un incordio temporal.

Ampliación y mejora de los tilesets. Esta tarea aún está en marcha. Son 11 tilesets y vamos por el 9. Ya habíamos revisado los tilesets varias veces, pero merece la pena, porque han de proporcionar suficiente variedad visual durante la aventura (eh, pero sin pasarse).

Sistema de partículas propio. A ver, los sistemas de partículas prefabricados son la caña, sí, pero están pensados principalmente para eso, partículas. ¿Y si necesito un sistema de partículas que lance enemigos? ¿O que lance efectos de animación? ¿O que lance proyectiles? ¿O cualquiera de esas cosas? Pues eso, la necesidad manda. Aparte, a modo de reflexión, los sistemas de partículas suelen necesitar mucho cómputo y el resultado visible (gran fluidez), a nuestro entender, discrepa bastante de lo que se espera en el conjunto de un juego pixel art donde el resto de animaciones son manuales y algo más toscas. Que no pega ni con cola, vamos.

Sistemas genéricos, independientes, reutilizables, compartidos, llámalo X. Es decir, los sistemas de efectos de animación, efectos meteorológicos, tilemaps y todo eso ahora pueden usarse en cualquier parte del proyecto. Por ejemplo, si quisiéramos podríamos hacer llover en un menú, aunque no venga a cuento. El objetivo de esto es, principalmente, poder compartir dichos sistemas entre el propio sistema de juego y las escenas o conversaciones (es obvio que en las escenas también hacen falta tilemaps, efectos de animación o meteorológicos). Y por qué no, reutilizarlos en futuros proyectos.

Parpadeo de jefes cuando les queda poca vida. Un clásico.

Pues ya está, eso es lo más importante. Ahora mismo se está trabajando en completar los tilesets y las IAs nuevas, y luego se pasará a diseñar los 55 niveles y a darle vida a los jefes (animarlos, programarlos, etc). Sí, hemos recortado la duración de la aventura: lo vamos a dejar en 55 niveles totales (5 de ellos opcionales, para conseguir el final verdadero). Apostar por una duración no excesiva puede que sea ir contra corriente, pero ¿qué es si no el desarrollo independiente de juegos? Exacto, hacemos lo que nos viene en gana.

Una última reflexión acerca de los documentos de diseño. Uno puede pensar que todos estos cambios, añadidos y descartes son fruto de no haber hecho un buen documento de diseño previo. Podría ser, pero los documentos de diseño son importantes en proyectos grandes, que cuentan con un presupuesto y tiempo de desarrollo determinados, y donde un pequeño cambio actúa como el efecto mariposa: bates un ala aquí y hay un tornado allá. Para un equipo pequeño, un documento de diseño complejo y detallado no sirve de mucho, puesto que en la práctica se van a tener que modificar y corregir muchas cosas que en la teoría parecían funcionar. Garantizado. Por tanto, para un equipo de desarrollo pequeño quizás sería mejor comenzar con un esbozo de la idea, obtener un prototipo jugable lo antes posible, y sobre ello construir una experiencia más compleja, añadiendo o quitando elementos según sea necesario.

Lo que sí recomendamos es, en cuanto se tenga una idea general de qué se quiere hacer, establecerse un límite (de niveles, enemigos, objetos y todo eso). El proyecto ha de tener un fin claro y reconocible, y no sobrepasarlo, o se corre el riesgo de eternizar el desarrollo, con la consiguiente fatiga y pérdida de interés del equipo.

¡Saludos!

sábado, 28 de diciembre de 2013

Kickstarter, juegos pixel art y milongas varias

Escribimos esto a raíz de conocer la cancelación de este proyecto en Kickstarter (cancelación a posteriori, cuando ya había sido financiado). Se trata de Rainfall: The Sojourn. No se pretende hacer leña del árbol caído, ni mucho menos, sino iluminar un poco el camino a la gente que suele financiar este tipo de proyectos, atendiendo a nuestro criterio como desarrolladores y aficionados a los juegos pixel art y los 16-bits. Mi hermano Alberto suele decirme que, hoy en día, le gusta aprender cosas y saber de todo principalmente para que no le engañen. No le quito razón.


Rainfall pretendía ser "A 2D Action-RPG inspired by the SNES era and world culture!", o en cristiano, un Action-RPG 2D inspirado en la era SNES. No es por nada, pero ahí aparece el término RPG, y entonces ya estamos hablando de uno de los géneros más complejos de desarrollar. En la presentación sólo se mostraban bocetos de personajes y tres capturas de pantalla (de gran calidad, pero posiblemente eran montajes o mockups). No se mostraba ningún vídeo de gameplay o el juego funcionando, y ni siquiera se dice cuánto porcentaje de juego estaba ya implementado (si es que lo había). El equipo de desarrollo principal lo componían cuatro personas (diseñador del juego, pixel artista, músico y programador). Además, el programador quería crear su propio engine Action-RPG desde cero. Se pedían $6,000, y se obtuvieron casi $20,000. Al tiempo, el desarrollo se canceló.


Señores y señoritas aficionados al Kickstarter, sean serios, por favor.

Ese juego, al menos gráficamente, aspiraba a ser un triple A de SNES (Chrono Trigger, Terranigma, Secret of Mana y así un largo etcétera). El desarrollo de estos juegos pixel art costaron mucho dinero en su momento y a día de hoy cuestan lo mismo. Estos desarrollos los hicieron compañías con experiencia y recursos como Square o Enix. ¿En serio cuatro gatos, con un sólo grafista, iban a sacar eso adelante?

Os vamos a mostrar parte de los créditos de Chrono Trigger, correspondiente al trabajo gráfico:

Graphic Director
Masanori Hoshino
Yasuhiko Kamata
Tetsuya Takahash

Effect Graphic
Yukio Nakatani
Hirokatsu Sasaki

Field Graphic
Shinichiro Hamasaka
Yasuyuki Honne
Matsuzo Itakura
Akiyoshi Masuda
Yusuke Naora
Tetsuya Nomura
Yoshinori Ogura
Shinichiro Okaniwa
Kazuhiro Okawa
Takamichi Shibuya
Manabu Daishima
Toshiya Hasui
Masaaki Hayashi
Takayuki Odachi 

Character Graphic
Taizo Inukai
Fumi Nakashima
Hiroshi Uchiyama

Monster Graphic
Tsutomu Terada
Kouichi Ebe
Tadahiro Usuda 
Que no os sorprenda, porque esto es lo normal para una superproducción pixel art. Se trata de 25 personas sólo para el apartado gráfico. Chrono Trigger estuvo en desarrollo un año y pico (se comenzó en 1993 y se publicó en 1995). Si a cada trabajador le damos un sueldo de $10,000 al año, tenemos que, como mínimo, necesitamos un presupuesto de $250,000, repetimos, sólo para el apartado gráfico. Si además hay que pagarle a Akira Toriyama (diseño personajes), Nobuo Uematsu y Yasunori Mitsuda (música) y al resto del personal (programadores, efectos sonoros, diseñadores, mapeadores, etc.), que no son pocos, pues echad cuentas. Todo esto son números a groso modo y conjeturas, se entiende.


Lo que queremos que se comprenda ya de una vez por todas es que los juegos pixel art de ese nivel siguen costando lo mismo que antaño. No es más fácil hacer un juego pixel art ahora en el 2013. El pixel art de calidad no presenta facilidades de ningún tipo, se trata de arte gráfico y animación tradicional, pixel a pixel. No es como, por ejemplo, usar Zbrush para acelerar el proceso de creación de modelados 3D orgánicos. El pixel art de calidad no tiene atajos. Si Square-Enix quisiera sacar ahora un juego como Chrono Trigger, le costaría los mismos recursos y esfuerzos. Esto nos lleva a la gran milonga que parece haberse impuesto en el mundillo:

"Crear un juego 2D pixel art es lo más sencillo y asequible para un desarrollador indie"

MILONGA COMO UN TEMPLO.

¿Dependerá del tipo de juego? ¿Dependerá del tipo de gráficos? ¿Dependerá del personal y la experiencia? ¿Se ha hecho un cálculo del presupuesto realista? Todas estas preguntas hay que hacérselas antes de apoyar un proyecto ambicioso.

El problema que parece haber aquí es que las nuevas superproducciones 3D y la devaluación de los videojuegos han nublado la vista a prácticamente todo el mundo, hasta el punto de pensar que esos juegos de SNES tan "chulis" ahora podrían hacerse con un simple chasqueo de dedos. Muchos de esos juegos de SNES rozaron el top de los juegos pixel art (y eso sin tener en cuenta los increíbles arcades de recreativas) y tenían grandes compañías detrás. Si necesitaron 100 personas, ahora se necesitan 100 personas. Es como pensar que los desarrolladores indie, dentro de 10 años, podrán crear juegos como Metal Gear Solid con cuatro gatos y cuatro duros...

Entonces, ¿por qué se piensa que ahora cuatro gatos pueden hacer un Chrono Trigger con $6,000? Es absurdo.

Pensadlo.

domingo, 15 de diciembre de 2013

Peras 2D y manzanas 3D

Imaginad que estamos frente a un individuo o un medio especializado en videojuegos al que le enseñamos unas capturas de pantalla de ciertos títulos y le preguntamos "¿Cuál de estos juegos tiene los mejores gráficos?":


Si como respuesta obtenemos el título de alguno de esos juegos, desconfiad.

Técnica Gráfica


Todos esos juegos usan técnicas gráficas diferentes. En nuestra opinión, gráficamente no son comparables unos con otros. Y desde luego, gráficamente no tiene sentido comparar juegos 2D con juegos 3D. Metal Slug usa gráficos pixel art; Dragon's Crown mezcla dibujo digital y concept art; Rogue Galaxy usa un motor 3D con cel shading (o toon shading); Final Fantasy XIV es 3D al uso.

Vamos a fijarnos en la evolución de una saga longeva como Final Fantasy, para entender qué comparaciones gráficas tendrían sentido según la técnica gráfica empleada:


¿Se puede decir que Final Fantasy 6 es una mejora gráfica del primer Final Fantasy? Sí, porque la técnica gráfica empleada es la misma: pixel art. No importa si dichos títulos pertenecen a generaciones de consolas diferentes (FF es de NES y FF6 es de SNES). Si alguien nos dice que FF6 tiene mejores gráficos que FF, está en lo cierto. Obviamente parte de esta mejora se debe a las limitaciones del hardware, pero no deja de ser una mejora gráfica.

¿Final Fantasy 7 es una mejora gráfica de FF6? No, porque dichos títulos utilizan técnicas gráficas diferentes. FF6 utiliza pixel art, y FF7 utiliza 3D con gráficos pre-renderizados. Ahora bien, si alguien nos dice que Final Fantasy 9 tiene mejores gráficos que FF7, estará en lo cierto, porque tiene mejores gráficos pre-renderizados.

¿Final Fantasy 10 es mejor gráficamente que los anteriores? No, no son comparables. FF10 utiliza 3D puro, por decirlo de alguna forma. Sin embargo, sí se puede decir que Final Fantasy 13 tiene mejores gráficos que FF10.

Con esto queda bastante claro que las comparaciones gráficas tienen sentido cuando se está comparando la misma técnica. No obstante, sobra aclarar que una mejora gráfica sólo es eso, una mejora del apartado visual. Una mejora gráfica no implica una mejor experiencia jugable o un mejor videojuego. Por ejemplo:


Seiken Densetsu 3 es, gráficamente, ligeramente superior a Chrono Trigger. ¿Pero es mejor juego? Eso lo dejamos al gusto de cada uno.

Estilo Gráfico


Dentro de una misma técnica gráfica, ya sí podríamos introducir el término "estilo". Para nosotros, el estilo gráfico viene a ser el uso o interpretación que hacen los artistas gráficos de una misma técnica. Pero la valoración de un estilo gráfico no es tan mesurable como lo puede ser una mejora gráfica, de hecho, se trata en un juicio bastante subjetivo. Es más, el estilo puede venir condicionado por la ambientación del juego, y viceversa. No todos los estilos gráficos encajan o transmiten de igual forma una misma idea.


En la imagen anterior vemos a Samus del juego Super Metroid en el centro, y a los lados ciertos fan arts rebuscados en Internet y Pixeljoint. Como ejemplo, a alguien le puede gustar el estilo del segundo sprite (empezando por la izquierda), pero no deja de ser el que tiene la técnica más sencilla y, en ese sentido, técnicamente todos los demás son mejoras gráficas del segundo sprite, independientemente de qué estilo nos guste más. Sin embargo, ninguno de esos estilos es mejor que otro, ya que cada uno destaca mejor en según qué contexto. Que uno te guste más que otro es cuestión de gustos.

En realidad, la comparación más justa sería la que se hace entre dos juegos que usan la misma técnica y el mismo estilo en la misma generación (mismo hardware, mismas limitaciones, etc). En ese caso sí resulta evidente qué título posee el mejor apartado visual:


Resident Evil 2 supone una mejora gráfica de Resident Evil 1.

Conclusiones


Si te gustan las peras y las manzanas, pero prefieres las peras, entonces no digas que las peras son mejores que las manzanas. No compares peras con manzanas.

Si te tomas dos peras, una dulce y otra amarga, pero prefieres la dulce, entonces bueno es saberlo. Seguramente a alguien le gusten las peras amargas.

Si te dan a escoger entre dos peras que se sabe que son dulces, posiblemente elijas la que tiene la piel más brillante y perfecta.

¡Ahora vas y lo cascas, saludos!

domingo, 8 de diciembre de 2013

"Project V" - Dev Log 07

Bueno, gentecilla, aquí traemos un resumen de las tareas más importantes que hemos completado para el "Proyecto V":


Trabajo gráfico:

  • Animaciones Enemigo #49 (25 frames)
  • Animaciones Enemigo #50 (30 frames)
  • Animaciones Enemigo #52 (30 frames)
  • Animaciones Enemigo #53 (22 frames)
  • Animaciones Enemigo #54 (25 frames)
  • Efecto de Animación 70 (AFX #70)
  • Efecto de Animación 71 (AFX #71)
  • Efecto de Animación 72 (AFX #72)
  • Proyectil 27 (PK #27)
  • Proyectil 28 (PK #28)
  • Proyectil 29 (PK #29)
  • Proyectil 30 (PK #30)
  • Background para el combate con el jefe del Área 8
  • 17 NPC's para el Bar
  • 17 NPC's para el Poblado

Programación y demás:

  • IA Enemigo #49
  • IA Enemigo #50 
  • IA Enemigo #52
  • IA Enemigo #53 
  • IA Enemigo #5
  • Mejora de la IA de ciertos proyectiles

Mucho trabajo gráfico, para variar. Eso de que vamos al 98% en el apartado gráfico es esperanzador, pero claro, un 2% de mucha tarea sigue siendo mucha tarea. O dicho de otra forma, aún queda bastante tarea gráfica por delante. Pero hoy sí que se ha alcanzado un hito importante en el desarrollo, porque todos los enemigos normales están terminados y programados (44) y también 3 jefes, lo que significa que, en tema de enemigos, sólo resta terminar las animaciones e IA de 8 jefazos (ya que el juego cuenta con 55 enemigos, jefes incluidos).

Otra cosa importante que se ha terminado son los NPC's para ambientar el Poblado y el Bar, zonas de paso a las que siempre puedes volver desde el mapa mundi, que sirven para desconectar un poco y para cumplir cierto requisito para desbloquear el nivel oculto y el verdadero final del juego.

También hemos estado barajando la posibilidad de acortar el número de niveles del modo historia o modo aventura, como se le quiera llamar. Tenemos 110 niveles (10 niveles por cada una de las 11 áreas), pero lo vemos un poco excesivo y no queremos que el juego sea repetitivo. Preferimos que la experiencia de juego sea más corta, intensa y dinámica (aunque eso signifique cagarnos en todo y maldecir a los cuatro vientos después del curro que nos estamos metiendo). Dicho esto, quizás un buen número de niveles sea 5 o 6 por área. En fin, esto ya lo decidiremos sobre el terreno, cuando la aventura esté terminada y podamos jugarla de principio a fin. En realidad esto es lo que nos gusta del desarrollo de videojuegos: nunca te aburres y siempre surgen historias que resolver o cosas que ajustar. Y es éste también el motivo de que los desarrollos sean tan imprevisibles (y laaaaaargos).

Ah, arriba, por debajo de la cabecera del blog, se ha puesto un menú con varias opciones. Blog es esto, hombre, el blog. En Proyectos contamos un poco en qué juegos 100% propios andamos metidos, o los que se han terminado. En Nosotros se resumen un poco nuestras influencias en esto de los videojuegos y el desarrollo, aunque quizás lo más interesante es que pueden descargarse varios proyectos de RPG Maker.

¡Saludos!

sábado, 7 de diciembre de 2013

Humor - Jungle Survivor Tutorial


En este vídeo se explica cómo sobrevivir en la jungla. ¿Has visto algo raro moviéndose por ahí? ¿Parece peligroso? No hay problema. En este exhaustivo tutorial se explica cómo proceder, paso a paso.

Humor - Columbo Revelations


Si alguien ha jugado a esto, nos gustaría saber su opinión al respecto.

martes, 26 de noviembre de 2013

"Project V" - Dev Log 06

¡Uf, vamos a actualizar esto ya, que si no..!


Aquí tenemos lo más destacado que hemos podido hacer estas semanas atrás. "¡Poooooco a pooooco!", como decía nuestro profesor de dibujo técnico en el instituto.

Trabajo gráfico:

  • Mejora de las animaciones del Enemigo #5
  • Animaciones del Enemigo #45 (35 frames)
  • Animaciones del Enemigo #47 (18 frames)
  • Animaciones del Enemigo #48 (33 frames)
  • Proyectil #26 (13 frames)
  • Efecto de Animación #67 (4 frames)
  • Efecto de Animación #68 (6 frames)
  • Efecto de Animación #69 (6 frames)
  • Tileset del Poblado
  • Tileset del Mapa Mundi

Programación y demás historias:

  • IA del Enemigo #45
  • IA del Enemigo #47
  • IA del Enemigo #48
  • Sistema y pantalla de precarga inicial de recursos.
  • Mejora del sistema de tilemaps propio: capa de sombras, separación de propiedades, etc.
  • Programación del Mapa Mundi

El trabajo gráfico es lo más importante, como siempre. Se podría decir que suele ser la parte de producción más costosa en cualquier tipo de videojuego, además de imprescindible. Entre otras cosas, en esta ocasión se ha podido completar el mapa mundi, que no es otra cosa que una pantalla desde la cual acceder a las diferentes áreas del juego pulsando en un edificio representativo del lugar. El juego tiene desarrollo lineal. Lo hemos preferido así para mantener una línea argumental (aunque sea cachonda en su mayor parte) y para mantener el interés en ir desbloqueando nuevas áreas y jefes. Como ya se ha comentado, dentro de cada área hay 10 niveles. Éstos también se desbloquean de forma lineal, y siempre puedes volver a jugarlos (para recolectar más gemas, por ejemplo, que son la "moneda" del juego).

(Aquí va una imagen de nuestro juego. No, todavía no...)

Aparte, desde el mapa mundi se puede acceder a un poblado, donde, hablando con la gente o entrando en ciertas casas se accede a nuevos modos de juego, al visor de escenas e incluso se descubrirá algún que otro secreto. El juego es un arcade principalmente, pero hemos decidido meter estas cosillas porque nos gustan. Las influencias de los juegos de 16-bits pesan.

Cambiando de tema, se ha perdido algo de tiempo investigando otros game engines, como Unity o GameMaker, pero quizás son opciones a valorar en un futuro, dado que necesitan un tiempo de aprendizaje importante. Unity nos ha parecido más profesional. GameMaker Studio ni siquiera puede instalarse en Mac OS X, y eso no nos ha causado muy buena impresión, al menos tratándose de una solución de pago.


Nosotros usamos cocos2d. Hemos de aclarar, para los despistados, que cocos2d no es un game engine, sino un render engine. Es decir, es una librería que permite renderizar (dibujar) sprites en pantalla, manipular sus propiedades (posición, opacidad, escala), aplicarles secuencias de acciones o administrar el reconocimiento de la pantalla tácil. Cualquier otra cosa que necesites (supongamos un sistema de escenas automáticas y conversaciones, como en RPG Maker) has de diseñarla y programarla, y esto se lleva un preciado tiempo, además de dar serios dolores de cabeza. Aparte, cocos2d no es suficiente por sí sólo; hay que utilizar software de terceros, ya sea para crear sprite sheets, tilemaps, y todo lo que vayas necesitando.


Sin embargo, cocos2d es una gran opción para los desarrolladores iOS indie: es gratuito y open source, y el soporte de la comunidad es bastante bueno. Aparte, se programa en el lenguaje nativo de iOS (Objective-C), lo que garantiza que el juego va a funcionar muy bien en los dispositivos (la programación de juegos para móvil difiere bastante de programar juegos para ordenadores de sobremesa, ciertos recursos son algo más limitados, no conviene hacer burradas en el código). Últimamente se están haciendo serios esfuerzos por mejorar cocos2d y obtener una nueva y mejorada versión V3, porque aún le faltan cosillas super básicas para llegar a ser un game engine 2D (por ejemplo, un buen sistema de animación por secuencia de imágenes).

En nuestra opinión, si de algún sitio de puede sacar un poquitín de pasta ahora mismo es de la App Store. La escena Android nos parece un cachondeo absoluto. En cualquier caso, la App Store se está poniendo bastante difícil desde que las grandes desarrolladoras se han hecho con mucha cuota de mercado a base de gastar un pastizal en publicidad (mirad este artículo), además de que ya hay más de 1 millón de aplicaciones (y la mayoría son "juegos").

Aunque todos esos malos augurios nos dan igual. Vamos a seguir con cocos2d, vamos a seguir apuntando a la App Store y tenemos ilusión en nuestro proyecto, sencillo, pero nos está gustando mucho el resultado en conjunto. El objetivo último de un videojuego es entretener y divertir. Si sóis desarrolladores de juegos indies, no lo olvidéis nunca. Confiad en lo que hacéis, si lo estáis haciendo en serio y con un mínimo de calidad. No os dejéis engañar, no os disperséis, que no os deslumbren los títulos next gen, los desarrollos billonarios y toda esa parafernalia gráfica. Los indies competimos en otra liga, donde una de nuestras misiones es seguir proporcionando a los usuarios un modelo de juego más personal, humilde y directo, pero con igual potencial de diversión, como los juegos de antes.


Y eso es todo por hoy, ¡saludos!