Последние мои коммиты по проекту были в середине 2022, на текущий момент прошло полтора года. В целом это повод рарссказать о том, что это вообще такое было и для чего было нужно.
Что это такое
С самого начала лиди я грезил автоматизацией процесса сборки воркшоп контента. В начале это было просто мечтой - недостижимой идеей, однако ближе к 2022 году я практически реализовал этот проект на продакшене. К сожалению шафт скоропостижно скончался, а с ним и сборщик.
Суть этого автосборщика автоматизировать процесс сборки контента для серверов, оптимизация ресурсов и удаление лишнего хлама. Про техническую часть будет ниже.
Плюсы автоматической системы достаточно очевидны - снизить количество путаницы, удаление какие-то устаревших ассетов, быстрое добавление/удаление или хотфиксы текстур. Я очень не любил заниматься контентом, поэтому практически всю работу выполнял Женя. Мне кажется, что в последствии он преисполнился в познании этой нелегкой работы - 4 года умственного насилия, по сути свою работу он выполнял отлично.
Нюансы нашей работы с контентом на самом деле довольно хитрые, и это не только убрать луа файлы из контента… хотя, конечно, не совсем знаком с тем, как работали другие сервера в этом плане. Вся история в основном завязана на нашем опыте взаимодействия с воркшоп контентом, глубоким анализом работы движка Source и работы аддонов в гаррисе. У нас на учете стоял каждый контент с каждым весом, подсчитывали и вносили в таблицу учета. Раньше просто нельзя было загружать объемные файлы в воркшоп. Да и вся эта процедура была нужна в целом для того, чтобы контент не весил больше самой игры.
Так как мой самый первый проект был лиди, опыта в работе ни у кого не было, чистая проба пера. Да и в первое время контента было немного, поэтому конечное взаимодействие сводилось ближе к банальной ссылке из оригинальных воркшоп предметов в одну коллекцию без оптимизации.
Коротко о том, как работает контент в гаррисе
По мере наполнения контента мы сталкивались с трудностями, в первую очередь в плане кода. Сервер можно легко взломать, так как связанные с коллекцией предметы, сами обновлялись и в одном из предметов мог затесаться lua файл, который точно бы исполнился. Также какой нибудь автор мог использовать 4К полотно чисто белого цвета и без альфа канала… Зачем, одному автору известно, ну и сами 4К текстуры на моделях… Ну, такое. Да, круто… но такое, учитывая что в гаррис в основном играли на достаточно слабом железе, а сама игра обрабатывала такие текстуры с трудом. Мы пришли к выводу, что лучший вариант на тот момент - ручная проверка всех текстур, чистка от луа файлов и своеобразная консервация в наших собственных сборках.
Наша таблица ведения контента, было актуально до 2019 года
Наша таблица ведения контента, итоговые результаты
В конце концов помимо одинокой модели в gma может спокойно размещаться регдолл, который к модели имеет слабое отношение, мини оружия, туфельки всякие и прочие и чистка уже от этих моделей был наш следующий этап эволюции.
Первый запуск приложения, скриншот с теста
К сожалению никакого материала особо не осталось, а восстанавливать проект ради демонстрации работы как-то не очень не хочется. Я постарался собрать демо-версию сборщика, в которой только визуальная часть.
Демо-версия приложения для работы с сборщиком
Как это работает
В целом работоспособность логика приложения была сделана таким образом. Сервер > Коллекция > Воркшоп контейнер > Локальные контейнеры (сами модели, текстуры). Схема немного замудренная, в ней и разобраться на этапе проектирования было сложно.
Схема
- Сервер - это сервер, к которому принадлежит коллекция. Предполагалось, что коллекция будет иметь определенное напраление, к примеру - коллекция с оружием, коллекция с одеждой, коллекция с приватками и т.д.
- Коллекция - это набор воркшоп контейнеров, которые в свою очередь содержат в себе локальные контейнеры. Сама коллекция принадлежит только одному серверу, и она имеет прямую связь с коллекциями в стиме. Создание коллекций было автоматическим, связь была по ID коллекции в стиме, взаимодействие с ним было через Puppeteer.
- Воркшоп контейнер - это набор локальных контейнеров, которые в свою очередь содержат в себе модели и текстуры. Изначально была идея сделать контейнеры связанными с множеством коллекций, но в итоге было решено, что это будет не очень удобно. Воркшоп контейнеры тоже создавались автоматически, связь была по ID воркшоп контейнера в стиме, а взаимодействие происходило через gma, который в свою очередь был упакован через gmad_linux и загружался или обновлялся через gmpublish. Если контейнер был новый, то создавалась связь через puppeteer с родительской коллекцией.
- Локальный контейнер - это виртуальная сущность, к которой были привязаны файлы. Это больше сущность, которая позволяла легко и быстро чистить воркшоп контейнеры. Да, локальный контейнер мог быть связан с несколькими воркшоп контейнерами. При подготовке файлов к загрузке все файлы вгружаются во временную папку и если есть materials или sound, то оригиналы из папок переносятся в новый невидимый для админа воркшоп контейнер, а из временной папки все файлы из этих папок сжимаются. Таким образом образуя одновременно на выходе две коллекции - HD и SD, высокого и низкого разрешения соответственно.
По поводу локального контейнера стоит подробнее рассказать, так как штука действительно заслуживает большего внимания, чем все остальное. На сервер мы загружали не .gma, а .zip архив с тем же содержанием. Из архива ZIP удалялись все файлы *.lua, папка models чистилась от файлов dx9 и другого мусора, а с текстурами проводилась отдельная работа - нюанс в том, что я решил ограничиться для оригинала текстур vtf до 1024 пикселей, а для сжатой версии 256. Однако в один момент вскрылась неожиданная проблема - vtf это еще и анимированные текстуры, и пришлось изучать каким образом я могу переконвертировать анимацию в 1024x1024 и 256x256. Я далеко не специалист по C++, пришлось изрядно изнасиловать мозг, чтобы получить рабочий скрипт. Мне помогли библиотеки VTFLib и Magick++, которые позволили мне конвертировать vtf в png, а затем уже png в vtf. Тоже самое происходило с папкой sound, благо формат wav и с ним легко работать.
После того, как все файлы были готовы к загрузке, они отправлялись во временную папку, а затем уже в воркшоп. Все это происходило через gmad_linux и gmpublish. После загрузки воркшоп контейнера, админ вручную перезагружает сервер через веб-панель, либо сервер сам перезагрузится, когда игроков не будет.
Что не так
В целом сборщик работал, но было несколько проблем, которые не давали ему работать на 100%.
- Очевидно, что стабильность зависит от работоспособности серверов стима. Если сервера стима не работают, то и сборщик не работает.
- На тот момент у меня не было опыта в работе с Puppeteer, поэтому я не мог быть уверен в том, что он будет работать стабильно.
- Не было никакой защиты от дурака. Если администратор не знает что делает, то он может легко сломать сервер. Например, если он загрузит воркшоп контейнер с моделями, которые уже есть на сервере, то он просто перезапишет их, а если он загрузит воркшоп контейнер с моделями, которые уже есть на сервере, но с другими текстурами, то он просто сломает контейнеры. Единственный кто успел потестить сборщик - это Женя, и он был в курсе всех этих нюансов. Но в целом, если бы я продолжил работу над проектом, то я бы добавил защиту от дурака, Женя тоже не вечный.
- По какой-то причине gmad_linux не мог работать с файлами, которые в названии содержали КАПС, а gmpublish ругался на это. Такие файлы просто не загружались. Я не знаю, как это исправить, но это было очень странно - редактировались такие файлы вручную.
Что дальше
Теперь сборщик вместе с шафтом канули в лету, в принципе как и многие другие аспекты. Может быть как нибудь мои руки доберуться до релиза сборщика в опенсурс, но это не точно. В целом, я доволен тем, что сделал, и я думаю, что это был хороший опыт. Если вдруг такое произойдет и я высру репозиторий, то линк будет в этой главе.