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!