CategoríaPostmortem

Tetromino – Post-mortem

Durante el pasado fin de semana participé en la Jamtoday Granada, una gamejam auspiciada por la asociación Jamtoday, coorganizada por Granadajam e impulsada por la red Guadalinfo y el Consorcio Fernando de los Ríos, entre otras empresas e instituciones. Tras dos días de intenso trabajo, conseguimos terminar Tetromino, del que paso ahora a relatar el proceso de creación a modo de post-mortem.

El tema y formación del equipo

En esta ocasión, me ofrecieron colaborar en un equipo con gente con la que me moría por trabajar, así que no lo dudé un instante.

Junto a Alfonso y Lorena, de Estudio Nemo, con los que después de dos años ya iba tocando hacer equipo y aprender de ellos, se nos unió Valerio, con el que ya tenía experiencia colaborando en Forgive Me, un juego que realizamos en la primera jam de Granadajam.

Adrián y Jordi completaron el cuerpo de programadores y con ellos no había trabajado nunca. Realizaron un trabajo magnífico bajo presión.

Elena, con la que ya colaboré en mi última gamejam, completaba el equipo en el apartado artístico.

Durante la presentación del evento, Mauricio García de The Game Kitchen presentó el tema de la jam: Economía Circular. Un nuevo paradigma de gestión de los recursos en contraposición a la Economía Lineal. También nos indicó un vídeo en el que podíamos encontrar más información sobre éste paradigma e inspirarnos, os lo incluyo aquí para que podáis verlo.

El concepto

Durante el brainstorming pudimos ver con calma el vídeo que Mauricio nos había pasado para explicar como funciona el concepto de Economía Circular y las ideas fueron brotando con facilidad. Cómo es casi obligatorio descartamos la primera idea sabiendo que sería la que muchos equipos escogerían para empezar.

Pasamos de centrarnos en el concepto del reciclaje a uno que, para mí personalmente, parece aún más entroncado al paradigma que es el de la eficiencia. No se trata sólo de reciclar y reutilizar los recursos, además hay que ser eficiente tanto en la extracción como en la creación de nuevos productos y componentes para facilitar luego la reutilización de los recursos.

Sobre esta idea giró el primer concepto en el que trabajamos: Una nave espacial que surca el espacio llevando a los últimos terrícolas a otro planeta manteniendo en funcionamiento su nave con recursos finitos. Una idea que tenía su potencial, pero no veíamos como aterrizarla sobre un gameplay interesante.

Finalmente llegamos a la idea de un juego de puzzles en el que tendrías no sólo que construir y reciclar, sino fabricar las piezas siguientes para repetir el ciclo.

La jamtoday fue una gamejam rara en el sentido de que el tiempo que se disponía para desarrollar no llegaba a las 48 horas. Finalmente dispusimos de menos de 30 horas para realizar el juego desde cero. Esto hizo que el diseño se centrara en construir algo que supiéramos que podíamos tener funcionando en menos de 24 horas. De ahí que el juego de de puzzles se convirtiera en un tetris, algo que los programadores aseguraron que podían tener funcionando muy rápido y nos permitiría centrarnos en las mecánicas de recolección de recursos y fabricación de nuevas piezas. Y funcionó.

tetromino menu

La realización

Teniendo dos tremendas artistas como las que teníamos, quisimos que el diseño visual destacase. Utilizamos una estética “kawaii” y muy colorida, buscando atraer a los niños a jugarlo y así poder entregar el mensaje del juego.

Parte del arte del juego está hecho a partir de fotografías digitalizadas. Los árboles están hechos de plastilina y algodon, los contenedores y los tubos son trozos de botellas de plástico. De esta manera también se reforzaba el concepto de reciclaje además de dar un estilo artístico muy personal y llamativo.

A nivel de programación hay que destacar la ventaja de tener un programador con la experiencia de Valerio que nos ayudó a organizarnos y a utilizar el control de versiones de manera eficaz. La división del trabajo en ese área fue fundamental para que el producto final tuviera la calidad que tenía. Mención especial a Alfonso que logró simplificar mucho las ideas de funcionamiento para conseguir que todos los programadores tuvieran la idea clara.

La base del juego, el tetris, estuvo desarrollada bastante rápido y se le fueron colocando poco a poco capas encima (sprites cambiantes según las piezas, rotación de bloques al mismo tiempo que la pieza, fragmentación de las piezas en bloques al hacer líneas y absorción por la tubería) a la vez que se testeaban para comprobar que su colocación no rompía las capas anteriores.

El constructor fue una de las partes que más tiempo llevó, dado que requería coordinarse muy bien con la parte del tanque (el tetris), recogiendo lo que ésta le enviaba y mandándole la nueva pieza una vez construida. Además debía tener sistemas para que si el jugador fallaba se devolviesen los recursos y ayudas visuales para que el jugador pudiera ver que pieza podía fabricar.

El generador del entorno natural dio algunos problemas. De cara a poder cambiar fácilmente cuántos árboles había al principio el sistema de generación era aleatorio, lo que provocaba que los árboles se montasen unos encima de otros de manera grotesca. Finalmente y a base de tocar mucho código para crear una parrilla de generación, se consiguió que los árboles se creasen en una red de capas que dan un aspecto de bosque más realista.

tetromino

Qué funcionó

  • División del trabajo y funciones: Eramos un equipo grande y el proyecto también lo era. La fragmentación de las tareas y la coordinación entre todas las áreas fue fundamental. Aquí Valerio realizó un trabajo encomiable como Lead Programmer y gestor de los conflictos en el control de versiones, lo que nos permitió a los no programadores trabajar el aspecto estético sin preocupaciones.
  • Diseño adaptado al tiempo disponible y al equipo: En todas las gamejams es fundamental tener muy presente el escaso tiempo disponible pero más aún en esta, para la que sólo contábamos con unas 30 horas. Decidirnos por una mecánica muy consolidada sobre la que construir capas de complejidad fue uno de nuestros mayores aciertos.
  • El apartado estético: No es de extrañar que nuestro juego mereciera una mención del público por su diseño visual.  Las artistas encontraron un estilo llamativo y entrañable y se coordinaron a la perfección para dar un estilo muy marcado. Teniendo en cuenta el poco tiempo del que dispusieron, la gran cantidad de assets que lograron culminar fue extraordinaria.

tetromino carretilla

Qué no funcionó

  • Explicar como se juega: Lo que en nuestra mente era bastante claro, fue bastante complicado de plasmar en una imagen para ayudar al jugador a entender lo que pasaba. El resultado no fue todo lo satisfactorio que me hubiera gustado. No quise meter texto dado que el juego iba sobre todo orientado a niños y explicar todas las mecánicas en una sola imagen no funcionó, a pesar del encomiable trabajo de Lorena tratando de convertir mis notas en algo comprensible. Creo que hubiera sido mejor fragmentarlo en varias imágenes y haber ido construyendo las instrucciones conforme avanzaba el juego en vez de al final. También hubiera ayudado testearlas antes de la entrega para ver donde fallaban.tetromino instrucciones
  • Tardar mucho en hacer el primer build: Una advertencia importante. Que el juego funcione dentro del editor de Unity no significa que vaya a funcionar igual al hacer el build. El previsualizador es mucho más tolerante con según que fallos de scripting que lo que será luego al crear el ejecutable. A nosotros nos dio un fallo justo antes de entregar que luego tuvimos que “cazar” en una sesión frenética usando un build de desarrollo. Funcionó, pero no siempre lo va a hacer. Acostumbraos a hacer builds tan pronto tengáis algo para ver si no se rompe nada.

Conclusión

Realmente satisfecho con el trabajo realizado y con un producto sólido al finalizar. Fue un verdadero orgullo colaborar con tan magnífico equipo. Esperando los próximos retos con ansia.

Please follow and like us:

No se lo que hice – Postmortem

Durante el último fin de semana se llevó a cabo la gamejam de GranadaJam en la que tuve la suerte de participar con un equipo magnífico y me divertí muchísimo. Quiero compartir con vosotros el postmortem del juego que logramos entregar: “No se lo que hice el Último Verano“.

El equipo y la presentación del tema

Tuve la tremenda suerte de tener un equipo lleno de talento y que se compenetraba a la perfección.

A los dos programadores, Laura y Sergio, se unieron una excelente artista 2D, Elena y un productor de audio muy experimentado, Elior. En la parte final del post os acompaño enlaces a sus páginas y portfolios para que podáis contactar con ellos en el futuro.

La presentación del tema vino a cargo del Fernando Ruíz L_draven, cuyo canal de youtube es famoso por sus tutoriales sobre iniciación en el desarrollo de juegos y las herramientas más usadas el mismo. De entre los temas propuestos, Fernando se decantó por “¿Quién soy yo?”.

Casi todos los participantes coincidimos en que era un tema muy interesante por la flexibilidad que nos otorgaba a la hora de generar mecánicas e historias.

El brainstorming

Sentados a la mesa y con la “orden” estricta de no censurar ninguna idea de primeras, comenzamos a tomar nota de todo lo que se nos ocurría para ilustrar el tema.

Los temas más comunes fueron los primeros en salir, como hacer un simple “Quién es quién” o el juego del personaje misterioso. Las ideas giraron desde los juegos más mecánicos hasta otros más basados en la narrativa (identidad de género, disociación, generación de comportamientos…) que se fueron descartando por una u otra razón.

Las limitaciones autoimpuestas (podéis consultar mi artículo sobre generar ideas en el que hablo sobre ellas) que más permitieron acotar las ideas e ir afinando el concepto que surgió al final venían de la propia composición del equipo. El tener una excepcional artista 2D nos hizo abandonar los conceptos relacionados con el 3D o las perspectivas en primera persona. Además su deseo de probar con el pixel-art nos animó a buscar estéticas que encajaran bien con ese estilo. El contar con dos programadores hizo que también tendiésemos más hacia mecánicas propias que a la narrativa o juegos utilizando librerías públicas (aunque alguna usamos).

Finalmente el concepto cristalizó. Buscamos un poco el humor y desarrollamos un juego en el que las últimas personas conscientes en una fiesta pasada de rosca dan tumbos etílicos por una casa llena de obstáculos con el potencial de dejarles en ridículo. El último en pie conseguirá grabar a todos los demás y subir el vídeo a youtube donde se hará viral. La integración con el tema, por tanto, era la respuesta a la pregunta “¿Quién era yo anoche? ¿El que se puso en ridículo o el que grababa el vídeo?”

Y recordad: ¡Bebed siempre con moderación!

El concepto

postmortem noseloquehice

El juego requería de una IA basada en necesidades. Cada personaje deambularía por la casa buscando satisfacer una serie de necesidades que irían modificándose en el tiempo y les haría buscar la habitación que les permitiera satisfacerlas. El personaje que representaba al jugador estaría marcado con una flecha y sólo podría intercambiarse por otro personaje presionando la barra espaciadora cuando se cruzase con otro personaje. El jugador recibiría feedback de hacia dónde se dirige cada personaje mediante las frases que los mismos irían diciendo cuando las necesidades cambiaran y de esta manera podría “saltar” al personaje que más le conviniera en cada momento, esquivando así los obstáculos que periódicamente iban apareciendo por la casa.

Una mecánica relativamente simple (el salto entre personajes) que tenía muchas posibilidades de generar momentos de tensión, al ver como tu personaje va irremediablemente hacia la perdición mientras rezas para que otro de ellos se cruce en tu camino y así saltar y evitarlo.

Para darle a todo un punto cómico, los nombres de los personajes salían de la lista de participantes de la jam. Las frases que cada uno decía también estaban escogidas para hacer escapar una sonrisa o hasta una carcajada al jugador. Incluso los sprites y las animaciones buscaban este sentimiento.

La realización

Con un sistema de control de tareas tan simple como efectivo (post-its que se ibancontrol de tareas rompiendo al terminar cada una), comenzamos montando el entorno principal. Sergio trabajaba en la programación gráfica mientras Laura se ponía con la IA y la mecánica básica. Elena dibujaba sprites y más sprites sin parar (¡¡Realizó más de 200 en 48 horas!!), mientras yo montaba las animaciones y los prefabs e iba redactando todo el texto. Sergio fue el encargado también de integrar los temas musicales que Elior iba creando para la ocasión.

Todo funcionó a las mil maravillas salvo algunos problemas con la IA que se empeñaba en hacer cosas que no estaban en los planes, pero Laura la fue domesticando poco a poco. Los ajustes de la cámara para que respetasen el “pixel perfect” funcionaron también maravillosamente bien salvo algunos momentos puntuales.

Algunas animaciones costaron un poco, pero el feedback constante entre Elena y yo creo que dio un resultado final bastante decente. Ella tuvo una paciencia infinita conmigo y eso es algo que le agradezco mucho.

Elior no sólo desarrolló varias melodías de fiesta para que fueran apareciendo y entremezclándose, sino que trabajó con sonidos del exterior para dar una sensación de profundidad que simulaban muy bien el entorno de la casa.

El mayor problema nos vino originado por el control de versiones de Unity: Collab.

Durante el fin de semana estuvimos trabajando prácticamente en tiempo real, llegando casi a un centenar de commits. No teníamos que detenernos dado que trabajábamos en escenas distintas y siempre con prefabs, por lo que al hacer cualquier cambio en uno de ellos sólo teníamos que recargar la escena para que los cambios se aplicaran automáticamente.

El problema vino cuando la animación que preparé para uno de los prefabs rompía la IA del personaje. Cuando al fin detectamos el problema decidimos que daríamos a revertir ese commit, de manera que el prefab volviera al estado anterior. Lo que no sabíamos es que el revert iba a descartar los cambios que Laura llevaba haciendo en el script de la IA toda la mañana y que sólo tenía guardados en local. Un control de versiones normal (como git) te avisa cuando hay cambios en local sin guardar en la nube que pueden sufrir daño si se hace cualquier acción. Pero Unity no nos avisó de esto. El resultado fue que Laura perdió todo lo que había hecho esa mañana. Un juego que estaba casi terminado y preparado para el testeo pasó a estar roto.

Laura se autosometió a un crunch brutal que le valió para reconstruir el trabajo perdido en un tiempo record, pero el debug que hizo falta para poder montar el build que íbamos a presentar nos dejó sin casi tiempo para testear adecuadamente el juego. Esto ha hecho que el juego haya quedado considerablemente flojo. Si bien es algo que podremos corregir más adelante.

Que funcionó

  • El brainstorming: Todos los miembros del equipo participaron en el proceso de generación de ideas, lo que permitió que surgiesen muchas posibilidades entre las que elegir. Ésto nos permitió también desechar muchas ideas más comunes y que sabíamos que el resto de equipos iban a tocar en sus juegos.
  • El concepto: Creemos que el concepto de juego elegido fue un acierto. Para empezar encajaba bastante bien con el tema, que además abordábamos de una manera distinta a la que elegieron los demas equipos. El centrarnos en el 2D nos hacía movernos en un territorio que todos conocíamos bien y el pixel-art le daba un aspecto muy vistoso y divertido al juego. De no haber cometido el error catastrófico que tanto tiempo nos hizo perder, hubiéramos podido trabajar más el equilibrio del juego que fue su punto más débil. Esto nos indica que el alcance y extensión del juego estuvieron aceptablemente bien calculados.
  • La colaboración: El reparto de tareas y los mecanismos que definimos para la gestión de las mismas funcionó tremendamente bien y prácticamente no provocó colisiones durante toda la jam.

Qué falló

  • Unity Collaborate: Si bien soy un gran defensor de esta herramienta de trabajo colaborativo, he de decir que su comportamiento en el único conflicto de importancia dejó mucho que desear. Curiosamente dos días después de terminar la jam, Unity lanzó una nueva versión en la que el control de versiones está mejorado y corrige en gran medida el problema que nos dio.
  • Equilibro de mecánicas: Como ya he comentado más arriba, el fallo que tuvimos el domingo nos dejó sin tiempo para testear adecuadamente el juego y equilibrarlo para hacerlo más divertido y justo. Al no disponer de ese tiempo el juego adolece de problemas en su funcionamiento que hacen que sea difícil de controlar y que las decisiones sean confusas para el jugador.

Conclusión

Una nueva gamejam, un nuevo juego publicado (aunque hay trabajo por delante para equilibrarlo) y un nuevo equipo del que pude aprender mucho. Queda mucho por hacer y practicar, pero poco a poco me voy sintiendo más cómodo.

El equipo

Arte: Elena García

Programación: Laura del Pino, Sergio Linares

Música: Elior Dumont

Soporte y GameDesign: Yo mismo.postmortem el equipo

Please follow and like us:

From a grain of sand : Post-mortem

Durante el fin de semana del 21 al 24 de Abril se ha celebrado la Ludum Dare 38. Para quien no sepa que es la Ludum Dare, es la gamejam no presencial más importante del mundo y que se realiza tres veces al año, en Abril, Agosto y Diciembre. La Ludum Dare tiene dos posibilidades de participación: la jam y la compo.

La jam tiene un reglamento bastante clásico: Un equipo de personas, utilizando cualquier asset para los que tenga permiso de utilización, realiza un juego durante 72 horas. La compo es mucho más estricta: Es una competición individual, sólo se dispone de 48 horas y todos los assets tienen que haber sido realizados por esa persona y dentro de ese plazo.

Podéis ver mi participación en la compo de Diciembre de 2016 siguiendo este enlace.

Durante esta edición el tema seleccionado era “A Small World” (un pequeño mundo) e intenté participar para la compo. Lamentablemente, no logré terminar dentro del plazo, pero aprendí mucho durante la experiencia. Este pequeño post-mortem narra el proceso que seguí durante el fin de semana.

Sábado 7:00 AM – Brainstorming

Dado que el tema se anunciaba a las 3 de la mañana de España, preferí levantarme temprano en lugar de apurar la noche. Una vez visto el tema y preparado abundante café, pasé a iniciar el brainstorming.

Mi proceso siempre es el mismo: utilizo una libreta A4 y procuro empezar siempre en una página que ya esté sucia. Es un truco que utilizo para evitar el bloqueo de la hoja en blanco. Un papel ya ensuciado con otras palabras, dibujos, etc… es menos intimidatorio y facilita el jugar e improvisar con términos y esquemas.

Comienzo por vomitar sobre ese papel todos los conceptos que me inspira el tema sin censurar ninguno, por absurdo que parezca a priori. Si en algún momento tengo un parón, trato de encontrar nuevas inspiraciones búscando el término (o términos relacionados) en Google o Pinterest, sobre todo imágenes o vídeos. Para mi lo más importante es llenar al menos la mitad de la hoja sólo con términos sueltos o frases muy cortas. Entonces comienzo un proceso de combinación entre ellos para crear frases más largas o conceptos compuestos que me inspiren mecánicas o dinámicas de juego.

En este caso las primeras ideas iban relacionadas con pequeños planetas o con mundos microscópicos (microorganismos) y estaba completamente convencido de que una gran mayoría de participantes irían por ese camino, así que comencé el descarte por eliminar todos los conceptos relacionados con eso. Esto dejó el cuaderno bastante pobre de ideas así que pasé a otro truco: Salir a despejarme.

Pensar mientras se pasea ayuda a ver las ideas con otra perspectiva y estimular el pensamiento lateral y generar nuevas asociaciones. Pasar por zonas con gente, escuchar conversaciones a medias, estimular los sentidos con sonidos y colores distintos… son grandes generadores de conceptos. Cuando volví a casa había empezado a tirar de un hilo que acabó cristalizando en un concepto.

Sábado 11:00 AM – El concepto

Sí, cuatro horas me llevó alcanzar una idea que me pareciese novedosa y realizable.

No sólo era importante que fuese una idea novedosa, también era muy importante que estuviese acorde a mis habilidades. La compo es muy exigente, absolutamente todo tenía que hacerlo yo sin poder recurrir a assets gratuitos, por lo tanto tenía que estar seguro de que podría realizarlo todo por mí mismo antes de volcarme en una idea.

En esta caso me inspiré en el final de La Historia Interminable, cuando la Emperatriz Infantil le dice a Bastian que aunque su reino ha sido destruído por La Nada y sólo un grano de arena había sobrevivido, él podría hacerlo crecer de nuevo con sus deseos.

El juego iba a ser un campo de experimentación, en el que el jugador podría introducir palabras y esas palabras darían origen a regiones enteras, praderas, rios, montañas, bosques e incluso pueblos que habitasen esas regiones. El jugador podría observar como el mundo crece con sus deseos y visitar a vista de pájaro el territorio creado.

Diseñé un generador de nombres relativamente sencillo pero ampliable, que cogiese los términos que el jugador introducía y los descompusiese en caracteres, que luego combinaría con una serie de reglas y a los que se les añadiría prefijos y sufijos para generar nombres complejos. Para la generación de territorios vi posibilidades utilizando matrices de hexágonos (como en los wargames), que dependiendo del tipo de región creado por el jugador instanciaría un número determinado de ellos del tipo adecuado (verdes para bosques, azules para rios, etc…). No habría personaje y la cámara sólo necesitaría funciones sencillas como mostrar el nombre de la región sobre la que estuviese el ratón y moverse al último hexágono clickado. No habría un “final” ni una “condición de victoria”, sólo una campo de experimentos, un sandbox para que el jugador fuese viendo como el mundo crece y como los nombres se iban volviendo más complejos conforme el sistema aprendiese más y más términos del jugador.

Ciertamente, cuando dejé la mente volar pensé en lo bonito que sería que la mecánica se activase por voz usando el micrófono y extraer los datos de la onda para generar los territorios, pero mis capacidades no llegaban a tanto.

El Generador de Nombres

Una vez leída la documentación sobre como trabaja Unity con las cadenas de texto empecé a trabajar en el generador de nombres, dado que de él derivaría el generador de terrenos (Si se creaba “El Bosque de … “, el terreno usaría los prefabs de bosque, por ejemplo).

  1. El jugador introduce un término en un Input Field.
  2. El término se almacena en una lista de términos.
  3. El generador recorre la lista de términos y extrae algunos caracteres, creando una nueva palabra que almacena en otra lista.
  4. El generador comprueba cuántos términos se han introducido y si hay pocos aún saca los términos de un diccionario prefijado. En caso de que haya bastantes, se salta el diccionario prefijado.
  5. Se genera una serie de números aleatorios: Uno para el tipo de terreno de una lista precreada, otro para una lista de prefijos, otro para una lista de sufijos y otro para la lista de términos intermedios extraídos de la lista creada con los términos introducidos por el jugador.
  6. Con esos números se extraen los términos que compondrán la frase final.

Ésta era más o menos la teoría inicial y la que casi se quedó terminada. El principal problema encontrado era crear unas reglas que generaran términos atractivos. Siempre he sido un gran aficionado a los lenguajes construídos e incluso he creado algunos en otro tiempo, así que recordaba lo suficiente para crear unas reglas sencillas.

Más o menos quedó un generador que creaba terminos complejos y un sistema intermedio que hacía que de vez en cuando se creasen nombres más épicos como “Bosque de la Soledad” o “Llanuras de la Calma” como una manera de crear puntos emblemáticos dentro de un mapa más aleatorio generado por el jugador.

El generador de terrenos

Aquí llegó el obstaculo principal y el que me hizo abandonar finalmente el proyecto. La idea básica era la siguiente:

  1. Un vez el generador de nombres decide en un tipo de territorio para ser creado, y llama a una función del generador de terrenos pasándole el tipo.
  2. Cada función crea dos números aleatorios, ancho y alto de la matriz de hexágonos que se generarían para ese terreno. Cada terreno tenía unos límites mínimos y máximos para que no hubiese cadenas montañosas gigantéscas y mares de un sólo hexágono.
  3. El generador instancia los hexágonos prefab correspondientes en el mundo a continuación de los últimos creados.
  4. Los hexágonos generados son nombrados según la región a la que pertenecen para poder pasar ese nombre posteriormente al sistema de cámara.

Más fácil de decir que de hacer. Los únicos algoritmos que encontraba para instanciar los prefab hacían que todos los hexágonos se generasen desde el origen de coordenadas (0, 0, 0), lo que significaba que todas las regiones se instanciaban en el mismo sitio. Y al intentar modificar el código para arreglarlo cada vez se rompía más.

El problema estuvo en el diseño. Siempre digo que las gamejam no son el momento de aprender cosas nuevas sino aprender maneras nuevas de combinar cosas que ya sabes para hacer cosas novedosas. Puedes aprender a hacer algo nuevo para ampliar en lo que estás trabajando siempre que sea simple y conozcas más o menos lo básico. Intentar aprender un sistema completamente nuevo va a ser prácticamente imposible y encima retrasará el trabajo de todo lo demás.

La cámara

Esto era muy sencillo y no llevó demasiado tiempo.

  1. Si el ratón pasaba por encima de un hexágono, almacenaba el nombre del mismo.
  2. El nombre se mostraba en un apartado de la interfaz.
  3. Si el jugador clickaba sobre un hexágono, la cámara se movía hasta la posición central del mismo pero a cierta altura para mantener fija la perspectiva.

Si hubiera habido tiempo una de las opciones para ampliar un poco la experiencia del jugador era crear los hexágonos con relieves distintos dependiendo del tipo de terreno. De esta manera las montañas serían altas y picudas, los bosques tendrían pequeños árboles adosados en la cara superior, la arena tendría dunas… El mundo tendría un relieve y modificando la cámara para poder ver el mapa en ángulo y moverse con los cursores el mundo podría ser visitado realmente a vista de pájaro.

Opiniones finales

Durante una gamejam en la que el tiempo es tan limitado, es muy importante adaptar el diseño a las habilidades de los participantes si se quiere terminar dentro del plazo. En este caso, creí que sabría hacer todo lo que estaba dentro del diseño, pero nunca había trabajado la creación de mapas complejos. Si me hubiera informado un poco (como luego hice preguntándole a amigos programadores) el tema de la generación de terrenos es bastante más complejo de lo que yo suponía en un principio, saberlo me hubiera hecho descartar la idea y centrarme en algo más realizable con mis habilidades

Para esta gamejam volví a usar las herramientas con las que estoy más habituado y eso me ha funcionado bien. Hacknplan sigue siendo para mí la mejor manera de organizarme en mis proyectos y ya casi no se trabajar sin él. Mi manejo de Unity sigue mejorando y poco a poco me siento más cómodo haciendo escenas complejas.

Mi Talón de Aquiles sigue estando en la programación y es algo a lo que quiero dedicarme más durante las siguientes semanas.

No descarto trabajar un poco más sobre este concepto en el futuro, pero teniendo tantos frentes abiertos ahora mismo no puedo asegurarlo. Si pudiese trabajar la parte de usar el micrófono si me gustaría orientarlo a un juego educativo para niños, que creo que podría dar un buen resultado.

Lo más importante de un proyecto fracasado es analizar adecuadamente por qué ha fracasado para aprender de ello, y es lo que he intentado con este post.

Ahora a centrarme en los proyectos abiertos y aprender más para que la próxima gamejam tenga un mejor final que ésta.

Please follow and like us: