¿Tiene que saber un artista implementar en el engine?

Hace unos días Soph Podesta (recomiendo que la sigan) hizo un tuit (me niego a decirle “X”) en el que planteaba algo muy simple pero fundamental:

“¿Para ustedes, un Artista en videojuegos, tiene que saber implementar en el engine SI o NO? Justifique”

Honestamente, este tema, aun sin ser artista, me interesa muchísimo porque para mí es una cuestión de trabajo en equipo y no tanto de roles. Antes de dar mi opinión está claro que no tengo por qué tener razón y hay que decir que no estamos hablando de convertirse en un “Tech Artist” ni nada por asomo.

La pregunta va orientada a si un/a artista que solo se encarga de los dibujos (digitales), también podemos decirle ilustrador/a, debería saber importar al engine los recursos que creo e “implementarlos” (si son sprites para una animación ponerlos en la que corresponde, en el orden que deberían estar, si es un fondo o tiles para un tilemap saber como generarlos y probarlos, etc.)

Por un lado, mi filosofía es que todos los desarrolladores deberíamos entender de todos los roles y la implementación en el engine es una parte del todo. Esto es un poco por forma propia de ser y otro poco por la obligación inherente que tuve al estudiar una carrera universitaria (donde hay que atravesar todas las materias, que abarcan diferentes roles, y hacer la práctica).

Entiendo que la especialización es de lo más importante y que son esos devs los más requeridos; sin embargo, empiezo a ver lentamente una tendencia creciente en requerir que se adopte una forma “T-Shape”, donde por más especialista que uno sea hay que tener conocimientos de otras disciplinas que componen al desarrollo de un videojuego. Y no solo lo veo en estudios medianos (en los pequeños por necesidad no se puede trabajar de otra forma que no sea poniéndose “muchos sombreros”) también se nota en ofertas laborales de estudios grandes.

Entonces ¿debería?
Desde mi punto de vista, sí.
No es obligatorio, no dejaría de trabajar con un artista solo porque no sepa hacerlo. Pero es más que obvio para cualquiera con experiencia desarrollando que es un plus importante.

¿Cuántas veces nos vimos en la siguiente situación?:
Artista: Ahí ya terminé con los assets de tal cosa.
Programador: ok, ahora los importo y me fijo
… Al rato
Programador: mira, no quedo bien tal y tal Sprite, y el color de este fondo se ve mal en el juego. Ya lo consulté con el diseñador y me dijo que hay que modificar
Artista: uh, ok, ahora lo hago
… Al rato
Artista: Ahí ya terminé con los assets de tal cosa.
Programador: ok, ahora los importo y me fijo

El bucle de la muerte, como me gusta llamarlo, ese que dé a “ratitos” te quita un montón de tiempo de desarrollo.
Y la descripción que hice es una de las situaciones más sencillas, ni nos pongamos a hablar de cuando el artista ya estaba haciendo otra cosa “urgente” cuando se le avisó que lo anterior requería modificación… ufff.

Un artista que pueda implementar en el engine recorta todos estos tiempos “muertos”, puede producir los assets, probarlos en el engine, detectar de antemano defectos o mejoras necesarias, hablar directamente con el diseñador, y todo antes de que llegue a manos de un programador (que, por otra parte, no siempre es la persona más idónea para determinar si un asset está correcto o no para ser implementado).
Ni siquiera estoy hablando de que implemente para pushear a una rama y que esos cambios queden directamente implementados por él o ella (sí, ya sé que los artistas odian GIT y que hay VCS mejores, pero esa es una discusión para otro día), simplemente estoy diciendo que puedan hacer este workflow:

• Crear el assset
• Abrir el engine
• Importar el asset
• Implementarlo donde se deba
• Decidir si cumple con los requerimientos o consultar ante la duda
• Una vez que esta decisión es “sí, está todo OK” avisar que los assets están listos y subirlos a donde corresponda.

En mi opinión, de esta forma se mejora mucho el trabajo en equipo, se recortan tiempos de desarrollo que muchas veces carecen de sentido y subimos un poco la calidad del proceso de desarrollo.