मोनोलिथिक डेटा फ़ाइलों के कारण

Question

मुख्य रूप से यह गेम द्वारा उपयोग की जाने वाली तकनीक प्रतीत होता है, जहां उनके पास एक फ़ाइल में सभी ध्वनियां होती हैं, अन्य में बनावट आदि। इन फ़ाइलों के साथ आमतौर पर जीबी आकार तक पहुंच जाती है।

उपनिर्देशिकाओं में इसे सभी छोटी फ़ाइलों के रूप में बनाए रखने के पीछे ऐसा करने का क्या कारण है - एक बनावट जो कई छोटे गेम इसका उपयोग करती है, मोनोलिथिक सिस्टम को बड़ी कंपनियों द्वारा पसंद किया जा रहा है?

क्या बहुत सी छोटी फाइलों के साथ कुछ फाइल सिस्टम ओवरहेड है? क्या वे अपनी संपत्ति की रक्षा करने की कोशिश कर रहे हैं - हालांकि अधिकांश एक नए एक्सटेंशन के साथ एक संपीड़ित फ़ाइल प्रतीत होता है?

Answer 1

कारणों से हम इस जहाँ मैं (एक खेल विकास कंपनी) काम की तरह एक "संग्रह" प्रणाली का उपयोग करें:

• देखने गति: हम शायद ही कभी एक निर्देशिका में फ़ाइलों पर पुनरावृति करने की जरूरत है; हम उन्हें अक्सर नाम से सीधे देख रहे हैं। एक कस्टम "फ़ाइल आवंटन तालिका" का उपयोग करके जो अनिवार्य रूप से केवल hash(normalized_filename) -> [ offset, size ] का अनुक्रम है, हम फ़ाइलों को बहुत फ़ाइलों को देख सकते हैं। हम इस इंडेक्स को रैम में भी रख सकते हैं, संभावित रूप से इसे अन्य इंडेक्स टेबल, आदि के साथ इंटरलीव कर सकते हैं।
• (जब हमें पुनरावृत्त करने की आवश्यकता होती है, तो हम .arc में सभी फ़ाइलों को आसानी से फिर से सक्रिय कर सकते हैं, या हम फ़ाइल नामों की एक सूची स्टोर कर सकते हैं , हैश-ऑफ-फाइलनामों की एक सूची, या सिर्फ [ऑफ़सेट, आकार] जोड़ों की एक सूची - शायद संग्रह में एक फ़ाइल के रूप में भी। यह आमतौर पर एफएस पर निर्देशिका-ट्रैवर्सल से तेज़ है।)
• मेटाडाटा: हमारे लिए इच्छित किसी भी फ़ाइल मेटाडेटा में टक करना आसान है। उदाहरण के लिए, "आकार" फ़ील्ड में एक बिट इंगित करता है कि फ़ाइल संपीड़ित है या नहीं (यदि यह है, तो इसमें हेडर है कि इसे कैसे डंप्रॉप करना है)। यदि हम समय से पहले फ़ाइल की संरचना के बारे में पर्याप्त जानते हैं तो हम फ़ाइल के टुकड़ों पर संपीड़न भी बदल सकते हैं (हम इसे स्प्राइट अभिलेखागार के लिए करते हैं)।
• आकार: हमारे द्वारा उपयोग किए जाने वाले उपकरणों में से एक में "फ़ाइल का आकार एक्स का एक बहु होना चाहिए" आवश्यकता है, जहां एक्स हमारी कुछ फ़ाइलों की तुलना में बड़ी है। उदाहरण के लिए, हमारी कुछ लुआ स्क्रिप्ट संकलित होने पर केवल कुछ सौ बाइट्स होने लगती हैं; अतिरिक्त ओवरहेड प्रति .luc फ़ाइल लेना जल्दी से जोड़ता है।
• संरेखण: दूसरी ओर, कभी-कभी हम स्थान को बर्बाद करने के लिए चाहते हैं। फाइल सिस्टम से तेज स्ट्रीमिंग (जैसे पृष्ठभूमि डीएमए) का लाभ उठाने के लिए, हमारी कुछ फाइलें कुछ संरेखण/आकार आवश्यकताओं का पालन करना चाहते हैं। हम उपकरण में उस अधिकार का ख्याल रख सकते हैं, और जिस संरेखण/आकार के लिए हम शूटिंग कर रहे हैं, उसे अंतर्निहित एफएस के साथ लाइनिंग करने की ज़रूरत नहीं है, जिससे हमें केवल उस स्थान को बर्बाद कर दिया जा सकता है जहां हमें इसकी आवश्यकता है।

लेकिन ये प्रचलित कारण हैं। अधिक मजेदार सामान:

प्रत्येक .arc किसी सूची में पंजीयक, और फ़ाइल खोलने का प्रयास arcs में देखने के लिए पता है।हम पहले से ही राम संग्रह पहले खोजते हैं, फिर डिवाइस एफएस पर संग्रह, फिर वास्तविक डिवाइस एफएस। फाइल सिस्टम को

• गतिशील अतिरिक्त: यह हमें लचीलेपन का एक टन देता है किसी भी समय हम सवाल में एक नई फ़ाइल या मशीन के लिए संग्रह (नेटवर्क या की तरह अधिक) स्ट्रीम और यह जाहिर होता हो सकता है "लॉजिकल" फाइल सिस्टम के हिस्से के रूप में; यह बहुत अच्छा है जब वास्तविक एफएस रोम या सीडी पर रहता है, और हमें अन्यथा जितनी जल्दी हो सके उतना तेज़ करने की इजाजत देता है।
• (कयामत का .wad प्रणाली से ऊपर है, जो modders और अधिक आसानी से संपत्ति और लिपियों खेल में बनाया ओवरराइड करने देता है के उदाहरण के एक प्रकार है।)
• कोई अंतर्निहित FS की संभावना: यह एम्बेड करने के लिए bin2obj उपयोग करना संभव है लिंक समय पर सीधे निष्पादन योग्य (.rodata) में एक संपूर्ण चाप, जिस बिंदु पर आपको डिवाइस एफएस को देखने की आवश्यकता नहीं है - हम इसे कुछ छोटे डेमो बिल्डों और इसी तरह के लिए करते हैं। हम इस तरह के नेटवर्क या savegame-sneakernet में स्तर भी भेज सकते हैं। =)
• संगठन और लोड/अनलोड: चूंकि हम किसी भी समय हमारे फाइल सिस्टम के आभासी "टुकड़े" लोड और अनलोड कर सकते हैं, हम एफएस में फाइलों की संख्या बहुत छोटा होने के साथ कुछ प्रदर्शन चाल कर सकते हैं किसी भी समय। हम अतिरिक्त रूप से निर्दिष्ट कर सकते हैं कि एक संपूर्ण संग्रह स्मृति, अनुक्रमणिका तालिका और डेटा में लोड किया जा सकता है; हमारे फ़ाइल लोड कोड को यह जानने के लिए पर्याप्त स्मार्ट है कि अगर फ़ाइल पहले से ही स्मृति में है, तो इसे पॉइंटर को स्थानांतरित करने के अलावा इसे पढ़ने के लिए कुछ भी करने की आवश्यकता नहीं है। कुछ उच्च स्तरीय कोड वास्तव में यह पता लगा सकते हैं कि फ़ाइल रैम में है और केवल संभवतः पहले से दिखने वाले-जैसा-एक-संरचना सूचक के लिए पूछें।
• पोर्टेबिलिटी: हमें केवल यह पता लगाने की आवश्यकता है कि हम प्रत्येक नए डिवाइस पर कुछ फाइलें कैसे प्राप्त करें, और फिर शेष एफएस कोड उतना ही कम है। =) हम टूल आउटपुट को कभी-कभी कभी-कभी बदलते हैं (संरेखण कारणों के लिए), लेकिन अधिकांश प्रसंस्करण वही रहता है।
• डी-डुप्लीकेशन: इस तरह के हमारे स्प्राइट अभिलेखागार, हम कर सकते हैं (और कर) de-डुप्लिकेट डेटा के रूप में होशियार अभिलेखागार, साथ। यदि एनीमेशन के पांचवें फ्रेम "किक" और "किक" के तीसरे फ्रेम समान हैं, तो हम फ़ाइल को अलग कर सकते हैं और केवल उस फ्रेम की एक प्रति स्टोर कर सकते हैं। हम पूरी फाइलों के लिए भी ऐसा ही कर सकते हैं।

हमने हाल ही में बहुत धीमी एफएस उपयोग के साथ एक प्रणाली के लिए एक पीसी खेल स्थलांतरित किया। हमने डेटा प्रारूप को नहीं बदला है, और यह कच्चे डिवाइस एफएस पर एक डीआईआर के माध्यम से पुनरावर्तित हो जाता है ताकि एक सौ छोटी एक्सएमएल फाइलें लोड हो सकें, जो हमारे भार के समय को पूरी तरह से मार रही थी। हमारे द्वारा उपयोग किए जाने वाले समाधान को प्रत्येक डीआईआर लेना था, इसे अपने subdir.arc में बनाना, और इसे game.arc संपीड़ित मास्टर में चिपकाएं। जब डीआईआर की आवश्यकता थी (ओपेन्डर की तरह कुछ कहा जाता था) हमने पूरे subdir.arc को रैम में डिकंप्रेस किया, इसे फाइल सिस्टम में जोड़ा, फिर इसे सुपर-जल्दी से फिर से चलाया।

यह कुछ घंटों में इस तरह कुछ फेंकने की क्षमता है, और सिस्टम में पोर्टिंग के दर्द को कम करने की क्षमता है, जो इस तरह की चीजें बनाती है।

Answer 2

फाइल सिस्टम के ऊपर एक ओवरहेड है। आम तौर पर, एक फ़ाइल 2 की कुछ शक्ति (उदाहरण के लिए 4 केबी) तक गोल स्थान ले जाती है, इसलिए कई छोटी फाइलें अंतरिक्ष को बर्बाद कर देती हैं। कुछ आधुनिक फाइल सिस्टम इसे कम करने का प्रयास करते हैं, लेकिन AFAIK यह अभी तक व्यापक नहीं है। इसके अतिरिक्त, एकाधिक फ़ाइलों तक पहुंचने पर फ़ाइल सिस्टम अक्सर धीमे होते हैं। जैसे यह 4000 100 केबी फाइलों की तुलना में एक 400 एमबी फ़ाइल की प्रतिलिपि बनाने के लिए आमतौर पर काफी तेज़ होता है।

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

Answer 3

ऐप्पल सिस्टम पर, सबसे आम तरीका है, जैसा कि आप सुझाव देते हैं, निर्देशिकाओं का उपयोग करना है। उन्हें बंडल कहा जाता है, और खोजक में केवल एक फ़ाइल के रूप में प्रतिनिधित्व किया जाता है, लेकिन यदि आप उन्हें और अधिक खोजते हैं, तो वे वास्तव में निर्देशिकाएं हैं। इस बंडल से अलग-अलग वस्तुओं को लोड करते समय यह लेखन कोड और स्मृति को संरक्षित करता है। :-) इसके अलावा, यह विशाल डेटाबेस के बढ़ते बैकअप को आसान बनाता है, उदाहरण के लिए आपका आईफ़ोटो डेटाबेस केवल एक बंडल है, इसलिए आप बस बैकअप बदल चुके हैं और नई फाइलें

विंडोज़ पर, हालांकि, मेरा मानना ​​है कि यह बहुत कठिन है ऐसा करें, यह एक निर्देशिका की तरह दिखेगा "कोई फर्क नहीं पड़ता" (मुझे यकीन है कि स्मार्ट लोगों को एक समाधान मिला है जो एक्सप्लोरर को कुछ फाइलों को एक फ़ाइल के रूप में देखेगा, लेकिन यह आम नहीं है)।

देखने के एक खेल डेवलपर बिंदु से, आप इतना छोटा फाइलों के साथ काम कर रहे है कि डिस्क स्थान भूमि के ऊपर कुछ बहुत बहुत के साथ संबंध रहे हैं, इसलिए मैं @ doublep के सुझाव पर शक है, क्योंकि यह इस तरह के एक परेशानी के लिए बनाता है, लेकिन यह एक फ़ाइल के साथ बहुत आसान बनाता है अगर उपयोगकर्ता कहीं भी एक पूरे गेम की प्रतिलिपि बनाना चाहते हैं, तो यह जांचना आसान है कि पूरा सेट सही है या नहीं।

और, ज़ाहिर है, उन लोगों के लिए पढ़ना मुश्किल है जिनके पास इसका उपयोग नहीं होना चाहिए। लेकिन इसे संशोधित करना भी मुश्किल है, जिसका मतलब है पैच करना कठिन है, और एक्सटेंशन लिखना कठिन है। कोई भी जो एक्सटेंशन का बहुत उपयोग करता है, निर्देशिका संरचना पसंद करता है: सिम्स।

क्या मैं गेम डेवलपर थे, मुझे व्यक्तिगत फाइलों के लिए जाना पसंद है। तो फिर, मैं बंडलों का उपयोग किया था के रूप में मैं मैक ;-)

चीयर्स

के लिए लेखन होगी Nik

Answer 4

मैं कई कारणों के बारे में सोच सकते हैं।

जैसा कि डबल सुझाव दिया गया है, फ़ाइलों को डिस्क पर अधिक जगह पर कब्जा करने की आवश्यकता है। तो एक संग्रह अंतरिक्ष बचाता है। एक संग्रह में पैक होने पर 10k फ़ाइलों (किसी भी आकार के) आपको 20 एमबी बचा लेना चाहिए। आजकल वास्तव में बड़ी मात्रा में अंतरिक्ष नहीं है, लेकिन फिर भी।

अन्य कारण मैं डिस्क विखंडन के बारे में सोच सकता हूं।मुझे संदेह है कि एक खंडित स्थान पर हजारों अलग-अलग फ़ाइलों तक पहुंचने पर भारी खंडित डिस्क खराब हो जाएगी। लेकिन मैं इस क्षेत्र में कोई विशेषज्ञ नहीं हूं, इसलिए अगर मैं किसी और अनुभवी को सत्यापित करता हूं तो मैं सराहना करता हूं।

अंत में, मुझे लगता है कि अलग-अलग गेम फ़ाइलों तक पहुंच प्रतिबंधित करने के साथ इसका कुछ भी हो सकता है। आप लुआ स्क्रिप्ट का खुलासा कर सकते हैं, उनके साथ गड़बड़ कर सकते हैं और कुछ तोड़ सकते हैं। या आप आउट्रो सिनेमाई/ध्वनि/पाठ/जो कुछ भी उजागर हो सकता है और इसे एक्सेस करके खराब हो सकता है। मैं इसे स्वयं भी करता हूं: मैं एक मल्टीपास एक्सओआर कुंजी के साथ छवियों को एन्क्रिप्ट करता हूं, एक मोनोलिथिक फ़ाइल (अतिरिक्त सुरक्षा के लिए ज़िपित) में पाठ फ़ाइलों और कॉन्फ़िगर चर को पैक करता हूं और केवल संगीत को आसानी से सुलभ छोड़ देता हूं। इस तरह, गेम के रहस्य थोड़ी देर के लिए अनदेखा रहेंगे :)।

या ऐसा कोई अन्य कारण हो सकता है जिसके बारे में मैंने कभी सोचा नहीं: डी।

Answer 5

जैसा कि आप गेम जानते हैं, खासकर बड़ी कंपनियों के साथ जितना संभव हो उतना प्रदर्शन निचोड़ने का प्रयास करें। एक तकनीक है कि सभी डेटा एक बड़ी फाइल में रखें और केवल डीएमए को मेमोरी में रखें (इसे सीडी से रैम तक एक memcpy के रूप में सोचें)। चूंकि सभी फाइलें एक बड़ी संख्या में हैं, वहां डिस्क की तलाश नहीं होगी और तकनीक की वजह से आपके पास बड़ी संख्या में फाइलें हो सकती हैं (जो बड़ी मात्रा में तलाश कर सकती हैं)।