¿Control de origen para almacenar todo el proyecto del juego?

¿Es habitual administrar no solo el código fuente, sino todos los activos, texturas, arte, archivos de documentación, etc. en el repositorio de git para el control de versiones? Por ejemplo, quiero recuperar la versión anterior de la textura. Si es una práctica muy mala, ¿qué herramientas utiliza para el control de versiones de activos y otras cosas?

Yo diría que es una muy buena práctica. El control de fuente debe usarse para la fuente y los activos. Puede pensarlo como una copia de seguridad, desea poder restaurar desde el control de origen todo lo necesario para construir su juego.

He vinculado una pregunta sobre el almacenamiento de activos en un repositorio. Hay algunos repositorios que funcionan mejor que otros para almacenar arte. Le permitirán "diferir" el arte y ver qué ha cambiado. Otros solo tratarán los activos como datos binarios, por lo que tendrá que verificarlos para ver qué es diferente. Esto también significa que tendrá que cargar todo el activo cuando cambie, ya que no será posible que el repositorio "sepa" (analice) lo que ha cambiado entre versiones.

Guardo todo en el repositorio. Cuando obtuve mi nueva computadora portátil, pude revisar mi repositorio y construir mi juego, sin la necesidad de copiar ningún activo de ningún otro lado. Eso significa que también almaceno las bibliotecas de terceros, los activos y el control de origen en mi repositorio.

Git no es ideal para archivos que no son de texto. La clonación de un repositorio de git requiere la descarga de todas las versiones históricas de un archivo, a menos que se use una extensión de archivo grande (no estándar, a menudo no es compatible con GUI) o comandos especiales (requiere ser un git guru). Lo mismo ocurre con la mayoría de los sistemas DVCS. Para una textura, modelo o clip de audio, esto significa extraer muchas copias de un archivo muy grande. 1 GB de activos puede ser fácilmente 200 GB de datos de revisiones históricas, y git te hace descargarlo todo cuando clonas un nuevo repositorio, y descargar todas las revisiones intermedias cuando tomas la última. Esto se convierte en un gran cuello de botella en el futuro cuando menos se pueden tolerar retrasos en la producción.

Subversion, Perforce, etc. son mejores opciones para los activos, ya que solo requieren descargar la revisión deseada (la última, por lo general). Puede usarlos solo para activos y usar git para código, o también usarlos para fuente. Perforce tiene algunas características que le permiten actuar como un DVCS muy torpe, y es mejor que la funcionalidad SVN (aunque mucho más complejo) en mi experiencia, sin embargo, el costo significa que probablemente usará Subversion.

La mayoría de los profesionales de contenido tienen poca necesidad de DVCS, y algunos tienen problemas incluso con los conceptos básicos de VCS clásico de todos modos. No ensillar el con git. O Mercurial, DARCS, etc.

Es una buena práctica, incluso como artista cuando trabajas en un proyecto, tiende a haber algún tipo de control de versión, corrupción de archivos o errores, sin el control de fuente, los artistas tienden a hacer revisiones, lo que es un gran desastre.

Un ejemplo del mundo real que puede ver en esto son los proyectos de películas abiertas hechas con Blender (Big Buck Bunny, Durian, etc.)

La canalización de arte para un juego es más o menos la misma, excepto que podría haber un paso de compilación para que los activos mismos realicen alguna conversión de datos grandes y gordos a formatos específicos del motor, como la compresión de texturas y la conversión de formatos de modelos.

Algunas herramientas, como GitHub, incluso ofrecen buenas herramientas de comparación de imágenes y similares, que es mucho mejor que comparar un blob binario.

Dado que un repositorio de activos puede ser absolutamente enorme, mi / nuestra preferencia es mantener un repositorio de activos separado que es un submódulo en el repositorio del proyecto. No desea extraer gigabytes de activos cuando todo lo que quiere es ramificar la fuente, por ejemplo.