Acabas un proyecto en el que has trabajado durante un par de años y te sientes feliz. Por fin ha visto la luz y la gente ya puede tener acceso. Imaginemos que es un videojuego. Muchos están jugando, recibes críticas positivas y te sientes realizado. Sales en los medios y caramba, tienes esa satisfacción por un trabajo bien hecho que realmente nubla la realidad.
Así es el ser humano, programado para olvidar fácilmente los momentos malos y quedarse a disfrutar de los buenos. Es algo lógico, al fin y al cabo nadie quiere rememorar una y otra vez aquello que lo hace sufrir. Pero amigo, en el desarrollo de este videojuego has sufrido, has aprendido lecciones muy valiosas que te salvarán el pellejo en el futuro y que evitarán que cometas los mismos errores otra vez.
Apúntalo todo, que no se te olvide nada y guárdalo como si fuese tu nueva Biblia. Allí, cuando estés perdido encontrarás respuestas. Será como hablar con tu yo del pasado y que te recuerde el camino que debes tomar para no volver a cometer errores que ya cometiste.
Pero atrévete a dar un paso más. Comparte ese documento con otros desarrolladores. Hay mucha gente por el mundo que forma parte de una gran comunidad que hace videojuegos, en el fondo aunque no os conozcáis personalmente sois como una familia y si puedes ayudar a alguien de Oklahoma que está viviendo problemas que tu ya solucionaste… ¿Porqué no ayudarle?

En ese momento, es cuando nace una figura clave y vital en la industria del videojuego. Unos documentos que se han convertido en la lectura obligada de muchos desarrolladores, diseñadores, artistas, programadores y gente realmente interesada en saber cómo se gesta el difícil parto de un videojuego.
Bienvenidos al increíble mundo de los postmortems
No es una figura exclusiva del mundo del desarrollo de videojuegos, claro que no. Pero sí muy útil e interesante. Se trata de que el desarrollador de turno abra el corazón, eche la vista atrás y sea sincero consigo mismo y con su equipo. No es cuestión de buscar culpables, se trata de asumir qué partes del camino se han recorrido mal e implantar las bases para que no vuelva a suceder.
En ese documento, que suele ponerse a disposición de la comunidad, se detallan cinco o seis cosas que realmente fueron bien y cinco o seis cosas que lastraron al proyecto y supusieron un riesgo. Dicho de otro modo, qué cinco decisiones positivas y qué cinco decisiones negativas se tomaron en el desarrollo del videojuego en cuestión.
Y es aquí donde nos encontramos con los típicos problemas que todo estudio de desarrollo debería ser capaz de asumir al inicio del proyecto. Ya sea un estudio pequeño o grande, los problemas aparecen y suelen tener una pinta parecida.

Mala organización de recursos, valoración de la magnitud del proyecto errónea (todo videojuego acaba siendo más grande y bestia de lo que se pensaba en principio), cálculo de tiempos mal (hacer cualquier cosa bien hecha, por pequeña que sea, cuesta un mundo cuando el valor de producción es relativamente alto y se suele menospreciar el tiempo necesario), fallos en la producción del juego, cambios de diseño a mitad del desarrollo, malas herramientas, middleware que no da soporte técnico, mala comunicación, ausencia de metodología de trabajo y gestión de proyectos…
Una infinidad de cosas que suelen estar más relacionadas con la gestión de recursos que con la fuerza bruta o capacidad real del equipo.
Por eso los postmortems de videojuegos ya acabados son tan interesantes si están bien hechos. Por que no sólo le servirán al estudio que los ha hecho sino que posiblemente podrán ayudar a muchos otros desarrolladores que los lean y que estén viviendo situaciones parecidas.
Si tenéis cierta inquietud por el desarrollo, si soñáis con lanzar vuestro propio videojuego o si simplemente queréis una lectura muy interesante relacionada con una parte de la industria que no se suele conocer y que permanece alejada del frenesí de las noticias diarias, ha llegado vuestro momento.
Unos cuantos postmortems de lectura obligada
En portales como Gamasutra, lectura diaria obligada de todo desarrollador de videojuegos, se publican algunos de los mejores postmortems. Tienen una base de datos brutal que retrocede muchísimo en el tiempo pero yo os he elegido una pequeña recopilación de los que he encontrado más interesantes en estos últimos años.
Desde ‘BioShock’ hasta ‘Uncharted’ pasando por ‘Brutal Legend’ o éxitos independientes como ‘Super Meat Boy’ o ‘Splosion Man’. ¿Qué fue mal? ¿Qué decisiones erróneas se tomaron? ¿Cómo se pudo salir de ellas? ¿Qué podemos aprender de ellos? Lectura obligada, no lo dudéis ni un sólo momento.
• ‘Bioshock’ | Ver postmortem
• ‘Conduit 2’ | Ver postmortem
• ‘Super Meat Boy’ | Ver postmortem
• ‘Brutal Legend’ | Ver postmortem
• ‘Splosion Man’ | Ver postmortem
• ‘Rachet & Clank Future: Tools of Destruction’ | Ver postmortem
• ‘Uncharted: Drake’s Fortune’ | Ver postmortem
Si os habéis quedado con ganas de leer y aprender de las experiencias de otros desarrolladores podéis visitar el archivo de postmortems que guardan y bucear hasta dar con algunos realmente míticos.
Dicen que el ser humano es el único animal que tropieza dos veces con la misma piedra y puede que sea cierto pero caramba, intentemos que no pase. Bucear entre los postmortems que algunos equipos de desarrollo tienen a bien compartir con nosotros puede convertirse en una gran y útil herramienta de desarrollo y aprendizaje.
Elegir bien al equipo y al software, las herramientas, tiempo para prototipar, la denostada e importantísima (muchísimo más de lo que podéis pensar) parte del mérito que se lleva un buen departamento de QA, los cambios que propone el publisher a medio desarrollo, utilizar metodologías de trabajo adaptadas a la necesidad del equipo, un buen ambiente de trabajo, minimizar los periodos de crunch… son tantos factores los que pueden enquistarse y lastrar al proyecto que más vale ir con cuidado.
Al fin y al cabo seguro que los mejores juegos han tenido una gran gestión detrás. La calidad de artistas, programadores y diseñadores puede ser la mejor… pero un mal productor puede asesinar un proyecto sin que programadores, artistas o diseñadores tengan opción alguna a salvarlo.
Más Información | Gamasutra
Ver 18 comentarios
18 comentarios
HoTDoG
Lo que molaría echarle un ojo al Postmorten del Duke Nukem Forever...
LUISMI FOX
Muy interesante, me repasaré los que pueda con detenimiento, siempre se agradece aprender de los fallos ajenos.
Demux11
Cuando escuche hacerca de los postmortems hace mucho tiempo, pensaba que se trataba de algo que se hacian a los muertos despues de una autopsia, resulta que si es asi, solo que para los proyectos de software se les denomina postmortems a los elementos desechados de un software finalizado o cancelado. aqui se define mas a fondo: http://www.developer.com/tech/article.php/3637441/The-Project-Postmortem-An-Essential-Tool-for-the-Savvy-Developer.htm
Las palabras si que confunden xD
silva.raptor
Vaya, gracias por el reminder y los enlaces. No suelo mirar los postmortems porque no tengo mucho peso en las decisiones de mi proyecto, pero no estaría de más que les echara un buen vistazo.
Thanks!
rcerrejon
Muy útil, algunos me los estudiaré como si fueran textos sagrados porque tienen mucho valor hablar de programador a programador, ahora con Internet es todo mucho más fácil, claro que si, pero entre tanta información siempre te puedes perder.
Kikets
Vamos que los postmortem son como el Código deontológico del Gamer. Buscaré en la Web algo relacionado con algún RPG mítico como FF VII o Chrono Trigger.
darrufat
Me interesa mucho leer los independientes como Super Meat Boy, ya que hacer un Bioshock es casi imposible hacer un juego de este tipo sin participar mucha gente. No estará por ahí el del Angry Birds y el de Plants vs Zombies?¿ =P
ekil46
Realmente estan muy bien i sirven de ayuda, yo mismo podria hacer un postmortems: se me ocurrio la idea de un juego de zombis, tipo sandbox en el qual vayas avanzando, mejorar armas etc.... comenze con el word a escribirlo con todo de detalle para despues haber si alguna empresa lo acojia (ya que yo no tengo ningun tipo de recurso), asta que llego Dead Island, vi que tenia muchas similitudes con mi juego y deje de hacerlo. Vamos que la leccion seria que cuando empezeis una idea, mirat si hay algo parecido, parece muy basica pero con las ganas que tenia se me olvido xD.
Zarovich
Hombre, estas prácticas no es que procedan de los videojuegos. En general cualquier proyecto de software se rige por estas reglas y el postmorten es una práctica habitual.