Gestión de activos, base de datos o sistema de versiones?

Mientras desarrollas los recursos para el juego (mallas, texturas, sonidos, videos), ¿cómo los gestionas?

1. ¿Mantenerlos junto con el código fuente dentro del sistema de versiones? (forzosamente, git, etc.)
2. ¿O tener una base de datos central respaldada, dedicada a los activos y hacer que los editores siempre trabajen como les gusta? (PostgreSQL, MySQL, etc.)
3. ¿Otro?

¿Cuáles son los pros y los contras de cada uno y por qué uno debe elegirlo sobre el otro / s?

Para muchos de nosotros, especialmente trabajando en juegos más pequeños, absolutamente debe tener activos en el mismo repositorio que su fuente .

La sugerencia de que los activos pertenecen a un repositorio separado solo tiene sentido para conjuntos de activos muy grandes, o para conjuntos de activos algo grandes cuando hay un límite de motor / datos claramente definido. A menos que haya una razón técnica específica para ello, ¡es un mal consejo!

Desea que su control de versión se comporte como el control de versión . Desea poder rebobinar y avanzar rápidamente y ramificar y fusionar revisiones y aún así tener su juego funcionando. Y su código y activos serán dependen unos de otros.

Por ejemplo: su código podría esperar poder establecer un parámetro en un sombreador, y ese sombreador podría depender de que haya una textura allí. O tal vez el formato de datos de sus niveles dependa de una versión particular de su código de juego.

Es casi seguro que se ensuciará. Y tiene mejores cosas que hacer que tratar de mantenerlo ordenado.

Ahora, como comentó Mike Wagner ( en esta respuesta ): ¡no quiere ni necesita todas las versiones "en progreso" de sus activos bajo control de versión! Solo la versión final / de trabajo, como la usa su código, servirá, a menudo esto es lo que exporta desde su herramienta.

(Aunque si desea controlar la versión de las versiones en progreso de los activos, está bien. Y se adapta bien a un repositorio separado. Personalmente, creo que una buena organización de carpetas y un sistema de respaldo adecuado es suficiente).

Dicho esto, a veces es bueno tener la opción de mantener activos "en progreso" bajo el control de versiones. Por lo general, esto implica tener una canalización de contenido que pueda manejar cualquier paso de 'exportación' por usted, por ejemplo: aplanar una imagen de varias capas a una sola textura.

Sistema de versionado.

Con un enfoque de rodar su propio resultado, terminaría rodando un sistema de versiones, por lo que es mejor usar uno listo para usar que ya haya tenido años de diseño / código / ciclos de prueba.

Mantenga los activos en un repositorio separado de la fuente, para que sea más fácil mantener los tiempos de pago / sincronización al mínimo y tome diferentes decisiones sobre cuánto historial retener (aunque el espacio en disco es económico, consérvelo todo siempre que sea posible. No cambie tanto durante la vida de un proyecto).

Marque los archivos XML como binarios, las herramientas de fusión tienden a ser muy malas para fusionar el marcado anidado y no es probable que los artistas detecten el marcado roto si la herramienta cree que no hay conflictos.

Si puede, organice una verificación de sintaxis o incluso la creación de activos en cada confirmación y rechace la confirmación con un correo electrónico a la persona que confirma si falla; Esto ahorrará una gran cantidad de tiempo de equipo.

Todo en un repositorio, si puede permitírselo en términos de tamaño. He oído hablar de repositorios de Subversion cerca de 1 TB. Actualmente estamos un poco por debajo de los 400 GB.

Además, los artistas revisan mucho todo, incluidos los 30 esquemas generales de un concepto; utilizamos árboles de carpetas separados para "activos de origen" y para "exportados", los que van al script de compilación de activos. Si su artista es atropellado por un autobús mañana, debe poder hacer que alguien continúe trabajando en sus activos al día siguiente, solo mirando a través del repositorio (sin arqueología en su máquina personal). Érase una vez cuando los juegos eran 2D y los sprites se representaban a partir de complejas escenas animadas de Max, tuvimos que enviar un montón de unidades en un juego de estrategia en tiempo real con un aspecto un poco asqueroso y muy inconsistente (frente al resto de las unidades), incluso aunque era una cuestión de volver a renderizar con una configuración de iluminación y antialiasing ligeramente diferente, porque el artista original había renunciado y no teníamos sus escenas originales de Max. Don'