2016/10/13

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!

2015/10/12

Conservando el Pasado

Aunque he jugado muchos juegos, y he conocido muchos personajes a través de ellos, pocas veces me siento identificado con alguno. Más bien, suelo sentir como si manejara una marioneta, o si acaso, como si viera brevemente, como por una ventana, la vida de alguien más.

De esas pocas veces en las que he sentido una identificación o empatía particular con un personaje hay una que se me quedó muy grabada, tal vez porque incluso a mí me pareció poco obvia o inesperada, ya que se basa en un detalle muy poco notorio e irrelevante dentro del juego, pero que para mí tiene mucho significado. El personaje al que me refiero es Zasalamel, de la saga de Soul Calibur, y a decir verdad, no es mi personaje favorito del juegoni mucho menos... ni si quiera me gusta tanto su arma o su estilo de pelea... pero el momento que me hizo identificarme o al menos desear ser en parte como él, es un aspecto que se menciona en su epílogo, que me pareció muy memorable.


Zasalamel aparece por primera vez en Soul Calibur III, y en su origen se narra que nació mucho tiempo antes de los eventos del juego, en una tribu muy antigua, encargada de resguardar la espada Soul Calibur. Sin embargo, en algún momento, él tiene desacuerdos con las leyes de su pueblo, por lo que se rebela y decide autoexiliarse para tomar su propio camino. Ya que Zasalamel tiene afinidad por la magia, decide dedicarse a la búsqueda e investigación del conocimiento en esta área, incluido todo aquello que estaba prohibido en su tribu y lo que se creía que se habían perdido para siempre. En algún momento, Zasalamel logra aprender el arte de la reencarnación mágica, y de este modo puede morir y renacer indefinidamente, conservando intacta su consciencia y la memoria de sus vidas pasadas. Sin embargo, luego de numerosas reencarnaciones comienza a perder el gusto por vivir, así que decide finalizar con su vida de forma definitiva, pero desafortunadamente, no hay forma de anular el hechizo y está condenado a reencarnar por siempre (eso me recuerda algo que hice con algunos amigos hace ya casi 20 años). Buscando una respuesta a su problema, llega a la conclusión de que necesita el poder tanto de Soul Edge como de Soul Calibur para terminar con su existencia¹.

Al final del juego, Sazalamel logra su cometido, pero el poder de las espadas no lo elimina en el momento, sino que únicamente levanta la 'maldición' y Zasalamel vuelve a ser mortal:
"My curse was lifted, and I was freed from my eternal damnation. 
I then contemplated how I should spend the remainder of my life"

Ahora bien, la parte que me impactó y con la que me sentí muy identificado es lo que sucede inmediatamente después de esto:
Y posteriormente...
"With everything complete all that remains now... is to wait for my time."

Yo no he vivido ni viviré tanto tiempo como Zasalamel, y por lo mismo, nunca tendré tantas cosas que contar como él; y no sé si las cosas que yo experimente o presencíe durante mi vida sean del interés de los demás o si alguien siquiera se detendría a ver y repasar las cosas que viví.

Me gusta hacer muchas cosas y me gustaría hacer muchas otras más, pero de entre todas esas opciones, decidí enfocarme en unas cuantas y es lo que me lleva a definirme como 'Diseñador'. Sin embargo, hay una parte de mí que (tal vez de manera pretenciosa) no puede evitar sentirse 'historiador'.

Frecuentemente siento el impulso de llevar un registro de las cosas que hago y de las que pasan a mi alrededor: de las personas, de los lugares, de los eventos, etc, aun cuando algunos parezcan poco o nada relevantes. Me gusta recabar información, ordenarla y tratar de darle un sentido. Me gusta contar historias, tanto ficticias como reales. Me gusta tener y hacer referencias precisas que puedan consultarse cuando se requiera... Pero a nivel profesional, no soy historiador, no me dedico a esto, así que no puedo hacerlo de lleno. La mayoría de las veces lo que termino haciendo es ignorar ese impulso y tratar de evitar obsesionarme con eso para usar mi tiempo en cosas más 'productivas'... pero de vez en cuando, dejo salir esa pulsión y me pongo a escribir y registrar cosas. Esa es la principal razón por la que tomo fotografías, recopilo datos y comparto información. Quisiera poderle poner más esmero y dedicarle más tiempo para tener un archivo completamente extensivo, ordenado y sistemático, pero no puedo hacerlo. Tal vez no sería muy sano. Tal vez terminaría haciéndo una crónica de mí haciendo crónicas de mí todos los días porque seguramente las detallaría tanto que no me alcanzaría el tiempo para hacer crónicas de otras cosas. 

A veces quisiera poder tomar fotografías de todos los lugares en los que estoy, sacar planos y vistas de cada uno de ellos, explicar su uso, funcionalidad, de qué época es, la gente que está ahí, el motivo por el que estuve ahí, cuánto tiempo estuve ahí, cuándo y la sensación que me causó. Quisiera poder escribir una ficha exahustiva de cada persona que conozco, con imágenes y referencias y describir porqué estuvimos en contacto y lo que sucedió en cada ocasión que nos encontramos, etc. y también, recolectar y conservar toda evidencia física de los eventos importantes para mí, como boletos de cine, tickets de compra, boletos de transporte, objetos dañados (para registrar el evento en el que se dañaron). Pero es algo que nadie podría escribir/catalogar y nadie podría leer.

Mi parte autocrítica y psicoanalítica encuentra bastante obvias las razones de esta pulsión: Durante muchos años, sobre todo de mi infancia, mi vida fue una colección de etapas inconclusas, donde yo no tenía ningún poder de decisión de en donde y con quién estaría. Es decir, ese deseo de registrar y conservar elementos del pasado es el reflejo de mis traumas y carencias. 

Durante mucho tiempo sentí que apenas comenzaba a entender una nueva etapa de mi vida cuando esta concluía abrúptamente. Era como entrar y salir de albercas con distintas temperaturas, apenas me aclimataba a una y tenía que cambiarme a otra más fría o más caliente, así que nunca estaba a gusto y nunca las disfrutaba, solo experimentaba la parte incómoda de habituarse a algo nuevo. Como consecuencia de esto, por un lado, sentía un gran vacío y un enorme desasosiego porque sentía que las cosas eran interrumpidas de tajo. Por otro, todo ese cúmulo de situaciones me provoca(ban) un enorme deseo de volver atrás en el tiempo, de recuperar las cosas que había perdido y de aferrarme con vehemencia a lo que tenía en ese momento, porque sabía que en cualquier instante intentarían arrebatármelo, así que tenía que tomar medidas para evitarlo; y también porque necesitaba algo de cohesión y continuidad en mi vida; aunque ya no estuviera en el mismo lugar o con las mismas personas, necesitaba algo que fuera constante, que perdurara y me diera cierto sentido de pertenencia... Y por último, debido a esta situación, cada vez me sentía mas ajeno a todos los que me rodeaban, sentía que cada vez encajaba menos, y se iba volviendo necesario crear una especie de manual para explicarles quien era yo y de donde venía.



Aun así, toda esta necesidad de conservar el pasado, no lo veo como algo malo... o por lo menos tiene su lado positivo. Es decir, aun cuando todo fuera mi subconsciente tratando de protegerse, me agrada eso de tener 'souvenirs' que me remitan a momentos y personas específicos que ya no están a mi alcance. Mucha gente usa las fotografías, pero en mi caso no necesariamente es así; hay muchos objetos que me causan el mismo efecto o algo equivalente... Y sé que hay quienes piensan y sienten de modo similar. Aun si todo esto de preservar la historia, el conocimiento y la cultura resultara ser tan solo una consecuencia indirecta de los traumas e inseguridades de quienes se han ocupado de ello y de quienes han creado bibliotecas, museos y archivos, el beneficio es más que evidente. En tiempos recientes se habla mucho de que hay que saber dejar atrás el pasado y mirar hacia enfrente y entiendo el punto y su importancia, pero también, si todos pensaran así y siguieran al pie de la letra ese postulado, tal vez nadie se hubiera tomado la molestia de detenerse y preservar muchas de las evidencias históricas o de intentar recuperar la información perdida del pasado. A veces, la historia tiene un sentido y una relevancia bastante claros en el momento; pero no siempre es así, y por eso considero que todo conocimiento puede ser valioso y digno de ser preservado, además de que siempre habrá cierta pérdida de información y por eso, cualquier detalle adicional pueda servir para cotejar y recuperarla. Para mí, el conocimiento es lo más valioso de la cultura humana, por eso, no puedo pensar en un mejor final para un personaje que ha vivido tanto tiempo y ha visto tantas cosas, que el de pasar tranquilamente los últimos años de su vida registrando sus memorias.
Este sitio se visualiza mejor a 1280x1024 Pixels. Si tu monitor tiene una resolución menor, entonces está muy chafa... comprate uno nuevo.