El blog de Pablo Zurita.

Desde esta generación de motores en tiempo real nos podemos dar cuenta que ya no es posible diferenciaros a nivel técnico. La llegada de GPUs programables con lenguajes de alto nivel nos pone a todos en una situación similar. Escribiendo shaders y manipulando sus parámetros logramos obtener el aspecto visual de casi cualquier aplicación creadas por programadores conocidos como John Carmack o Tim Sweeney. Ya no hay necesidad de crear complicadas estructuras de datos, hacks complicados, y demás para lograr un aspecto visual definido. Esto demuestra un par de cosas. Primero, nunca fue tan fácil trabajar en computación grafica. Y segundo, para diferencia nuestro producto del resto vamos a depender en nuestros artistas y por consecuencia de ello, vamos a depender en las herramientas que les demos a nuestros artistas. Por eso va a ser muy importante darles herramientas que sean flexibles, fáciles de usar, y hacer todo en un tiempo razonable.

En el pasado estábamos acostumbrados a crear herramientas muy limitadas porque los recursos eran limitados. Por ejemplo en la era del Quake 2 tenias editores simples como el Qoole para la edición de geometría, las texturas eran de 256 colores creadas con editores como Wally, y a nivel técnico el aspecto visual era determinado por una simple modulación entre las texturas difusas y los lightmaps generados por q2rad. Ahora con los GPUs programables y su gran velocidad ya no hay necesidad de limitar la tecnología y los artistas. Lentamente con el progreso de los GPUs fuimos dejando Wally por editores como Photoshop, los editores de geometría se volvieron más complejos, y los sistemas de materiales e iluminación pasaron a ser más extensos y a tener en cuenta otros componentes como nivel de especularidad y demás. Ahora nos encontramos con la posibilidad de mostrar mucha geometría, tener texturas de alta resolución (o sintetizar texturas si así lo deseamos), y los sistemas de materiales e iluminación pueden ser tan diferentes y complejos como los shaders que podemos escribir. Por eso tenemos que crear herramientas que sean flexibles para que los artistas puedan utilizar todos los recursos disponibles. Estas herramientas tienen que ser tan flexibles como los shaders que podemos correr y la geometría que podemos mostrar. Además nuestras herramientas tienen que estar muy integradas con nuestro motor para que los artistas puedan ver exactamente como el usuario va a ver el contenido. De esa manera, por ejemplo los editores de shaders como FX Componer y RenderMonkey quedan descartados. Mirando desde el punto de vista de los materiales no es posible darles un editor de texto para que escriban shaders porque eso crearía un gran gasto de tiempo y dinero en capacitación. Es necesario crear un entorno donde el artista pueda aprovechar las capacidades de los shaders pero a la vez que sea una herramienta visual que el artista pueda entender. Una posible solución es lo que hizo Epic Games con su editor de materiales. Los materiales y shaders en el Unreal Engine 3 son creados en un editor por módulos como el Reaktor. Los módulos son creados por los programadores y los materiales son creados por el artista conectando esos módulos. Si uno crea módulos bien chicos y específicos es posible darle la chance al artista de crear shaders complejos sin necesidad de ver una sola línea de HLSL o glSlang. Y a la vez esto nos da más tiempo a los programadores porque todo el trabajo recae en los artistas.

Síntesis de sonido por módulos en Reaktor.
Editor de materiales del Unreal Engine 3. Diferentes módulos son conectados para obtener el resultado final.

Por otra parte, es sumamente importante mantener las herramientas fáciles de usar. Como todo programa la usabilidad es sumamente importante. Si creamos una herramienta complicada (como el Sapien de Bungie) vamos a perder productividad, vamos a frustrar a los artistas, y se nos va a ser innecesariamente complicado integrar nuevos artistas a nuestro proyecto. También es muy importante mantener la calidad de la usabilidad durante todo el proyecto porque las posibilidades de un gran cambio de paradigma en la creación de contenido es muy poco probable en el futuro cercano. Personalmente no preveo un cambio importante en la creación de contenido hasta que pasemos a usar voxels en vez de polígonos. También es importante mantener un buen estándar de usabilidad porque generalmente nos vemos forzados a incluir nuevos artistas a nuestros proyectos que ya están en marcha por lo tanto es necesario que este nuevo integrante de nuestro equipo como miembro productivo del proyecto lo antes posible. Teniendo en cuenta esto nos podemos dar cuenta que hay un problema en general en la mayoría de los engines y soluciones actuales, y es que los estudios no están aprovechando las aplicaciones que sus artistas ya conocen. Por ejemplo, en vez de aprovechar las aplicaciones de edición de geometría como 3ds Max hay estudios que todavía siguen haciendo editores propios como D3Radiant o UnrealEd. Algunas generaciones atrás estos editores eran necesarios porque la tecnología donde corrían también era limitada, pero ahora nuestros motores son muchos mas flexibles y al final terminamos duplicando funcionalidad que ya esta disponibles en otros editores como 3ds Max o SoftImage. Esto significa que no solo los programadores pierden tiempo duplicando funcionalidad ya disponible en otros editores, sino que también los artistas pierden tiempo en capacitación para usar las herramientas nuevas. En cambio podríamos utilizar los sistemas de plug-ins para expandir estos editores según nuestras necesidades. Obviamente si tomamos esta decisión tenemos que crear los plug-ins de tal manera que mantengan la forma de trabajo del editor que estamos expandiendo. Con respecto a la usabilidad recomiendo el libro About Face 2.0 : The Essentials of Interaction Design de Alan Cooper y Robert Reimann (ISBN 0764526413).

Sapien de Bungie. Un test de usabilidad demostraría que esta interfaz sobrecarga al usuario con información.

Justamente la necesidad de realizar todo en un tiempo razonable puede ser la razón por la que expandir un editor existente puede ser una opción buena. Crear las funciones más básicas de edición implica un tiempo razonable, y después los sistemas más avanzados pueden ser más complicados (como por ejemplo la edición de geometría con bezier patches). En cambio realizando plug-ins toda esa funcionalidad esta disponible, por lo que nosotros no tenemos que encargar de desarrollar la funcionalidad que es especifica a nuestra tecnología. Algunos podrán decir que esto puede ser malo porque realmente no tenes el control de las herramientas, pero en definitiva tenemos que tener en cuenta cuales son las prioridades. Otros tendrán problemas con los SDKs de los diferentes productos (por ejemplo el SDK de 3ds Max es horrible) pero hay que ver desde el punto de vista de los beneficios. Y aunque nos tome tiempo adaptarnos a un SDK y entorno al que no estamos acostumbrado, ese costo siempre va a ser menor que crear una herramienta nueva e instruir a los artistas sobre su uso. El único problema con hacer esto es que si pensas hacer un producto modificable como los mods para Quake, se vas a poner una barrera. Los costos de estas aplicaciones de edición son bastante altos para que un usuario estándar.