Un Juego Por Semana: Semana 4 – PostMortem

No me cabe duda, Licorun ha sido el juego que mas me ha costado hasta ahora; hasta ahora la reacción ha sido positiva pero vamos a analizar los resultados .

Que Salio Bien

• Adaptar una Idea Ajena: Como ya he mencionado en varias ocasiones, Licorun no fue una idea propia; fue algo que me sugirieron mitad en broma/mitad en serio, pero de igual manera fue interesante explorar un concepto que no origine yo y que me llevo a descubrir el proceso de una forma un poco mas evolutiva a como lo venia explorando antes. De hecho, del post original de concepto que surgió el lunes y que me costo bastante escribir de forma clara, se cambio mucho de lo que originalmente esperaba con el juego, no se si llamar esto algo positivo o negativo, porque si bien descubrí mucho del proceso conforme iteraba, mis expectativas iniciales y el producto final son muy diferentes.
• Componentes Reutilizados: El sistema de audio, que viene en evolución desde Hunger, es un punto extremadamente positivo; con cada juego encuentro formas de mejorar un poco el código y es una de las piezas con las que me siento mas satisfecho; aunque por motivos de tiempo volví a utilizar música no licenciada.
• Análisis de Diseño: Por muchas partes el desarrollo de Licorun fue descubrir lo que iba saliendo conforme se iba haciendo; suena raro escrito, pero era aun mas raro en mi cabeza, el proceso fue muy diferente a los juegos que había hecho anteriormente; pero una vez cuando estuve a punto de caer en la zona negra del fracaso por falta de tiempo fui salvado por los conceptos básicos de diseño de juegos que vengo estudiando  y que por alguna razón deje de lado los primeros 3 días de desarrollo. Detalles tan simples como preparar los elementos del juego usando «place-holders», enfocarme en iterar sobre los elementos esenciales del juego y el playtesting fueron decisivos para poder completar el juego(aunque pague un precio por no hacerlo mas rápido).
• Iterar, Iterar, Iterar: Aunque el proceso de prototipar empezó tarde en el proyecto fue un factor clave.
• Prototipo Completo: El juego esta listo como una prueba de concepto, aunque no estoy para nada conforme con el resultado por mas de que hasta ahora la recepción ha sido positiva.

Que Salio Mal (mucho)

• Enfoque Errado: Los primeros 3 días de desarrollo fueron un desperdicio completo por tratar de probar ideas que no tenían nada que ver con la experiencia de juego que quería expresar o sencillamente pensar en ideas para juegos próximos; desde explorar ideas de Tweening a preocuparme por ubicar modelos 3D o implementar un sistema de manejo físicamente realista, nada de esto era importante para la generación de prototipos jugables o la idea de juego que se iba formando; no fue hasta que descarte lo superfluo y empece a enfocarme en lo importante que logre empezar a ver resultados….. El jueves a 2 am.
• Coder Art: Visualmente Licorun es atroz, mucho tiene que ver con que mis habilidades como diseñador de niveles son muy pobres, si hubiese utilizado «placeholders» para generar un prototipo jugable, pudiese haber dedicado mas tiempo a la pulir el juego  al final de la semana, gran fallo aquí.
• Falta de Playtesting: El playtesting del juego fue casi nulo, lo que me llevo a descubrir los bugs muy tarde en el proceso y las correcciones o ideas de mejoras fueron muy apresuradas.
• Correcciones Post-Lanzamiento: Hay 3 versiones del beta en mi 4shared, gracias a que el playtesting fue muy tarde las ideas de corrección llegaron muy tarde. De hecho, haciendo este post en el proceso de tomar las capturas de pantallas del juego me percate que los atributos de las licorerías estaban mal asignados y subí una nueva versión del juego a las 10:30 pm del domingo….. Ugh
• Gestión de Tiempo: Mal desde todos los ángulos, esta semana fue la peor con respecto a la administración de tiempo y fue totalmente mi culpa; tengo que trabajar esto excesivamente.

Que Aprendí (mucho!!!!!!!!)

• Una idea tiene que romperse en una o dos experiencias esenciales y partir de allí.
• Los prototipos jugables son los que permiten iterar exitosamente.
• Al momento de definir un nivel las técnicas tradicionales de «placeholders» tienden a ser exitosar porque permiten acercar a una verdadera experiencia de juego con el mínimo esfuerzo gráfico, el refinamiento viene una vez se tiene algo que se pueda jugar. A no ser que se cuente con tiempo para explorar modelado de escenarios de forma tangencial(que no cuento con el), hay que usar «placeholders».
• Los shaders y elementos gráficos que he dejado de lado hasta ahora tienen que ser explorados de mejor manera para lograr mejores resultados visuales, bañar a algo con una luz no es la respuesta a todos los problemas.
• El desarrollo en 2D es interesante pero necesito arrancar con un proyecto pequeño y una idea que parta como una experiencia para 2D.
• La música me ayuda a pensar mejor que tener conferencias o TEDs como música ambiental, y al parecer mientras mas «corta venas» mas me ayuda a programar…. Bizarro

Una vez mas, gracias a Nereida por la idea del juego, ojala y mas adelante pueda hacer algo mas decente con los conceptos que alguien me de.

 Este es el link de descarga

Nos leemos mañana que como todos los lunes arrancamos un juego nuevo y acá les dejo una galería con imágenes del proceso de desarrollo.

 

Mapa de San Francisco

Mapa de San Francisco (fuente: Google Maps)

Croquis de San Francisco

 

Prototipos del Escenario

Adaptación de San Francisco en Unity

Un modelo jugable con edificios modelo y puntos de inicio

Prototipo jugable con refinamiento de los puntos de inicio y las licorerias, audio implementado

 

Análisis de Mecánicas del Juego

Distribución de licorerías original

Características de las licorerías en excel

Calculo de las fiestas, y el tiempo maximo de cada partida en segundos

 

Modelo del Beta

Mapa actual del juego

Licores Nereida

Arrancando la partida al lado de un punto de inicio

Una licorería Polar

recorriendo san francisco

Una licorería regional

 

AudioControl

AudioControl, componente que controla el sonido del juego

Los clips pueden reproducirse al azar de la lista o pueden moverse de forma adrede por la lista música

 

Todo son llamadas al método ReproducirAudio que controla al AudioSource