Global Game Jam 2014 – Kyoto

On the 25th/26th of January 2014 some cool developers met at Vitei‘s offices in Kyoto and spent the weekend making games for the Global Game Jam 2014. I went too, and along with two young japanese programmers we did this game. It was a great experience and I’d like to share with you a bit of the process.

So Kyoto’s Game Jam was kind of relaxed. While other people in Osaka where starting on the evening of the 24th we gathered at 9 a.m. on the 25th. We started by watching this video:

Then we started to discuss ideas on the whiteboards based on this year’s theme (“We don’t see things as they are, we see things as we are“) and split into teams. I was involved in a discussion of a game that turned out to be this one. But since we where 6 people (4 programmers) talking about that game we decided to split into two teams. My team were two programmers and me. We thought about a few ideas and eventually we sticked with one to be able to start developing (at around noon).

facebodybullet_sad

 

The first thing I did was paint a few placeholders of background and the player so my fellow programmers would be able to work on the game and see results before any “final” art was done. After that I did the player’s graphics.

body01e

 

And then I struggled for a long time trying to get the right style for the background that was supposed to be like big random tiles that could fit with any other in a 3×3 grid. Eventually we did not do the random thingy but the final assets are indeed capable of that.

Since when you are stuck with something the best thing you can do is try and do something different, I changed to doing music. For this I used Garageband. The first music style that came to my mind (only god knows why) was THIS. But the music I did was much simpler than that. The moment I felt I got something I could hear repeated for long enough and not get too sick of it I stopped composing. Of course I would have liked to lengthen it and add a melody to it if we had had the time. Here is the main loop repeated 3 times.

Screen Shot 2014-02-02 at 3.13.56 PM

 

After doing some animations of bullet impacts so you know if you’re getting damage or not and the death animation, I did some SFX. I recorded some sounds I made with my mouth or hands with my phone (which I bet was the best mic I was carrying) and then changed the pitch, added echoes, removed noise, etc. on Audacity. Here are the sounds along the original recording in a zip file. The death sound was made with Garageband as well.

Finally I did two screens on how to play and control scheme, and the title of the game (we didn’t have a title so I made something up a few minutes before the deadline!). So that’s the story behind Geometry Ikaruga Wars. I hope you liked it.

At 4 p.m. we did a short presentation of the games and after that we fixed a few things and uploaded it to the Global Game Jam site (again a few minutes before 6 p.m. that we where supposed to leave so it’s not the best upload ever I’m afraid ^^’). Anyway. Seems everybody managed to get a game working and I liked the concepts other teams gave life to. Amazing experience I recommend to anyone. ^_^

The Making of… (III)

Querido público, hoy vamos a hablar de un tema que afecta directamente a la producción gráfica de los juegos pero que también es importante para todo lo demás ya que conseguirá que podamos ir probando un juego que aún está inacabado. Estoy hablando de…

The Making of… Zombie Master / Snowflakes (Placeholders)

Los placeholders son sustitutos de los assets del juego (archivos gráficos, de audio, video, texto…) que antes de estar hechos, se añaden a los proyectos para no interrumpir o retrasar otras labores como la de los programadores, o test de usabilidad o focus testing. Cuando los assets ya estén grabados, dibujados, escritos, etc. entonces se van sustituyendo los placeholders.

En EA por ejemplo, se usaban como placeholders muchas texturas que eran de un color plano y las letras NULL, textos como “Un placeholder al día da alegría” o voces, aún por doblar, hechas con el típico programa de text-to-speech.

Aunque parezca una tontería o un trabajo extra, además de ayudar a poder ver los avances de programación, los placeholders ayudan a algunos de los miembros del equipo de desarrollo a saber la cantidad de trabajo que queda exactamente por hacer y, de esta forma, poder organizar el tiempo mejor y evitar retrasos.

Un vistazo al directorio en que vamos sustituyendo los placeholders por los gráficos acabados nos dará instantáneamente y de forma visual la información de la cantidad de trabajo que nos queda hasta finalizar el juego. Ésto, que en programación no puede hacerse, por poner un ejemplo, evita en el periodo final de desarrollo una falsa imagen de “haber casi terminado ya” que causa desgana, desmotivación y finalmente, retrasos. Pero para el tema de programación hay otros sistemas ;).

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.*

The Making of… (II)

Hoy vuelvo a traeros otro documento de diseño. En este caso, el tercero que realicé para que otras personas pudieran programar el juego, pero en este caso, sin estar cerca de ellos y con poca comunicación. Así que tuve que esforzarme especialmente en que todo quedase claro. Hoy con todos ustedes…

The Making of… Zombie Master (Design Document)

De nuevo, el documento de diseño de este juego está hecho en Google Docs. A diferencia del anterior, en esta ocasión no he hecho uso de las notas de página sino que he utilizado diferentes recursos para darle variedad al texto, que no resulte demasiado aburrido y quede bien diferenciadas las partes. He usado texto en negrita e itálica, listas y “bullets” y cajas de colores. Cada recurso con una intención bien diferenciada.

Para ayudar al entendimiento total de la mecánica de juego, y para explicarlo de la forma más fácil, he usado en el documento los Casos de Uso. Creo que ésto es una forma sencilla de entender la mecánica y además puede servir de test para ver si se ha implementado correctamente.

Os dejo con el documento de diseño exportado en un archivo PDF: ZOMBIES_TT_DESIGN_DOCUMENT

The Making of… (I)

Hoy empiezo una nueva “sección” en la que voy a poner documentos del desarrollo de los juegos que he hecho, por si os parece interesante. Empiezo por un documento de diseño.

El primer documento de diseño que hice para que otros lo leyeran y a partir de ahí crearan el juego fue el del Alien Spidy, trabajando en Enigma. El juego inicialmente iba a ser para Nintendo DS y tenía unas mecánicas que no había visto aún en el momento de hacer el diseño, pero que posteriormente he visto implementadas en algunos juegos de iPhone como HookChamp, Cut the Rope y me ha hecho ilusión. Además uno de los mejores juegos de iPhone es de una araña ;).

Pero ese documento de diseño no os lo puedo enseñar, obviamente, así que os enseñaré el segundo que escribí para que otra persona lo leyera y pudiese trabajar sobre él.

The Making of… BOPPLE (Design Document)

El documento de diseño de Bopple está hecho para leerse en Google Docs y abusa en exceso de las notas de página (que en Google Docs salen a la derecha) pero me pareció un gran arma contra los excesos de texto y ideal para notas de efectos y elementos que no afectan al juego en sí sino a su estética, pequeños detalles y aclaraciones.

La ventaja que tuve en cuanto a este diseño fue que si algo no se entendía, trabajaba codo con codo con el programador (a quien iba dirigido este documento, ya que el resto lo hacía yo y no hacía falta). Los que hayáis jugado al juego os daréis cuenta que falta una mecánica importante del juego en el documento, que se introdujo posteriormente y no se actualizó el documento (gran error, no hagáis ésto en casa niños!). Por supuesto aprendí haciendo el documento y el siguente fue mejor.

Os dejo con el documento de diseño exportado en un archivo PDF: 090406_BALLS_DESIGN_DOCUMENT