CRUDe programming

Benko ha escrito un post titulado "Consejos para desarrollar un videojuego en 72 horas". La verdad es que es algo sobre lo que tenía pensado escribir, y como lo que quería decir yo no lo ha dicho Benko, pues aprovecho para escribir el post :)

Antecedentes

Durante el 2006 he participado en dos competiciones de desarrollo rápido:

Desarrollo rápido de un videojuego (Campus Party 2006)

Es la competición a la que se refiere Benko

Tiempo

72 horas

Objetivo

Escribir un videojuego que contuviera al menos tres de los cuatro conceptos que presentó la organización

Requisitos

A parte de tener que programarlo y diseñarlo prácticamente todo, había que mantener un blog en el que ir comentando cómo llevábamos el tema

Equipo

Éramos 4 personas, pero hasta llegar allí sólo conocía a Benko

Resultado

En el blog está el juego. Ganamos el primer premio y el premio especial del público

Desarrollo rápido de una web en Ruby on Rails
(Conferencia rails hispana 2006)

Tiempo

48 horas

Objetivo

Teníamos que hacer la web que nos pidieran, al final resultó ser otro juego, un hundir la flota. Nota: Creo que al final programé más javascript que Ruby on Rails xD

Requisitos

Tener la web colgada en público (salvo que estuvieras en las conferencias y te acercaras con tu portátil, pero yo estaba en Helsinki, así que no era una opción xD)

Equipo

Esta me la comí solito, que el ipod no se podía partir por la mitad ;)

Resultado

Fui el único que logró terminar y presentar mi hundir la flota, así que gané :P

Mis consejos

A continuación una lista de las cosas que considero más importantes para afrontar cualquier competición de este tipo.

Aprenderse bien las bases

Siempre que voy a participar en una competición me leo y releo las bases de la misma. Si algo no es opcional en cualquier competición seria es saltarse las bases, así que aprende bien todos los requisitos: qué puedes hacer, qué no puedes hacer y qué tienes que hacer de forma obligatoria.

Muchas veces hay puntos que son especialmente olvidadizos, por ejemplo: en la competición de la campus uno de los requisitos era poner una pantalla en la que saliesen nombres y correos electrónicos de todos los participantes del equipo, así como el logo de la campus party y las menciones al material de terceros que pudieras haber utilizado (gráficos, música, etc...). Ten en cuenta que este tipo de cosas son obligatorias.

Además, en ocasiones las bases mencionan qué es lo que se va a valorar en los trabajos presentados, con lo que te pueden servir para enfocar tu trabajo en aquello que el jurado va a prestar más atención.

Llegar preparado a la competición

En este tipo de competiciones sueles tener toda la información antes de la fecha de comienzo y lo único que te falta es qué hacer. Es una tontería esperar al pistoletazo de salida para empezar con todo. Siempre hay cosas que se pueden llevar preparadas. Por ejemplo, en estas dos competiciones en las que preparé llegué con todo lo siguiente montado:

• Campus Party
  1. Subversion: Siempre utilizo un sistema de control de versiones
  2. El blog: Las bases decían bien claro que teníamos que mantener un blog durante la competición, así que dos semanas antes ya teníamos un wordpress instalado, habíamos escogido un tema y habíamos creado las cuentas para los cuatro que éramos.
  3. Ideas: Pese a que no podíamos idear nada sobre el juego antes de la fecha una semana antes ya estábamos hablando de posibles ideas, cosas que nos gustaría hacer, etc... Luego, una vez supimos los requisitos, pasamos muchas horas pensando en qué hacer definitivamente, pero hay cosas que teníamos en mente antes de la competición, como lo de que el juego fuese multijugador.
• Conferencia Rails
  1. Subversion: ya lo he dicho, no puede faltarme ;)
  2. Esqueleto de la aplicación: Tenía el esqueleto de la aplicación rails preparada, bastaba con ponerme a trabajar sobre él
  3. Entornos de desarrollo y producción: bases de datos creadas, la aplicación rails configurada para conectarse a ellas y un mini-sistema de despliegue.

Son cosas que pueden parecer rápidas, pero en estas competiciones el tiempo es limitado, si sabes qué vas a necesitar, así que no está de más prepararse antes :)

He de decir que conseguir montar el entorno de producción para la conferencia rails me llevó un día, y si hubiera esperado a hacerlo en las 48 horas de la competición yo tampoco habría acabado a tiempo para presentar. Cada minuto cuenta

Dormir poco y no desesperarse

Como he dicho en el apartado anterior: Cada minuto cuenta. A medida que van pasando las horas se te va echando el tiempo encima y te empiezan a agobiar más todos esos bugs que no aciertas a corregir o el ToDo interminable.

Antes de plantearte participar en una competición de desarrollo rápido, si pretendes ganar, has de ser consciente de que van a llegar momentos de mucha presión, pero al final merece la pena ;)

Como ejemplo de dormir poco y desesperarse, la última noche de la competición de la conferencia rails la pasé tratando de hacer funcionar la sincronización de los tableros de ambos jugadores. Unas horas antes de la entrega creía que no me iba a dar tiempo a lograrlo, me estaba tirando de los pelos, pero al final, ya de día, acabó funcionando ^_^

No tires la toalla!

No atascarse

Enlazando con los dos puntos anteriores: No hay que atascarse!. Si ves que algo no te sale y tienes otras cosas pendientes, no malgastes horas dándote de cabezazos contra lo mismo, ponte con otra cosa más relajada y luego vuelve con lo que te atormentaba.

El diseño del hundir la flota lo hice en los ratos de "descanso" cuando me atascaba con la programación :)

No menosprecies tu trabajo

Tienes que ser realista, por muy bueno que seas en 72 horas no vas a conseguir algo bien pulido, siempre vas a tener bugs e imperfecciones, así que no te amargues más de lo necesario con los bugs misteriosos. Nadie va a esperar que hagas algo perfecto en tan poco tiempo

A modo de anécdota, en la campus nosotros optamos por hacer un juego multijugador por red, pero al final no nos dio tiempo a implementar la parte de multijugador. Sin eso nuestro juego al final no era más que un bicho biscoso saltando por ahí y moviendo bolas, y aun así ganamos :)

Así que ya sabes, presenta tu trabajo aunque no esté del todo acabado