Control de versiones y Assets

[TrOnTxU]

Esta es la eterna pregunta: ¿Como manejar el versionado de los assets de un juego?

Normalmente siempre he utilizado el mismo VCS (Subversion por norma general) que tengo para el código para almacenar los assets.
Pero solo los finales (resultado final de la tuberia de importacion), los binarios que se cargaran directamente por el motor.
Los grafistas y diseñadores se suelen guardar sus propias copias de los documentos (con guardado incremental generalmente) y suelen tener un ftp para subir copias de seguridad. El documento se exporta al binario final, y este es el que incluyo yo en el control de versiones.

Esto me ha funcionado bien en "antiguos" proyectos de PC, moviles e incluso en la DS.
En mi último proyecto de Wii ya me ha costado bastante mantener coherencia en los archivos por el movimiento que representa: el asset va del modelador, al texturizador, luego al animador, y si hay que cambiar algo vuelta para atrás, y en medio estas tu exportando el asset a mitad del desarrollo para que el jefe "vea el muñequito en la pantalla".

Me ha pasado de todo, el grafista te da el fbx exportado y dice haber subido el .max al ftp. Cuando el fbx demuestra algun fallo y se tiene que corregir no se encuentra por ninguna parte el .max original que contenia la ultima version y hay que hacer "maravillas" para solucionarlo, etc, etc, etc.


Ahora todavia es peor, se supone que voy a tener que manejar una cantidad cada vez más grande de assets, y vamos a gestionar una cantidad de datos bastante pesada, que se tiene que ir moviendo arriba y abajo.
Para que la organización sea medianamente aceptable veo totalmente necesario el uso de control de versiones en los documentos binarios (al menos los principales que sirvan de fuente para exportar los assets al motor), con un repositorio (incluso un sistema) diferente del usado para el código fuente.
Para colmo, el editor genera los datos del proyecto, y he de integrar algun tipo de wrapper o front-end para un control de versiones de archivos COLLADA, PSD, .doc, .cls, FBX, DDS, .CG, etc, etc, en el mismo editor.

Las opciones que estoy evaluando:

1) Perforce. El standard de la industria, tan bueno como caro. (creo que paso por el precio) No lo he probado, aunque he oido hablar mucho de él. Segun cuentan las malas lenguas es probablemente el mejor VCS actual, sobretodo si estas trabajando con archvos binarios (desde documentos office, a archivos Maya, pasando por PSDs). Utiliza deltas para almacenar diferencias entre binarios, logrando que las revisiones de los binarios ocupen muy poco espacio (relativamente) en el repositorio, y parece ser extremadamente rápido.

2) Subversion. A mi no me ha ido mal con los binarios, excepto cuando he intentado implantar un sistema completo de versionado de archivos binarios on candados, etc. Generalmente los "no programadores" se vuelven un poco locos. El problema viene al tener muchos archivos, y archivos grandes. Es lento comparado con Mercurial, Git o Bazaar, y el repositorio crece bastante rápido al meter actualizaciones de assets binarios.

3) Mercurial, Bazaar, Git. De entrada son distribuidos, lo que implica que almacenarian una copia de toda la historia de la branch en el "working directory", aunque se pueden podar (al menos en Git) no es la configuracion por defecto. Pienso que para gestionar los assets quizas seria mejor un repositorio centralizado que ir juntando branches, ya que los branches de los binarios ...
Aun asi, se puede hacer que estos sistemas funcionen "emulando" un repositorio centralizado. Mercurial y Bazaar son los más rápidos, si contamos que Git tiene que hacer un "pack" del repositorio, o este crece hasta niveles desmesurados. A pesar de esto ultimo un repositorio de Git  lleno de binarios con cambios en el historial y acabado de "empaquetar" puede llegar a ocupar la mitad que el mismo repositorio en svn. Mercurial y Bazaar generan repositorios ligeramente más pequeños que Svn, aunque no tanto como Git.

4) Gestionar los assets con un sistema propio, ya sea basado en bases de datos, etc. (ni de coña tengo tiempo ahora mismo, ..., y creo que nunca)

5) Big files for ... hay una modificacion (fork) de Git, llamada Git for Big Files, la tengo que probar y medir todavia, pero puede que funcione mejor que Git a secas. Hay otro Big Files para mercurial pero no lo he mirado.


Conclusion:
- Perforce es demasiado caro.
- Svn no es lo mejor para grandes cantidades de datos binarios. Pero tiene soporte para candados.
- Parece que Git se defiende bien, pero tendria que estudiar las posibilidades de configurarlo lo más parecido a un sistema con repositorio centralizado. Es el que produce repositorios más pequeños (aunque haya que hacer un pack del mismo)
- Mercurial y Bazaar son otras dos opciones a estudiar.

- El problema de que dos personas modifiquen "a la vez" un mismo asset y luego intenten subir los cambios creando conflictos, es una cosa que no se como solucionara Perforce, pero que a mi me trae de cabeza (los candados no son siempre la solución), asi que supongo que será cuestión de establecer una "rigurosa" politica de comunicacion y notificación entre el equipo.



¿Opiniones? ¿Sugerencias? ¿insultos?

Bueno gracias a los que lo leais (a los que no, no ;) )
Un saludo

[AgeR]

Pues ya lo sabes, pero no hay una solución única ni sencilla.  :)

Nosotros estamos tirando de SVN. Como bien dices, para datos binarios no es la mejor solución, pero al menos es barata. La opción si hubiera pasta suficiente, sería Perforce, obviamente.

Con SVN, nosotros tenemos repositorios distintos, básicamente 3: Código, Datos Fuente y Datos finales. De esta forma podemos hacer backup con distinta periodicidad de cada cosa, por ejemplo.

El tema es tener un servidor que se encargue de pillar los datos fuente, y exportarlos a su formato final en el repositorio oportuno. Para ello, hay que tirar de scripts que automaticen la tarea de comprobar si se ha subido una nueva versión de un dato fuente, y en ese caso, exportar y subir al repositorio de datos finales.

Con respecto al trabajo de varios artistas de forma paralela, el tema sería más jodido. Lo suyo sería tener el modelo por un lado y las animaciones por otro (trabajando a partir del esqueleto en la medida de lo posible). Lo mismo con los PSDs. De todas formas, aquí siempre va a haber problemas, porque son áreas muy interdependientes.

En cualquier caso, la mejor solución a mí me parece (salvo que tiréis de opciones más caras) tirar de SVN + lockeo de archivos. Eso sí, habría que cuidar mucho el timming de tareas, para que los artistas que tienen un modelo "vetado" puedan trabajar en otras áreas durante ese tiempo. Pero para eso están el jefe de proyecto y el productor.  :)

Saludos!