Что такое lore и зачем он нужен
Представьте: у вас игра, над которой работают 200 человек. Художники заливают ассеты по 500 мегабайт, программисты коммитят код каждый час, и всё это должно лететь по сети без задержек. Знакомая ситуация? Мне — да. И именно поэтому я обратил внимание на Lore.
Epic Games выкатили Lore — open source систему контроля версий, заточенную под масштаб. Не очередной Git-форк, а что-то с нуля. Причём для мира, где код — это только 10% от всего, что хранится в репозитории.
Что такое lore
Lore — это распределённая система контроля версий (version control system, VCS — инструмент, который отслеживает изменения в файлах и позволяет команде работать над одним проектом без конфликтов), созданная Epic Games и открытая для сообщества. Главная ставка — масштабируемость: и по объёму данных, и по размеру команды.
ТРАДИЦИОННЫЙ VCS vs LORE ───────────────────────── Традиционная система: ┌─────────────────────────────────────┐ │ Git-сервер │ │ ┌─────┐ │ │ │ 1TB │ ◀── Все ассеты тут │ │ └─────┘ │ │ Проблема: клонирование = 10 часов │ └─────────────────────────────────────┘ Lore: ┌─────────────────────────────────────┐ │ Распределённое хранилище │ │ ┌─────┐ ┌─────┐ ┌─────┐ │ │ │300GB│ │300GB│ │400GB│ │ │ └─────┘ └─────┘ └─────┘ │ │ Параллельная загрузка фрагментов │ └─────────────────────────────────────┘
Ключевое отличие: Lore не пытается впихнуть все бинарные ассеты (текстуры, модели, звуки) в стандартную модель Git. Вместо этого — своя архитектура, заточенная под работу с тяжёлым контентом.
Зачем нужна новая система контроля версий
Git — прекрасный инструмент. Но давайте честно: он проектировался для текста. Кода. Мелких файлов. Когда вы пытаетесь запихнуть туда двухгигабайтные текстурные паки, начинается боль:
- Клонирование репозитория занимает часы
- Каждый коммит с тяжёлыми ассетами — это лаг
- Fetch и push (получение и отправка изменений на сервер) превращаются в русскую рулетку
- Художники страдают больше всех — они не программисты, им непривычно разбираться с конфликтами merge
РОСТ ПРОЕКТА И НАГРУЗКА НА VCS ────────────────────────────── Размер репозитория: │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ │ ╱ │──┬──┬──┬──┬──┬──┬──┬──┬──┬──▶ 1GB 5GB 10GB 50GB 100GB Время клонирования: │ ╲ │ ╲ │ ╲ │ ╲ │ ╲ │ ╲ │ ╲ │ ╲ │ ╲ │ ╲ │ ╲ │──┬──┬──┬──┬──┬──┬──┬──┬──┬──▶ 1GB 5GB 10GB 50GB 100GB Git ломается на больших объёмах
Epic Games с их Unreal Engine и Fortnite (тысячи разработчиков, петабайты контента) ударились в эту стену. И вместо того чтобы костылить Git, написали своё решение.
Чем lore отличается в масштабе
Lore заточен под три вещи:
1. Работа с бинарными ассетами из коробки
Не нужно настраивать Git LFS (Large File Storage — расширение Git для больших файлов), писать скрипты очистки или объяснять художникам, почему нельзя коммитить текстуры напрямую. Lore понимает, что бинарные файлы — это не баг, а норма.
2. Распределённая архитектура
Вместо одного сервера, куда все стучатся, Lore использует подход, где данные могут быть размазаны (sharded) по нескольким узлам. Команда получает только то, что ей нужно, а не весь репозиторий целиком.
3. Оптимизация для совместной работы
Художник и программист работают в разных частях проекта. Lore позволяет им не мешать друг другу, не создавать гигабайтных коммитов и не ждать, пока кто-то другой зальёт свои ассеты.
Где это применять
Lore не для всех. Вот сценарии, где он имеет смысл:
- Gamedev — очевидный кейс. Большие команды, тяжёлые ассеты, частые билды.
- Визуальные эффекты и анимация — киностудии, которые работают с терабайтами видеоматериала.
- Архитектурная визуализация — когда BIM-модели весят больше, чем весь ваш код.
- Любой проект с «не-git-friendly» контентом — если вы уже пытались прикрутить Git LFS и плакали, Lore может помочь.
Кому подойдёт и что проверить перед внедрением
Подойдёт, если:
- У вас команда 50+ человек
- Репозиторий больше 50 гигабайт
- Художники и разработчики работают в одном проекте
- Вы готовы к тому, что Lore — это не Git, придётся переучиваться
Стоит подумать дважды, если:
- У вас маленький проект (Git справится)
- Команда привыкла к Git и не хочет миграции
- Нет ресурсов на пилотное внедрение
Перед миграцией я бы рекомендовал:
- Попробовать Lore на тестовом проекте
- Замерить скорость операций (clone, fetch, push) на ваших объёмах данных
- Проверить интеграцию с вашим CI/CD (непрерывная интеграция — автоматическая сборка и тестирование кода при каждом изменении)
- Убедиться, что команда понимает, зачем вы это делаете
Выводы
Lore выглядит как специализированный ответ на проблему, с которой Git справляется всё хуже по мере роста ассетов и команды. Если у вас большой контентный проект, Lore стоит проверить в пилоте. Если проект небольшой, Git по-прежнему остаётся разумным выбором.
Ссылки
- Lore — официальный сайт — описание системы и основные возможности
- Lore на GitHub — исходный код и релизы
- Документация Lore — руководство по использованию и внедрению
Дмитрий Полухин — продуктовый дизайнер. Пишу про разработку, AI и дизайн интерфейсов. Обо мне, контакты и профили.