Un...¿diseñador de juego?
Hace ya tiempo que hacen falta grandes equipos y gente muy especializada para hacer un videojuego. Sin embargo, aunque todos sabemos perfectamente lo que hace un programador o un texturador, queda menos clara la labor del diseñador de juego. Fijaos que digo diseñador de juego, que no es lo mismo que diseñador de niveles o, un puesto que existe en algunos estudios, diseñador de contenidos.Asi que, ¿qué es un diseñador de juegos? ¿Es el que...
- ...define el mundo donde se desarrolla el juego, el objetivo del jugador, los conflictos y la motivación de los enemigos?
- No, ese es el escritor
- ...define el aspecto que va a tener el juego, el estilo de iluminación a utilizar, el tipo de vestimenta que llevan los enemigos?
- No, ese es el artista de concepto
- ...coordina el trabajo de arte y programación, definiendo los requisitos y haciendo el seguimiento de cuando se van entregando?
- No, ese es el producer
- ...especifica cómo van a funcionar las herramientas que se usan para producir el juego, incluyendo scriptado, definición de propiedades y estructura de misiones?
- No, ese es el programador de tools
- ...define como se va a estructurar y configurar el funcionamiento de los enemigos?
- No, ese es el programador de IA
- ...define las misiones, plantea el espacio donde se van a desarrollar y elabora las situaciones que se pueden producir?
- No, ese es el diseñador de niveles
- ...escribe el código de script, coloca a los enemigos y configura sus propiedades para implementar las misiones del juego?
- No, ese es el scriptador
- ...juega con la versión para detectar anomalías, como problemas en el código o en los gráficos?
- No, ese es el tester
- ...explica qué es lo que el público quiere y los juegos que tienen éxito comercialmente, para incorporar sus elementos?
- No, ese es el analista de marketing
- ...escribe periódicamente informes de actividad, evaluaciones de progreso, estadísticas de datos definidos y planificaciones?
- No, ese es el burócrata
- ...organiza documentación, selecciona tipos de letra, formatos, prepara índices y glosarios?
- No, ese es el documentalista
- ...identifica las piezas que componen la jugabilidad: acciones del jugador (verbos) y elementos interactuables en el juego (nombres), define su funcionamiento e interacciones, y explica por qué son divertidos?
- Si, efectivamente :-)
- ...juega con la versión o ve a otros jugar para identificar elementos que funcionan y que no, y potenciar los que sí y corregir los que no?
- Si, eso también
Dicho esto, es perfectamente normal que una persona haga uno o más de estos trabajos, además del de diseño de juego, pero no hay que perder de vista que, mientras lo hace, no está diseñando el juego, propiamente dicho. Además, esta clasificación nos puede ser útil para tratar de identificar mejor los roles que va a desempeñar una persona, y ver si tiene las habilidades necesarias o ayudarle a desarrollarlas.
Lo que sí es cierto es que, en cualquier caso, el diseñador de juego va a tener dependencias con muchos de los roles aqui descritos. El tener conocimientos en esas áreas le será de gran utilidad. Igual de importante será a la inversa, que la persona que desempeñe el rol correspondiente entienda el trabajo del diseñador. Creo que la clave para funcionar bien es que cada uno haga lo que mejor se le da, y la comunicación sea fluida en los puntos donde haya dependencias.
Mostrar/ocultar resto...
creado por sgarces
9 comentarios
9 Comments:
En cuanto a las funciones del designer que expones:
1.- identifica las piezas que componen la jugabilidad: acciones del jugador (verbos) y elementos interactuables en el juego (nombres)
2.- define su funcionamiento e interacciones
3.- y explica por qué son divertidos?
estoy totalmente de acuerdo pero entiendo que falta una cuarta función altamente imprescindible y que puede tirar por la borda el resto:
4.- Evalua su viabilidad (junto al Technical lead y al AI Lead designer, principalmente). Me explico: Muchos mecanismos de juego son divertidos, funcionarían en el contexto del juego, pero son claramente imposibles de llevarse a la practica por las limitaciones del motor gráfico, motor de IA, etc..
(Ejemplo: Quizás el considerar que las sombras dentro del juego tengan un papel ACTIVO en las acciones de los personajes sea una muy buena idea pero con el motor concreto del juego las sombras no son más que meros efectos gráficos de escena --aplicación práctica: una caja que proyecta sombra sobre un bloque de hielo que contiene un artefacto explosivo que al contacto con el aire explota. Las sombra proyectada sobre el hielo impide que éste se derrita y la bomba no explote. Retirando el personaje la caja y exponiendo el bloque de hielo a la luz directa del sol el escenario haría booommm...'. En este hipotético caso el mecanismo de juego de proyección de sombras puede ser divertido pero quizás el entorno técnico del juego no pueda -o quizás sí- soportar tal mecanismo => Es importantísimo la capacidad del DESIGNER de conocer las posibilidades de cada pieza del sistema (contra más detalle mejor), comunicarse con los distintos leads del equipo (que le proporcionaran el conocimiento específico y capacidades de cada área), se capaz de analizar (importantísimas las dotes de analísis), valorar (si es de manera formal -demostrativa- mucho mejor), sopesar y evaluar (saber priorizar y seleccionar/descartar)si este mecanismo -junto o por encima de otros- será capaz de funcionar el entorno global del juego.)
Salu2
imaGame
Excelente ejemplo. Pero sigo manteniendo mi postura.
Dices que el diseñador debe, tras definir una mecánica, "evaluar su viabilidad". Pero creo que no es necesariamente exigible para el diseñador el conocimiento técnico necesario para hacer una evaluación correcta. Para ello está el programador que se encargará de implementar la mecánica. Él (o su lead) será quien deba hacer la evaluación del coste de implementar esa mecánica, no el diseñador.
Es justamente este tipo de situaciones sobre las que intento llamar la atención desglosando la responsabilidad de manera tan fina. En mi experiencia, muchas veces se sigue esperando del diseñador un abanico de conocimientos que contrasta con la mayor especialización (y complejidad) del desarrollo hoy. Se pide que el diseñador defina la mecánica, luego escriba la historia que la ambientará, dé una idea del aspecto que tendrán los personajes, especifique los requisitos y el funcionamiento de la herramienta que se usará y, como dices, evalúe la dificultad técnica de implementarla. Salvo que el diseñador tenga un talento extraordinario, algunas de estas responsabilidades serán excesivas.
Ya de por sí es extremadamente difícil llegar a un diseño que sea divertido, coherente, innovador... Si además exigimos al diseñador ser capaz de hablar con autoridad sobre todos los aspectos del desarrollo (que hemos dicho es cada vez más complejo), le estamos pidiendo un imposible. O el resultado será mediocre (p.ej. con un diseñador poco técnico, o que no sea buen escritor), o directamente no encontraremos diseñadores para reclutar que sepan de todo.
Lo que el diseñador tiene que hacer es apoyarse en la comunicación. En realidad, la exigencia de ser "hombre orquesta" aisla al diseñador. Si le pedimos hacer la evaluación técnica, quizás consulte al programador, quizás no. Si le decimos que tiene que pedir la evaluación técnica al programador, lo hará sin duda. Todo el equipo debe participar en el proyecto, y todos tienen algo que aportar, cada uno en su área de especialización.
Cierto es que no es exigible que el diseñador tenga el conocimiento técnico necesario para realizar una evaluación técnica por sí mismo (cada maestro en su campo). Debe siempre apoyarse (a través de comunicación, mediante delegación de prebas, soporte continuo, etcc..).
Pero sí soy de la opinión que el DESIGNER del juego debe ser capaz de evaluar (valorar o ser consciente del impacto de toda mecanica/elemento de juego que diseñe y que vaya a integrarse en el entramado del sistema). Sólo cuando las cosas se valoran adecuadamente (mediante un correcto estudio de viabilidad) se puede asegurar que cada pieza del conjunto funcionará y lo hará de la forma correcta.
Esta función de valoración o viabilidad es la que puede asegurar que los mecanismos de juego identificados y funcionen en el conjunto final, minimizando riesgos de marcha atrás o cambios tardíos en el desarrollo que tan costosos son. que Eso aseguraría que que según creo es lo que hace que un juego enganche y se pueda calificar como Buen juego.
Recuerdo el follón que se armó con Peter Moulineux cuando hablaba de lo que iba a ser Fable y tras x años de desarrollo y pretendiendo hacer algo muy ambicioso tuvo que recortar muchas funcionalidades (incluso ya implementadas), a mi entender, por no valorar todo dentro del conjunto desde una temprana fase del diseño. No se si recuerdas que todo el tema de la "vegetación viva" tuvo que quedarse fuera por el alto consumo de CPU que suponía (se comia el performance en la XBOX) o incluso que el mecanismo de matar a todo NPC del juego tuvo que ser recortado para sólo poder darle leches a los adultos (sino podías llegar matar a todos los niños del pueblo con todos los problemas -de prensa y legales- que conllevaría). Son dos ejemplos (de los N que hubo) y que retrasaron el proyecto por no ser visualizados, valorados o evaluados (desde cualquier punto de vista, sea técnico, de historia, o factor externo al proyecto) en una fase previa de preproducción y durante el diseño.
Volviendo al tema del Designer como evaluador de las mecánicas que diseña, también es cierto que en función de la magnitud del juego (y de la dimensión del equipo) podiamos hablar de único diseñador (muy raro en juegos AAA), o una jerarquía de designers liderados por un lead-designer. Ese lead-designer debería tener un mejor conocimiento de la complejidad del sistema en su totalidad (elementos del sistema y relaciones entre las partes), y del impacto que puede suponer un nuevo elemento y las relaciones del mismo con el resto (y conocer el sistema de juego en su totalidad dista mucho de ser perfecto conocedor del detalle técnico de cada área). Es decir, como en todo tipo de proyectos, el sistema jerárquico es el que (nos guste o no) sigue funcionando, y en materia de GAME DESIGNING también pienso que es así.
En cualquier caso veo que en proyectos cada vez más grandes y complejos sí es necesario esa figura de 'hombre orquesta' que mencionas, y no es por nada incompatible con que todo el equipo participe o aporte en su área específica. Según mi experiencia en proyectos 'grandes' (más de 40 programadores) alguien debe valorar, filtrar, aprobar esas aportaciones, y siempre, sin perder de vista el gameplay o Diseño de juego, que debe ser lo que más pese en el conjunto. Dentro de una estructura organizativa de proyecto, ese hombre orquesta cuyo eje de rotación es el Diseño de gameplay sería quizás ese lead-designer, cuya figura se complementaria con la del Project Lead. La diferencia principal radicaría en que el ámbito de actuación del lead-designer sería 'cross' o transversal a todas las áreas del equipo (al contrario que el project lead que actuaría verticalmente sobre todas las jerarquías de cada área -arquitectura tecnologica, IA, música, arte, contenido, gameplay-). En ambos casos todos ellos actuarían bajo el paraguas de control del Product Manager, el cual además tendría visión y comunicación externa con terceras partes.
Bueno, no sé si me he extendido demasiado, pero ahí quedan mis ideas.
Salu2
imaGame
# ...define el mundo donde se desarrolla el juego, el objetivo del jugador, los conflictos y la motivación de los enemigos?
* El inicio de esta tarea es responsabilidad del jefe de diseño, junto con el director de juego. La definicion detallada la hará un escritor, de acuerdo con ellos, de lo que quieren que se enfatice en el juego, etc.
# ...define el aspecto que va a tener el juego, el estilo de iluminación a utilizar, el tipo de vestimenta que llevan los enemigos?
* Más o menos igual que antes, los detalles los realizará un artista de concepto pero siempre de acuerdo con y basado en la idea general plantada y defendida por (en general) el jefe de diseño y el director de juego.
# ...coordina el trabajo de arte y programación, definiendo los requisitos y haciendo el seguimiento de cuando se van entregando?
* Ciertamente, ese es el producer
# ...especifica cómo van a funcionar las herramientas que se usan para producir el juego, incluyendo scriptado, definición de propiedades y estructura de misiones?
* Huy, tema "espinoso". :) Diferentes diseñadores pueden verse involucrados en esta definición, pero siempre de acuerdo con los programadores de tools. Los programadores están al servicio de las necesidades de los diseñadores, pero eso no significa que no haya diálogo; se deben dar peso a aquellos criterios que tengan más fuerza, experiencia en el tema, etc.
# ...define como se va a estructurar y configurar el funcionamiento de los enemigos?
* Diseñador + programador de IA.
# ...define las misiones, plantea el espacio donde se van a desarrollar y elabora las situaciones que se pueden producir?
* Diseñador de niveles, que normalmente tambien debe implementar esos niveles y misiones ("bicho A en la posicion X,Y", etc), a veces llegando a modelar el nivel propiamente dicho.
# ...escribe el código de script, coloca a los enemigos y configura sus propiedades para implementar las misiones del juego?
* Es trabajo de escriptado, que en la medida de lo posible debe hacer un diseñador bien formado en esos temas.
# ...juega con la versión para detectar anomalías, como problemas en el código o en los gráficos?
* No, ese es el tester, pero el diseñador debe jugar tambien para detectar anomalías conceptuales y/o funcionales en la implementación, o conflictos y problemas generados por el diseño que se ha realizado.
# ...explica qué es lo que el público quiere y los juegos que tienen éxito comercialmente, para incorporar sus elementos?
* No, ese es el analista de marketing, pero el diseñador hará bien en escuchar y tener en cuenta estas ideas para no hacer un juego que nadie quiera jugar.
# ...escribe periódicamente informes de actividad, evaluaciones de progreso, estadísticas de datos definidos y planificaciones?
* No, ese es el burócrata, aunque yo prefiero llamarlo "producer de diseño".
# ...organiza documentación, selecciona tipos de letra, formatos, prepara índices y glosarios?
* No, ese es el documentalista, que será un miembro del equipo de diseño.
Vamos, que estoy de acuerdo en tu idea de lo que es un "diseñador DE JUEGO", pero me parece interesante dar nombre también a los otros roles de diseño. Eso sí, para evitar confusiones con el termino general "diseñador de juegos", sería mejor llamarlo "diseñador de jugabilidad" o "de mecánicas". Al fin y al cabo, los niveles tambien forman parte de "EL JUEGO". ;-)
En el post he intentado no hablar en ningún momento sobre estructura ni jerarquía. Cuando desgloso las supuestas responsabilidades de un diseñador de juego, no pongo etiqueta, ni 'lead', ni 'senior', ni 'junior', ni nada. Esa es otra discusión, de reparto de responsabilidad, difícil y extensa. En cualquier caso, esperar que haya una persona, aunque lo llamemos lead designer o director de juego, que sea un experto en todas las áreas mencionadas, me parece imposible. Podrá explicar lo que espera conseguir, y evaluar si se ha conseguido, pero no tiene porqué saber cómo conseguirlo (en temas como la ambientación (historia), el look visual, la usabilidad de las heramientas, etc).
En todas las áreas que he dicho que no son directamente responsabilidad del diseñador, éste puede tener dependencias. No en vano diseño se sitúa en una parte muy central del juego, y cualquier cosa que se haga que impacte cómo se juega concierne al diseñador. Si el jefe de diseño quiere esbozar la estructura de la historia y dar un concepto inicial sobre el aspecto visual del juego, muy bien, pero espero que sea un buen escritor y un buen artista. Si quiere definir los requisitos de la herramienta, espero que sea competente técnicamente, ya no para usar una herramienta, sino para diseñar su funcionamiento.
Respecto a las razones de que el Fable se retrasara y tuviera problemas, digamos que no soy exactamente un fan de Peter Molyneux. Creo que el proceso de desarrollo de concepto y preproducción que tenían en Lionheart era, siendo generosos, lamentable, y pagaron las consecuencias. En cualquier caso, si el responsable de evaluar si el crecimiento de las plantas era viable técnicamente era un diseñador, no me sorprende que no lo hiciera correctamente.
Lo que sí me sorprende es ver en ocasiones a supuestos "diseñadores de juego" haciendo muchas de las tareas que no les corresponden, y no haciendo la que sí es su responsabilidad, porque "no tienen tiempo". No sé si esto es el resultado de buscar el ideal de hombre orquesta, como defiende imaGame, o quizá un desconocimiento del trabajo central del diseñador, que es cierto suena muy abstracto y difícil de cuantificar o, peor, parece casi innecesario si se está haciendo un clon de un juego popular.
El hecho es que yo no conozco a nadie que sea experto en todas las áreas que menciona el post. Sí existe en cambio el perfil de diseñador-programador, como un ex-programador que ha acabado como diseñador y puede opinar en ambas áreas, pero quizás no sea buen escritor, o un buen artista de concepto. Pero yo no estoy seguro de que sea imprescindible contar con este perfil, siempre que los diseñadores y los programadores hablen y se entiendan.
Sobre la organización del equipo de diseño, la estructura que más he visto distingue entre "diseñadores de juego" y "diseñadores de niveles", como hago en el post. Puede ser que el diseñador de niveles se encargue de scriptar, puede que lo haga un grupo distinto, con perfil de programador junior. Puede que una persona haga de escritor además de diseñador de juego. O que haya un diseñador de juego que se encargue de organizar la documentación y moderar el servidor wiki. No hay ningún problema con hacerlo así, mientras se reconozcan como responsabilidades distintas. Podemos tener a un programador administrando el servidor de Perforce, pero sabemos que no es trabajo de programador, propiamente dicho.
Sgarces, sí y no.
No defiendo la existencia de un experto en todas las áreas ni digo que ese hombre orquesta sea responsable de esbozar la historia, ni definir su aspecto visual, ni tampoco diseñar el funcionamiento de las herramientas (yo tampoco conozco tales expertos, y no creo que los haya). Simplemente digo que el diseñador no puede abstraerse del resto de áreas y siempre va a estar condicionado por ellas, e igualmente va a poder influir sobre ellas, de ahí la necesidad de valorar la viabilidad de los mecanismos y elementos de juego que diseñe dentro del marco común de todas las áreas del proyecto.
Aprovecho para decir (si no lo he hecho todavía) que me parece muy correcta la diferencia de roles, y clarificación de funciones, que has expuesto en el blog (la cual comparto en un 99%), pero sigo pensando que en el área de diseño las funciones se han quedado cojas: ese perfil de 'hombre orquesta' (con funciones de valoración y análisis de viabilidad fundamentadas en el diseño de la jugabilidad) es altamente necesario. Cierto es que la justificación de tal perfil cobra mayor sentido en cuanto hablamos de estructura y organización de equipos, que como bien dices es otro mundo (espero que escribas futuros hilos al respecto), pero que no pueden dejarse de lado al hablar de roles de un equipo. En caso de roles hablamos sólo de una visión sectorial del tipo de trabajo pero no podemos olvidar la visión jerárquica dentro de esos sectores, y tampoco claro está la visión transversal que atraviesa a todas ellas.
Y tal orquestación, centrada en el diseño de juego/jugabilidad, responde a un hecho muy sencillo y que todos sufrimos: trabajar con personas es muy difícil, y contra más recursos hay en un proyecto más complejo resulta que todo conecte, que todo encaje y que todo siga unas líneas comunes. De ahí que la figura de perfiles de orquestación o coordinación transversales, es algo necesario en estructura de equipo grandes (y más en el sector de los videojuegos, donde todo se complica exponencialmente por el alto nº de interrelaciones entre las partes).
Sergio,
Yo sigo viendo bien que los equipos de desarrollo se sigan organizando bajo la estructura general "diseñadores - programadores - grafistas", y que después cada una de estas categorias incluya dentro un montón de roles y subcategorías. Dividir "Diseño" en "diseño de jugabilidad" y "diseño de niveles" me parece demasiado pobre, y como todas las tareas al final alguien tiene que hacerlas, pues mejor agrupar de una forma sensata.
Comentas que administrar Perforce no es una tarea de programación, pero hasta que no tengas una persona o grupo dedicados exclusivamente a esa tarea ("administracion de sistemas"?), pues mejor que eso lo lleven programadores.
Me muestro tan aparentemente "opuesto" a algunas de las ideas que has expuesto, sobre todo porque creo que debajo de ellas se respira la filosofía de que "los diseñadores solo deben diseñar juego", que me parece tremendamente peligrosa por lo que he dicho antes, que al final TODAS las tareas necesarias las tiene que hacer alguien. :)
Bueno, al hilo de roles, tareas de diseño, y relaciones entre diseñadores y programadores, si queréis podeis echar un vistazo al powerpoint de las charlas que he dado este mes sobre el tema. Están en http://www.iguanademos.com/Jare/docs/2006_GameLab_Diseno.zip
Ya me contaréis si lo que digo son burradas, teorías abstraídas de la realidad, o tienen algo de sentido.
os aburris demasiado, salid mas de casa
Publicar un comentario
<< Home