30 de junio, 2014
Artículo indiespensable
Indiespensable
Dev Lavde 17# – Sistemas de Control de Versiones
Dev Lavde 17# – Sistemas de Control de Versiones

La colaboración no siempre es fácil. A las luchas de egos hay que sumarles los problemas de logística y organización. En los grandes juegos decenas de programadores, artistas y diseñadores han de trabajar codo con codo y en los mismos ficheros a la vez. Además, los proyectos suelen crecer y ramificarse de formas inesperadas: distintas versiones, actualizaciones, parches… Es por todo ello que alguien inventó los Sistemas de Control de Versiones. Esto que contaré hoy no es nada nuevo para los desarrolladores con experiencia, pero, si no lo conoces, te vendrá muy bien echar un ojo.

Hay muchos inconvenientes que pueden surgir simplemente por el hecho de trabajar en un proyecto de carácter informático (ahora expondré unos pocos). No sólo aplicable a videojuegos, y no sólo en programación, un sistema de control de versiones puede ser muy útil cualquiera que sea el proyecto, siempre que implique manejar ficheros.

Problemas y más problemas

Iniciar un proyecto de videojuegos es tan sencillo como bajarse las herramientas adecuadas y empezar a programar y a hacer gráficos. Y es tan fácil comenzarlo como destrozarlo y acabar con él de forma catastrófica. Desarrollando en solitario se tiene control absoluto sobre todos los ficheros del proyecto, pero si no se organiza uno bien, y no hace copias de seguridad regularmente, un error puede ser fatal. Modificaciones sin retorno del código del juego ocurren con frecuencia, a menudo para bien, a veces para mal. Esa fue la metida de pata clave de mi primer proyecto en 3D: intentar incluir un modelo físico en un proyecto de juego de coches acabó transformando tanto el código que jamás pude volver atrás, y lo mejor que conseguí fue un vehículo tan inestable como un Fórmula 1 en una pista de patinaje artístico. Bien mirado, esa catástrofe pudo salvarme de 13 años desarrollando el mismo juego (¡Ay! Tobías and the Dark Sceptres).

Trabajar en equipo (aunque sea pequeño) añade más problemas a la ecuación. En los inicios, una buena organización puede permitir que cada uno trabaje en partes aisladas del juego, arrimando el hombro y juntando las piezas sólo de vez en cuando. Herramientas gratuitas como WinMerge permiten comparar ficheros de texto, y mover partes de un archivo a otro, facilitando mucho la tarea de fusionar el código. Repositorios como DropBox, Google Drive o OneDrive también ayudan a mantener centralizado el proyecto y permiten trabajar remotamente. Pero la cantidad de ficheros crece y la cantidad de trabajo. Cada vez se modifican más ficheros, y más frecuentemente. Es normal que varios miembros del equipo hayan tocado el mismo fichero en distintas partes, ¡incluso la misma! Al final resulta una complicación tremenda mantener una versión actualizada y fusionar los ficheros periódicamente. Y los repositorios no hacen necesariamente copias de seguridad, borrar por error una carpeta podría no tener vuelta atrás.

Ahora vayamos a los equipos de mayor tamaño. Imagina que se acerca la fecha de entrega para una nueva versión de un juego, ya sea para un publisher, una demo, o una versión interna que someter a pruebas. Con el código estable, esa versión se compila y se envía. A continuación el equipo continúa trabajando añadiendo nueva funcionalidad. Pero, ¿y si algo fue mal? ¿Y si hay un bug grave que paso inadvertido? Si han pasado horas o días desde que se compiló la versión entregada, el resto del equipo habrá cambiado el código y el contenido suficientemente para que ya no sea estable. Aún con el fallo arreglado, no se podrá generar una versión entregable con el nuevo código hasta haberla probado adecuadamente, lo que introducirá más retrasos aún.

¿Qué es un sistema de control de versiones?

Simplificando, un sistema de control de versiones es un software que se encarga de almacenar y gestionar todos los cambios que sufre un proyecto a lo largo del tiempo.

El sistema de control de versiones almacena las modificaciones que ha sufrido un mismo fichero a lo largo de toda su historia, por lo que no es necesario ir haciendo copia de todo el proyecto cada vez que se cambia algo. Cuando algo se estropea, no sólo se puede volver a una versión anterior de un determinado fichero sino que es posible ver todos los cambios que ha sufrido con el paso del tiempo, y encontrar el momento exacto en el que comenzó a fallar.

Además facilita mucho la tarea de trabajar en equipo y remotamente, ya que se encarga de fusionar los ficheros automáticamente, siempre que no haya inconsistencias cuando dos usuarios han modificado la misma parte de un archivo, que generalmente se han de solucionar a mano. Y al tener duplicados los ficheros para todos los usuarios, no es tan necesario hacer copias de seguridad.

Un sistema de control de versiones también se encarga de gestionar las ramificaciones. Gracias a él, se puede acceder a una determinada versión, modificarla y generar una rama distinta, que luego puede ser fusionada con la rama principal si es necesario. Parte del equipo de desarrollo puede estar trabajando en una rama que lleva la siguiente versión a entregar, mientras otros modifican una versión anterior para dar soporte.

Pero no todo es perfecto en la Viña del Señor. A pesar de funcionar muy bien con ficheros de texto (código fuente, scripts, documentos), no lo hacen tan bien cuando se trata de ficheros binarios (sonidos, imágenes, texturas). Además, incitan al uso de anglicismos terribles como «mergear». El control de versiones no puede gestionar las diferencias de los ficheros binarios y fusionarlos (o «mergearlos») como lo haría con ficheros de texto. Y, al contrario que sucede con estos últimos en los que sólo se almacena la diferencia, con los binarios muchas veces no es posible, por lo que una nueva versión implica una copia nueva. Si hay cambios frecuentes en los ficheros binarios (caso normal en videojuegos), el tamaño del repositorio puede crecer desbocadamente. Si, además, se guarda una copia de todo el árbol de cambios en la máquina local como sucede con los sistemas de control de versiones distribuidos, se necesitará una gran capacidad en el disco duro (y una buena velocidad de descarga para obtener el proyecto).

La filosofía de funcionamiento de algunos motores de juego también puede añadir problemas: sin irnos muy lejos, Unity3D se tomó su tiempo en llegar a ofrecer un soporte adecuado (y gratuito) para el uso de sistemas de control de versiones en sus proyectos.

En resumen

Un control de versiones es una herramienta imprescindible a la hora de emprender el desarrollo de un videojuego (y de cualquier software en general).

Hay numerosas alternativas, siendo más populares SVN, Perforce, Git o Mercurial y, aunque todos están diseñados, en principio, para solucionar el mismo problema, cada uno tiene sus peculiaridades. Pueden ser centralizados o distribuidos, los hay que gestionan mejor o peor las ramificaciones, con sistemas de revisión de código y otras herramientas más o menos avanzadas, gratuitos o de pago… Algunos desarrolladores incluso utilizan varios a la vez, para obtener todas las ventajas de los distintos flujos de trabajo.

Es un hecho que acostumbrarse a trabajar con un sistema de control de versiones, si no se ha hecho nunca, es complicado y tedioso al principio. Pero las ventajas son inmediatas. Una vez hecho al uso, será inconcebible la vida sin él.

Acerca de Enrique Hervás


Humano Nivel 32. Diseñador y Programador de videojuegos Nivel 6. De esos a los que sus padres prohibieron jugar a "las maquinitas" por estar demasiado enganchados. No sabían lo que les esperaba. Actualmente trabajo como Game Designer en Exient, e intento no olvidarme de mi pasado indie de Game Jams y jueguitos con Join2 Games

No hay comentarios