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
