Git para el desarrollo de videojuegos
14 de marzo de 2012 A lo largo de los años he utilizado varios sistemas de control de versiones para producción cinematográfica y de videojuegos: CVS , Perforce e incluso algunas herramientas internas. Siempre me parecieron males necesarios pero torpes: indispensables para hacer seguimiento del trabajo en proyectos grandes, pero también una fuente constante de confusión, cuellos de botella y rigidez en la producción.
Git apareció por primera vez en mi radar hace unos seis meses. Parecía increíblemente potente y flexible. Los desarrolladores de Massively Fun ya lo estaban usando para el desarrollo de código cuando me uní al equipo. Tenía muchas ganas de ver si podíamos adaptarlo a la producción de arte.
Esta publicación cuenta la historia de lo que sucedió. Antecedentes: ¿Qué es Git? Git es un sistema de control de versiones distribuido . Casi todo el mundo en el desarrollo de videojuegos ya estará familiarizado con al menos otro sistema de control de versiones como Subversion o Perforce .
Al igual que estos otros sistemas, Git nos permite llevar un registro de las muchas versiones diferentes de todos los archivos que forman parte de un proyecto. Pero Subversion y Perforce son sistemas centralizados: todos los archivos se envían (check-in) o se extraen (check-out) de un repositorio que reside en un servidor central. Git es diferente.
No depende de un servidor central. Cada usuario obtiene una copia completa de todo el repositorio, con todo su historial y revisiones. Este diseño tiene varias implicaciones importantes , la mayoría de ellas positivas.
Pero lo que hace que Git destaque especialmente a mis ojos es cómo convierte las operaciones de ramificación (branch) y fusión (merge) en algo casi trivial. Puedes crear una rama para trabajar en alguna idea experimental, otra para solucionar algún problema no relacionado y una más para una nueva funcionalidad. Puedes moverte rápidamente entre estas distintas ramas y fusionarlas cuando sea necesario. Es una característica increíblemente útil.
Relacionado: — Arte, herramientas y plantillas listas para usar que se incluyen directamente en tu proyecto de Unity.
Obstáculos A pesar de sus muchas fortalezas, Git tal cual viene tiene dos defectos obvios para la producción de arte: No es amigable para los artistas. La interfaz predeterminada de Git es la línea de comandos.
Hay muchos comandos y opciones que aprender, junto con conceptos subyacentes que difieren lo suficiente de otros sistemas de control de versiones como para generar confusión. La documentación es abundante, pero a menudo difícil de entender. Todo ello da como resultado un paquete poco accesible y algo intimidante. No está diseñado para gestionar los grandes archivos binarios que crean los artistas.
El hecho de que cada repositorio local contenga todo el historial y las revisiones significa que una gran cantidad de obras de arte en constante cambio puede consumir mucho espacio en disco muy rápidamente. Se nos ocurrieron soluciones para ambos problemas. La interfaz importa Existen varias buenas interfaces gráficas para Git.
Si estás de compras: — Motor HTML5 sin código basado en navegador que exporta a la web, dispositivos móviles y computadoras de escritorio.
Los artistas aún necesitan comprender los conceptos básicos de Git, pero un front-end bien diseñado facilita considerablemente su aprendizaje y uso. Descubrimos que SourceTree de Atlassian funcionaba de maravilla en nuestro entorno basado en Mac: es potente, intuitivo y gratuito (por ahora), algo importante para una startup con recursos limitados. El equipo de SourceTree también respondió con rapidez (< 12 horas) a nuestras consultas de soporte enviadas por Twitter.
Una extensión de Git muy elegante Git-media aborda las limitaciones de Git respecto a los grandes archivos binarios. Es una extensión de Git que te permite almacenar archivos fuera de Git.
Git sigue rastreando las versiones de los archivos; simplemente almacena el contenido de los archivos en algún lugar fuera del repositorio. Planeábamos almacenar nuestros grandes binarios en la nube S3 de Amazon. No tan rápido Sin embargo, usar SourceTree con Git-media presenta un inconveniente: transferir archivos entre nuestros repositorios y Amazon S3 requiere ejecutar un comando de shell; es decir, $ git media sync Un flujo de trabajo que obliga a los artistas a abandonar la relativa comodidad de una aplicación gráfica para escribir comandos de shell no es nada amigable para ellos.
SourceTree sí ofrece una manera de ejecutar este comando como una acción personalizada, pero eso no era suficiente. Los artistas todavía tendrían que recordar hacerlo en los momentos adecuados.
Tarde o temprano lo olvidarían y alguien perdería un tiempo valioso tratando de averiguar qué salió mal y solucionándolo. ¿Cómo podríamos lograr que SourceTree y git-media trabajaran juntos armoniosamente? Git Wrap Escribimos un script envoltorio genérico que opcionalmente ejecuta algunos otros comandos antes y/o después del propio comando git. Lo configuramos para llamar automáticamente a ‘git media sync’ antes o después de los comandos que interactúan con un repositorio remoto, según corresponda.
Configuramos SourceTree para invocar el envoltorio en lugar del Git listo para usar. El código fuente del envoltorio está disponible aquí en Github . La aventura continúa Me gustaría poder decirles que ahí terminó la historia, que SourceTree y git-media trabajaron juntos a la perfección y que todos vivieron felices para siempre.
De hecho funcionaron, hasta cierto punto. Por desgracia, no fue suficiente. SourceTree normalmente hace un buen trabajo previsualizando archivos de imagen. Esto es crucial para los artistas cuando confirman (commit) o fusionan cambios en dichos archivos.
Pero usar git-media rompió la capacidad de SourceTree para previsualizar estos archivos, porque significaba que ya no estábamos almacenando las imágenes en Git; solo estábamos almacenando información de versión sobre las imágenes. No pudimos encontrar una solución aceptable; fue un motivo decisivo para descartarlo.
Al momento de escribir esto, estamos haciendo otro intento con la función de submódulos de Git. Almacenar nuestros activos de arte en un submódulo es otra forma de minimizar el tamaño del repositorio principal del proyecto. SourceTree comprende y admite bastante bien los submódulos, y su capacidad para previsualizar imágenes permanece intacta. Los submódulos tienen algunas peculiaridades, pero nada que parezca demasiado disruptivo para el flujo de trabajo de nuestros artistas.
Estén atentos a las actualizaciones; les haremos saber cómo resultan las cosas. comentarios del blog con tecnología de Disqus
Llene su escritorio de desarrollo
Libros de programación de juegos, teclados mecánicos, monitores y hardware de escritorio de desarrollo.