Управление активами, база данных или система управления версиями?

29

Разрабатывая ресурсы для игры (сетки, текстуры, звуки, видео), как вы ими управляете?

Хранить их вместе с исходным кодом внутри системы управления версиями? (выступления, мерзавцы и т. д.)
Или иметь центральную резервную копию базы данных, предназначенной для ресурсов, и иметь редакторов, которым всегда нравится работа? (PostgreSQL, MySQL и т. Д.)
Другие?

Каковы плюсы и минусы каждого и почему следует выбирать его среди других?

assets version-control asset-management

— NocturnDragon
источник

Хороший вопрос. Мне очень интересно услышать, как другие подходят к этому.

— Дэвид Макгроу

1

Для получения информации о контроле версий: gamedev.stackexchange.com/questions/480/… и gamedev.stackexchange.com/questions/245/… Я не думаю, что это дубликат, поскольку речь идет конкретно об активах

— Шон Джеймс,

22

Для многих из нас - особенно для небольших игр - у вас обязательно должны быть ресурсы в том же хранилище, что и у вашего источника .

Предположение о том, что активы принадлежат отдельному репозиторию, имеет смысл только для очень больших наборов активов или для несколько больших наборов активов, когда существует четко определенная граница механизма / данных. Если для этого нет конкретной технической причины - это плохой совет!

Вы хотите, чтобы ваш контроль версий вел себя как контроль версий . Вы хотите иметь возможность перематывать и ускорять перемотку вперед, а также ветвиться и объединять ревизии, и при этом ваша игра должна работать. И ваш код и активы будут зависеть друг от друга.

Например: ваш код может ожидать установки параметра в шейдере, и этот шейдер может зависеть от наличия текстуры. Или, возможно, формат данных ваших уровней может зависеть от конкретной версии кода вашей игры.

Это почти наверняка станет грязным. И у вас есть дела поважнее, чем пытаться поддерживать порядок.

Теперь, как прокомментировал Майк Вагнер ( об этом ответе ), вы не хотите или не нуждаетесь во всех «находящихся в процессе» версиях ваших активов под контролем версий! Подойдет только окончательная / рабочая версия, используемая вашим кодом - часто это то, что вы экспортируете из своего инструмента.

(Хотя, если вы хотите контролировать версии текущих версий ресурсов - это нормально. И хорошо подходит для отдельного репозитория. Лично я считаю, что достаточно хорошей организации папок и правильной системы резервного копирования.)

Это, как говорится, иногда приятно иметь возможность просто «активировать» активы под контролем версий. Как правило, это подразумевает наличие конвейера контента, который может обрабатывать любые шаги «экспорта» для вас, например: выравнивание многослойного изображения в одну текстуру.

— Эндрю Рассел
источник

10

Система управления версиями.

С подходом «сам по себе» вы фактически получите систему управления версиями, поэтому лучше использовать готовую систему, которая уже имела годы разработки / кодирования / тестирования.

Храните ресурсы в отдельном репозитории от источника, чтобы упростить сведение времени извлечения / синхронизации к минимуму и принимать различные решения о том, сколько хранить истории (хотя дисковое пространство дешево, сохраняйте все это, когда это возможно. Отдельные текстуры не нужны не сильно изменится за всю жизнь проекта).

Пометка файлов XML как двоичных, инструменты слияния, как правило, плохо подходят для слияния вложенной разметки, и художники вряд ли обнаружат разорванную разметку, если инструмент решит, что конфликтов нет.

Если вы можете, организуйте проверку синтаксиса или даже создайте ресурс для каждого коммита и отклоните коммит с электронным письмом обратно тому, кто его коммитит в случае неудачи; это сэкономит много командного времени.

— Лунная тень
источник

2

Договорились о хранении художественных активов и активов кода в отдельных репозиториях. Вы также можете обнаружить, что художники более неохотно проверяют что-то, чем программисты, и не обязательно, потому что они находят систему пугающей. У них может быть 30 грубых набросков концепции, и они не хотят представлять, пока не сузят ее до того, что им нравится. Фактор это в производственный трубопровод. Если технический директор дышит им в шею, чтобы проверить все, они будут проводить больше времени в репо, чем чертить вещи.

— Кейси Вагнер

1

О маркировке XML-файлов как двоичных: если ваша VCS допускает использование отдельных инструментов сравнения, попросите ее использовать что-то, что специализируется на XML-различии для файлов XML. Это может помочь избежать странной сломанной разметки.

— Джефф

+1 на это. :) Активы принадлежат в их собственном хранилище - если вообще в хранилище. Может быть, с помощью специального программного обеспечения для хранилища активов? Специально созданный для этой цели, вместо того, чтобы пытаться приспособить его к системам управления версиями, предназначенным в основном для текстового контента.

— Жакмо

8

Все в одном хранилище, если вы можете себе это позволить с точки зрения размера. Я слышал о хранилищах Subversion в районе 1 ТБ. Сейчас у нас чуть меньше 400 ГБ.

Кроме того, художники много проверяют во всем, в том числе 30 грубых набросков концепции; мы используем отдельные деревья папок для «исходных ресурсов» и «экспортируемых» - тех, которые входят в сценарий сборки ресурса. Если ваш художник попал в автобус завтра, вам нужно, чтобы кто-то продолжил работу над его активами на следующий день, только просматривая хранилище (без археологии на его персональной машине). Когда-то, когда игры были 2D и спрайты были представлены в сложных анимированных сценах Макса, мы должны были отгружать кучу юнитов в игре RTS с немного дрянным и очень непоследовательным видом (по сравнению с остальными юнитами), даже хотя это был вопрос повторного рендеринга с немного другими настройками освещения и сглаживания - потому что оригинальный художник ушел, а у нас не было его оригинальных сцен Макса. Дон»

— Unsigner
источник

1

Upvote за упоминание "автобусного фактора")

— Кромстер говорит, что поддерживает Монику