Git لا يمكنه التعامل مع الألعاب... لذا قامت Epic ببناء Lore

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

스크립트

00:00:00قامت شركة Epic Games ببناء نظامها الخاص للتحكم في الإصدار لأنها سئمت من استخدام Git.
00:00:05لقد بنته باستخدام لغة Rust ثم أطلقته مجانًا. واسمه Lore. لذا، أجل،
00:00:10الشركة المطورة للعبة Fortnite بنت بديلاً لـ Git. لكن Git لا يزال رائعًا،
00:00:15بالطبع. لكن Git صُمم للكود البرمجي. في الغالب ملفات نصية، الكثير من الملفات الصغيرة،
00:00:21تغييرات عادة ما تكون بضعة أسطر في المرة الواحدة. الألعاب هي نقيض ذلك تمامًا. لذا
00:00:26كيف يقارن Lore بـ Git وكيف نتعامل معه؟ لنكتشف ذلك.
00:00:35في هذه المرحلة، لدينا قوام ضخمة، وملفات صوتية، وفيديوهات، ونماذج ثلاثية الأبعاد،
00:00:41وجميع أنواع الأصول الثنائية (Binary Assets) التي يمكن أن تصل أحجامها إلى مئات الميجابايتات أو حتى عدة جيجابايتات لكل ملف. وعندما
00:00:47تبدأ تلك الملفات في التغيير، تصبح الأمور فوضوية حقًا. ينمو المستودع، وتصبح عمليات الاستنساخ أبطأ،
00:00:53ويصبح السجل ضخمًا. وفي النهاية يقول أحدهم، حسنًا، ربما يجب أن نستخدم Git LFS. يساعد Git LFS،
00:01:01لكنه يبدو أيضًا كحل بديل أُضيف إلى نظام لم يُصمم أبدًا لهذا النوع من البيانات.
00:01:06ثم تواجه حصصًا نسبية، وقيودًا على عرض النطاق الترددي، وأصولًا قديمة عالقة في السجل. لذا
00:01:12تستخدم الكثير من الاستوديوهات Perforce. وللإنصاف، Perforce يعمل. هناك سبب يجعل الكثير من استوديوهات الألعاب
00:01:18تستخدمه، لكنه مكلف. ويمكن أن يصبح معقدًا. وبمجرد أن يصبح إعدادك كبيرًا بما يكفي،
00:01:24ينتهي الأمر عادة بشخص ما ليصبح المسؤول عن إبقائه يعمل. هذا هو الشيء الذي صُمم Lore
00:01:29بشكل أو بآخر لإصلاحه. إذا كنت تستمتع بأدوات البرمجة لتسريع سير عملك، تأكد من الاشتراك.
00:01:35لدينا فيديوهات تصدر طوال الوقت. حسنًا. الآن، بدلاً من مجرد الحديث عن Lore،
00:01:39إنه أمر رائع. دعني أشغله. دعني أريك كيف يعمل. يبدأ العرض التوضيحي بأمر تثبيت واحد
00:01:44وعلامة تجريبية (demo flag)، سنقوم بتشغيله هنا. وهذا كل شيء. بعد ثوانٍ قليلة،
00:01:51أصبح لدي خادم Lore يعمل محليًا. لا حساب سحابي، لا مفتاح، لا إعداد شهادات. إنه يعمل هنا
00:01:57على هذه المنافذ. ولإثبات أنه يعمل بالفعل، يمكنني فقط الاتصال بنقطة نهاية الفحص (health endpoint) هنا
00:02:03مباشرة. وسأفعل ذلك في هذه الطرفية. وها نحن ذا. إنه يعمل. إنه قيد التشغيل.
00:02:08لا توجد خدمات في الخلفية أحتاج إلى ربطها يدويًا. لا يوجد رمز مصادقة لإنشائه. لا يوجد
00:02:14معالج إعداد. إنه يبدأ فقط. الآن، دعني أنشئ مستودعًا. لذا سأنشئ مجلدًا،
00:02:22أليس كذلك؟ وسنقوم بإنشاء هذا المستودع. والآن سأنشئ ملفًا ثنائيًا كبيرًا
00:02:27وأقوم بعمل commit له، أليس كذلك؟ هذا مجرد ملف وهمي، لكن دعنا ننشئ ملفًا أكبر. أنا أشغل
00:02:32أمر DD هنا لتكرار البيانات. الآن، بدلاً من التعامل مع هذا الملف الذي يبلغ حجمه 100 ميجابايت ككائن واحد ضخم،
00:02:40يقوم Lore بتقسيمه إلى أجزاء أصغر. يتم تجزئة تلك الأجزاء، وضغطها باستخدام Z standard، وتخزينها في
00:02:47شجرة Merkle المعتمدة على المحتوى. إذا ظل معظم الملف كما هو، فلن يحتاج Lore إلى حفظ نسخة كاملة أخرى
00:02:52من الملف بالكامل. يمكنه إعادة استخدام الأجزاء التي يمتلكها بالفعل وتخزين الأجزاء التي تغيرت فقط.
00:02:58هذا مناسب بشكل أفضل بكثير للأصول الثنائية الكبيرة. بعد انتهاء عملية الـ commit مباشرة، يمكنك رؤية
00:03:04الحالة المحلية التي تم إنشاؤها على القرص. يوجد الآن دليل Lore هنا مع الإعدادات و
00:03:10البيانات الوصفية. حسنًا، الآن بعد أن حصلنا على ذلك، لننشئ فرعًا. حسنًا، يمكنني تشغيل Lore branch create
00:03:17وتسمية الفرع. إنه يعمل تمامًا مثل Git. لذا دعنا ننتقل إليه. لنقم بإجراء تغيير صغير
00:03:24هنا. سأنشئ ملفًا نصيًا سريعًا وأقوم بعمل commit له في هذا الفرع. لذا أقوم بالتعديل، ثم يمكننا تجهيزه (stage)،
00:03:31ثم يمكننا عمل commit له، أليس كذلك؟ التدفق هو نفسه تقريبًا كما في Git. الآن سأعود
00:03:37للفرع السابق. وكان ذلك فوريًا تقريبًا. الشيء المهم الآخر هو أنه لم يتطلب أي شيء من ذلك رحلة
00:03:44إلى أي خادم. التجهيز، والـ commit، والفرع، والتبديل، والمقارنة (diffing)، كل ذلك يحدث محليًا. لذا
00:03:50على الرغم من أن Lore لديه خادم مركزي، إلا أن عملك اليومي المعتاد لا يزال يبدو سريعًا ويمكنك مواصلة
00:03:56العمل دون اتصال. إنه يجعله يبدو خفيف الوزن. الآن السؤال يصبح، حسنًا،
00:04:02أين تذهب كل البيانات؟ في هذا العرض التوضيحي هنا، كل شيء مؤقت. لذا عندما أوقف الخادم،
00:04:08تختفي البيانات. هذا لأنني أستخدم وضع العرض التوضيحي فقط. في إعداد حقيقي، ستقوم بتشغيل خادم Lore
00:04:15مع ملف إعداد وتخزين دائم. تظل نفس أوامر واجهة سطر الأوامر (CLI) وسير العمل المحلي كما هي تمامًا.
00:04:21أنت فقط توجه الخادم إلى أدلة حقيقية أو وحدة تخزين كائنات بدلاً من التخلص
00:04:27من ذلك المجلد المؤقت. الآن مع Git، يمنحك Git سجلاً للقطات المشروع. على الرغم من أن
00:04:34Git يقوم داخليًا بالكثير من التحسين الذكي، فإن Lore مصمم حول التقطيع وإزالة التكرار من
00:04:40البداية. لذا بالنسبة لمشروع كبير مليء بالأصول، لا يتعين عليه التعامل مع كل إصدار جديد من الملف
00:04:47ككائن عملاق منفصل تمامًا. يمكن لـ Lore أيضًا تحميل الملفات عند الطلب بحيث يمكنك العمل مع
00:04:53المستودع الذي يحتوي على كمية هائلة من البيانات دون تنزيل كل أصل من اليوم الأول.
00:04:59أنت تسحب ما تحتاجه فعليًا للجزء من المشروع الذي تعمل عليه.
00:05:03الآن، أحد الأشياء المربكة قليلاً هنا عند إطلاق Lore هو ما إذا كان مركزيًا أم
00:05:08موزعًا. إنه مركزي. هناك خادم واحد للسجل، لكن معظم العمل الذي نقوم به
00:05:15يحدث محليًا. لذا من الناحية العملية، يقع في مكان ما بين Perforce و Git. تحصل على تحكم مركزي
00:05:22وإدارة وصول، لكن العمليات المحلية لا تزال تبدو سريعة ولا تعتمد على توفر الخادم
00:05:28في كل ثانية. هناك بعض الاختلافات الجميلة أيضًا. Lore مرخص برخصة MIT، والبروتوكول
00:05:34مفتوح المصدر، وهناك حزم تطوير برمجية (SDKs) للغات متعددة، مما يجعله أسهل بكثير في البرمجة
00:05:39وبناء الأدوات حوله. الآن، ربما تكون نقطة جيدة لنكون واقعيين هنا. Lore ليس شيئًا سأقوم باستبدال
00:05:45إعداد Perforce للإنتاج به غدًا. إنه لا يزال قبل الإصدار 1.0. تقول Epic Games إن واجهات البرمجة قد تتغير
00:05:52قبل أول إصدار مستقر، والمشروع يتطور بوضوح. لا يوجد أيضًا توافق مع Git
00:05:58في الوقت الحالي، ولا يمكنك فقط توجيه Lore إلى مستودع Git موجود ونقل السجل بالكامل.
00:06:03كما أنه مستضاف ذاتيًا. لا توجد خدمة مستضافة حيث تنشئ حسابًا،
00:06:09وتقوم برفع مستودعك، وتكون قد انتهيت. وتطبيق سطح المكتب الذي قد تراه يتجول ليس مدرجًا في
00:06:15الإصدار مفتوح المصدر. ما تحصل عليه هو المكتبة الأساسية، والخادم، وواجهة سطر الأوامر، و SDKs. تلك الواجهة الرسومية ليست
00:06:22جزءًا منه. ثم، بالطبع، الأداء. كيف يؤدي هذا؟ تقول Epic إن Lore يمكنه التعامل مع مستودعات ضخمة
00:06:28دون إبطاء بالطريقة التي تعمل بها الأنظمة الأخرى. ومن الواضح أن Epic لديها خبرة مع
00:06:33بعض المشاريع الكبيرة جدًا. لكن في الوقت الحالي، تأتي معظم هذه الادعاءات من Epic نفسها. لا
00:06:39يوجد حقًا معايير قياس مستقلة وموثوقة حتى الآن. لذا يبدو الأداء واعدًا، ولكن حتى نبدأ حقًا
00:06:45في اختبار هذا، من الصعب معرفة كيفية أدائه. هل يجب عليك استخدامه؟ حسنًا، إنه ممتع للتجربة
00:06:50معه. هل تصنع ألعابًا؟ هل تبني مشاريع ضخمة؟ حسنًا، بالنسبة لمشروع جديد، ربما.
00:06:56إذا كنت تريد فقط رؤية أين يمكن أن يتجه التحكم في الإصدار للأصول الثنائية الكبيرة، فإنه يستحق
00:07:01التجربة. اختبره على شيء غير حرج، وتجرب معه، وانظر كيف يعمل، وانظر كيف يبدو سير العمل.
00:07:07النقطة الأكبر هنا ليست ما إذا كان Lore سيحل محل Git أو Perforce في أي وقت قريب. النقطة الأكبر هي أن
00:07:14التحكم في الإصدار توقف عن كونه مشكلة محلولة بمجرد أن بدأت المشاريع في الشحن بكميات ضخمة من
00:07:19البيانات الثنائية. فاز Git للنصوص والملفات الصغيرة. يحاول Lore حل شيء يأتي بعد ذلك.
00:07:27وبصراحة، سواء نجح أم لم ينجح، فإنه لا يزال اتجاهًا رائعًا حقًا. إذا كنت تستمتع بنصائح
00:07:32وحيل البرمجة كهذه، فتأكد من الاشتراك في قناة Betterstack. نراكم في فيديو آخر.

핵심 요약

يوفر نظام Lore من Epic Games حلاً متخصصًا للأصول الثنائية في تطوير الألعاب من خلال التجزئة وإزالة التكرار، مما يتجاوز قيود Git التقليدية في التعامل مع الملفات الكبيرة.

하이라이트

  • قامت Epic Games بتطوير Lore، وهو نظام تحكم في الإصدار مبني بلغة Rust للتعامل مع الأصول الثنائية الكبيرة في مشاريع الألعاب.

  • يعتمد Lore على تقسيم الملفات الكبيرة إلى أجزاء صغيرة (Chunks) وضغطها عبر خوارزمية Zstandard لتخزينها في شجرة Merkle المعتمدة على المحتوى.

  • يسمح نظام Lore بتحميل الملفات عند الطلب، مما يتيح للمطورين العمل على المستودعات الضخمة دون تنزيل كافة البيانات مسبقًا.

  • يوفر Lore سير عمل محليًا سريعًا يماثل Git، مع دعم لعمليات الـ commit والتفرع والتبديل دون الحاجة للاتصال بخادم مركزي في كل خطوة.

  • يأتي المشروع بترخيص MIT مفتوح المصدر ويتضمن حزم تطوير برمجية (SDKs) متعددة اللغات، رغم أنه لا يزال في مرحلة ما قبل الإصدار 1.0 ولا يدعم التوافق المباشر مع Git حاليًا.

타임라인

محدودية أدوات التحكم الحالية في تطوير الألعاب

  • يصمم Git خصيصًا للكود البرمجي النصي، مما يجعله غير مناسب للأصول الثنائية الضخمة في الألعاب.
  • تعتمد استوديوهات الألعاب حاليًا على حلول مثل Git LFS أو Perforce، ولكل منها عيوب تتعلق بالتكلفة أو تعقيد الإدارة.
  • تؤدي الملفات الثنائية الكبيرة التي تصل إلى عدة جيجابايتات إلى بطء عمليات الاستنساخ وتضخم سجل المستودعات.

تتطلب الألعاب الحديثة التعامل مع قوام ضخمة، ملفات صوتية، وفيديوهات تتجاوز طبيعة Git. بينما يعد Git LFS حلاً بديلاً، إلا أنه يواجه حصصًا نسبية وقيودًا في عرض النطاق الترددي. في المقابل، يظل Perforce الخيار الأكثر شيوعًا رغم تكلفته العالية والحاجة لمسؤولين متخصصين لصيانته.

آلية عمل Lore وسير العمل المحلي

  • يتم تثبيت خادم Lore وتشغيله محليًا دون الحاجة لإعدادات سحابية معقدة أو مصادقة خارجية.
  • يعيد Lore استخدام أجزاء الملفات الثابتة عبر شجرة Merkle، مما يقلل من حجم التخزين المطلوب.
  • تدعم واجهة سطر الأوامر الخاصة بـ Lore عمليات الـ commit والتفرع والمقارنة محليًا وبسرعة فورية.

يعتمد Lore على تقسيم البيانات إلى أجزاء (Chunks) وتخزين الأجزاء المتغيرة فقط، مما يجعله أكثر كفاءة من Git في التعامل مع إصدارات الملفات الكبيرة. يعمل النظام محليًا بالكامل في المهام اليومية، مما يضمن سرعة الاستجابة حتى عند فصل الخادم عن الشبكة.

المميزات التقنية وقيود المرحلة الحالية

  • يتبنى Lore هيكلًا مركزيًا للسجل مع أداء موزع للعمليات اليومية، مما يجمع بين مزايا Perforce و Git.
  • لا يدعم Lore حاليًا التوافق مع مستودعات Git الموجودة ولا يقدم واجهة رسومية رسمية في إصداره المفتوح المصدر.
  • ما زال المشروع في مرحلة ما قبل الإصدار 1.0 مع وعود بأداء متفوق دون وجود معايير قياس مستقلة وموثوقة حتى الآن.

يمثل Lore اتجاهًا جديدًا لمعالجة بيانات الألعاب الضخمة. رغم كونه واعدًا للمشاريع الجديدة والمفتوحة المصدر، إلا أن Epic Games تشير إلى احتمالية تغير واجهات البرمجة. ينصح باستخدامه حاليًا في تجارب المشاريع غير الحرجة لتقييم كفاءة سير العمل.

커뮤니티 글

모든 글 보기