¿Qué debería aprender un desarrollador de motores de videojuegos?

En el pasado GameLab, y más allá de las charlas de grandes gurús explicando sus batallitas, también fue posible asistir a ponencias más de tipo orientación para aquellos interesados en dedicarse al mundo del desarrollo de videojuegos. Todas eran muy interesantes, pero quizá la que más me llamó la atención  por su título fue la ofrecida por Mike Acton, director de motores (Engine Director) en Insomniac Games, creadores de sagas con tanta solera como Spyro o Ratchet & Clank (de éste último hay hasta una película de animación relativamente reciente). La ponencia llevaba el título «Process I wish they taught engine programmers in school» (Procesos que desearía que enseñaran a programadores de motores en la escuela). Un tema interesante no solo para los estudiantes, sino toda una llamada a los propios docentes.

Su punto de partida era el hecho que, una vez tras otra, se encontraba que desde que un nuevo miembro se incorporaba a su equipo hasta que estaba listo para valerse por si mismo pasaban al menos dos años en los que debía ser formado. Desde su punto de vista, este problema venía dado por algunas costumbres o prácticas de programación que se enseñan en las escuelas técnicas o de ingenierías, que si bien sobre el papel o en una gran cantidad de proyectos funcionan, para la programación de  motores de videojuegos deben ser corregidas.

El meollo del asunto según su punto de vista es que a menudo tendemos a sobrecomplicar las cosas bajo la justificación de la escalabilidad. Se nos plantea un problema y enseguida hacemos API’s o capas de abstracción que permitan resolver ese problema… y los hipotéticos diez siguientes. Pero según Mike, a la hora de programar motores esto es una mala estrategia. Hay que ir directo a resolver el problema planteado y no dedicarse a dejar ya la puerta a funcionalidades futuras que no se han pedido y, seguramente, no serán necesarias. A nivel de motor, la máquina debe ser considerada y crear capas de abstracción no funcionará. Si bien se pueden organizar algunos aspectos comunes, el concepto de «independiente a la plataforma» NO existe. Cada hardware es específico.

La verdad es que con el tema de la creación de capas de abstracción fue muy reiterativo. Como ya he comentado, lo que le molesta principalmente es que el hecho de crear dicha capa es distraerse de crear las piezas que, más adelante, alguien realmente usará para resolver el problema que se ha puesto sobre la mesa (y no otros que no vienen al caso). Pero no es resolver el problema en sí que se ha puesto sobre la mesa, que es lo que él, como director de motores, realmente quiere.

Otro aspecto relacionado que explicó fue su experiencia de que, a menudo, la mente del estudiante ingenieril tiende a enfocar los problemas a resolver como si fueran rompecabezas. Pero no es así, pues un rompecabezas tiene un conjunto de soluciones que son objetivamente correctas. Un problema como el que te puedas encontrar programando un motor no tiene más solución que la que tú propongas. Tu propio jefe de proyectos la podrá evaluar, pero no sabe la solución (o lo que haría él/ella). Esta será mejor o peor, y cumplirá o no los requisitos demandados. Pero no es «la» solución. Entonces, el problema suele ser que se quedan bloqueados hasta que encuentran esa solución perfecta. Pero bueno, esto quizá ya es una cuestión aplicable a toda la ingeniería en general.

Finalmente, desde el punto de vista conceptual destacó el concepto de «sacar los payasos del coche» (get the clowns out of the car), frase que repitió pero que unas cuantas veces. Las cosas se deben hacer bien de entrada, y «optimizar» no es arreglar aspectos que ya de entrada están mal para después hacerlos bien. En un motor, todo lo que ya esté calculado no se puede volver a calcular, ya sea a nivel de frame, nivel o instancia. ¡Y nada de bucles anidados!

A nivel ya más de conocimientos, destacó que un buen desarrollador de motores debe dominar como funcionan los sistemas operativos, el procesador y las GPUs, la memoria, y trabajar a nivel de ensamblador. Para ello, recomendó el libro «Game Engine Architecture», de Jason Grogory. Y como último consejo, dedicarse siempre a buscar lagunas en los conocimiento propios y practicar. Dedicar siempre cada día 30 minutos a subsanar dichas lagunas practicando en plena concentración. Y si no se encuentran esos 30 minutos, pues se buscan. Para él, esto es tan importante como dedicar un rato a hacer deporte.

Joan Arnedo es profesor de los estudios de Informática, Multimedia y Telecomunicación en la UOC. Director académico del Máster en Diseño y Desarrollo de Videojuegos e investigador en el campo de la ludificación y los juegos serios. Su experiencia se remonta a cuando los ordenadores MSX poblaban la Tierra…