Система контроля версий для разработки игр с UDK?

Question

Мы - команда, думающая сделать игру с использованием Unreal Development Kit , и мы ищем решения для контроля версий.

Я всегда предпочитал децентрализованные VCS, такие как Git и Mercurial, и использовал его для всех своих личных проектов. Хотя я слышал о проблемах, связанных с разработкой игр с использованием этих систем, они не подходят для больших двоичных файлов.

Subversion кажется хорошим решением, однако я не использовал его вообще в прошлом, поэтому я не знаю, что он предлагает.

Answer 1

Вы можете использовать Mercurial или Git без проблем. Я не знаю, почему @TomTom заявляет иначе, не давая никаких подсказок о причинах.

Конечно, вам придется управлять различными бинарными файлами, которые входят в каждую разработку игры (фильмы, текстуры, карты и т. Д.). Но у обоих программ есть способы справиться с ними.

Mercurial

Mercurial имеет различные расширения для работы с большими файлами, особенно двоичными.

Начиная с версии 2.0, расширение Large File включено в Mercurial, и вы можете использовать его, не загружая ничего другого. Файлы не хранятся непосредственно в хранилище, но Mercurial отслеживает, какая версия файла необходима для каждого набора изменений, поэтому вы можете загрузить точную версию вашей игры с нужным файлом, когда вам это нужно.

До версии 2.0 использовалось в основном два расширения:

1. расширение Bfiles , которое использовалось в качестве основы для нового расширения в 2.0
2. Расширение Bigfile , что немного сложнее, чем два других, на мой взгляд

1025 * Гит * Я не очень знаком с возможностями Git для обработки больших файлов, но я знаю, что существуют различные решения. Этот пост должен дать несколько хороших указателей: Управление большими двоичными файлами с помощью git Я слышал много хорошего о git-annex . 1035 * SVN * Я использовал SVN с большими файлами, и у меня нет впечатления, что он управляет ими лучше, чем Mercurial (без расширений) из коробки. Если вы решите использовать расширение для управления большими файлами с помощью Mercurial / Git, Subversion значительно отстает в плане функциональности. Заключение

Если вы хотите, чтобы версия двоичных файлов синхронизировалась с исходным кодом, расширения бота Mercurial и Git отлично справляются с этим.

Каждая версия двоичных файлов хранится в отдельном централизованном каталоге (largefile store в терминах Mercurial), а когда разработчик клонирует репозиторий или обновляет определенный набор изменений, только необходимые файлы загружаются из этого магазина.

Вы даже можете использовать один и тот же магазин для различных хранилищ!

Процесс добавления файла в хранилище или его обновления почти прозрачен для разработчика, поэтому, например, нет проблем с длинной кривой обучения.

В заключение, я действительно не понимаю, почему Git или Mercurial не подходят для этой задачи, и никакой другой ответ не дает никакой реальной причины.

По моему мнению, крупные игровые компании придерживаются старых инструментов, потому что изменение требует времени, и когда вы платите за что-то, вы его используете! Сколько компаний до сих пор используют VSS или CVS только потому, что иерархия ничего не услышит о чем-то еще? Мы только что перешли на TFS (из VSS) в прошлом месяце, где я работаю ...

Answer 2

Hq (Mercurial) 2.0 поддержка больших файлов отличная.

Раньше это было LargefilesExtension , но с версии 2.0 оно распространяется с ядром.

Answer 3

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

Answer 4

Я всегда предпочитал децентрализованные VCS, такие как Git и Mercurial,

ПОЛНОСТЬЮ непригоден для использования. Точка.

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

Если вы занимаетесь разработкой игр, у вас будет множество управляемых версиями ресурсов, в которых программисты заинтересованы в ZERO. Даже большинству графических людей это не нужно. DCS распадается на части, когда вы можете ожидать, что ваш репозиторий будет больше, чем обычный жесткий диск. И в зависимости от того, насколько вы хороши в графике, вы можете легко найти тысячу + gb opf-репозиторий. Идея слияния этого с моим локальным репозиторием в качестве программиста, не имеющего отношения к grpahics, за исключением небольшой тестовой графики, заставляет меня злиться - как это сводит с ума администратора сети.

Это становится еще хуже, когда вы правильно справляетесь с анимацией / фильмами сверху. Каждое изменение и рендеринг - это другая версия. Boom. Это достаточно плохо для обработки в центральном хранилище (где я могу добавить диски на центральный сервер), это совершенно непригодно в тот момент, когда вы раздаете это каждому члену команды В КАЖДОЙ ВЕРСИИ.

Subversion кажется хорошим решением,

Возможно, если вы справитесь с его глупостями.

Я бы настоятельно рекомендовал проверенное решение здесь - спектакли в значительной степени способны справиться с этим проверенным.

Answer 5

Большие игровые студии обычно используют http://www.perforce.com/ (если честно, я понятия не имею, почему.)

SVN также является довольно хорошим вариантом, но он немного устарел по сравнению с Git иMercurial.

В любом случае, зачем помещать большие двоичные файлы в хранилище?Вы определенно захотите добавить строки игнорирования для всех скомпилированных двоичных файлов и т. Д. Всегда включайте только исходные файлы: -)

Лично я бы придерживался Mercurial или Git.