Git no puede manejar juegos... Así que Epic creó Lore

BBetter Stack
컴퓨터/소프트웨어창업/스타트업게임/e스포츠

스크립트

00:00:00Epic Games construyó su propio sistema de control de versiones porque se hartó de Git.
00:00:05Lo construyeron en Rust y luego lo lanzaron gratis. Se llama Lore. Así que sí,
00:00:10la compañía detrás de Fortnite creó una alternativa a Git. Pero Git sigue siendo genial,
00:00:15obviamente. Pero Git fue creado para código. Principalmente archivos de texto, muchos archivos pequeños,
00:00:21cambios que suelen ser de unas pocas líneas a la vez. Los juegos son básicamente lo opuesto a eso. Entonces,
00:00:26¿cómo se compara Lore con Git y cómo trabajamos con él? Vamos a descubrirlo.
00:00:35Ahora, a estas alturas, tenemos texturas masivas, archivos de audio, videos, modelos 3D,
00:00:41y todo tipo de activos binarios que pueden pesar cientos de megabytes o incluso varios gigabytes cada uno. Y
00:00:47una vez que esos archivos empiezan a cambiar, las cosas se ponen realmente difíciles. Tu repositorio crece, los clones se vuelven más lentos,
00:00:53el historial se vuelve enorme. Y eventualmente alguien dice: “está bien, quizás deberíamos usar Git LFS”. Git LFS ayuda,
00:01:01pero también se siente como una solución improvisada añadida a un sistema que nunca fue diseñado para este tipo de datos.
00:01:06Luego tienes cuotas, límites de ancho de banda y activos antiguos dando vueltas en el historial. Así que
00:01:12muchos estudios usan Perforce. Y para ser justos, Perforce funciona. Hay una razón por la que tantos estudios
00:01:18de juegos lo usan, pero es caro. Puede volverse complicado. Y una vez que tu configuración crece lo suficiente,
00:01:24alguien usualmente termina siendo la persona que lo mantiene vivo. Esta es la cosa que Lore fue
00:01:29diseñada para arreglar. Si disfrutas programar herramientas para acelerar tu flujo de trabajo, asegúrate de suscribirte.
00:01:35Tenemos videos saliendo todo el tiempo. Muy bien. Ahora, en lugar de solo hablar de Lore,
00:01:39es genial. Déjame ponerlo en marcha. Déjame mostrarte cómo funciona. La demostración comienza con un comando
00:01:44de instalación y una bandera de demostración, que ejecutaremos aquí mismo. Y eso es todo. Unos segundos después,
00:01:51tengo un servidor Lore ejecutándose localmente. Sin cuenta en la nube, sin claves, sin configuración de certificados. Se está ejecutando aquí
00:01:57en estos puertos. Y solo para probar que realmente está vivo, puedo simplemente acceder al punto de salud justo
00:02:03aquí. Y voy a hacer eso en esta terminal. Y listo. Está vivo. Está funcionando.
00:02:08No hay servicios en segundo plano que deba conectar manualmente. No hay token de autenticación que generar. No hay
00:02:14asistente de configuración. Simplemente comienza. Ahora, déjame crear un repositorio. Así que voy a crear una carpeta,
00:02:22¿verdad? Y vamos a crear este repositorio. Y ahora voy a crear un archivo binario grande
00:02:27y confirmarlo, ¿verdad? Esto es solo un archivo ficticio, ¿cierto? Pero vamos a crear un archivo más grande. Estoy ejecutando
00:02:32DD aquí para la duplicación de datos. Ahora, en lugar de tratar ese archivo de 100 megabytes como un objeto gigante,
00:02:40Lore lo divide en fragmentos más pequeños. Esos fragmentos son hasheados, comprimidos con Zstandard y almacenados en un
00:02:47árbol Merkle direccionado por contenido. Si la mayor parte del archivo permanece igual, Lore no necesita guardar otra copia completa
00:02:52de todo el asunto. Puede reutilizar los fragmentos que ya tiene y solo almacenar las partes que cambiaron.
00:02:58Eso es un ajuste mucho mejor para un activo binario grande. Justo después de que termina la confirmación, puedes ver el
00:03:04estado local que se creó en el disco. Ahora hay un directorio de Lore aquí con la configuración y los
00:03:10metadatos. Muy bien, ahora que tenemos eso, creemos una rama. Vale, puedo ejecutar “Lore branch create”
00:03:17y darle nombre a la rama. Funciona casi igual que Git. Así que cambiemos a ella. Vamos a hacer un pequeño
00:03:24cambio aquí. Crearé un archivo de texto rápido y lo confirmaré en esta rama. Así que modifico, luego podemos prepararlo,
00:03:31y luego podemos confirmarlo, ¿cierto? El mismo flujo es más o menos igual que en Git. Ahora voy a cambiar
00:03:37de vuelta. Y eso fue básicamente instantáneo. Lo otro importante es que nada de eso requirió un
00:03:44viaje a ningún servidor. Preparar, confirmar, ramificar, cambiar, comparar, todo eso sucede localmente. Así que
00:03:50aunque Lore tiene un servidor central, tu trabajo diario habitual sigue siendo rápido y puedes seguir
00:03:56trabajando sin conexión. Simplemente hace que todo se sienta ligero. Ahora la pregunta es, está bien,
00:04:02¿a dónde van todos los datos? En esta demostración, todo es temporal. Así que cuando detengo el servidor,
00:04:08los datos desaparecen. Eso es porque solo estoy usando el modo de demostración. En una configuración real, ejecutarías “Lore server”
00:04:15con un archivo de configuración y almacenamiento persistente. Los mismos comandos de CLI y el flujo de trabajo local permanecen exactamente
00:04:21igual. Solo apuntas el servidor a directorios reales o almacenamiento de objetos en lugar de desechar
00:04:27esa carpeta temporal. Ahora, con Git, Git te da un historial de instantáneas del proyecto. Aunque
00:04:34internamente hace mucha optimización inteligente, Lore está diseñado alrededor de la fragmentación y la deduplicación desde
00:04:40el principio. Así que para un proyecto grande y pesado en activos, no tiene que tratar cada nueva versión del archivo
00:04:47como un objeto gigante completamente separado. Lore también puede hidratar archivos bajo demanda, así que puedes trabajar con
00:04:53el repositorio que contiene una gran cantidad de datos sin descargar cada activo desde el primer día.
00:04:59Descargas lo que realmente necesitas para la parte del proyecto en la que estás trabajando.
00:05:03Ahora, una cosa que fue un poco confusa cuando se lanzó Lore fue si es centralizado o
00:05:08distribuido. Es centralizado. Hay un servidor de registro, pero la mayor parte del trabajo que estamos haciendo
00:05:15ocurre localmente. Así que en la práctica, se sitúa en algún lugar entre Perforce y Git. Obtienes control central
00:05:22y gestión de acceso, pero las operaciones locales siguen siendo rápidas y no dependen de que el servidor esté
00:05:28disponible cada segundo. También hay algunas diferencias agradables. Lore tiene licencia MIT, el protocolo
00:05:34es de código abierto y hay SDKs para múltiples lenguajes, lo que facilita mucho crear scripts y
00:05:39construir herramientas alrededor. Ahora, probablemente sea un buen momento para ser realista. Lore no es algo que yo
00:05:45reemplazaría por una configuración de producción de Perforce mañana. Todavía está en pre-1.0. Epic Games dice que las APIs pueden cambiar
00:05:52antes del primer lanzamiento estable, y el proyecto claramente sigue evolucionando. Tampoco hay interoperabilidad
00:05:58con Git en este momento, y no puedes simplemente apuntar Lore a un repositorio Git existente y traer todo el
00:06:03historial. También es autoalojado. No existe un servicio alojado donde creas una cuenta,
00:06:09envías tu repositorio y listo. Y la aplicación de escritorio que quizás veas flotando por ahí no está incluida en el
00:06:15lanzamiento de código abierto. Lo que obtienes es la biblioteca central, el servidor, la CLI y los SDKs. Esa interfaz gráfica no es
00:06:22parte de eso. Luego, por supuesto, el rendimiento. ¿Cómo funciona esto? Epic dice que Lore puede manejar repositorios
00:06:28enormes sin ralentizarse de la forma en que lo hacen otros sistemas. Y Epic obviamente tiene experiencia con
00:06:33algunos proyectos muy grandes. Pero en este momento, la mayoría de esas afirmaciones provienen de Epic. Todavía
00:06:39no hay puntos de referencia independientes sólidos. Así que el rendimiento parece prometedor, pero hasta que realmente
00:06:45comencemos a probar esto, es difícil ver cómo funciona. ¿Deberías usarlo? Bueno, es divertido para
00:06:50jugar un poco. ¿Estás haciendo juegos? ¿Estás construyendo proyectos masivos? Está bien, para un nuevo proyecto, quizás.
00:06:56Si solo quieres ver hacia dónde podría ir el control de versiones para activos binarios grandes, vale la pena
00:07:01probarlo. Pruébalo en algo no crítico, juega con él, mira cómo funciona, mira cómo es el flujo.
00:07:07El punto más importante aquí no es si Lore reemplaza a Git o Perforce pronto. El punto más importante es que
00:07:14el control de versiones dejó de ser un problema resuelto una vez que los proyectos comenzaron a enviarse con grandes cantidades de
00:07:19datos binarios. Git ganó para texto y archivos pequeños. Lore está tratando de resolver algo que viene después de eso.
00:07:27Y honestamente, gane o no, sigue siendo una dirección realmente genial. Si disfrutas consejos y trucos
00:07:32de programación como este, asegúrate de suscribirte al canal de Betterstack. Nos vemos en otro video.

핵심 요약

Lore ofrece una alternativa de código abierto a Git y Perforce que optimiza el manejo de archivos binarios masivos mediante fragmentación y almacenamiento direccionado por contenido, aunque actualmente se encuentra en fase experimental.

하이라이트

  • Epic Games desarrolló Lore, un sistema de control de versiones escrito en Rust diseñado específicamente para gestionar grandes activos binarios como texturas, audio y modelos 3D.

  • Git utiliza una arquitectura basada en texto que se vuelve ineficiente con archivos de gran tamaño, lo que obliga a depender de extensiones como Git LFS o sistemas costosos como Perforce.

  • Lore fragmenta archivos grandes y utiliza un árbol Merkle direccionado por contenido para almacenar solo los cambios, lo que optimiza significativamente el espacio en disco.

  • El flujo de trabajo local de Lore incluye funciones como ramificación, confirmación y comparación que operan instantáneamente sin necesidad de conexión a un servidor central.

  • Lore permite la hidratación de archivos bajo demanda, lo que evita la descarga de todo el historial del repositorio antes de comenzar a trabajar en un proyecto.

  • El proyecto se encuentra actualmente en una etapa de desarrollo pre-1.0 y carece de interoperabilidad directa con Git o de una interfaz gráfica oficial.

타임라인

Limitaciones de Git en el desarrollo de juegos

  • Git fue diseñado para archivos de texto y cambios incrementales pequeños.
  • Los juegos actuales dependen de activos binarios masivos que superan los cientos de megabytes.
  • Git LFS actúa como una solución improvisada y Perforce es una alternativa estándar pero costosa y compleja.

El control de versiones tradicional falla al manejar grandes volúmenes de datos binarios típicos de la industria del videojuego. A medida que los archivos crecen, los repositorios se vuelven lentos y el historial se vuelve inmanejable. Aunque estudios recurren a Perforce, este suele requerir mantenimiento dedicado y altos costos, motivando la creación de una herramienta específica para estos desafíos.

Arquitectura y funcionamiento de Lore

  • Lore divide archivos grandes en fragmentos comprimidos con Zstandard.
  • El sistema utiliza un árbol Merkle direccionado por contenido para la gestión de datos.
  • Las operaciones básicas como ramificación y confirmación ocurren localmente de forma instantánea.

Lore elimina la necesidad de configuraciones complejas mediante un servidor local liviano. Al dividir archivos de 100 megabytes o más en fragmentos, el sistema reutiliza partes del archivo que permanecen sin cambios en lugar de guardar versiones completas. Esto permite que el flujo de trabajo diario sea rápido y funcione sin conexión, incluso cuando hay un servidor central para la gestión de accesos.

Diferenciación y estado actual del proyecto

  • Lore permite la hidratación bajo demanda, descargando únicamente los activos necesarios.
  • El software es de código abierto con licencia MIT e incluye SDKs para facilitar la integración.
  • El proyecto se encuentra en pre-1.0 y no permite migrar repositorios de Git directamente.

Lore se posiciona entre Perforce y Git al combinar control centralizado con agilidad local. Aunque su rendimiento promete manejar repositorios masivos, no existen puntos de referencia independientes que confirmen estas capacidades fuera de las pruebas de Epic Games. Actualmente, su uso se recomienda para proyectos no críticos, sirviendo como una experimentación sobre el futuro del control de versiones para datos pesados.

커뮤니티 글

모든 글 보기