sábado, 2 de febrero de 2019

¿Qué aprendí de la Global Game Jam 2019?

Lecciones de la GGJ 2019




Hace una semana participé en la Global Game Jam 2019. Para los que no la conocen, es una Game Jam que sucede al mismo tiempo en todo el mundo. El tema fue "What home means to you" (Qué significa hogar para ti).

Pueden descargar el juego desde la página de la Global Game Jam (https://globalgamejam.org/2019/games/come-home-0) o pueden mirar el código desde GitHub (https://github.com/GonzaloHirsch/GGJ-2019).

Fue una muy linda experiencia en donde aprendí mucho tanto de desarrollo de juegos, de Unity y de trabajar en equipo. 

Quería compartirles un par de lecciones que me llevo de este evento y espero poder aplicar en próximas Game Jams a las que vaya. Espero que les guste y les sirvan por si participan de algún evento similar.

Empecemos.

Una vez dado el tema lo primero que hicimos el Viernes con el equipo fue empezar a tirar ideas sobre cómo podíamos abordarlo. Había de todo tipo de ideas, pero nos dimos cuenta que todas recaían sobre una misma idea central, el hecho de que un personaje recorra el mapa y vaya aprendiendo o recordando cosas de su pasado. Para esto creímos que lo mejor era hacer un Walking Simulator (en 3D).

Aprendizaje #1: El Tamaño del juego


En el equipo éramos 2 programadores (acá estaba yo), 2 artistas 3D, 1 músico y 1 narradora/escritora. Por la composición del equipo, un Walking Simulator 3D nos iba a dar la facilidad de no tener que programar muchas mecánicas (solo el movimiento del personaje y algunas interacciones con objetos) y dedicarle la mayor parte a el modelado 3D del ambiente y a la historia.

El juego iba a ser enteramente dentro de una casa y para completarlo puede que no tardes más de 10 minutos. Hacer el juego así de corto nos llevó a que en ningún momento tengamos que correr para solucionar problemas o estar apurados para llegar a tiempo, en este aspecto creo que acertamos al elegir la temática y el tamaño del proyecto.


Habrán notado que nos "faltó" el rol de Game Designer en el equipo. Si bien nadie ocupó este rol al 100%, nos permitió que todo el tiempo cualquier integrante del equipo pueda aportar ideas sobre un nivel o  de agregar algo extra al juego y entre todos la analizábamos en vez de responsabilizar todo el diseño en una sola persona.

Aprendizaje #2: Que todos participen de la idea del juego


Al comenzar el evento, empezamos a desarrollar las cosas que si o si íbamos a necesitar (el movimiento del jugador por ejemplo) dejando algunas cosas "para el futuro" como por ejemplo, cómo va a ser la historia del juego o cómo iba a ser contada o qué iba a pasar al interactuar con los objetos.

Luego de un rato de desarrollo, se nos sumó el músico que conocimos en el evento y al contarle la idea que teníamos ya planeada para el juego, nos dio la idea que nos terminó cerrando el gameplay central del juego. Como la casa (el "mundo" del juego) iba a estar divida en habitaciones, cada habitación cuenta la historia de un recuerdo que tuvo el personaje en esa habitación.

Con esta última idea definimos el juego: Walking Simulator en la que el personaje va reviviendo sus recuerdos al entrar en las habitaciones de su antigua casa.

Sin el aporte del músico no hubiéramos podido cerrar la idea tan fácilmente, por esto creo que siempre todos deben participar de la idea del juego.


De ahí en adelante fue todo sin mayores complicaciones. Pudimos dividirnos bien las tareas y cada uno pudo avanzar por su lado con sus tareas asignadas. Aunque no faltó mucho para que tengamos el primer problema como grupo, la falta de comunicación clara.


Aprendizaje #3: Resolver lo antes posible los problemas de grupo


Nuestra situación fue la siguiente, fuimos con un grupo ya armado (excepto el músico y la escritora) y ya para el Sábado a la mañana teníamos una idea de qué queríamos hacer. Esto dejó poco lugar para que se pudiera integrar cómodamente un integrante al equipo y agregar ideas pero aún así integramos a la narradora/escritora el sábado por el mediodía que conocimos en el evento.

A medida que trabajábamos tocó el turno de definir la historia para ajustarla al gameplay del juego.

Tuvimos un gran problema de comunicación con la escritora entre explicarle lo que necesitábamos para que el juego funcione y lo que ella quería crear. Si bien su historia no era que estaba fuera de lugar, no era el nivel de profundidad de historia que necesitábamos para el juego que estábamos desarrollando.

Esto nos llevó a que al final el resto del equipo tuvo que realizar su parte del trabajo y ella enojándose con nosotros. Una pena que no hayamos podido comunicarnos efectivamente. Para la próxima, lo mejor creo que sería resolver este tipo de problemas lo antes posible de forma clara para que no escale.


Aunque mirando para atrás este fue el único problema que tuvimos como equipo, los demás problemas fueron técnicos y ninguno grave por lo que pudimos repararlo rápidamente. Un problema recurrente que tuvimos fue especialmente técnico de Unity, el hecho de que varias personas trabajen sobre la misma escena, lo que lleva a la otra lección.


Aprendizaje #4: De ser posible, que cada uno trabaje en una escena aparte (en Unity)


Una limitación muy marcada que tuvimos fue que no podíamos trabajar varias personas en una misma escena de Unity al mismo tiempo. Si esto pasaba, después no podíamos integrar ambas escenas con GitHub (o no supimos cómo). Esto nos atrasó mucho el trabajo porque tal vez teníamos que esperar que alguien termine de arreglar algún detalle o modelo en la escena para que otras dos personas puedan agregar algo a la escena.

Esto se pudo haber solucionado si cada uno trabajaba en "zonas" de la casa distintas (escenas distintas). 

Este problema no fue grave porque el tamaño del juego era chico y ya teníamos las mecánicas desarrolladas. Lo único que faltaba eran cuestiones de diseño.


Quitando lo técnico, hubieron unos momentos donde se nos ocurrieron algunas ideas locas para agregar al juego, algunos easter eggs que ayudaron a que nos pasemos la madrugada riendo,  integrando memes o ideas locas al juego. De ahí la siguiente lección:

Aprendizaje #5: Arriésgate

Muchas de estas "ideas locas" fueron los "¿Que tal si..?" que fueron bien recibidos por todo el equipo. Agregar una habitación secreta con una parodia a un meme o elementos dentro del juego que desentonen con la temática del juego. Estos elementos trajeron una gran distensión al grupo sin alejarnos de nuestro objetivo principal.

Desde el lado técnico, si bien el tiempo no sobra en las Game Jams y en eventos similares, cuando me encargaba de la programación de las "misiones", me arriesgué a desarrollar un "Sistema de misiones". Si bien esto me llevó más tiempo que hacer las cosas directamente, a largo plazo nos hizo mucho más fácil agregar más "misiones". El riesgo lo tomé porque ya tenía un poco de experiencia realizando este tipo de sistemas y porque había otro programador en el equipo que finalmente me ayudó a integrar este sistema dentro del juego.


Por último y no menos importante para mi:

Aprendizaje #6: Duerme

Este evento iba a ser mi 4° evento competitivo (5° contando la Game Jam que organicé) en el que el tiempo es el mayor recurso. Esto para algunos suele inducir a que hay que quedarse toda la noche programando o a lo sumo dormir 1 o 2 horas.

En los eventos pasados llevaba esta idea de no dormir y aguantar lo más posible y siempre quedaba exhausto y de malhumor para el día siguiente. Esta vez hice algo distinto, primero consulté a mis compañeros si no les molestaba que en ese momento vaya a dormir (parece tonto pero tal vez alguien espera que todos sus compañeros se queden sin dormir para trabajar). Viendo que no había problema, dormí mínimo 4 horas y ahí estuvo el cambio.

Cuando me levanté no tuve ni dolor de cabeza ni mal humor y tuve energía suficiente para el resto del evento. Si bien puede que no estábamos al 100% de nuestra energía, fue suficiente para que resolvamos los problemas que surgían y pudiéramos terminar el juego.

Esta Game Jam fue un evento muy distinto para mi. No solo porque el evento era de videojuegos sino por cómo lo abordamos. Me gustó mucho el resultado final que tuvimos y como al elegir un juego de pequeño tamaño, no tuvimos que quedarnos todos hasta último momento programando para terminar.

Espero poder asistir ( y organizar)  más Game Jams este año y espero que estas lecciones les puedan servir a alguien.

Hasta la próxima.

-L

miércoles, 10 de octubre de 2018

Hosteando nuestra propia Game Jam - Parte 2

Pre-evento: Buscar socios y Sponsors

Hola!

Les traigo la primera parte de esta serie de artículos sobre cómo fue que organizamos lo que fue la ITBA Game Jam.

Lo primero que hicimos fue buscar socios y Sponsors.

¿Por qué necesitamos socios?  DINERO + DIFUSIÓN.

Cualquier evento de este estilo va a requerir plata, por más que no se de comida a los participantes, siempre va a haber algún gasto como algún banner o flyers para difundir el evento.

Una vez que definimos cómo iba a ser el evento a grandes rasgos y cuantos participantes íbamos a poder recibir, lo siguiente era buscar quienes estarían interesados en participar del evento.

Nuestros socios finalmente fueron Etermax y Fundav, además de tener algunos regalos de parte de Razer. Gracias a todos estos socios, el evento fue posible y fue tan grande como fue.

Si bien ellos fueron los que estuvieron finalmente, no fueron los únicos a los que recurrimos.

En la primera etapa del evento, uno de mis trabajos era encontrar empresas que quieran participar del evento. Algunas respondieron con mucho ánimo y otras ni respondieron los mails, esto es muy común por eso, creo que un primer consejo sería:
No tengas miedo en intentar
Nuestro contacto con Razer surgió porque les escribí personalmente por la página de Facebook y ellos justo últimamente están soportando este tipo de eventos, por eso, al escuchar la idea comenzaron las conversaciones por mails. No tengan miedo en enviar mails o mensajes a empresas grandes!

Sin embargo, hay que tener en cuenta que siempre va a ser mejor tener algún contacto dentro de la empresa que se busca. Siempre es mejor mandar un mail a alguien dentro de la empresa que a una casilla de correo genérica.

Entre las empresas a las envié mail, también incluí a las instituciones que tienen carreras o cursos con orientación en videojuegos más conocidas de Buenos Aires. Es una lástima que no hayan respondido los mails ya que el evento tal vez hubiera sido incluso más grande de lo que fue, esperemos que para la próxima estén más atentos a su bandeja de entrada de los mails y no tanto a enviar mails sobre sus cursos y promociones.

Aunque algunos podrían, para estos casos, decir que mientras más socios, mejor, siempre hay que tener en cuenta el alcance del evento y las cuestiones "políticas".

Con cuestiones políticas me refiero a las negociaciones con las empresas que potencialmente quieran involucrarse su nivel de participación en el evento. Un tira y afloje sobre qué logo aparece primero, en qué tamaño, quién se queda con los derechos de autor de lo producido en el evento, quién lo difunde, etc.

Este tire y afloje es muy variable. Podríamos catalogar las empresas en "Reservadas" y "Colaborativas".

Para dar ejemplo de una empresa "Reservadas", podemos hablar de empresas a las que le tengamos que pedir permiso para solamente mostrar  su logo junto al nuestro en caso de que quieran participar o  empresas que tengan su departamento de comunicaciones tercerizado, por lo cual uno no habla con la empresa en sí hasta que ya se hayan definido algunas cosas. Si bien esto pueden parecer detalles menores, estas pequeñas trabas se acumulan y dificultan la interacción con la empresa. En estas, el tire y afloje suele ser bastante más delicado.

Para dar ejemplo de empresas "Colaborativas" (Etermax y Fundav en nuestro caso), tenemos empresas que persiguen el mismo objetivo que el evento. Estas empresas facilitan la organización porque ambas partes están altamente beneficiadas con la realización del evento. Por lo tanto, estas empresas si bien pueden tener sus demandas, las compensan con las acciones que realizan. En estas, el tire y afloje es mucho más relajado.

En nuestro caso, un detalle no menor para mi fue que Etermax además de ser sponsor del evento económicamente, nos dio cajas de sus figuras de silicona de su juego "Preguntados" para que les regalemos a cada participante además de unos regalos de la empresa para que hagamos sorteos. Razer (sin ser sponsor) también utilizó este principio, nos regaló tazas para que les regalemos a cada participante. Estos son gestos que mejoran el evento para ambas partes ya que ellos promocionan sus empresas mientras nosotros podemos regalarle algo a cada participante.

Por nuestra suerte, pudimos alcanzar nuestras necesidades teniendo solamente socios colaborativos. Cuando detectamos que una empresa era la que tiraba, tratábamos de, en lo posible, no involucrarnos. De nuevo, esto fue por la suerte que tuvimos de poder arreglarnos con los socios que ya teníamos, de haber sido otra la situación, nos tendríamos que haber conformado con otras empresas (algunas reservadas) y aceptar sus demandas.

Para resumir, a menos que el equipo organizador sea auto-suficiente, es un vital conseguir socios para realizar el evento. En lo ideal, socios que tengan el mismo objetivo en mente, que compartan las mismas motivaciones. Hay que pensar que nosotros como organizadores tenemos recursos finitos para entregarles a los socios, tenemos que saber cómo distribuir estos recursos y saber manejar el tira y afloje dependiendo de estos.

Espero que les haya gustado esta primera parte.

Hasta la próxima.

-L

domingo, 7 de octubre de 2018

Hosteando nuestra propia Game Jam - Parte 1


Introducción
 
Hola!

Sé que hace mucho que no escribo por acá.

Entre exámenes y falta de tiempo no pude dedicarme a hacerme tiempo a realizar algo nuevo.

Aunque por otro lado, es muy probable que vuelva a retomar el proyecto de Pirate's Tycoon, me parece un muy buen concepto a explotar. Tal vez lo arranque desde cero y solo me enfoque en la parte Tycoon, quitando la parte de batallas navales para mucho más adelante.

Por otro lado, les quería comentar otra de las razones por la cual estuve tan ocupado: estuve organizando (junto con otra gente de mi facultad) la primer Game Jam de la universidad.

El evento tuvo el formato "default": 1 tarde en donde dimos talleres, charlas y se armaron los equipos y luego 72hs de puro desarrollo.

Pueden ver los juegos que hicieron acá: https://itch.io/jam/itba-game-jam

No hubo ganador ni más votado, queríamos incentivar a los equipos a que se ayuden entre ellos, que fue lo que ocurrió.

Quería dividir mis comentarios sobre la organización de este evento (tips y cosas que aprendimos) en varios artículos, dividiendo la organización antes del evento, durante el evento y después del evento.

Así que estén atentos que tanto si quieres armar un evento con un formato similar o solo te interesa saber cómo fue que organizamos esto, estos consejos tal vez les puedan servir.

Hasta la próxima.

-L

domingo, 6 de mayo de 2018

Pirates Tycoon - Shipwrecked

Proyecto Suspendido



En este Post voy a hablar de este proyecto y de mis proyectos en general, de por qué creo yo que muchos terminan de esta manera.

En pocas palabras la respuesta a por qué suspendo este proyecto es: Es una idea muy grande. Si bien traté de reducirlo a una demo simple, no tengo la buena costumbre de reducirlo lo suficiente como para que sea hecho por una sola persona.

Tengo 2 juegos completos lanzados al mercado y un clon del Snake. Si bien con esto ya tengo un poco de experiencia sobre cómo manejarse en Unity, no es suficiente. De nuevo el problema (que suele surgir en los indies) de querer hacer juegos muy grandes.

Si bien el proyecto anterior a este último (Rock Climber) tenía potencial, no supe encontrarle la manera de que sea divertido y tardé mucho en hacer lo que hice, lo que me desanimó a seguir desarrollándolo.

Por eso siento que tengo que volver a lo básico, recrear los "clásicos" juegos en Unity (para ganar experiencia y aprender algunos trucos del motor) según tutoriales. De esta manera, voy a aprender a hacer juegos que ya funcionan de forma rápida. Encima de eso, voy a agregarles alguna modificación, desde tratar de optimizarlo hasta cambiar un poco las mecánicas del juego para hacer mi versión de este.

Lo primero que hice hasta ahora fue un Tetris. Siguiendo un par de tutoriales, en aproximadamente 2 semanas pude tener este resultado:



Es completamente funcional. Todavía me faltan agregarles detalles como una tabla de puntuaciones y música y sonidos entre otras cosas pero el progreso es mucho mayor al que tengo normalmente con un juego 100% propio.

Actualmente este juego corre a 60-70 FPS en mi computadora. Mi objetivo de optimización es elevar eso a 70-80 o idealmente, más de 90 FPS. Acá es donde me sirven los "trucos" de Unity que pueden mejorar el rendimiento.

Como posible modificación, se me ocurre hacer un "Tetris Doble" en donde hayan dos tableros y el jugador tenga que jugar en simultáneo. 

Personalmente siento que esto me sirve mejor como práctica para estar listo para cuando quiera desarrollar completamente mis juegos.

Una lista de los juegos 2D que voy a hacer serían:
  • Tetris.
  • Pacman.
  • Pong.
  • Mario (simplificado).
Espero poder traerles más y mejores progresos de estos juegos .

Hasta la próxima.

-L

miércoles, 18 de abril de 2018

Pirates Tycoon - Part 3

Batalla Naval


Como habrán notado, estuve mucho tiempo ausente.

Principalmente por temas de estudio pero también porque quise probar algo nuevo para mi, quería incorporarle al juego la posibilidad de tener batallas navales.

Pero estas van a ser de una forma muy peculiar, no quería que el barco sea totalmente controlado por el jugador moviendo directamente al barco con el teclado. Quería que sea un combate táctico.

Para hacer esta demo de batalla naval necesito reunir tres elementos que creo que son esenciales:
  1. Un océano con olas variables.
  2. Un barco que se pueda mover y sea influenciado por el viento.
  3. Inteligencia Artificial para los barcos enemigos.
De los 3 elementos que busco, el primero lo encontré en la Asset Store de Unity. Si bien no es el tipo de agua ideal para lo que quiero, cumple lo que necesito (aunque sin olas). Por lo que decidí quedarme con él.

Sobre el segundo elemento es en lo que estuve trabajando últimamente.

En definitiva, buscaba cómo hacer un controlador para simular la mecánica de un barco a vela. En Internet suelen haber varios tutoriales pero estos son de otro tipo de embarcación (como yates u otros barcos a motor), en donde la mecánica del movimiento es distinto.

Sobre esto voy a entrar más en detalle en otro Post pero para resolver este problema se me ocurrían varias formas:
  1. Tener un barco como un "bloque", crear una "fuerza" que represente el viento y que este empuje constantemente al barco, con algunos cálculos vectoriales para que la dirección del viento afecte la velocidad del barco
  2. Un tutorial en Internet indicaba como hacer un bote realista en donde el objeto "flotaba". Decidí no hacer esto ya que, en el caso de tener varios barcos y más mecánicas en juego, siento que esta forma iba a gastar un gran porcentaje del procesador para calcular "como hacer que el barco flote" constantemente.
Así que arranqué con la primer idea que tenía.

Primero con un cubo, le agregamos el componente de "RigidBody" de Unity y agregamos un "campo" en donde esa fuerza iba a actuar. La fuerza no era más que la fuerza que ofrece el mismo componente RigidBody de Unity, con el modo de fuerza en constante.

Claramente esto no iba a dar buenos resultados. Mi idea era "empujar" constantemente al barco y si esta flotaba por su propia cuenta, entonces se podría decir que estamos simulando la navegación del barco. Pero yo no tenía bien en claro qué reacción iba a conseguir utilizando este método.

Así que descarté la primer idea y la segunda ya sin siquiera probarla.

¿Entonces?

Después de mirar en muchos videos de juegos como el Sid Meier's Pirates (uno de mis favoritos) y similares para ver como estos resolvían este problema, me iba surgiendo una idea...

Si lo pensamos desde un punto de vista mecánico y minimalista, ignorando toda la interacción con el agua y el viento, un barco es "empujado" de la siguiente manera:


Si al barco "lo empujan" de atrás (el viento), el barco avanza y gira hacia la dirección contraria. Entonces de esto vi una similitud en algo más cotidiano, un auto.

Entonces... por qué no hacer un auto? Si descontamos el hecho de que lo "empujan" con el viento y hacemos que este constantemente en movimiento, es igual que un auto.

Estaba tratando de no utilizar este método ya que no me parecía muy "técnico" y pensaba que la solución era el método 1 o 2. Pero después, encontré en Internet algunos ejemplos de juegos que aprovechaban el componente "WheelCollider", hecho especialmente para las ruedas de los vehículos en Unity, para realizar esta idea.

Por lo tanto mi problema pasó de cómo crear un barco a cómo crear un auto.

En conclusión, a menos que valga la pena el detalle y se pueda alcanzar la producción (como en el juego "Sea of Thieves"), un barco en los juegos indies es un auto.

Todo parecería estar listo entonces, crear un auto utilizando un modelo 3D de un barco como "chasis" de este y listo, un barco que se puede manejar en Unity! (sin contar la influencia del viento).

Si tan solo hubiera sido tan fácil...

Hasta la próxima.

-L