Контроль джерел для зберігання всього ігрового проекту?

Як правило, керувати не лише вихідним кодом, але всіма активами, текстурами, графікою, файлами документації тощо у сховищі git для контролю версій? Наприклад, я хочу повернути стару версію текстури. Якщо дуже погана практика, які інструменти ви використовуєте для контролю версій активів та інших речей?

Я б сказав, що це дуже хороша практика. Контроль над джерелами повинен використовуватися для джерела та активів. Ви можете думати про це як резервну копію, ви хочете мати можливість відновити з джерела управління все необхідне для створення вашої гри.

Я пов’язав питання про зберігання активів у сховищі. Є деякі сховища, які краще зберігають мистецтво, ніж інші. Вони дозволять вам "розіграти" мистецтво і побачити, що змінилося. Інші будуть просто розглядати активи як бінарні дані, тому вам доведеться перевірити це, щоб побачити, що відрізняється. Це також означає, що вам доведеться завантажувати весь актив, коли він змінюється, оскільки репозиторій не зможе "знати" (розбирати), що змінилося між версіями.

Я зберігаю все у сховищі. Коли я придбав свій новий ноутбук, я зміг перевірити своє сховище та створити свою гру, не потребуючи копіювання будь-яких активів з будь-якого іншого місця. Це означає, що я також зберігаю сторонні бібліотеки, ресурси та управління джерелами у своєму сховищі.

Git не чудово підходить для нетекстових файлів. Клонування git repo вимагає завантаження всіх історичних версій файлу, за винятком випадків, коли використовується велике розширення файлу (нестандартне, часто не підтримується графічним інтерфейсом) або спеціальні команди (для цього потрібен git guru). Те саме стосується більшості систем DVCS. Для текстури, моделі чи аудіокліпу це означає, що витягуєте багато копій дуже великого файлу. 1 Гб активів може бути 200 ГБ історичних даних про перегляд, а git змушує вас завантажити все, коли ви клонуєте нове репо, та завантажте всі проміжні версії під час захоплення останніх. Це стає величезним вузьким місцем у дорозі, коли можна як мінімум терпіти затримки виробництва.

Subversion, Perforce тощо - це кращий вибір для активів, оскільки вони вимагають завантаження лише потрібної версії (як правило, останньої). Ви можете використовувати їх лише для активів і використовувати git для коду, а також використовувати їх і для джерела. Perforce має деякі функції, які дозволяють йому діяти як дуже незграбний DVCS, і на мій досвід кращий за функціональність SVN (хоча і набагато складніший), однак вартість означає, що ви, швидше за все, використовуєте Subversion.

Більшість професіоналів із контенту мало потребують DVCS, а у деяких в будь-якому випадку виникають проблеми навіть з основами класичного VCS. Не сідлайте з git. Або Mercurial, DARCS тощо.

Це хороша практика, навіть як художник, коли ви працюєте над проектом, має тенденцію до контролю над версіями, пошкодження файлів або помилок, без того, щоб виконавці з контролю джерел прагнули зробити ревізію, економить в будь-якому разі, що просто величезна безлад.

Приклад із реального світу, який ви можете побачити, це проекти з відкритих фільмів, зроблені за допомогою Blender (Big Buck Bunny, Durian тощо)

Художній конвеєр для гри є більш-менш однаковим, за винятком того, що може бути крок складання для самих активів, щоб здійснити певну конверсію з великих даних про жир у певний формат двигуна, наприклад стиснення текстури та перетворення формату моделі.

Деякі інструменти, як-от GitHub, навіть пропонують приємні інструменти порівняння зображень і подібні, що набагато краще, ніж порівнювати двійкову крапку.

Оскільки сховище активів може бути абсолютно величезним, моїм / нашим перевагою є збереження окремого сховища активів, яке є підмодулем у сховищі проектів. Ви не хочете знижувати гігабайти активів, коли, наприклад, потрібно лише розв'язати джерело.