Videogames Tools Por Daniel Snchez Quiros

La seccin de Tools en un proyecto de videojuegos es una parte muy importante. Primero, ayuda al resto de departamentos a efectuar su trabajo con mayor rpidez y con mayor eficiencia; y segundo es un trabajo que en parte queda perenne por lo que no solo se ajusta al proyecto en ciernes si no que continuara presente en futuros proyectos siempre sujeto a cambios y adaptaciones!. "ic#o esto dividir$ las tools en % apartados& '. Pipeline Tools. (. )rtist Tools. %. *ame Tools.

1.-Pipeline Tools: Las Pipeline Tools son aquellas #erramientas que ayudan al flujo de trabajo en cualquier departamento, desde un gestor de recursos, por ejemplo, #asta una base de datos, pasando por un repositorio. +uc#as de estas #erramientas se suelen adquirir ya #ec#as pero siempre se modifican plugins o )P,-s! para que encajen con la personalidad del estudio. .n el caso de que se necesiten o se quieran #erramientas especificas a desarrollar internamente se #ay que tener en cuenta la compatibilidad con equipos, sistema operativo e interconectividad con el resto del soft/are a usar, por ejemplo, si los artistas usan )utodes0 +aya y tu quieres conectar una base de datos con un gestor de recursos seguramente interese #acerlo en un lenguaje y1o frame/or0 que puedas usar tambien en +aya, en este caso interesaria #acerlo en pyt#on, lenguaje soportado por el soft/are, bastante portable y que seguramente puedas usar con tu base de datos tambi$n; de esta forma tu gestor de recursos que deberia de tener una api! seria facilmente accesible para +aya y poder trabajar con el sin requerir ning2nn puente. 2.-Artist Tools: .stas #erramientas son todas aquellas que requieren los artistas para realizar su trabajo, se las podria encapsular junto con las #erramientas de pipeline, pero a mi me gusta #acer un apartado para ellas, primero, por que normalmente van a ir unidas a un soft/are espec3fico y para una tarea espec3fica y segundo por que no estan enlazadas a otros recursos o procesos ejemplo& gestor de recursos del estudio vs #erramienta de clonado %", la primera es compartido por varios departamentos, la segunda no!. )qui es un poco mas complejo, al estar ligadas estas #erramientas a un soft/are especifico estas obligado a ce4irte a las posibilidades que te da dic#o soft/are, la api que te ofrece y los lenguajes compatibles; cabe destacar que igual que en las pipelines tools #abra que elejir lo que mejor nos convenga, es decir, si tienes un frame/or0 interno de scripting en pyt#on para +aya, nunca vas a desarrollar nada en +.L puesto que sera insostenible a lo largo del tiempo y te llevara a tener que mudarlo en alg2n momento. 5ay que analizar tambien distintos factores como rendimiento o tiempo de desarrollo, es decir, si necesitas un sistema de particulas, lo mas probable es que necesites que sea eficiente y esto subira el tiempo de desarrollo ya no solo por que sea complejo o no, si no por que seguramente tengas que realizarlo en 677 y no en un lenguaje de scripting!, pero si lo que necesitas es un men2 donde el artista pueda rellenar una fic#a #abra que escojer una opcin que no nos lleve muc#o tiempo en realizar.

.-!ame Tools: .stas son las #erramientas que van ligadas directamente al juego, muc#as de ellas deberian de estar conpartidas entre proyectos, estudios grandes suelen tener un visor de recursos del juego imagnes, secuencias, objetos %", etc.!, editores de mapas, editores de recursos donde los designers puedan cambiar comodamente los distintos aspectos de los recursos del juego, armas, automoviles, compa4eros, enemigos; que puedan cambiar la cantidad de vida, lo rpido que disparn,etc.!. La implementacin de dic#as #erramientas tambi$n iran ligado a la conveniencia del estudio, deberan de ser escalables y sostenibles. .s importante saber si se va a dar acceso a ellas al usuario o simplemente seran de uso interno, en el caso de dar acceso al usuario, deberan de ser lo mas sencillas posibles, dando la m8ima usabilidad pero sin perder eficacia. 5abria que #ablar tambi$n de la parte de preparacin de tales #erramientas, una buena base de codigo, es decir un buen core del estudio, unas buenas )P,-s, #arn que siempre se este preparado para producir aquello que sea requerido. .ste codigo tambi$n puede ser acogido como #erramienta, que no tenga *9, no significa que no sea una #erramienta como tal. :i se tiene una buena base #ar que el desarrollo de las #erramientas sea mas fluido y menos esparcido y con esparcido me refiero a que cada programador no usara tanto codigo desarrollado por si mismo, sino que utilizara llamadas a codigo ya probado!. 6omo cierre volvere a destacar que la correcta planificacin de las #erramientas necesarias para llevar a cabo un proyecto o varios y la planificacin con vistas al futuro del flujo de trabajo del estudio puede llevar a la reduccin drstica de tiempos y esfuerzo de trabajo para gran parte del estudio.