Crítica a la música de cine (por alquien que no es músico ni crítico de cine)

Últimamente, no me considero "fan" de casi nada. Ya no veo, leo o juego como antes, pero lo que más he seguido en los últimos años es el Universo Cinematográfico de Marvel (MCU). Me parece sorprendente lo que han hecho, cómo lo han hecho y, en general, disfruto de sus películas... aunque también es cierto que no están exentas de fallos y/o puntos débiles y la música es uno de ellos.

Hace ya varios meses, vi este video que critica las películas de Marvel por este aspecto. Menciona varios puntos que me parecen válidos pero siento que no llega al meollo del asunto y se desvía a medio camino.

Mi principal objeción con esta crítica es que, cuando le pregunta a la gente sobre alguna pieza musical de una película, las personas 'tararean' los temas principales, pero el cuerpo del video no habla de eso, sino de la música incidental. De hecho, la mayoría de la música incidental, aun de cintas con un gran tema principal, suele ser bastante olvidable, lo que no quita que haya un problema.

El anterior video se enfoca mucho en culpar de este mal al uso de la llamada “Temp Music”, es decir, música usada como ‘placeholder’ durante el montaje y la edición, sin embargo, esto no me parece ningún tipo de justificación para hacer música mediocre ni creo que radique allí el problema. Recuerdo haber visto algún video o texto que hablaba sobre el buen uso del ‘Temp Music’, pero por ahora no ahondaré en ello para no desviarme demasiado del punto al que quiero llegar.

Ayer en la mañana vi este otro video, que es una respuesta al anterior, y de nuevo, toca otros puntos relevantes, pero yo diría: “close!… but no cigar”.

Este segundo video habla de que para lograr una conexión emocional con el espectador, y que la música le sea memorable, hay que saber donde y como utilizarla para crear una asociación positiva significativa, y en el caso de las franquicias, también menciona la importancia de la reiteración, no solo durante la cinta, sino también en el material promocional, como trailers o comerciales. Ambos puntos son válidos, pero sigue dejando de lado lo más importante.

Bien, para este momento, me parece importante señalar/recordar que yo no soy músico, soy diseñador gráfico y diseñador de juegos. Ni siquiera tengo mucho vocabulario musical, sin embargo, la respuesta siempre me ha parecido bastante obvia (o tal vez por eso mismo creo que es algo simple).

En el segundo video, cuando habla de la reiteración, la autora pone unos ejemplos sobre uso de marcas/logos y fue lo que me hizo pensar en escribir este post, ya que pasó justo al lado del tema que quiero abordar, pero en lugar de hacerlo se pasó de largo.

¿Por qué son tan reconocibles estos "logos" (isotipos)?

Reconocemos que son 'McDonalds' y 'Nike', sin necesidad de texto. Sí, la repetición (es decir, que los vemos frecuentemente) es un factor de peso, pero lo que nos permite recordarlos con tanta facilidad es su sencillez y claridad, los cuales son principios fundamentales de diseño. Es información clara, breve y concisa. No es necesario almacenar muchos datos para saber cual es uno u otro y es evidente en que son distintos. No hay forma de que nos confundamos. Si conocemos las marcas y vemos el isotipo de la derecha en la marquesina de una tienda, no vamos a pensar que ahí venden hamburguesas.

Esta forma de información es tan concisa, que si cambiamos ligeramente los elementos visuales que la conforman lo notamos fácilmente. ¿Qué pensarían si ven esto en la entrada de un negocio?

Lo más probable es que lo interpretemos como una copia burda de la marca 'Nike'.

 

¿Alguien dijo “marcas chinas”?

Ok... pero ¿esto qué tiene que ver con la música para películas y en particular con la del MCU? La respuesta radica en un término...

MELODÍA

"Una melodía es una sucesión de sonidos que es percibida como una sola entidad. Se desenvuelve en una secuencia lineal, es decir a lo largo del tiempo, y tiene una identidad y significado propio dentro de un entorno sonoro particular."

“En su sentido más literal, una melodía es una combinación de alturas y ritmo" … "se puede considerar que la melodía es el primer plano respecto del acompañamiento de fondo.”

Tomado de Wikipedia

En otras palabras, una melodía es básicamente esto:

En los tiempos de los juegos de 8-Bit, la música de los videojuegos se componía casi exclusivamente de una melodía. Podía haber acompañamiento, pero regularmente era muy sencillo (como en este caso). Así que para que la música funcionara y fuera distinguible de la de otros juegos, la melodía, es decir esa sucesión de notas de distinto tono y duración, debía ser única e inconfundible. Igual que las formas y colores de un logo. 

"La melodía parte de una base conceptualmente horizontal, con eventos sucesivos en el tiempo, y no vertical, como sería en un acorde donde los sonidos son simultáneos".
Tomado de Wikipedia

Es decir, una melodía consiste en un conjunto de notas que se tocan individualmente, una detrás de otra, por eso es información breve, clara y consisa... como en un logo. Es poca información y es fácil de identificar y recordar (aunque probablemente la mejor analogía con un logo sería una "Frase Musical").

Además, aun con acompañamiento, como dice la definición, la melodía debe ser el primer plano, debe ser lo que resalte y el resto girará en torno a esta.

 

Si la melodía está bien creada y, por lo tanto, es clara, entonces vamos a poder hacer esto:

Aun agregando elementos o modificando algunas de sus características (como el tempo) una buena melodía sigue siendo reconocible y podemos jugar con ella para generar diferentes versiones que pueden utilizarse de diferentes maneras.

En el caso de la música incidental para cine, es común es que no tenga una melodía distintiva o que esta no sobresalga mucho, lo cual es muchas veces intencional, justamente porque lo que se quiere es acompañar la imagen y marcar un tono pero no robar la atención del espectador... pero no tiene que ser forzosamente de esta manera y hay claros ejemplos de ello, como toda la magnífica música que John Williams ha compuesto para "Star Wars", y que tienen melodías muy bien trabajadas que encajan perfectamente con las imágenes en movimiento, y que ayudan a forjar la identidad de lugares, personajes y situaciones.

 

Tampoco es forzoso que cada una de las piezas de un "Music Score" sea una obra maestra única e inconfundible para que este sea bueno. Hay diferentes momentos en una película con diferentes necesidades de audio, pero lo que si me parece pertinente es que se establezcan diferentes grados de jerarquía y complejidad según se requiera, partiendo del tema principal hasta llegar a los motivos musicales de uso más general; y aquí es donde, además de la melodía o las frases musicales recurrentes, entran otros aspectos como el ritmo o la instrumentación para definir el estilo y darle cohesión a la obra.

La Melodía es el principal elemento que hace memorable a una pieza musical... y es de lo que carece, en gran medida, la música de las películas del MCU.

Tratando de entender de forma un poco más sistemática y general cómo funciona esto, podemos enumerar varias razones por las cuales un conjunto de información (llámese pieza musical, imagen, texto o lo que sea) llega a ser poco memorable, lo cual tiene que ver con la forma en la que el cerebro procesa dicha información. Mencionaré tres aspectos que están interrelacionados:

a) Porque la intensidad del estímulo/información es débil y no sobresale. Si la información es muy similar al 'fondo' no habrá suficiente contraste y tenderá a pasar desapercibida.

b) Porque se compone de patrones simples y/o repetitivos, sin variaciones significativas. Por lo tanto, nuestro cerebro tiende a habituarse rápidamente o simplemente no encuentra información importante, lo considera irrelevante y lo descarta. Tal vez, algo como esto(?):

b) Porque el estímulo/información es muy complejo pero no hay un conjunto que resalte del resto. Nuestro cerebro intentará analizar toda esa información, lo cual, es cansado (saturación), así que buscará simplificar el proceso buscando patrones, pero si no los encuentra y no puede determinar rápidamente qué parte de toda esa información es relevante y qué parte no, al final se vuelve una 'plasta'... y nuestro cerebro descarta el conjunto. En otras palabras, aunque haya mucha información si no es clara y fácil de catalogar, se pierde el contraste entre estímulos. El 'Black Midi' puede ser un ejemplo:

En resumen, el Contraste es fundamental, y por ello es tan importante la melodía, porque las variaciones en el tono y/o ritmo son información clara que capta fácilmente la atención de nuestro cerebro y nos predispone a recordarlo.

Ejemplo:

¿Cuál es la diferencia entre estas dos imágenes?

.
.
.
.
Respuesta:  
Es la misma imagen, pero invertida verticalmente.

Es poco probable, pero tampoco es imposible que lo hayan podido determinar, porque cuando hay conjuntos de información complejos el cerebro trata de ubicar patrones emergentes, y al ver las imágenes yuxtapuestasse puede ser más fácil notarlo si es que estos se forman. Ahora, si les dijera: "descríbanme la imagen" o más aun "dibújenla sin verla" ¿cómo lo harían? Aunque la imagen contiene mucha información, nuestro cerebro no la puede catalogar fácilmente, así que solo la interpreta como "conjunto de puntos blancos y negros sin orden particular".

Otro ejemplo:

Encuentra las diferencaeste entre la imagen 'A' y la 'B'

Fácil, ¿no?

Ahora, encuentra las diferencias entre 'C' y 'D'

Aun cuando hay un mayor número de diferencias en el segundo caso, al manejar más información se vuelve más difícil interpretarla y recordar detalles. Podrán memorizar fácilmente que en la imagen hay una bicicleta verde, pero si mañana, alguien de ustedes ve en la calle una bicicleta similar, difícilmente podrán decir si es la misma bicicleta o no, o cuáles son las diferencias... a menos que hagan un gran esfuerzo consciente. Lo mismo sucede con la música. 

La música orquestada puede ser muy bella (aunque desafortunádamente a veces se cree que el solo hecho de ser orquestada es garantía de que será buena música) y esa complejidad que le brindan los acordes, el ensamble de los instrumentos y otros factores, le pueden añadir gran profundidad, pero si no se hace bien y su construcción no gira alrededor de una melodía definida, los estímulos se mezclan y termina sintiéndose 'plana' y por ende, poco memorable. Por eso hay actualmente mucha "música orquestada genérica" tanto para cine como para otros medios, y es parte de lo que le pasa a la música del "Marvel Cinematic Universe". 

El tema principal de los Avengers (que es la pieza más destacable del MCU), me agrada y no se me hace malo, aunque tal vez le falta 'un algo más' para ser excelente. No sé si la melodía es un poco simple (entendiendo que 'simple' y 'sencillo' son cosas distintas). Siendo honesto, cuando lo intento recordar, no siempre puedo hacerlo y me tardé en ubicarlo como el tema principal de los Avengers. De hecho, no lo interioricé con las películas, sino con el juego de "Marvel: Avengers Alliance" y es lo que se me viene a la mente cuando escucho el tema musical (y aquí si tiene que ver también lo que menciona el segundo video sobre la reiteración).

Claro que también podemos mencionar las canciones de AC/DC y Black Sabbath que se utilizaron en la primer película de "Iron Man", y el soundtrack de "Guardians of the Galaxy", que son muy buenas selecciones que le agregan mucha personalidad a las películas y personajes...

 

 

...pero la música compuesta ex-profeso para las cintas no logra ser trascendente y sus melodías no son memorables. Revisándola un poco, la música no es del todo mala. La escucho y tiene elementos agradables... pero tampoco es suficientemente buena porque ni siquiera puedo recordar la melodía a los pocos minutos de haberla escuchado. Y es que, más que tener una buena melodía como columna vertebral, algunas piezas parecen compuestas por retazos (que suenan bien, pero al final son retazos) pegados sin un orden específico. No varían sustancialmente y no tienen una estructura que me marque momentos como un climax o un desenlace o un cambio de intensidad... y, de nuevo, aunque tengan muchos elementos se sienten planas porque no hay un buen contraste entre los sonidos.

 

Una forma muy coloquial de decirlo, pero que me parece precisa, es:

Para que una pieza musical sea memorable, debe ser 'tarareable'.

Si no la puedes 'tararear' o silbar ¿cómo &$%! la vas a recordar? ¿qué vas a recordar?

De cierta manera, la música incidental del MCU (y de muchas otras películas), es como las pinturas de Bob Ross. En general, son agradables, cumplen en el momento y para ejecutarlas se requiere cierta capacidad técnica... pero al final no hay algo importante que las diferencie del resto. Están construidas con "ladrillos" genéricos que ya hemos visto o escuchado previamente en incontables ocasiones y por ello nuestro cerebro ya ni siquiera les presta demasiada atención. Hay miles de pinturas similares con montañas, árboles y ríos y ninguno de estos elementos es único, es decir, no son ningún río o montaña en particular, son árboles, montañas y ríos genéricos. Si mañana o cualquier otro día vemos 10 pinturas de este estilo, posiblemente no sabremos cual es la que vimos hoy, y tal vez ni siquiera podamos saber cuales son de Bob Ross y cuales no. 

De hecho, hacer estas pinturas es una especie de atajo porque, aunque requiere cierta capacidad técnica, tampoco es demasiada y tiene que ver más con la ejecución que con la composición. Están compuestas por elementos fáciles de hacer y repetirse, y tampoco requiere demasiada precisión (no pasa nada si el 'árbol genérico 8' queda un poco más a la izquierda o a la derecha). Lo mismo sucede con la música incidental que solo es un 'filler' pero no tiene personalidad. Una nota más o menos, o una nota más larga o más corta no va a afectar sustancialmente el resultado final.

 

Ok, está bien. Queda claro que hay un problema con la música del MCU y de otras cintas. Pero entonces ¿cómo debería ser?, o al menos ¿cómo me gustaría que fuera? 

Para decirlo brevemente, al cuestionarme el asunto, pienso en esto: 

Y no solo me refiero al tema principal que podemos identificar fácilmente con el programa y los personajes en conjunto, sino que cada personaje protagonista tiene un tema que va muy acorde a sus características y personalidad y la simple presencia de la música nos anuncia su aparición y refuerza su identidad. 

 Hasta el tanque tiene su tema... XD 

(y está bien chido!)

¿Alguien recuerda o puede 'taratear' los temas de Iron Man, Thor o el Capitán América de las películas del MCU? (si, si existen esos temas):

.

.

.

.

.

.

.

.

Y ya solo, a manera de epílogo, para no dejar la idea en el tintero, me acordé de la manera en la que Masafumi Takada (que es mi compositor favorito de música para videojuegos) juega con las melodías y otros elementos musicales, de manera que es capaz de agarrar algo como esto:

...y producir algo como esto:

Me parece muy sorprendente como logra mantener la identidad de las piezas originales, pero a la vez, con cambios (en ocasiones) sutiles, logra que se escuchen tan bien y al mismo tiempo les imprime la personalidad del juego.

Mi Proceso de Diseño (de Juegos)

Yo estudié la Licenciatura en Diseño Gráfico hace… ya algunos ayeres. Sin embargo, mi interés siempre han sido los Juegos. Estudié diseño gráfico para poder entrar a la industria de videojuegos haciendo gráficos… bueno, ese era mi plan original. Surgió la oportunidad de trabajar profesionalmente como diseñador de juegos en el 2006 y la tomé. 

Desde que era estudiante, siempre tuve la inquietud de tratar de definir qué es Diseño, sobre todo, en contraposición con el Arte, ya que yo estudié en una escuela de Artes Plásticas y comúnmente me enfrentaba a la necesidad de aclarar: “No soy artista, soy diseñador” o “lo que hago no es arte, es diseño”. Pero entonces, ¿qué es diseño? Si bien, utilizo algunas herramientas en común con los artistas, el enfoque es distinto. Entonces posiblemente el Diseño era la otra cara de la moneda, así que mi primera conclusión fue que el Diseño Gráfico podría ser una Ciencia. Sin embargo, al conocer de cerca el ámbito científico me di cuenta que una ciencia es otra cosa, el objetivo de la ciencia es la generación de conocimiento. El diseño, al igual que muchas otras áreas, echa mano de la ciencia pero su objetivo es otro. La conclusión a la que llegué (al menos hasta ahora) es que el Diseño pertenece al campo de la técnica, y está emparentado con la ingeniería (aunque ya me habían dicho antes algo similar).

Esta interrogante tomó un segundo rumbo cuanto entré en contacto con el Diseño de Juegos, y siendo algo tan distinto al Diseño Gráfico, surge la pregunta ¿qué es lo que tienen en común?, ¿por qué ambos se denominan diseño?, ¿hay principios, herramientas o procedimientos que sean aplicables a ambas áreas? Al principio no parecía tan evidente, pero con el tiempo, me di cuenta que el proceso que estaba aplicando en el diseño de juegos básicamente era el mismo que aplicaba como diseñador gráfico y que se podía aplicar a muchas otras cosas.

Este es mi proceso general de Diseño:

Primeramente, parto de la definición de Diseño que utilizo. Esta definición la construí yo mismo tomando como referencia varias definiciones que he encontrado a través de los años, así que es muy probable que se parezca mucho a otras que pueden encontrar.

Como se puede ver, esta definición es muy general y por lo tanto, aplicable a muchas cosas. Esa es la idea, que sirva para algo tan básico como definir en qué orden voy a hacer los pendientes del día y que ruta tomaré, hasta cosas complejas como plantear a detalle que características debe tener una aplicación, y obviamente, también aplica a Juegos. 

En esencia, todos aplicamos este Principio de Diseño a diario, porque el principal aspecto del proceso de diseño es la TOMA DE DECISIONES, elegir entre ‘a’ o ‘b’, definir si ‘n’ debería ir antes o después de ‘m’, o si mi proyecto deberá llevar ‘x, y, z’ o solo ‘x,y’, ‘x,z’ o cualquier otra opción disponible.

Con base en lo anterior, podemos establecer un flujo muy básico donde partimos de una necesidad o problema, luego nos surge una idea y con esa idea construimos una propuesta de diseño.

Sin embargo, el Diseño es un Proceso Formal, debe hacerse de manera Ordenada y Sistemática y aquí todavía no existe esa formalidad. Además - como lo dice la definición - no habrá una solución ideal para todos los casos sino que variará dependiendo de las circunstancias. Es decir, no solo dependerá del problema planteado, sino también de los recursos con los que contamos y las limitantes que tenemos en cada caso. Ese es el trabajo del diseñador, tomar en cuenta esos factores.

Hace ya algunos años, me topé con esta entrada en este blog que menciona un proceso similar, pero un poco más formal. En este caso, el “First Principle” es el problema a resolver o el objetivo que se persigue. En segundo lugar, hay que tomar en cuenta las Limitaciones, y a partir de ahí, podemos formular “Decisiones de Diseño” que puedan resolver el problema o cumplir el objetivo inicial.

Lo anterior, es muy similar a lo que había leído en el libro “Fundamentos del Diseño” de Robert Gillam Scott, él menciona una “Causa Primera” que es equivalente al “First Principle”, una “Causa Material”, es decir, ¿con qué se va a elaborar esa solución? Y una “Causa Técnica”, la cual representa los conocimientos y procedimientos con los que se cuenta para producir la solución planteada. Tanto la “Causa Material” como la “Causa Técnica” están relacionados a la parte de Recursos y Limitantes.

 

Tratando de conjuntar todo lo anterior en un solo proceso, de forma más clara (al menos para mí), llegué a esta conclusión, la cual se compone de:

• Planteamiento: Es equivalente a la “Causa Primera” o el “First Principle”, es decir, es el planteamiento del problema u objetivo ¿qué es lo que tengo que resolver?
• Investigación: Posteriormente, mediante la observación, consulta o cualquier método pertinente se recopila la información relevante del caso, como fechas de entrega, presupuestos, el tipo de personas que utilizarán esa solución, etc.
• Análisis: No solo basta reunir la información sino que deberá analizarse para tener claro cuales son nuestros recursos, limitantes, obstáculos, opciones, etc. o si las necesidades reales del caso corresponden con lo establecido en el Planteamiento y de esta manera podremos empezar a sacar conclusiones que nos lleven al siguiente paso.
• Formulación de Solución: Esta es la etapa de Proyección o Planeación como tal, lo que diríamos que es la parte central del Proceso de Diseño.
• Implementación: Por último, se implementa la solución, es decir, se construye, programa, o ejecuta lo que se haya diseñado; lo cual, desde esta perspectiva, sería una etapa distinta al Proceso de Diseño.

Sin embargo, ¿cómo podemos saber si esta solución es adecuada? Actualmente, en muchas áreas se pone un gran énfasis en los procesos iterativos. Es prácticamente imposible tomar todas las decisiones correctas a la primera, por lo que es importante someter el producto o solución a un ciclo que incluya algún tipo de prueba y revisión, que nos permita perfeccionarlo. Gráficos como este los van a encontrar fácilmente si 'googlean' las palabras iterative process.

Sin embargo, este ciclo no puede ser infinito, sino que es más bien una espiral que luego de cada ciclo se acerca más a su culminación, tomando en cuenta que el tiempo y el dinero también son recursos/limitantes que dictarán que tanto podemos invertir en nuestro Proceso de Diseño, por lo tanto, es muy probable que no encontremos una solución ideal, sino que simplemente debemos acercarnos lo más posible a ese ideal, dentro de nuestros límites.

Así que retomando el esquema de la fig. 05 cambiamos “Formulación de Solución” por “Propuesta”, ya que esta no es definitiva, sino que está sujeta a los resultados obtenidos. Añadimos una fase de “Prueba” y en caso de que los resultados no sean satisfactorios, se regresará a la parte de “Análisis” para determinar el por qué no fue así, se replantea la Propuesta, se Implementa de nuevo y se vuelven a hacer Pruebas hasta que el resultado sea satisfactorio (dentro de nuestros límites) y tengamos un Producto Final. El tipo de implementación dependerá de la etapa de desarrollo en la que nos encontremos. Hablando de Juegos, puede referirse a un prototipo en papel, a un prototipo digital,  un ‘feature’ del juego o incluso un juego completo.

Poniéndonos un poco más exigentes, la aplicación de Pruebas debe ir de la mano con un sistema de Evaluación que nos permita determinar si el resultado es o no satisfactorio y dependiendo de ello se decide si se requiere aplicar un ciclo adicional o ya podemos tener un producto terminado.

La Implementación y las Pruebas no son responsabilidad directa del Diseñador, pero se incluyen como parte del proceso porque no puede ni debe desentenderse de estas etapas. Su trabajo no concluye hasta que se haya comprobado que, efectivamente, su propuesta soluciona el problema planteado inicialmente. En el caso de los juegos, el Diseñador no hace Documentos, o Pitches o Prototipos; el diseñador hace juegos, y mientras no esté terminado el juego, deberá estar al pendiente de todo el proceso de desarrollo y hacer los ajustes necesarios.

Obviamente, este proceso es muy general y muchas cosas no se están detallando porque la idea es que (como ya se mencionó) aplique a diferentes tipos de soluciones, no solo juegos, pero puede ser un punto de partida para plantear flujos más específicos, detallando uno o más pasos del proceso, según se requiera.

En ocasiones, algunos de los pasos se llevan a cabo de manera informal o implícita, pero aun así es importante tomar en cuenta que deberán cubrirse estos aspectos.

Esta es una variante del proceso anterior, más aplicado a Diseño de Juegos y que era con el que que estuve trabajando hace algunos años:

• Todo comenzaba con un Requerimiento o petición. No necesariamente para un nuevo juego, sino que regularmente era un minijuego o cualquier característica que se pensaba agregar al proyecto. Este requerimiento podía venir del 'Project Manager', del área de Marketing, del Community Manager o de cualquier otra área, incluido el mismo departamento de Diseño, y regularmente se decidía en junta si ese elemento era relevante se llevaría a cabo o no.
• Una vez tomada la decisión, se Asignaba la tarea a un miembro del equipo de diseño. Aunque no necesariamente esa persona tenía que hacer todo el proceso, se nombraba un responsable de esa tarea. Se determinaban ‘deadlines’ y se definían los elementos 'must have' y/o 'nice to have'. A partir de este punto, cada quien trabajaba de la manera que mejor le parecía, pero personalmente procuraba seguir esta línea.
• Se procedía a la etapa de Investigación. Se consultaban otros juegos, se revisaban métricas o estadísticas, se buscaban imágenes de referencia, se consultaban artículos que hablaran de lo que se iba a haer, y se revisaba la documentación de luego ya existente o lo que fuera necesario, incluida la revisión del material de la licencia con la que estábamos trabajando, y por supuesto, los demás miembros del equipo también son fuente de información. El tipo de consulta o información requerida dependia de lo que fuéramos a diseñar. 
• El Análisis abarcaba también una revisión de los recúrsos físicos y humanos y cualquier limitante técnica encontrada en la investigación que pueda ser relevante en el desarrollo del feature pensado. Por lo regular, el resultado del análisis se ve reflejada hasta la elaboración de los documentos.
• Después de eso, llegamos a la etapa crítica de Diseño, comenzando con la Generación de Ideas de cómo resolver el problema, la cual podía ser individual o en equipo. Esta etapa todavía es muy informal y podía incluir una "Lluvia de Ideas" o algún tipo de sondeo, dependiendo que tan específico haya sido el Requerimiento. Por ejemplo, si era un módulo para enviar mensajes entre usuarios, solo habría que ver cómo iba a funcionar, pero si se trataba de un nuevo minijuego, el trabajo era mucho más libre.
• De las ideas propuestas, se elegían una o más que parecieran satisfactorias o fueran lo más cercanas posible a lo que se planteó en el Requerimiento. A veces no había mucho margen de acción y solo se tendía una idea con la cual trabajar. En este punto, se elaboraba un documento breve de ‘Alto Nivel’ de cada una de las ideas elegidas como lo serían un Documento de Concepto, o un ‘Pitch’ si se requiere.
• Posteriormente, este documento se compartía con varios miembros del equipo para obtener su Retroalimentación. Se consultaba con quien hubiera hecho la petición, con el 'Project Manager' y con los líderes de las demás áreas (básicamente con el lider de gráficos y el de programación). Cada quien lo revisaba para analizar su viabilidad y empezaran a contemplar los tiempos de producción y quienes estarían a cargo de la implementación. Ya sea de manera oral o escrita, cada miembro del equipo con quien se compartió la información debía externar sus inquietudes, comentarios y dudas para darles solución, poder aprobar la propuesta y pasar a la siguiente etapa. Si surgía un problema grave de viabilidad, en este punto aun se podía descartar la característica pensada, pero si no, por lo regular se llevaba a su culminación.
• Una vez aprobada la propuesta de Alto Nivel se procede a generar Documentos a Detalle con todo lo que se tiene que implementar, tomando en cuenta los comentarios del resto del equipo. En esta etapa se definen flujos de navegación, flujo de manejo de errores, diagramas, gráficas, mockups, tablas de valores, listado de assets y todo lo que haga falta. Es decir, se producen lo que comunmente se conoce como Documentos de Diseño, pero es importante señalar que el formato y tipo de documento dependerá de lo que se tenga que hacer y de cómo se deba comunicar al equipo. La forma en la que yo elaboraba documentos iba cambiando porque me daba cuenta que algunos recursos que usaba no eran claros para los demás y los fui sustituyendo por otros más entendibles.
• La documentación se compartía con el resto del equipo, a veces hasta que se completaba, pero muchas veces conforme se iba generando cada gráfica o diagrama, dependiendo de lo que se estuviera haciendo, con el fin de agilizar la Producción e Implementación. Si llegara a haber una omisión mayor en el documento, se regresa al departamento de diseño, de lo contrario, se puede proseguir o corregir sobre la marcha.
• Durante la etapa de Pruebas, se revisaba que la característica o elemento implementado cumpliera con las especificaciones del documento de diseño, además se hacían otro tipo de pruebas para revisar su funcionalidad o su propensión a errores.
• La mayor parte de los 'bugs' y problemas detectados en la etapa de testing eran de funcionalidad e implementación, por lo que se regresaba a la etapa de Producción, pero si había problemas de diseño, se tenía que regresar y modificar la documentación, modificar el juego o ambos. En ocasiones, el problema podía ser completamente de funcionalidad (bugs,  desempeño), pero aun así, podía ser que lo más práctico fuera hacer ajustes al diseño para sortear ese problema. Una vez resueltos todos los problemas, o al menos los que son críticos, se puodía considerar como producto terminado y proceder al lanzamiento.

Falta mucho más por detallar, pero considero que esta es una estructura general que se puede aplicar a todos o la mayoría de los casos. ¿Cuál es su proceso de diseño? ¿cómo mejorarían este proceso? ¡Cualquier comentario es bienvenido!