28 junio, 2006

¡Novatos a la carga!

¡Novatos al poder!Hace tiempo leí un artículo sobre la valoración de los productores novatos en una desarrolladora de videojuegos y su comparación con la de un programador: http://www.edery.org/2006/03/what-does-top-entry-level-talent-cost-nowadays/

De este artículo y de lo que comentan algunos de los contertuliantes, saqué estas conclusiones también aplicadas a los diseñadores novatos:

La valoración de un programador o un artista “novatos” en una empresa de videojuegos es mayor que la de un productor o un game designer. Esto se debe a que el resultado del talento y conocimientos de un artista/programador nuevo en la empresa se pueden palpar de forma prácticamente inmediata desde el primer día en que entran a formar parte de la plantilla.

El productor y el diseñador novatos, en cambio, tan solo ven recompensados sus esfuerzos una vez el proyecto ha avanzado lo suficiente, puesto que entonces se demuestra que su intuición era la correcta y que las decisiones tomadas durante el desarrollo del juego apuntaban a un objetivo que finalmente se ha conseguido.

El trabajo del Productor pasa la mayor parte del tiempo por contactar con agentes externos a la desarrolladora y hacer números de los que los integrantes de la plantilla ni siquiera son conscientes, por lo que es un trabajo que para la plantilla es difícil de valorar, porque no lo ve.

El Diseñador tiene un contacto más directo con la plantilla pero la mayoría de veces sus decisiones se analizan de forma aislada, sin tener en cuenta la visión global que el diseñador sí que debe tener sobre el conjunto del proyecto. Cambiar estos casos aislados sin tener en cuenta el juego al completo comporta, algunas veces, errores graves de coherencia que después afectan a la calidad del diseño del producto final.

Con todo esto no vengo a decir que ser un buen artista o un buen programador sea más fácil, sino que demostrar su valía es, en la fase inicial, más sencillo. A un productor o un diseñador se les debe dar confianza y esperar a que los resultados de sus decisiones hablen por sí mismos una vez se ha avanzado lo suficiente en el proyecto y empiezan a verse los frutos. Pero hasta entonces... hay que fiarse de la intuición del que "fichó" a ese diseñador o productor.

Quizás esto también se deba a que el producto del trabajo de un diseñador o productor depende del trabajo del resto del equipo. Por ejemplo, para un diseñador es difícil, a veces, expresar a alguien que no se dedica a diseño que un documento que él ha creado, con su concepto, listado de reglas, condiciones, funcionamiento, etc. tendrá como resultado algo "divertido". Y más cuando el programador no quiere un documento con los motivos (llamados habitualmente "pajillas") sino uno con las 4 tablas que resuman el comportamiento lógico que le permita crear ese "trozo de código".

¿Vosotros qué opináis?

Mostrar/ocultar resto...

15 Comments:

At 28/6/06 20:30, Blogger Julio Gorgé said...

Leyendo los comentarios del artículo, parece que en USA los sueldos son *mucho* más altos que en Europa. ¿70K para programadores junior? Supongo que tambien habrá que tener en cuenta la calidad de vida y otras cosas.. pero a simple vista impresiona.

Tema sueldo aparte, coincido en que hay posiciones para las que es más difícil medir el talento de manera rápida.
¿Cómo se suelen valorar a los candidatos para productor o diseñador junior? El diseñador puede aportar diseños de pequeños juegos publicados u otro tipo de material como experiencia acreditativa.. pero, ¿y el productor?

PD: Enhorabuena por el blog, seguid así : )

 
At 28/6/06 23:19, Blogger sgarces said...

No sé como es en otros estudios, pero en Pyro lo cierto es que tradicionalmente ha habido muchos problemas para contratar tanto diseñadores como productores.

Es mucho más fácil para un programador o un artista iniciarse en su disciplina e ir aprendiendo con los años, hasta alcanzar un nivel de competencia que le permita afrontar con éxito una entrevista de trabajo. Para un diseñador es más complicado. No están claras las habilidades que requiere el puesto, como desarrollar esas habilidades, las responsabilidades... Lo mismo sucede para los producers.

Además, evaluar si un diseñador tiene talento o no en una entrevista de trabajo, y valorar su capacidad y potencial es extremadamente dificil. Es dificil para programadores, y eso que hay una lista bien clara y definida de conocimientos y habilidades que se les exigen.

Así, o entras con experiencia o es fácil que no conozcas las dinámicas de trabajo y tus habilidades no estén suficientemente desarrolladas. O puede que, aunque lo estén, la dificultad de evaluarlo correctamente impida que se reconozca, como apunta Saul.

Una cosa que no me convence del post es lo que dices del Diseñador teniendo una visión global sobre el proyecto. Creo que ahi radica parte del problema de identificar el perfil de diseñador, ya que se le exige saber de todo y conocer de todo. Muy poca gente tiene la capacidad de hacer esto y por ello pueden parecer peor diseñadores de lo que son.

Me parece un ejercicio interesante tratar de definir lo mejor posible el trabajo de diseñador y, relacionado con ello, si el esfuerzo creativo y la visión de un proyecto tiene que provenir principalmente de una persona o grupo pequeño (diseñadores) o del equipo en su conjunto.

 
At 29/6/06 09:33, Blogger Saül said...

Estoy de acuerdo contigo, Sergio, con el matiz sobre la "visión global", pero en el post me refería con eso tan solo a la parte de diseño, a la "visión global de diseño". La próxima vez ya lo expresaré mejor. Pero, de todas formas, esto abre un interesante debate, como apuntas, sobre los límites y responsabilidades de un diseñador.

Yo creo que quizás al diseñador "normal" se le debe exigir conocer el conjunto global tan solo a nivel de diseño, mientras que, en cambio, el "lead designer" sí que debe, como mínimo, conocer el planning de programación o incluso "pactarlo" con el respectivo lead programmer para así planear cómo se van a empezar a implementar, y en qué orden, los "features" de diseño. Pero aquí también entra el productor... y arte... por lo que creo que el lead designer debe trabajar codo con codo con el producer y los leads de cada área para planificar conjuntamente como se llevará a cabo todo el proyecto.

Con esto no vengo a decir que un programmer o designer "no lead" no deba conocer estos plannings, timings, etc. de todo el conjunto, sino que creo que es importante que los perfiles que he indicado tengan reuniones constantes y planeen conjuntamente "el siguiente paso", corrigan posibles errores de cálculo de tiempo, afronten las nuevas peticiones del publisher, etc. Mientras que el designer "no lead" pueda trabajar de forma "pura" en su campo tal y como hace un texturizador o un programador de red, por ejemplo.

 
At 29/6/06 16:26, Blogger sgarces said...

Cierto. Yo no creo que haya asimetría entre la necesidad de tener una visión global entre los distintos departamentos. El lead de diseño necesita trabajar con el producer igual que el lead de programación o de gráficos para organizar la planificación. El diseñador novato necesitará preguntar al programador novato como funciona algo que ha hecho, y el programador novato pedirá al diseñador novato que le explique cómo debería funcionar un elemento del juego.

Es simétrico.

De hecho, hay varios estudios en los que no se hace una división estricta por departamentos (diseño, graficos, programacion), sino que se montan grupos mixtos que se encargan de una feature o de un nivel. Yo no he trabajado nunca con esta estructura, pero me parece muy interesante, y creo que se apoya en esta simetría.

 
At 29/6/06 17:27, Blogger Diegix said...

Ese tipo de estructura es el que a mi modo de entender proponen las metodológias ágiles, que tanto están de moda. Tener grupos heterogéneos pequeños para que puede haber comunicación fluida entre ellos y que se centren en un aspecto del sistema para llevarlo a una versión "final".
Desde mi punto de vista, la interacción entre gente de diferentes disciplinas dentro de un proyecto es muy valiosa porque en una estructura tradicional un diseñador junior que estuviera trabajando en una parte del juego, haría una petición de funcionalidad y/o grafica que debería hacer a su lead designer, éste a su vez la haría a los lead programmer y/o lead artist, que encargarían la tarea concreta a los senior/junior programmers y/o artists. Toda esta burocracia, además de posibilidad de perder datos en el camino y obvia falta de fluidez en la comunicación hace que las cosas integren mucho peor si se hacen las distintas partes (programación, graficos, diseño) cada uno por su lado y luego se intenta juntar a martillazos.
En mi experiencia, cuando ha sido posible trabajar mano a mano con grafistas/animadores/diseñadores el resultado ha sido mucho mejor y en menos tiempo que cuando ésto no ha sido posible (por impedimiento de estructura o de personas)

 
At 29/6/06 18:16, Blogger Saül said...

Yo tampoco he tenido la suerte de trabajar con el sistema que propone Sergio, por lo que no sé hasta que punto puede ser más productivo. Pero suena muy bien, puesto que todos los "novatos" imagino que tendrían muchísima motivación. Aunque esto no quita que estén trabajando solo en un pequeño bloque (o nivel) mientras, además, los respectivos leads supervisan todos los "trozos" que después deben juntarse. Este sistema creo que es perfecto para un proyecto pequeño o uno grande dividido en pequeños bloques fácilmente "independizables" (como los niveles).

Sobre la burocracia que comenta diegix... normalmente se soluciona si la documentación de diseño es buena y se puede actualizar rápidamente con las nuevas especificaciones/peticiones. Esta documentación permite que no haya pérdua de información por el camino y que los leads puedan calcular los timings y el cumplimiento de los objetivos originales (para que no haya "pegotes"). Aunque la comunicación entre ambos trabajadores es "indirecta", cuando uno de los dos necesita una aclaración, como apunta Sergio, se lo pregunta al otro.

En Novarama tenemos un sistema mixto. Cada bloque trabaja en su campo, pero si un diseñador de niveles quiere modificar una casa, se lo consulta directamente al artista correspondiente. Cuando ambos han llegado a un "acuerdo", se lo comentan a sus respectivos leads para que estos tengan constancia de ello y puedan ver si esa modificación puede comportar otras problemáticas al conjunto del proyecto. Creo que esto fomenta la creatividad y motivación de ambos trabajadores, el trabajo en equipo, pero a la vez permite tener control sobre "como va el proyecto". Además, da a ambos trabajadores la consciencia de que "nada es gratis", puesto que una decisión que pueda parecer "local" podría llegar a afectar al conjunto del proyecto (quizás no 1 sola, pero cuando vas a 1 por día...). Además, cuando uno se centra mucho en una única temática, acostumbra a perder el mundo de vista, y para eso existen los leads, para coordinar a los equipos entre sí mismos y con el resto.

 
At 29/6/06 22:29, Blogger sgarces said...

Je, lo que está dando de si este tema.

Yo tengo una pregunta, que dejo abierta: ¿cómo se forma a un diseñador de juego novato?

Para formar un programador, yo busco documentación sobre C++, de creciente dificultad y se la voy pasando. A continuacion le presento las normas de código, prácticas recomendadas y librerías básicas del proyecto. Luego, le hago diseñar y programar un pequeño sistema autocontenido. En cada paso del proceso reviso lo que ha hecho y le sugiero correcciones. Hecho eso, le hago hacer otro modulo que vaya integrado con alguno de los grandes sistemas del proyecto, para que se vaya familiarizando con ellos. En este punto ya deberia haber alcanzado un nivel suficiente como para trabajar de forma más o menos productiva.

El objetivo es empezar general, e ir particularizando, hasta que se convierte en un experto del juego que se está haciendo. A partir de lo que vea ahi, si es listo, empezará a poder generalizar y con el tiempo será capaz de trabajar de forma cada vez más independientemente.

¿Como se hace con un diseñador de juego?

 
At 30/6/06 03:08, Blogger Saül said...

jajaja! la pregunta del millón :)

Cada maestrillo tiene su librillo, pero todo depende de para qué quieras a ese diseñador. ¿Quieres que llegue a ser un lead capaz? ¿Un Game Designer? ¿Quieres que sea un level designer? Eso es lo primero que debes pensar: para qué lo necesitas, pues el proceso de aprendizaje es completamente diferente.

Quizás hablo demasiado desde mi experiencia personal, pero intentaré explicar el proceso que creo que se debe seguir para llegar a "entrenar" a un lead designer.

Creo que el camino a recorrer es a la inversa que el que comentas para un programador. En vez de empezar por abajo (lo más básico, poner cifras de daño a las 100 espadas del juego) e ir subiendo, creo que el diseñador debe hacerlo al revés, empezar por lo más "alto" (reuniones de leads) y después bajar, puesto que al final es lo que va a tener que hacer cuando trabaje de diseñador, empezar con lo abstracto y terminar con lo concreto.

Me explico. Creo que hay que hacerle asistir a algunas reuniones entre leads como oyente para que primero aprenda que cualquier decisión tomada desde diseño afecta, de forma directa, a los otros departamentos. Debe aprender que nada es trivial, que toda decisión tiene consecuencias. Evidentemente esto se podría hacer con una "explicación", pero verlo por tí mismo es mucho mejor que recibir una clase. No te lo tienes que creer. Lo ves.

Mientras, se complementan estas asistencias de oyente a las reuniones con un trabajo continuo, codo con codo y en paralelo, con el resto de diseñadores. Creo que es muy práctico asignarle a uno "ya maduro" para que le enseñe su trabajo.

Empezar diseñando un nivel, por ejemplo, puede ser una muy buena forma (independientemente de que acabe sin diseñar niveles). Ambos diseñadores (o los que haya) crean niveles en paralelo y se reúnen asiduamente para plantear ambos sus niveles. El diseñador novato, salvo contadas excepciones, verá que el trabajo del otro es más objetivo, se basa en argumentos sólidos y, en general, es mucho más coherente. El diseñador "entrenador" deberá explicarle el porqué de la diferencia entre los diseños y cómo mejorar ese trabajo. Es clave explicarle el proceso de pensamiento que ha seguido independientemente de que el novato, lógicamente, acabe creando su suyo propio. Ver como piensa el otro designer es clave para su aprendizaje, pues le enseñará a pasar de conceptos abstractos a concretos de una manera, quizás no la mejor, pero una al fin y al cabo. Le enseñará que no hay que generar ideas "de forma aleatoria" que hay que planearse un objetivo y concretizar, diseñar, una manera de conseguirlo.

Es decir, que le dirá: este nivel debe dar miedo. Y lo primero que hará es preguntarse: ¿Qué es el miedo? Lo definirá de alguna manera y le mostrará que todas las decisiones de su nivel las ha tomado respetando y buscando reflejar esa idea original (abstracto-> concreto).

También es importantísimo hacerle leer libros de la temática que debe tratar, pues si estos son de calidad, le enseñaran otros procesos de pensamiento que alimentarán su necesidad de crear uno propio.

He visto que muchas veces los diseñadores noveles tienden a creer que diseñar es "tener ideas a cascoporro". Y eso no es así, su trabajo es concretar las ideas abstractas que se le asignan respetando los límites que se le marcan.

¿Y qué pasa si quieres enseñar a un level designer? ¿O un game designer?... son las 3 de la noche y tengo mucho sueño. Mañana será otro día :D

 
At 30/6/06 06:34, Blogger sgarces said...

Muy interesante.

Cuando hablo de "diseñador de juego" me refiero a lo que llamas game designer, que me parece es el puesto más elusivo y difícil de concretar.

Me imagino que mi enfoque para un programador no funcionaría bien, ya que se basa en comenzar estudiando documentación (que para programación es fácil de encontrar) para adquirir conceptos generales (que podrían servir para trabajar en Microsoft) y luego ir especializando este conocimiento hasta poder aplicarlo al juego. Con diseño de juego entiendo más lo que tú propones, participar casi desde el principio en el trabajo, asistiendo a reuniones y recibiendo críticas y sugerencias de diseñadores senior.

Lo que más me intriga de este tema es que la literatura que existe sobre diseño es casi siempre superficial y difícil de aplicar. Es como si la única forma de sacarle partido realmente sea habiendo tenido la experiencia; como una forma de internalizarla, de entender el porqué las cosas han salido como han salido. Entonces, para aprender a diseñar, la única forma parece ser mediante práctica: ensayo y error. Casi diría que la única manera de diseñar bien es basarse en la intuición o el instinto, que sólo se pueden alimentar mediante experiencia.

Creyéndome mi propio argumento de momento, diría entonces que esto es una limitación grande para el aprendizaje del diseño de juegos y la aparición de talento joven. Es difícil aprender esto en casa de uno (sobre todo si no sabes programar ni hacer gráficos), y los errores de diseño en un juego son muy costosos (que puede ser la razón por la que los novatos tienen dificultades para adquirir responsabilidad, como apuntabas en el artículo).

 
At 30/6/06 09:51, Blogger Grihan said...

Buff, tema complicado...
Por mi propia experiencia, en España la mayoría de diseñadores que he conocido eran programadores o grafistas que evolucionaron hasta ese puesto, o en muchos casos, compartían sus responsabilidades anteriores con las de diseño de juego. Esto ha ocurrido basicamente porque a los estudios llegaban muy pocas personas que realmente se ofrecieran para ese puesto, y cuando aparecía algún diseñador solía ser de 2 tipos
- El diseñador que tiene "ideas a cascoporro", como dice Saül
- El diseñador que viene con su idea genial, pero que no la tiene desarrollada lo más minimo.

Eso sí, también mucha parte de culpa la han tenido las compañías, donde hasta hace relativamente poco, el hecho de que ocupara un puesto en el equipo una persona que no fuera grafista o programador parece que dolía en el bolsillo de más de uno, jejeje.

Ahora que por fin parece que NECESITAMOS diseñadores en el equipo (viva!!) creo que sería muy importante que el diseñador novel que entra en un estudio tenga experiencia en diseño de cualquier tipo de juego, ya sea de mesa, de rol, de cartas estilo magic, etc. Es decir, que sepa tener una idea, desarrollarla, creando los elementos y su interacción entre ellos y que esa idea con todo lo que la rodead sea divertida, no olvidemos que es lo más importante.

 
At 30/6/06 11:11, Anonymous ghware said...

Muy interesante el blog. Gracias a Grihan por pasarmelo ;)

El diseño de juegos es un tema complejo, si, y el puesto de diseñador dentro de una empresa mucho más. Definir las líneas de responsabilidad de un diseñador es difícil. Además, en España es un puesto que no ha existido 100% por si mismo, cuando en otras industrias de fuera es un cargo crítico.

Una "idea" desde diseño puede trastocar timings y recursos, cosas que un diseñador novel desconoce por completo. Un lead si tiene esto más en la cabeza (y si no, ya se lo recordará el productor jeje).

Un diseñador con background de programación o arte tiene experiencia, y por tanto tiene más en la cabeza lo que se puedo o no hacer. Esto es bueno y malo. Bueno porque tomará decisiones más reales de cara a que se realicen en el proyecto. Malo porque generalmente se autolimitará, y eso frenará su creatividad. Esto es algo que obsesiona un poco a las empresas japos, que incluso meten designers ajenos a los videojuegos para buscar ideas innovadoras. Aunque yo pienso que un requisito fundamental del designer es jugar, jugar y jugar, es cierto que a veces te encuentras con que _todo_ lo que se te ocurre lo has sacado de otros juegos.

El diseño de juegos en realidad es bastante abstracto. Cualquier mecánica divertida es válida. Jugar a juegos que no sean videojuegos y leer mucho creo que es algo que ayuda mucho a un diseñador.

Hay que oxigenar la imaginación fuera de las pantallas.

Nunca se sabe... igual puedes sacar un sistema de negociación inspirado en los faroles del mus o una idea de guión basada en la estructura de capítulos de un libro de Chuck Palahniuk ;)

Uff, me he ido por las ramas, y es que hay mucho que decir sobre este tema... pero no tengo demasiado tiempo jeje. Nos leemos!

 
At 30/6/06 11:45, Blogger Diegix said...

El tema de diseño es un tema espinoso, porque es un poco como ser entrenador de futbol: todo el mundo cree que tiene la idea genial para ganar la copa del mundo. Sin embargo, y atendiendo a la keynote del amigo Will Wright en la GDC de este año, el trabajo de diseñador es en una gran parte trabajo de documentación y extraer ideas de ahí. En la misma linea iba el tutorial sobre creatividad al que fui en la GDC del año pasado, las ideas se extraen de toda una serie de vivencias anteriores. Así que estoy de acuerdo con que un diseñador tiene que jugar, jugar y jugar, pero no sólo eso, tiene que viajar, leer, ver peliculas, etc...
Eso hace el puesto de diseñador un puesto dificil de completar en mi opinion ya que tiene unas caracteristicas que son dificiles de aunar en una persona, como son ser creativo y tener gran disciplina personal para documentarse previamente y para documentar el diseño del juego de una forma estructurada y coherente que pueda entender el resto del equipo que lo necesite.
En cualquier caso y a la vista de que gran parte de los diseñadores famosos partieron de un puesto de programación, quizá una cierta formación previa tecnológica no venga mal para desarrollar un poco la capacidad de disciplina de un diseñador, aunque supongo que si tienes la suerte de contar con diseñadores senior metódicos y que utilicen método, se podría también enseñar por otros medios más puramente de diseño.

 
At 30/6/06 19:22, Blogger Saül said...

"la literatura que existe sobre diseño es casi siempre superficial y difícil de aplicar" Eso es un problema que hay que solventar, pues es totalmente cierto. Los libros de diseño existentes no te ayudan a concretar nada, que es básico para el diseño. Quizás estaría bien algún libro-tutorial que explicase todo el proceso, paso a paso, y no los típicos que te analizan "todos los géneros", "todas las posibilidades" intentando ser una especie de biblia. Esa es la intención de los "talleres" que propondremos en los foros de la futura web.

"parte de culpa la han tenido las compañías" yo diría que también el marketing, puesto que siempre que aparece un diseñador en una entrevista fomenta la imagen de que ser diseñador es "tener ideas", tener "cretividad infinita". Insisten en lo "maravillosamente originales" que son, cuando en realidad tener ideas es "la parte más fácil" y diseñar es el resto. Eso se nota con algunos diseñadores noveles, que parece que quieran competir a ver quién tiene más ideas en menos tiempo y muchas veces se aferran a ellas como si fueran algo "sagrado".

Estoy de acuerdo con Sergio que el diseñador basa mucho de su aprendizaje/formación en la experiencia dentro de un equipo. Pero creo que también sucede con un programador o un artista. Por buenos que sean, deben aprender a trabajar en equipo. He visto despedir a gente por no encajar en el conjunto global de trabajo de un equipo, pq iban a "otro ritmo" o a "su bola".

Imagino también que como el diseño es, en definitiva, lo que marcará cómo será el juego final, es por ese motivo que se debe tener la suficiente experiencia como para que el resto del equipo confíe en las decisiones de un designer. Por eso es importante el aprendizaje dentro de la empresa de manos de uno con más experiencia. Si el novato no quiere aprender del más experto pq se aferra a sus ideas... lo tiene bastante difícil para poder avanzar. Al menos en ese equipo.

Creo que alguien que opte a ser game designer debe ir desde casa "con los deberes hechos", y para hacerlo hay varios procesos que puede seguir. A continuación listo algunos:

- Analizar los juegos existentes: es clave pare ver qué hay en el mercado, cómo funciona el lenguaje del medio. Es importante escribir constantes reviews de juegos desde un punto de vista del diseño. Empezar con cosas descriptivas (al estilo reviews de revistas normales) e ir profundizando en la materia para acabarse preguntando: ¿PORQUE se ha hecho esto así? ¿PORQUE no se ha hecho de otra forma? Analizar géneros, empezar a proponer modificaciones a algunos juegos, etc. Vamos: desdoblar un videojuego en un conjunto de decisiones claves e ideas de concepto.

- Proponerse a uno mismo retos de diseño: proponerse hacer mini-juegos que expresen alguna idea/sentimiento/concepto abstracto. A nivel teórico, haciendo documentos. Y cuando se tienen unos cuantos, intentar aplicar el que vea más maduro en una creación FLASH/VIRTOOLS/DIRECTOR/DIVSTUDIO para entender lo que cuesta hacer ciertas cosas y lo verde y poco especificado que tiene el documento. Aquí es cuando empezará a ver que concretizar no es tan fácil. Si no se tiene la opción de crear una aplicación por una insuficiencia técnica, hacerlo en un juego de mesa o de cartas es también una opción muy buena para aprender a concretizar. El testeo serio con usuarios (amigos/familia) le dirá si el diseño que ha hecho está acertado o no. Es decir: pasar de las ideas de concepto a algo concreto (contrario que 1er paso).

Creo que este proceso podría asegurar mínimamente que al ir a una entrevista de trabajo y optar a ser junior game designer, te puedan coger. Evidentemente, allí debes ir con todos tus análisis y mini-juegos (aunque sean de cartas). Si tu trabajo no es aceptado por los entrevistadores, es clave preguntar siempre el POR QUE. No creo que tengan ningún problema en comentarte los 4 puntos que deberías trabajar más.

Aunque creo que el problema actual es más bien el desconocimiento de lo que es realmente un diseñador desde fuera (debido al ruido que se crea por el marketing), lo que hace que la gente no vaya desde casa con los deberes hechos (pq no sabe lo que es). De aquí la tendencia al reciclaje (programador/artista -> designer) que también es otra vía muy utilizada y realmente válida, puesto que conocerá todos los límites de la empresa y las necesidades de diseño (lo ha vivido ya en sus carnes).

Un proceso diferente seguiría alguien que opte a ser level designer. Este creo que debería hacer niveles a cascoporro con editores de otros juegos y compartirlos constantemente con la comunidad jugona de ese juego que ha tomado como base, para testear hasta dónde llega su habilidad y, sobretodo, mejorarla con el tiempo. Esto también es un proceso de "aprender a concretizar". Porque es facil decir: haré un nivel en el que pase bla bla bla... pero venga, ponte a hacerlo. Creo que es importante documentar estos niveles diciendo el PORQUE de prácticamente todas las decisiones, incluso las que se han tomado a nivel práctico del estilo: creí que esto funcionaría pero no ha sido así, lo he cambiado pq los usuarios no lo entendían. Y presentar todo este trabajo en la entrevista, para que vean tu ojo crítico y tu forma de pensar.

Alguien que se quiera dedicar a ser game designer también puede empezar por cualquier otra vía, como hemos dicho antes, entrando como "level designer" o "tester" y mutar dentro de la misma empresa a medida que se van aprendiendo las habilidades.

Buff... me estoy enrollando demasiado... esto creo que sería tema para un artículo completo.

 
At 1/7/06 00:25, Blogger sgarces said...

Gran explicación. Especialmente importante el analizar juegos existentes desde el punto de vista de diseño (he visto usar esto como prueba antes de una entrevista). Si posteamos analisis aqui es posible que convirtamos el site en "el rincón del vago" :-)

Por cierto, lógicamente un programador tiene que encajar bien en el equipo e integrarse, y por supuesto que su formación debe hacerse dentro de ese marco. Lo que yo quería decir es que, normalmente, el programador puede empezar a formarse simplemente leyendo manuales de C++ u orientación a objetos, o libros sobre cómo implementar un motor gráfico. Siempre alcanzará un tope así, que luego habrá que complementar con práctica, programar mucho, y correcciones o sugerencias por parte de compañeros.

Yo me sumo al carro de desbancar la idea de diseñador de juego como "el que tiene la idea". Muy rara vez la idea de un juego sale de un diseñador al que le han dicho "ten una idea". El diseñador lo que hace es desarrollarla, identificar los elementos que la componen, perfeccionarlos, relacionarlos, evaluarlos, definirlos, pulirlos, corregirlos, explicarlos. Anda, que no queda curro por hacer desde "vamos a hacer un juego de un gangster que va conduciendo coches por una ciudad y matando gente" hasta llegar a tener el GTA...

 
At 6/7/06 10:47, Anonymous imaGame said...

Como en todos los ámbitos de la ingeneria de software siempre hay niveles de abstracción y no se puede estar en todo, al mismo tiempo en lo concreto (o detalle) y en lo general (o abstracto). En toda esa jerarquía de abstracción caben varios niveles de Diseñadores de juegos y el Diseñador novato no puede ubicarse libremente en cualquier punto de la jerarquía.

Desde mi punto de vista lo crítico es formar al diseñador de mecánicas de juego, que quedaría ubicado en un nivel intermedio entre el diseñador del juego de alto nivel (más cercano al guionista o storyteller) y el diseñador de bajo nivel (que tiene un rol cercano a un asistente de diseñador).

A grosso modo:
El diseñador de juego alto nivel es el que plantea la historia, conexiones, tipo de juego, filosfía de puzzles,etcc.

El diseñador de bajo nivel o asistente es el que detalla y da valor a todos los parámetros de diseño que le vienen dados e impuestos (es el que asigna los 100 puntos de peso a la espada, a base de balancear y equilibrar, según los criterios que se le marcan).

El diseñador intermedio o creador de mecánica de juegos es el alma mater, es el guro, es el peso pesado del diseño de un juego. Conocedor de la capacidad técnica del motor, de lo que puede o no puede hacerse y que crea y define como deben ser las mecanicas de jeugo y elementos de gameplay, que están en sintonía con la historia definida por el designer de alto nivel, y que impone criterios al asistente de diseño que se encargaría de detallar, dar valores, y especificar cada elemento de juego.


Todo esto es una visión VERTICAL de la jerarquía de Designers en cuanto a historia y gameplay. Habría otra visión complementaria HORIZONTAL altamente mandatory en proyectos grandes (entre los cuales ya se encuentran todos los jeugos AAA) que son los conocidos comos Equipos Cross. Estos aseguran y controlan la homogeneidad y perfecto encaje del Diseño,...pero eso es otro tema.

 

Publicar un comentario en la entrada

Links to this post:

Crear un enlace

<< Home