⏱️ Lectura: 12 min
Epic Games, la empresa detrás de Unreal Engine y Fortnite, liberó Lore, un sistema de control de versiones open source con licencia MIT diseñado para escalar a repositorios gigantes que combinan código con archivos binarios pesados.
📑 En este artículo
No es otro clon de Git: Lore apuesta por almacenamiento direccionado por contenido, árboles de Merkle y descargas a la carta para resolver un problema que arrastra cualquier estudio de videojuegos o entretenimiento: versionar terabytes de texturas, modelos y audio sin que el flujo de trabajo se desplome.
TL;DR
- Epic Games liberó Lore, un sistema de control de versiones open source bajo licencia MIT, mantenido por la propia empresa.
- Lore usa almacenamiento direccionado por contenido y árboles de Merkle para garantizar la integridad criptográfica del historial.
- Está optimizado para archivos binarios grandes: fragmentación (chunking), deduplicación y descargas a la carta.
- Ofrece SDKs en C/C++, C#, Rust, Go, Python y JavaScript, además de una CLI completa.
- Las ramas son referencias ligeras y mutables; crear o cambiar de rama no duplica los datos subyacentes.
- Se posiciona como alternativa abierta a Perforce, el estándar propietario en estudios de videojuegos.
- El código vive en el GitHub de Epic Games y la comunidad se coordina en Discord.
Qué pasó: Epic abre su propio control de versiones
Epic Games anunció Lore como un proyecto íntegramente de código abierto, publicado bajo la permisiva licencia MIT. La empresa lo describe como un sistema pensado para ofrecer escalabilidad poco común tanto en volumen de datos como en tamaño de los equipos, ideal para proyectos que mezclan código con grandes recursos binarios y que necesitan satisfacer por igual a desarrolladores y a artistas.
El movimiento es relevante por quién lo hace. Epic no es un actor cualquiera en el mundo del software: mantiene Unreal Engine, uno de los motores gráficos más usados de la industria, y opera Fortnite, un juego con repositorios y pipelines de producción descomunales. Que una empresa con ese volumen de activos abra su infraestructura de versionado, en lugar de venderla como producto cerrado, marca una diferencia con la tradición del sector.
El argumento de Epic es explícito: para que un ecosistema sea verdaderamente abierto no debe construirlo una sola empresa, sino crearse de forma colaborativa y sobre estándares abiertos. Por eso Lore se publica con licencia MIT y su desarrollo ocurre a la vista de todos en el GitHub de Epic Games, con la comunidad coordinándose en Discord.
📌 Nota: Lore es un sistema centralizado, no distribuido como Git. Esa decisión de diseño está pensada para equipos grandes que comparten un mismo origen de verdad, no para el modelo de cada quien con su copia completa del historial.
Qué es Lore y por qué reinventa el control de versiones
Para entender Lore conviene recordar dónde falla el control de versiones tradicional cuando hay binarios de por medio. Git fue diseñado para texto: calcula diferencias línea por línea y comprime de maravilla el código fuente. Pero un archivo binario (una textura de 200 MB, un modelo 3D, un clip de audio) no tiene un “diff” legible. Cada cambio obliga a guardar prácticamente una copia nueva, y el repositorio crece sin control hasta volverse inmanejable.
La solución parche más conocida es Git LFS (Large File Storage), que reemplaza los binarios por punteros y guarda el contenido real en un servidor aparte. Funciona, pero agrega fricción: configuración extra, un servidor adicional y un modelo mental partido en dos. En la industria del videojuego el estándar de facto ha sido históricamente Perforce (Helix Core): centralizado, robusto con binarios y con bloqueo de archivos, pero propietario, costoso de licenciar y atado a un proveedor. El propio Epic ha sido, durante años, un usuario intensivo de Perforce.
Lore intenta quedarse con lo mejor de ambos mundos: la centralización y el manejo de binarios de Perforce, pero como software libre y con una arquitectura moderna basada en contenido. Es, en esencia, un control de versiones que trata los activos pesados como ciudadanos de primera clase, no como un añadido incómodo.
Cómo funciona la arquitectura de Lore
La arquitectura de Lore se apoya en varias ideas que, combinadas, explican su promesa de escalabilidad. La pieza central es el almacenamiento direccionado por contenido: los datos del repositorio se identifican por el hash de su contenido y se organizan en un árbol de Merkle. Esto permite comparaciones rapidísimas (si dos hashes coinciden, el contenido es idéntico) y comprobaciones de integridad casi gratuitas, además de reutilizar todo el historial y las ramas sin duplicar bytes.
Sobre eso se construye una cadena de revisiones inmutable. La firma hash de cada versión se deriva de su estado completo, incluidos los hashes de las versiones padre y los hashes de los datos que contiene. El resultado es una cadena con integridad criptográfica: una fuente de verdad a prueba de manipulaciones, donde alterar cualquier revisión pasada invalidaría toda la cadena posterior. El concepto es el mismo que sostiene a Git y a las cadenas de bloques, llevado aquí al terreno de los activos grandes.
Para los binarios entra en juego el almacenamiento fragmentado (chunking): los archivos se parten en fragmentos reutilizables con búsqueda indexada. Si cambias un trozo pequeño de un archivo enorme, solo se transfiere y almacena ese fragmento, no el archivo completo. Es deduplicación a nivel de bloque, y es lo que hace viable iterar sobre activos pesados sin saturar la red ni el disco.
Finalmente, la hidratación a la carta y los espacios de trabajo dispersos evitan el problema clásico de tener que descargar el repositorio entero. El workspace se mantiene ligero y obtiene los datos de cada archivo solo cuando realmente se necesitan. Una arquitectura basada en servicios, con una capa de caché delante del almacenamiento duradero, escala el rendimiento entre equipos y repos grandes. Las ramas, por su parte, son referencias ligeras y mutables: crearlas o cambiar de una a otra apenas cuesta, porque no se copian los datos subyacentes.
graph LR
A["Archivo o commit"] --> B["Hash de contenido"]
B --> C["Árbol de Merkle"]
C --> D["Cadena de revisiones inmutable"]
D --> E["Servicio central + caché"]
E --> F["Workspace disperso (hidratación a la carta)"]💭 Clave: el chunking más la deduplicación significan que el costo de versionar un binario gigante deja de ser proporcional a su tamaño total y pasa a ser proporcional a lo que realmente cambia entre versiones.
Datos, SDKs y plataformas
Lore no se limita a una CLI. Una de sus apuestas más fuertes es la API de superficie completa: se puede ampliar, personalizar e integrar desde C/C++, C#, Rust, Go, Python o JavaScript. Esa cobertura de lenguajes es una señal clara de intención: Epic quiere que Lore se incruste dentro de herramientas, editores y pipelines de automatización, no que se use solo desde la terminal.
El ecosistema publicado en el GitHub de Epic Games incluye la biblioteca, el servidor y la CLI de Lore, además de SDKs dedicados para JavaScript, Python, C# y Go. Empezar en modo local toma minutos y, a partir de ahí, se puede escalar a una arquitectura de servicio con caché para equipos grandes.
Como Lore es muy reciente, la forma más fiable de instalarlo es construyéndolo desde el repositorio oficial. El flujo base es el mismo en los tres sistemas operativos:
# Windows (PowerShell)
git clone https://github.com/EpicGames/lore.git
cd lore
# seguir las instrucciones de build de la documentación oficial
# macOS
git clone https://github.com/EpicGames/lore.git
cd lore
# seguir las instrucciones de build de la documentación oficial
# Linux
git clone https://github.com/EpicGames/lore.git
cd lore
# seguir las instrucciones de build de la documentación oficialUna vez disponible la CLI, el flujo de trabajo conceptual se parece a esto (sintaxis ilustrativa según el modelo descrito por Epic):
# Inicializar un repositorio local
lore init mi-proyecto
cd mi-proyecto
# Crear una rama ligera para experimentar
lore branch feature/nueva-textura
# Registrar cambios en la cadena de revisiones inmutable
lore commit -m "Agrega assets del nivel 3"
# Sincronizar con el servicio central (hidratación a la carta)
lore sync⚠️ Ojo: al ser un proyecto en etapa temprana, los comandos exactos, los nombres de los repos y las opciones de build pueden cambiar. Confirmá siempre contra la documentación oficial antes de adoptarlo en producción.
Impacto y análisis para LATAM
¿Por qué debería importarle esto a un desarrollador en América Latina que no hace videojuegos AAA? Por dos razones. La primera es que el problema que resuelve Lore es cada vez más común fuera del gaming: equipos de machine learning que versionan datasets y modelos de varios gigabytes, estudios de diseño y video, proyectos de realidad aumentada y cualquier flujo que mezcle código con activos pesados. La segunda es el costo: Perforce es caro, y para un estudio pequeño o una startup de la región una alternativa MIT puede ser la diferencia entre tener un pipeline serio o improvisar con Git LFS.
El control de versiones centralizado de Lore también encaja con realidades de conectividad. La hidratación a la carta y los espacios de trabajo dispersos significan menos ancho de banda gastado en descargar lo que no se va a tocar, algo nada trivial cuando la oficina no tiene fibra de un gigabit. Y la deduplicación a nivel de fragmento reduce el almacenamiento real necesario en el servidor, abaratando la infraestructura.
El gran riesgo, como con todo proyecto nuevo, es la madurez. Lore compite contra herramientas con décadas de rodaje y ecosistemas enormes. Su éxito dependerá de que Epic mantenga el impulso, de que la comunidad adopte y contribuya, y de que aparezcan clientes gráficos, integraciones con IDEs y casos de producción más allá de la propia Epic. La licencia MIT y la API multilenguaje juegan a favor; la curva de adopción y la falta de tooling de terceros, en contra.
Qué sigue
Lo más interesante a vigilar es la hoja de ruta y la tracción de la comunidad. Las preguntas abiertas que la propia documentación de Lore reconoce —compatibilidad con bloqueo de archivos, infraestructura necesaria para correr un servidor, manejo de conflictos de fusión, disponibilidad de un cliente de escritorio y nivel de madurez para producción— son exactamente las que definirán si Lore pasa de ser una curiosidad técnica a una opción real.
Si Epic integra Lore de forma nativa en Unreal Engine y lo usa internamente a gran escala, ese sería el respaldo más fuerte posible: un control de versiones validado por uno de los pipelines de producción más exigentes del mundo. Por ahora, lo prudente es probarlo en proyectos paralelos, evaluar su rendimiento con tus propios activos y seguir el repositorio en GitHub para ver cómo evoluciona. La promesa es ambiciosa; el tiempo dirá si la cumple.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es Lore?
Lore es un sistema de control de versiones centralizado, open source y mantenido por Epic Games. Está optimizado para repositorios grandes que combinan código con archivos binarios pesados, usando almacenamiento direccionado por contenido, árboles de Merkle y una cadena de revisiones inmutable.
¿Qué licencia tiene Lore?
Lore se publica bajo licencia MIT, una de las licencias de software libre más permisivas. Eso permite usarlo, modificarlo e integrarlo en proyectos comerciales sin las restricciones ni los costos de una herramienta propietaria como Perforce.
¿En qué se diferencia Lore de Git?
Git es distribuido y está optimizado para texto; cada clon tiene el historial completo. Lore es centralizado, trata los binarios grandes como prioridad mediante fragmentación y deduplicación, y permite hidratar datos a la carta para no descargar todo el repositorio de golpe.
¿Qué plataformas y lenguajes soporta?
Lore expone una API de superficie completa con SDKs para C/C++, C#, Rust, Go, Python y JavaScript, además de una CLI. La biblioteca, el servidor y los SDKs están publicados en el GitHub de Epic Games.
¿Lore está listo para producción?
Es un proyecto reciente. Aunque está respaldado por Epic Games, conviene tratarlo como tecnología en evolución: evaluarlo en entornos de prueba, revisar la documentación oficial y seguir su hoja de ruta antes de migrar flujos críticos.
¿Por qué Epic lo abrió en lugar de venderlo?
Epic argumenta que un ecosistema verdaderamente abierto debe construirse de forma colaborativa y sobre estándares abiertos, no por una sola empresa. Por eso liberó Lore con licencia MIT y desarrolla en abierto, invitando a la comunidad a contribuir desde el inicio.
Referencias
- Lore — sitio oficial — anuncio, documentación y documento de diseño del sistema (fuente original).
- GitHub de Epic Games — organización donde se publican la biblioteca, el servidor, la CLI y los SDKs de Lore.
- Merkle tree (Wikipedia) — fundamento del almacenamiento direccionado por contenido que usa Lore.
- Git — referencia de comparación para entender las diferencias de diseño.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios