Предисловие

Доброго времени суток! Меня зовут Евгений, я разработчик геймдев студии. Как и в любой разработке, мы используем системы контроля версий. Моей любимой является Plastic SCM, вместе с тем я почти не встречал команды её использующие. Обидно. Попробую исправить это недоразумение и познакомить вас с миром самой приятной SCM.

В первую очередь рассказано будет об использовании этого инструмента в разрезе игровой разработки, в частности в связке с игровым движком Unreal Engine. В отличие от стандартной разработки ПО данная сфера имеет свои нюансы, и опираться мы будем именно на них. Однако, если вы используете другой движок или вообще далеки от игровой индустрии, возможно вам тоже будет интересно познакомиться с этим инструментом.

Зачем. Как и в любой разработке, в геймдеве для синхронизации результата работы разных людей используются системы контроля версий. Если мы говорим об Unreal Engine, то в 99.(9)% это одно из: Git, SVN, Perforce или Plastic SCM. Spoiler alert: так как самый распространённый инструмент всё таки Git, то большинство сравнений будет именно с ним.

От всех инструментов, которые ты используешь в работе, ты хочешь получить максимум комфорта и минимум потребления твоего когнитивного ресурса. Для меня подобным инструментом стал Plastic SCM. Я нарочно лишний раз выделяю этот пункт, потому что обсуждая преимущества и недостатки того или иного инструмента программисты склонны выносить удобство за скобки. Хотя удобство рабочего процесса как минимум повышает его результативность, как максимум люди становятся счастливее когда им комфортно. Я, лично, люблю быть счастливее.

Особенности разработки. При выборе любого инструмента следует учитывать особенности работы, в которой он будет использоваться. В геймдеве есть две основные особенности разработки:

• Бинарники - в UE все ассеты представлены в первую очередь в виде бинарных файлов (*.uasset, *.umap и т.д.), так называемые блупринты (BP). В среднем 90%+ всех файлов, хранящихся в вашем репозитории, будут именно бинарными (и большими). Что самое противное, мёрджить их нельзя (почти, есть новый инструмент для мёрджа BP, однако это редко используется и в этой статье рассматриваться не будет).

• Артисты - помимо разработчиков, пишущих код для вашей игры, есть и другие команды, которые будут участвовать в разработке продукта. Причём их обычно больше, чем самих разработчиков, а их технические навыки зачастую не так высоки (и это нормально).

Without further interaction let's celebrate and go ahead.

Плюсы

UI

Говоря об удобстве использования данного инструмента, его визуальная оболочка является самым главным преимуществом. Если мы сравним условный Source Tree и клиент Plastic, то ощущения сопоставимы с переходом с FreeDOS на Windows 10, с Vim на Sublime, с дедушкиного запорожца на BMW I8.

После этих строк уже летят помидоры от старожилов разработки, готовых объяснить, почему они до сих пор пишут код в консоли, но я напомню про особенность Артистов. Попробуйте объяснить 50-ти летнему геймдизайнеру, что ему теперь надо учиться пользоваться Гит консолью, чтобы иметь свежую версию проекта.

Да, сейчас существует множество решений для работы с Git в графических интерфейсах. Но будем честны, они всё равно не столь удобны и понятны, особенно для людей не технической направленности. И это не только личное мнение: не раз я заходил в тот же Source Tree и обнаруживал, что кто-то из Level Design команды при слиянии локальной ветки ревёртил изменения, внесённые в Origin, думая что это какие-то левые файлы, из-за чего люди в панике обнаруживали отсутствие своей недельной работы. LD, конечно, побили Прошу обратить внимание, проблема не в человеке который это сделал - проблема в том, что он не понял что он сделал. UI он как анекдот, если его надо объяснять...

А теперь представьте себе мир, где обновления происходят нажатием на одну кнопку (которая появляется и подсвечивается как только таковые появляются), где переход с ветки на ветку переходит нажатием на ПКМ и ЛКМ, где нет необходимости помнить какие виды коммитов существуют, где слияние веток настолько просто и интуитивно понятно, что даже джун не ошибётся с этим процессом, даже не потратив перед этим час на изучение обучающих материалов. Всё это в Plastic SCM. _{не на правах рекламы}

Про удобство и лаконичность использования Plastic SCM можно ещё долго говорить. Я бы советовал просто попробовать самому (можно завести бесплатный Cloud сервер до 5GB и 3 клиентов) и убедиться, что даже без траты времени на обучалки спустя минут 20-30 использования вы уже будете чувствовать себя уверенным пользователем. И я не зря вынес это преимущество именно на первое место. Многие разработчики его недооценивают, говорят, что надо не лениться и просто выучить пару команд и пользоваться консолью, но я напомню два важных пункта, обозначенных ещё в начале:

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

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

Ветки

Тут стоит ещё немного прояснить. Поскольку большинство файлов - бинарники без возможности слияния, а большинство коммитов полезно вытягивать по мере их поступления, то довольно распространён подход, в котором все работают на одной ветке. Да-да, прямо в одной. И если мы говорим о, например, Perforce - то можно сказать, что просто все работают в Master. Кто-то может ужаснуться, но это не лишено смысла и во многом удобно.

Однако во многом != всегда. Разработчикам нужны ветки. Когда ты пишешь код, ты не хочешь его поставлять всем до завершения и проверок. Как разработчик ты хочешь иметь разделение на Dev и Master, чтобы всегда иметь доступ к максимально стабильной версии. И не все системы контроля тебе это дают. В Plastic SCM есть привычные в понимании того же Git ветки и это плюс. Не постесняюсь сказать большой жирный плюс, которого уже достаточно чтобы выбрать Plastic в противовес тому же Perforce (да, там тоже есть аналог веток - стримы, но де факто ни в одной из команд они не использовались).

Работа с бинарниками / Blueprints

Поскольку большинство файлов, хранящихся в вашей системе контроля версий, будут бинарными, хочется ожидать, что ваша система контроля версий будет хорошо с ними работать. И Plastic SCM это делает. Постараюсь кратко в тезисах.

LFS. Сравнивая с Git, стоит сказать, что не нужно никаких расширений и тд. Plastic работает с бинарниками легко и быстро прямо из коробки. И с лок системой из коробки, без какого-либо геморроя с настройкой (привет Git) и без залочивания файлов только на чтение на диске (привет Perforce). А локинг нам нужен, не забываем про 90+% бинарников.

Компактность. Plastic имеет свой быстрый и результативный метод компрессии файлов, так что можно не переживать что ваш репозиторий разрастётся в невероятных масштабах, успевай только докидывать память в сервер. А, ещё он не хранит всю историю в ненормально огромной локальной .git папке. Можно даже не докупать терабайтные SSD каждому пользователю в комп. Прикольно.

Скорость. Тут, конечно, зависит от сервера. Можно и Enterprise свой поднять где-то у бабушки в деревне на Raspberry Pi, естественно такой сетап быстрым не будет. Но тот же клауд на европейских серверах у меня Download/Upload использовал все доступные 800 Мбит интернета. Да и сам клиент работает довольно шустро.

Интеграция с UE. Плагин поставляется из коробки движка (где-то с 4.20-какой-то версии). Работает хорошо, всё чекаутит, подсоединяется, можно коммитить и обновляться (не рекомендуется) прямо из движка. Причём плагин продолжают поддерживать и развивать - была история, что плагин не учитывал ignore файл, но это пофиксили. Включение синхронизации в движке так же в два клика, если проект находится в контролируемой директории.

Минусы

Куда же без них.

Стоимость

В отличие от того же Git придётся платить. И это, пожалуй, уже причина отказаться от продукта. Но мы же уже пришли к тому чтобы оплачивать новые модные IDE для разработчиков, мы оплачиваем Photoshop артистам, а не заставляем их переходить на GIMP. Так что если вы менеджер/CTO/просто человек, ответственный за трату ресурсов, - это сообщение вам : инструмент стоит своих денег. Время сэкономленное на использовании окупит затраты. Подробнее о ценах тут.

• Cloud edition - 7$ за пользователя в месяц (пользователей может быть заведено сколько угодно, оплата происходит только за активных в данном месяце пользователей) + 5$ в месяц за каждые 25GB (первые 5GB бесплатно).

• Enterprise Edition - 23$ за пользователя в месяц. Но сервер уже ваш, сколько хотите, столько памяти и выделяйте, ставьте его где хотите и тд + остальные плюшки.

• Free Cloud edition - по факту - обычный клауд, для использования в серьёзных проектах вряд ли подойдёт (хотя был и такой опыт). Но стоит понимать, что если хотите попробовать - просто создайте свой аккаунт, скачайте клиент и попробуйте.

Пара особенностей:

• Нет никаких привязок к воркспейсам как, например, в Perforce. В целом, все на проекте могут быть одним пользователем. Неудобно, но если бюджет ограничен - можно и покрутиться в Cloud на трёх бесплатных пользователях. У меня был как-то проект мобильный, весил мало, и мы реально командой пользовались полностью бесплатно. Вполне себе вариант на попробовать, если боитесь переезжать сразу платно.

• Бесплатный Cloud можно поднять и без привязки карты. Не стоит бояться, что может произойти ситуация как с Amazon. Также карту можно будет отвязать, контролировать оплату не сложно, но если не заплатите спустя небольшой промежуток времени, доступ будет закрыт (если оплатить позже, доступ вернут, данные потеряны не будут).

РФ Situation

Если ваша компания зарегистрирована в РФ/РБ, может произойти ситуация, что подрубят санкции и не будут принимать вашу оплату. Весной как раз произошла такая ситуация и студия, в которой я работал, осталась без доступа к системе контроля версий. Причём спустя пару месяцев Plastic всё таки стал работать с компаниями из РФ, но потребовал оплату и за тот период, в который не было доступа к системе. Обидно.

Workaround. В целом такой риск уже достаточен, чтобы выбрать скорее Open source решение (Git), однако предупреждён - вооружён. Если предпринять пару превентивных шагов, риски будут нивелированы:

• Синхронизировать репозиторий с Git. У Plastic есть такая опция и в целом можно просто поднять у себя локально ещё и Git, с которым условный Jenkins/TeamCity etc. будут дублировать всё, что происходит в Plastic, и, если наступит день Х, работать будет где.

• Оплата через внешний субподряд/дочку. Думаю, в комментировании не нуждается.

P.S. Я спрашивал поддержку, планируют ли они снова перестать работать с компаниями из РФ - они сказали что не планируют, но не могут обещать, что такого не случиться.

Закрытость системы

У вас не будет исходников. Если вы DevOps, любящий всё написать самостоятельно - Bad news. Хотите соединить с каким-то необычным Яндекс трекером задач - скорее всего не выйдет (нельзя говорить, что что-то нельзя сделать, но это точно будет непросто).

Однако система уже довольно популярна, для тех же CI/CD инструментов уже есть плагины для интеграции с Plastic SCM. Я лично поднимал полный процесс сборки и деплоя в TeamCity.

Часть развёртки заставит вас повозиться, чтобы понять как в среде настроены доступы, где хранится Encryption ключ и т.д., но в целом это всё решаемо. Форумы и хорошая поддержка вам в руки.

Long story short - в 99% интеграции с Plastic уже сделаны и надо просто найти плагин и т.д., но порой закрытость даст о себе знать, и DevOps команда должна быть к этому готова.

Приятные фишечки

Поддержка. Низкий поклон ребятам из поддержки. Отвечают всегда довольно оперативно (у меня максимальное время ожидания несрочного вопроса было < суток, даже для клиента бесплатного уровня пользования). Только на английском, правда, но вроде это не супер проблема.

Синхронизация с GIT. Как и писалось выше, можно настроить Plastic для синхронизации с Git репозиторием. Однако процесс не автоматизирован как хотелось бы, и я бы не рекомендовал часть команды оставлять в Гите, а часть на Пластике, скорее стоит рассматривать эту опцию как бекап репозитория. Также будьте внимательны : с GitLab, например, Git LFS синхронизация не работала, так что не все провайдеры подойдут.

Синхронизация с Jira/другими таск трекерами - насчёт всех остальных не скажу, но из коробки идёт синхронизация с тасками из Jira (+ несколько других таск трекеров) и создавать ветки можно сразу под конкретные таски. Очень удобная фича, пользовался лично, ставлю лайк. Выглядит примерно так (старый скрин):

Код ревью. Есть инструмент для ведения код ревью прямо в клиенте, с комментариями и просьбами изменений к конкретным строкам кода. К сожалению, как раз с UE фича не самая лучшая, т.к. нельзя писать комментарии к бинарникам и частям BP соответственно, но если у вас полностью C++ проект, вам понравится.

Удобное сравнение. Diff любого файла с любой ревизией в два клика. Если настроить дифф через UE (как здесь - уже работает), то можно за два клика сравнивать даже блупринты.

Cloaked.conf & hidden.conf - представьте ситуацию, что вы работаете с движком из исходников. У каждого в версии проекта в .uproject будет своё значение. Вручную каждый раз убирать .uproject из списка изменений? Или закинуть его в игнор/локальный игнор (работающий через раз) и по ошибке не добавить .uproject в список изменений при включении нового плагина? В Plastic SCM есть концепция Hidden files и Cloaked files - файлов, которые часто обновляются, но не должны постоянно появляться в обновлениях. Подробнее тут по поиску ключевых слов (hidden cloacked).

Xlinks. Представьте, что у вас в студии несколько проектов, между ними используются кодовые модули, шарятся модельки (как в ситуации, описанной в статье) или, не дай бог, используется один кастомизированный движок. Чтобы хранить всё это в одном месте и оперативно вытягивать изменения, есть такая фича, как Xlinks - аналог symlinks из linux. Можете иметь отдельные репозитории для моделек, звуков, плагинов и т.д. и подтягивать их к проектам по мере необходимости и без лишних дубликатов.

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

Детект изменений. Боль, наверняка известная для пользователей Perforce. Ты изменил файл, но не был включён/залагал/просто не сработал нужный плагин, который должен был зачекаутить файл - он не появился в changelist - ты закоммитил каку. Plastic сам автоматически детектит все нужные изменения перед сабмитом. Ничто не пропадёт.

Триггеры. Хорошие новости для DevOps - триггеры есть, можно автоматизировать многие штуки.

Distributed/Centralized - по умолчанию, Plastic во время установки предлагает нам работать в режиме Centralized - все изменения не складываются локально перед финальным "push", а сразу заливаются в "origin". И для геймдева я бы советовал именно такой подход, так как изменения нужны ASAP, файлы лучше не лочить и т.д. Да и интернет уже достаточно развит, чтобы не так переживать о времени, когда посылать изменения. Однако, если вы ярый фанат Git подхода, Plastic SCM вас не ограничивает и позволяет пользоваться в Distributed режиме.

Proxy. Если ваша команда расположена на разных континентах, иметь один единственный сервер доступа == супер тормозить процесс загрузки\выгрузки внесённых изменений для части участников. Для этого (в Enterprise версии) есть функция создания Proxy серверов для более быстрого доступа для всех участников.

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

И многое другое.

Послесловие

Надеюсь, я смог вас убедить хотя бы обратить свой взгляд на эту систему контроля версий и желаю ей расти и развиваться.

Было бы интересно узнать в комментариях отзывы от тех, кто уже пользуется этим инструментом, а также почитать что-то подобное на тему SVN.

Спасибо за внимание!