|
Senior Member
Bleen está desconectado
Fecha de Ingreso: marzo-2004
Mensajes: 296
Poder de Credibilidad: 60
|
Post mortem
Buenas queridos colegas... hoy estaba revisando viejos backups, y me encontre con un post-mortem que escribi el año pasado. El post mortem es del juego "Mis Ladrillos Interactivo", e ilustra pegadas y errores en la produccion del juego. No es ni muy largo ni muy detallado, pero bueh... el que tenga ganas de leer, tal vez pueda aprender algo de las situaciones que pueden llegar a pasar en una produccion comercial. :-)
Puteadas bienvenidas :-P
----------------------------------------------------------------------
Mis Ladrillos interactivo: Post-mortem
2/7/03
Project planning:
Fue transmitido al departamento de arte, allá por el mes de Enero, la intención de hacer un juego para la compañía Mis Ladrillos, el cual consistiría de varios mini-juegos e instrucciones interactivas. Producción renegoció varias veces con el cliente, logrando achicar el numero inicial de 12 juegos a sólo 4, pero más trabajados. En arte esto nos daba un gran respiro (o al menos eso creí), ya que crear assets para 4 juegos medianos tendría que ser menos que hacer assets para 12 juegos chicos. Los juegos estaban definidos al nivel de “uno de carreras”, “uno de naves”, “uno de piratas” y “uno de la ciudad”. En ese momento la compañía estaba impaciente por empezar el trabajo, ya que cuando esto sucediera se cobraría el adelanto, el cual era necesario por temas económicos. Se hizo un rápido relevamiento de lo que quería el cliente, y se consultó a los departamentos de programación y arte (la reunión entre producción y arte duró no más de 30 min. según recuerdo). Pero todavía no había juegos diseñados, mas allá de la cabeza de algún que otro game designer. O sea, no había un texto que indicara los features de los juegos, sus requerimientos, objetivos, etc. Esto resultó en una evaluación errada de los requerimientos de arte, por lo tanto se presupuestó menos tiempo de realización. Se presupuestó 2 meses aproximadamente para todo el arte del juego, haciendo cuantas mentalmente sobre las ideas de los juegos. El arte total del juego tardó 5 meses y medio. Se falló en evaluar cosas como la interfaz (tanto in-game como menú), complejidad de los gráficos para los juegos, y, fundamentalmente, las instrucciones de armado, que en ese momento entendí que serían sólo para 1 kit de cada setting.
La producción:
Resulta que no había que hacer 1 kit por setting... esto lo descubrí cuando un día llegaron todos los kits que había que construir virtualmente: toda la línea de Mis Ladrillos Expertos. No recuerdo haber abierto tanto mi mandíbula como en ese momento. No solo teníamos que armar virtualmente todos los kits, sino que además teníamos que hacer las instrucciones de armado de cada uno. Para colmo me enteré en esos días, mientras armaba los kits, que los manuales provistos por Mis Ladrillos tenían varios errores. Por lo cual había que: 1)Armar los kits con las instrucciones “reales” 2) “Desarmar” los kits para hacer las animaciones de armado (se animó de atrás para adelante) 3) Pasarle las animaciones pre-renderizadas al cliente para que este corrija los errores que pudiéramos haber hecho, que sean culpa nuestra o de los manuales que él envió. 4) Corregir los modelos y animaciones 5) Aplicar calcomanías virtuales (el juguete lleva calcomanías, otra cosa que nunca se había definido).
Hay que aclarar un tema que sucedió con las instrucciones de armado virtuales: La idea de game design era hacer una serie de imágenes fijas, las cuales las definiría el cliente una a una. En tiempos de realización esto no nos difería mucho a hacer animaciones (o eso creíamos), ya que mediante el scripting de Maya hicimos una serie de herramientas para armar los kits, pintarlos y desarmarlos. La diferencia es que si hacíamos imágenes fijas hubieramos necesitado un input del cliente que creo aún hubiera sido muy difícil sino imposible. Hay que pensar que el cliente tendría que habernos mandado de alguna forma todas las posiciones de todas las piezas, y la de la cámara, para todas las imágenes de las instrucciones de armado de cada kit. Haciendo animaciones, mi idea era que no necesitaríamos de tanto feedback de su parte. Lo cierto es que las animaciones necesitaron de una corrección por parte del cliente, la cual tardo mucho tiempo. Por si esto fuera poco, el cliente trajo, en medio de la producción, 3 kits nuevos (debo aclarar que cada kit incluye 1 sub-kit, o sea cada kit se puede armar de 2 formas distintas, ergo son 2 modelos). De estos modelos ni había instrucciones de armado, por lo tanto tuvimos que armar los kits virtuales con los kits reales al lado, a veces desarmando alguna parte.
Lo que tampoco pensamos al hacer los manuales interactivos animados es que esto requeriría un sistema que pase las animaciones. Igualmente se suponía que de cualquier forma habría video en el juego, ya que estaban previstas 4 introducciones animadas (1 para cada juego). Aún hoy en día no podría decir si hacer las instrucciones en video fue algo favorable o no. Lo único que puedo decir es que seguro que quedó con más nivel.
Como mencioné antes, en la etapa de preproducción no se hizo un documento de diseño, lo cual produjo problemas presupuestarios. En esta etapa tampoco hubo documentos de diseño (por lo menos yo no los vi), por lo tanto, la gráfica que hacíamos la íbamos definiendo on the run. Un buen ejemplo de esto fueron cuando se hicieron 2 players de video tematizados por setting que luego no se usaron, se animaron y renderizaron todas las naves para el juego espacial, pero este cambió y se tuvieron que rehacer todas, y siempre se agregaban cosas cuando uno creía que ya se había terminado con todo (se hacían las listas “mis ladrillos arte final.txt”, “mis ladrillos arte final 2.txt”, “mis ladrillos arte final FINAL.txt”, etc... no parecía terminarse nunca). Un ejemplo de esto son los power-ups del juego de naves.
Otro problema a resaltar fue el tema del scissor. En arte teníamos entendido que no se podía usar alpha bajo ningún concepto. Por esto, tuvimos que recortar todos los sprites y backgrounds a veces a mano, a veces automáticamente, pero siempre con scissor. Lo cual nos dio mas trabajo. Finalmente, cuando el proyecto ya se estaba por terminar, nos enteramos que no era necesario hacer TODO con scissor... demasiado tarde, desafortunadamente. Personalmente creo que esto se debió a una mala comunicación entre equipos, o una mala coordinación entre estos.
Además, tal vez por falta de coordinación o bases de trabajo, no se trabajó tratando de optimizar al máximo la memoria del usuario – se hicieron gráficos demasiado grandes, con mucho espacio transparente (ejemplo el de la interfaz de barcos in-game).
Y se siguieron agregando tareas cuando se estaba finalizando el proyecto, por ejemplo el cliente decidió, de la noche a la mañana, que quería tener las cajas de 3 juguetes, por lo tanto, mientras terminábamos el proyecto, tuvimos que hacer las tapas de 2 de estos 3 juguetes, ya que las cajas se imprimían en las mismas plantillas.
Otro de los problemas que aparecieron hacia el final del proyecto es que, por alguna razón, dejó de funcionar el render queue del Maya. Esto hizo que renderizar las animaciones de armado de los kits fuera un caos. Por suerte Gastón hizo una planilla para organizarlos, sino hubiera sido imposible.
Vale resaltar lo que sucedió con el juego de helicópteros. Por tiempos ya teníamos que empezar a hacer los gráficos del juego de helicópteros, pero game design no tenía nada salvo una vaga idea de cómo sería. Así que empezamos a hacer la gráfica que suponíamos que se iba a usar (tiles de la ciudad, helicóptero). Milagrosamente los gráficos sirvieron, pero no es exactamente el ejemplo de una forma de trabajar.
Por otra parte, tengo que resaltar algunas cosas buenas del proyecto:
La elección de Maya como programa de 3D nos dio la flexibilidad de poder crear barras de menú por scripting sin conocer MEL, pudiendo agilizar increíblemente el armado de los kits y la confección de las animaciones de armado (aunque es cierto que luego tuvimos problemas con el render queue y la estabilidad). La simulación de agua del Maya nos posibilitó la creación del opening de piratas de una forma ágil.
Además, por utilizar Maya, usamos la misma estructura de directorio, lo cual nos vino muy bien, ya que si alguno de los dos no estábamos, la otra persona podía entrar a la computadora del otro y encontrar lo que quería.
Los 4 openings se hicieron muy rápido, con economía de recursos y tiempo, pero con calidad. Por ejemplo, se trató de planificar que haya la menor cantidad de animación de personaje posible (ya que tarda más), y si la había, estos deberían o no trasladarse, o si lo hacían, que no se vieran los pies (que es un tema complicado). El único problema con los openings fue con la primera secuencia del de carreras, el cual tardó una semana en poder renderizarse, ya que estaba demasiado cargado de cosas.
Al final, Gastón cargó el CVS con el juego, y pudo probar las modificaciones que hacía en los gráficos directamente en el juego, cosa que hasta entonces no podíamos hacer directamente, sin molestar a los programadores. Es lamentable que no nos hayamos enterado de esto antes.
Resumiendo
Mis Ladrillos Interactivo fue un proyecto accidentado desde un principio, pero mi impresión es que el mayor fallo fue no haber hecho un planeamiento detallado. Si lo hubiera habido, podríamos haber hecho un mejor presupuesto, y podríamos haber trabajado de una forma mucho más estructurada. Sin embargo, y a pesar de habernos pasado 3½ meses de lo planeado, a nuestro juicio la calidad del producto es muy buena.
Pablo A. Selener
|
Mode Lineal
