Gamejam 2010 (29 a 31 de Enero)

[[EX3]]

En primer plano Sipox, Naranjo y Ex3!

Dios bendito, salgo como el puto culo! Parece que le estuviera echando la bronca a Gorka xDDD

http://www.rtve.es/mediateca/videos/20110205/zoom-net-05-02-11/1007667.shtml

En el Zoom net de esta semana... 6:45

En el video creo que hemos salido todos los strateros :D

Salu2...

[Mars Attacks]

Wala, cómo de animado ha estado esto. Yo me conformé con seguir las noticias por algunas webs con los dientes del tamaño de los del ronaldo antiguo.

Sobre vuestros postmortems y todo el asunto (muy bien esos postmortems, por cierto, ya os ha servido para algo el evento ;)) me gustaría comentar alguna cosilla. La primera, que el productor no debería ser nunca el diseñador del juego. ¿Por qué? Porque la labor del productor es hacer viable un producto con los recursos que se tienen. Si el productor es el que diseña el juego, su subjetividad probablemente nublará su juicio al no querer "matar a sus propios hijos". Esto, sin embargo, implica que los demás componentes del grupo deben acatar el juicio del productor (quien tiene que conocer mínimamente los costes temporales de lo que se va a producir, según su complejidad, en sus distintas áreas de código, gráficos, música, etc.). El producer tendrá que encargarse de aplicar la sensatez del principio de escasez de recursos, asegurarse de que lo que puede salir mal (que saldrá mal) se puede evitar o minimizar con alternativas o reorganizaciones, y asegurarse de que los chicos tienen todo lo que necesitan para ser felices (esto puede implicar ordenarles que se vayan a dormir o traerles la cena al sitio para que no se tengan que preocupar de estas cosas).

Pero hay otra cosa más muy importante para un productor, que SiPoX apunta al final de su postmortem, el del desarrollo iterativo. Para poder hacer un desarrollo iterativo (o mejor dicho, para hacerlo en condiciones), lo mejor que conozco es hacer el GDD con el "conjunto de features" ordenado de mayor a menor importancia (es decir: el core indispensable del juego, las cosas que queremos que tenga, y las cosas que nos gustaría que tuviera), para poder empezar por lo primero y, en función del tiempo que quede, hacer el resto.

He estado observando el GDD del juego y me ha parecido demasiado "orientado a programador". En el GDD, según mi punto de vista, se debería tratar sobre todo las características de gameplay, de estilo y el concepto general para que todos tengan la misma idea de lo que se busca en el proyecto, dejando la implementación a "bajo nivel" para otro documento si se quiere, o a discreción del programador (si son varios, otro documento dejando claras las reglas a bajo nivel está estupendo como biblia para que nadie meta la pata, pero sin mezclarlo con el GDD, que debe ser "apto para todos los públicos").

Alguno diréis que parece una pesadilla burocrática y que no es necesario. Y es verdad, no tiene por qué ser necesario, lo cual lo convierte en burocrático. Pero sirve para dos cosas: no desviarse de la idea original (evitar el feature creep) y darse cuenta de si se ha pasado algo por alto, ya que en ese GDD debe estar especificada cada pequeña posible respuesta del sistema y sus restricciones. Con un buen documento de diseño, el programador debería casi ver los algoritmos, el grafista los gráficos, y el músico emborracharse, como siempre. O dicho al revés, un documento de diseño no es bueno si alguien puede preguntar un "¿y qué pasa si...?".

Hay algunas cosillas en las que discrepo también (sobre temáticas "buenas" o malas, porque una aventura gráfica o un juego de estrategia se podría hacer perfectamente en 16 horas, o sobre ideas más complejas o simples), pero sí me quedo y subrayo con lo que ha dicho Panreyes: plantéalo (al menos plantea el core con la idea básica o unas pocas ideas básicas fundamentales) para que se pueda hacer en 4 horas, y deja que la entropía haga el resto.

Hay otra cosa muy importante también, que ya comenté en la charla de la Campus Party (si le echáis un ojo sin dormiros, igual encontráis que ya se comentaban algunas de estas posibles problemáticas), y es que muchas veces te das cuenta de que llevas 15 minutos discutiendo sobre un concepto en particular, cuando hacer una prueba en bruto te hubiera llevado 5, haciendo más rápida y fiable la decisión de si funciona o no para el juego. Personalmente, yo tendría Blender muy cerquita para una de estas compos.

Menudo tocho acabo de soltaros... pura envidia todo :)

[panreyes]

Bueno, la verdad es que no he comentado nada sobre cómo hemos trabajado en mi grupete, creo que fue inmejorable :)

Yo programaba, Miguel se encargó de game designs y músicas, y Daniel hizo los procesos gráficos.

El documento de diseño era un papelajo en el que ponía los nombres de los minijuegos con una mínima explicación, y con unos números a su izquierda indicando la prioridad en base a lo divertidos que nos parecían y el tiempo que tomaría desarrollarlos. Fue un éxito :)

Esto fue la "planificación" del desarrollo:
1. Ideas para poder empezar: diseño del tablero, eventos, minijuegos, etc...
2. Empiezo a programar las estructuras y los diferentes eventos
2. Miguel empieza a diseñar el gameplay y crear gráficos base (rectángulos) del primer minijuego (n=1)
2. Daniel empieza a crear los gráficos del tablero en general, en base a unos pocos dibujos

++repetir
3. Programo el minijuego ya diseñado con rectángulos
3. Daniel se pone a crear los gráficos del minijuego en base a los rectángulos y descripciones de Miguel
3. Miguel empieza a diseñar el gameplay del próximo minijuego, y a crear gráficos base (rectángulos)
++hasta que quede una hora para entregar el proyecto

4. Se crea el menú del juego
5. Se entrega

Funcionó realmente bien. Lo único que no hubiera venido mal hubiera sido otro programador, y que los otros dos del grupo me apareciesen a las 10.00 y se fuesen a las tantas como yo. Lo hubiéramos petado xD

[fjfnaranjo]

He estado observando el GDD del juego y me ha parecido demasiado "orientado a programador".

Aquí entono el mea culpa.

Es cierto que el GDD no eran tan GDD como debía. De todas formas, la descripción por componentes no pretendía ser una explicación técnica de programación , sido una puesta en escena de lo que serían los sistemas básicos que componen la mecánica del juego.

Una restricción importante es que había que hacerlo en unas 4 horas... así que creo que me deje llevar un poco por mi vena de programador y escribí algo demasiado técnico.

Sobre el resto de cosas que dices, se agradece tu tono  ;) . Y te hemos echado de menos, por supuesto  :P

[Makaimura]

Y donde estan esas joyas para probar?

[[EX3]]

Y donde estan esas joyas para probar?

Los juegos?

[blau]

Ahi va una  ;)

http://globalgamejam.org/2011/evil-god

[valnar]

Y bueno, siendo un poco más general, aquí estan todos los proyectos que se hicieron en la GameJam de Madrid ;)

http://globalgamejam.org/sites/2011/universidad-complutense