Git गेम्स के लिए नहीं बना है... इसलिए Epic ने Lore बनाया

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

스크립트

00:00:00एपिक गेम्स ने अपना खुद का वर्ज़न कंट्रोल सिस्टम बनाया क्योंकि वे Git से तंग आ चुके थे।
00:00:05उन्होंने इसे रस्ट (Rust) में बनाया और फिर इसे मुफ्त में जारी किया। इसका नाम है Lore। तो हाँ,
00:00:10Fortnite बनाने वाली कंपनी ने Git का एक विकल्प तैयार किया है। लेकिन Git अभी भी बेहतरीन है,
00:00:15जाहिर है। लेकिन Git को कोड के लिए बनाया गया था। मुख्य रूप से टेक्स्ट फ़ाइलों और ढेर सारी छोटी फ़ाइलों के लिए,
00:00:21जिनमें बदलाव आमतौर पर एक बार में कुछ लाइनें ही होते हैं। गेम्स तो इसके बिल्कुल विपरीत हैं। तो
00:00:26Lore, Git से कैसे तुलना करता है और हम इसके साथ काम कैसे करते हैं? चलिए जानते हैं।
00:00:35अब इस बिंदु पर, हमारे पास भारी टेक्सचर, ऑडियो फ़ाइलें, वीडियो, 3D मॉडल,
00:00:41और सभी प्रकार की बाइनरी एसेट्स हैं जो सैकड़ों मेगाबाइट या कई गीगाबाइट की भी हो सकती हैं। और
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कमांड और एक डेमो फ्लैग के साथ शुरू होता है, जिसे हम यहाँ चलाने वाले हैं। और बस इतना ही। कुछ सेकंड बाद,
00:01:51मेरे पास स्थानीय रूप से Lore सर्वर चल रहा है। कोई क्लाउड अकाउंट नहीं, कोई की (key) नहीं, कोई सर्ट (cert) सेटअप नहीं। यह यहाँ
00:01:57इन पोर्ट्स पर चल रहा है। और सिर्फ यह साबित करने के लिए कि यह वास्तव में जीवित है, मैं बस इस हेल्थ एंडपॉइंट को यहाँ
00:02:03हिट कर सकता हूँ। और मैं इसे इस टर्मिनल पर करने वाला हूँ। और देखिए। यह जीवित है। यह चल रहा है।
00:02:08ऐसी कोई बैकग्राउंड सर्विस नहीं है जिसे मुझे मैन्युअल रूप से जोड़ना पड़े। कोई ऑथ टोकन (auth token) जेनरेट नहीं करना है। कोई
00:02:14सेटअप विज़ार्ड नहीं है। यह बस शुरू हो जाता है। अब, मुझे एक रिपॉजिटरी बनाने दें। तो मैं एक फोल्डर बनाने वाला हूँ,
00:02:22है ना? और हम इस रिपॉजिटरी को बनाएंगे। और अब मैं एक बड़ी बाइनरी फ़ाइल बनाने वाला हूँ
00:02:27और इसे कमिट करूँगा, ठीक है? यह सिर्फ एक डमी फ़ाइल है, है ना? लेकिन चलिए एक बड़ी फ़ाइल बनाते हैं। मैं यहाँ
00:02:32डेटा डुप्लिकेशन के लिए DD चला रहा हूँ। अब, उस 100 मेगाबाइट फ़ाइल को एक विशाल ऑब्जेक्ट के रूप में मानने के बजाय,
00:02:40Lore इसे छोटे टुकड़ों में तोड़ देता है। उन टुकड़ों को हैश किया जाता है, Z स्टैंडर्ड के साथ कंप्रेस किया जाता है, और एक
00:02:47कंटेंट एड्रेस मर्कल ट्री में स्टोर किया जाता है। यदि फ़ाइल का अधिकांश हिस्सा वैसा ही रहता है, तो Lore को पूरी फ़ाइल की
00:02:52एक और पूर्ण कॉपी सहेजने की आवश्यकता नहीं है। यह उन टुकड़ों का पुन: उपयोग कर सकता है जो इसके पास पहले से हैं और केवल उन हिस्सों को स्टोर करता है जो बदल गए हैं।
00:02:58यह बड़ी बाइनरी एसेट के लिए बहुत बेहतर है। कमिट खत्म होने के तुरंत बाद, आप देख सकते हैं कि
00:03:04डिस्क पर स्थानीय स्थिति बनाई गई थी। यहाँ एक Lore निर्देशिका है जिसमें कॉन्फ़िगरेशन और
00:03:10मेटाडेटा है। ठीक है, अब जब हमारे पास यह है, तो चलिए एक ब्रांच बनाते हैं। ठीक है, मैं Lore ब्रांच क्रिएट रन कर सकता हूँ
00:03:17ब्रांच का नाम रखें। यह काफी हद तक Git की तरह काम करता है। तो चलिए इस पर स्विच करते हैं। चलिए वास्तव में एक छोटा
00:03:24बदलाव करते हैं। मैं एक त्वरित टेक्स्ट फ़ाइल बनाऊंगा और इसे इस ब्रांच में कमिट करूँगा। तो मैं मॉडिफाई करता हूँ, फिर हम इसे स्टेज कर सकते हैं,
00:03:31और फिर हम इसे कमिट कर सकते हैं, है ना? प्रवाह मोटे तौर पर Git के समान है। अब मैं स्विच करने वाला हूँ
00:03:37वापस। और वह लगभग तुरंत हो गया। दूसरी महत्वपूर्ण बात यह है कि इनमें से किसी के लिए भी
00:03:44किसी सर्वर पर जाने की आवश्यकता नहीं थी। स्टेजिंग, कमिटिंग, ब्रांचिंग, स्विचिंग, डिफिंग, यह सब स्थानीय रूप से होता है। तो
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:34आंतरिक रूप से यह बहुत सारा चतुर ऑप्टिमाइज़ेशन करता है, 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 से पहले है। एपिक गेम्स का कहना है कि API बदल सकते हैं
00:05:52पहले स्थिर रिलीज़ से पहले, और प्रोजेक्ट स्पष्ट रूप से अभी भी विकसित हो रहा है। अभी कोई Git
00:05:58इंटरोपेरेबिलिटी नहीं है, और आप बस मौजूदा Git रिपॉजिटरी पर Lore को इंगित नहीं कर सकते और पूरी
00:06:03हिस्ट्री नहीं ला सकते। यह सेल्फ-होस्टेड भी है। ऐसी कोई होस्टेड सर्विस नहीं है जहाँ आप एक अकाउंट बनाएं,
00:06:09अपनी रेपो पुश करें, और काम हो गया। और डेस्कटॉप ऐप जिसे आप घूमते हुए देख सकते हैं, वह ओपन सोर्स
00:06:15रिलीज़ में शामिल नहीं है। आपको जो मिलता है वह कोर लाइब्रेरी, सर्वर, CLI, और SDKs हैं। वह GUI इसका
00:06:22हिस्सा नहीं है। फिर, निश्चित रूप से, प्रदर्शन। यह कैसा प्रदर्शन करता है? एपिक का कहना है कि Lore भारी
00:06:28रिपॉजिटरी को बिना धीमा किए संभाल सकता है जिस तरह अन्य सिस्टम करते हैं। और एपिक को जाहिर तौर पर अनुभव है
00:06:33कुछ बहुत बड़े प्रोजेक्ट्स के साथ। लेकिन अभी, उनमें से अधिकांश दावे खुद एपिक से आ रहे हैं। अभी तक
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, गेम प्रोजेक्ट्स में इस्तेमाल होने वाली विशाल बाइनरी फ़ाइलों के लिए एक केंद्रीकृत वर्ज़न कंट्रोल विकल्प प्रदान करता है, जो Git की टेक्स्ट-आधारित सीमाओं को हल करने के लिए चंकिंग और कंटेंट एड्रेसिंग का उपयोग करता है।

하이라이트

  • एपिक गेम्स ने गेम डेवलपमेंट में बाइनरी एसेट्स को संभालने के लिए Lore नामक वर्ज़न कंट्रोल सिस्टम बनाया है।

  • Git टेक्स्ट फ़ाइलों के लिए डिज़ाइन किया गया है, लेकिन Lore बड़ी बाइनरी फ़ाइलों के लिए चंकिंग और डुप्लिकेशन का उपयोग करता है।

  • Lore का सर्वर सेटअप बिना क्लाउड अकाउंट या जटिल ऑथेंटिकेशन के, सिर्फ एक इंस्टाल कमांड से शुरू होता है।

  • Lore में फाइलें छोटे टुकड़ों में टूटकर मर्कल ट्री में स्टोर होती हैं, जिससे केवल बदले हुए हिस्से ही डिस्क पर सेव होते हैं।

  • यह सिस्टम केंद्रीकृत है, लेकिन ब्रांचिंग, कमिटिंग और डिफिंग जैसे दैनिक कार्य स्थानीय रूप से तेजी से होते हैं।

  • Lore MIT लाइसेंस प्राप्त है और इसमें कई भाषाओं के लिए SDK उपलब्ध हैं।

타임라인

गेमिंग के लिए Git की सीमाएं

  • Git मुख्य रूप से कोड और छोटी टेक्स्ट फ़ाइलों के लिए बनाया गया है।
  • गेम डेवलपमेंट में सैकड़ों MB या GB की बाइनरी एसेट्स होती हैं।
  • Git LFS और Perforce जैसे समाधान या तो जुगाड़ जैसे लगते हैं या फिर महंगे और जटिल हैं।

Git में भारी एसेट्स के साथ काम करने पर रिपॉजिटरी का आकार तेजी से बढ़ता है और क्लोनिंग धीमी हो जाती है। Perforce उद्योग का मानक तो है, लेकिन यह महंगा है और इसके रखरखाव के लिए समर्पित संसाधनों की आवश्यकता होती है। Lore को इन्हीं चुनौतियों का सामना करने के लिए रस्ट में विकसित किया गया है।

Lore का संचालन और तकनीकी संरचना

  • Lore का सर्वर सेटअप सरल है और बिना बाहरी निर्भरता के स्थानीय रूप से चलता है।
  • बड़ी फ़ाइलों को टुकड़ों में तोड़कर Z स्टैंडर्ड के साथ कंप्रेस किया जाता है।
  • यह कंटेंट एड्रेस मर्कल ट्री का उपयोग करता है ताकि केवल बदले हुए हिस्सों को स्टोर किया जा सके।

यह सिस्टम एक डेमो फ्लैग के साथ कमांड लाइन से तुरंत शुरू होता है। फाइलें पूरी तरह से दोबारा सेव नहीं होतीं, बल्कि पहले से मौजूद टुकड़ों का पुन: उपयोग किया जाता है। स्थानीय स्तर पर काम करने के कारण ऑथेंटिकेशन और सर्वर से जुड़े बिना भी कमिटिंग और ब्रांचिंग तेज़ बनी रहती है।

उपयोग और सीमाएं

  • Lore केंद्रीकृत है लेकिन स्थानीय वर्कफ़्लो को प्राथमिकता देता है।
  • सिस्टम मांग पर फ़ाइलों को हाइड्रेट करने की सुविधा देता है, जिससे पूरी रिपॉजिटरी डाउनलोड करने की आवश्यकता नहीं होती।
  • यह अभी भी 1.0 संस्करण से पहले है और इसमें Git जैसी पूर्ण इंटरोपेरेबिलिटी की कमी है।

अभी के लिए, Lore पूरी तरह से प्रोडक्शन-तैयार Perforce को बदलने के लिए नहीं है। इसमें डेस्कटॉप GUI का अभाव है और यह अभी भी विकास के चरण में है। हालांकि, बड़े एसेट-भारी प्रोजेक्ट्स के लिए यह एक नई दिशा प्रदान करता है जिसे नए प्रोजेक्ट्स पर आज़माया जा सकता है।

커뮤니티 글

모든 글 보기