क्या सभी गेम पोस्ट-स्टार्ट लोडिंग से नहीं बच सकते थे?


23

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

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


16
ध्यान दें कि कई 'सहज' खुली दुनिया खेल में, वहाँ रहे हैं लोडिंग समय है जब एक अप्रत्याशित स्थान पर खिलाड़ी ले जाता है। एक न्यू यॉर्क के एक छोर से दूसरे तक एक डिवीजन में एक लोडिंग स्क्रीन को छोड़े बिना चल सकता है- जबकि किसी स्थान की तेजी से यात्रा के लिए लोडिंग की आवश्यकता होती है। यह सब जानने के बारे में है कि आगे क्या लोड करना है।
फेलिसिर

2
@Felsir डंगऑन घेराबंदी ने इसे उसी तरह से किया।
मेसन व्हीलर

एक उदाहरण के रूप में, बैटमैन अरखम ओरिजिंस कटकनेस से ठीक पहले और पूरी तरह से नए क्षेत्रों में प्रवेश करते समय लोडिंग स्क्रीन का उपयोग करता है। इसकी कहानी चालित, प्रगतिशील प्रकृति खुद को अच्छी तरह से उधार देती है, और उपयोगकर्ता को एक प्राकृतिक ब्रेक देती है। यह विशेष रूप से अच्छी तरह से बहुत उच्च-परिभाषा संपत्ति वाले बहुत विस्तृत क्षेत्रों के कारण काम करता है। इस सुविधा को कम लाभ के लिए कोड करना और परीक्षण करना बहुत समय लेने वाला होगा।
केसी कुबैल

अपने RAM को 128gb तक लाएं। 64 जीबी या इतनी रैम ड्राइव बनाएं, अपने गेम को रैम ड्राइव पर लोड करें। लोड समय इतनी जल्दी होगा कि आप मुश्किल से उन्हें नोटिस करेंगे। मैंने एक SSD में अपग्रेड किया और अधिकांश समय नाटकीय रूप से छोटा किया। वीडियो कार्ड को अपग्रेड करना, विशेष रूप से अधिक वीडियो रैम के लिए।
साइबरबर्ड

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

जवाबों:


31

इसका उत्तर है हां, यह हो सकता है, ज्यादातर मामलों में, कम से कम कुछ हद तक।

कारण यह नहीं किया है कई हैं:

  • इसे सही करने के लिए समय और धन की आवश्यकता होती है।
  • परीक्षण पास करने वाले कीड़े की मात्रा अधिक होगी
  • लोड समय उपयोगकर्ताओं द्वारा स्वीकार किए जाते हैं।
  • लोड समय के अन्य कारण हो सकते हैं, जैसे कि सर्वर लोड को संतुलित करना।
  • सामान्य समाधान जो शेल्फ से खरीदे जा सकते हैं वे "एक साथ लोड सभी" के साथ अधिक संगत हैं।

'बैलेंसिंग सर्वर लोड' बिंदु तक अनुवर्ती के रूप में, आज बाजार में आने वाले बहुत सारे ऑनलाइन गेम एक केंद्रीय 'हब' क्षेत्र की सुविधा प्रदान करते हैं जो आपके लिए अद्वितीय है और जिस पर कोई पहुंच नहीं सकता है। अक्सर, इन क्षेत्रों को एक लोड जोन या धीमी गति से चलने वाले क्षेत्र के पीछे रखा जाता है (उदाहरण के लिए, 'द डिवीजन' में BOO) ताकि वे सुरक्षा कर सकें, जो आपको उस उदाहरण से दूर कर दें जो आप पहले थे और आपको अपने निजी उदाहरण में जगह देते हैं ।
एसजीआर

7
स्मृति का मुद्दा भी है। वर्तमान में मेमोरी (विशेषकर कंसोल या पोर्टेबल उपकरणों के लिए) को रखते हुए एक मौजूदा स्तर को लोड करना संभव नहीं हो सकता है, इसलिए आपको एक लोडिंग स्क्रीन का उपयोग करना होगा
Jezzamon

@Jezzamon मैं सोच रहा हूं कि स्कीयर मैप की संपूर्णता को कभी भी किसी एक समय में याद में नहीं रखा जाता है। शायद मैं गलत हूँ? लेकिन यदि नहीं, तो बड़े पैमाने पर खुली दुनिया के गेम मैप की गतिशील लोडिंग रणनीतियों के साथ कोई अन्य स्थिति क्यों अनुपयुक्त होगी?
विजिओनेरी

वस्तुतः कोई भी अब खरोंच से अपने स्वयं के खेल इंजन को रोल नहीं करता है। वे एक इंजन (अवास्तविक, एकता, CryEngine) और मिडलवेयर का एक गुच्छा खरीदते हैं और इसे एक साथ गोंद करते हैं। बेस इंजन आमतौर पर एक सतत आधार पर स्ट्रीम-इन सामग्री के लिए सेट नहीं होते हैं, या फिर से लोड किए बिना पुनः आरंभ करने के लिए। इस बात पर विचार करें कि किसी खेल में कितनी बार आपकी मृत्यु हुई है, केवल 60 सेकंड लोड समय के साथ सामना करना पड़ता है, इस तथ्य के बावजूद कि संपत्ति और स्तर पहले से ही लोड थे। @Peter ने जो कारण बताए हैं, वे कारण भी हैं कि आप ऐसे गेम नहीं देखते हैं जो आपको खेलना शुरू करते हैं जबकि आप अभी भी बहुत बार संपत्ति डाउनलोड कर रहे हैं।
टॉम बी

2
@Vizionary Level आमतौर पर बनावट को बहुत अधिक पुन: उपयोग करता है, और एक अलग स्तर बनावट के एक अलग सेट का उपयोग करता है। एक तहखाने के स्तर में बहुत से कालकोठरी दीवार बनावट का उपयोग किया जाएगा, एक रेगिस्तान स्तर रेत और रेगिस्तान रॉक बनावट का उपयोग करेगा, एक पहाड़ी स्तर रॉक, घास और बर्फ बनावट आदि का उपयोग करेगा, उन खेलों के लिए जहां यह सही है, आधा स्तर उतारने पर। सभी स्तरों पर बनावट का उपयोग किया जाता है, केवल उपयोग की जाने वाली मेमोरी का एक छोटा सा अंश मुक्त करेगा (या यह बनावट को अनलोड करेगा जो आपको अभी भी आवश्यक है)।
पीटर - Unban रॉबर्ट हार्वे

10

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

एक खुली दुनिया के खेल में, आप जानते हैं कि खिलाड़ी कुछ निश्चित गति की तुलना में तेजी से आगे नहीं बढ़ेगा, इसलिए आपको पता है कि आपको दूर के स्थानों के विस्तृत संस्करणों को लोड करने की आवश्यकता नहीं है जब तक कि वे उनसे संपर्क नहीं कर रहे हैं।


क्यों भारी / अक्सर एक्सेस किए गए मेनू को लोड करने को प्राथमिकता न दें? किसी भी आरपीजी में, अगर मैं मेनू खोलता हूं, तो यह उस समय का 90% है जो मुझे मिला, या किसी वस्तु का उपयोग करने के लिए। आप थ्रोस मेनू द्वारा शुरू कर सकते हैं। या मेनू से शुरू करें जो लोड करने के लिए 5 मिनट लेता है, और लोडिंग को छोड़ देता है यदि उपयोगकर्ता मेनू से बाहर निकलता है।
ड्रेकसन

1
@DrakaSAN लेकिन वह है अक्सर अनुकूलित। यहां तक ​​कि मूल डियाब्लो ने आपको टोपी की बूंद पर सूची दिखाई। "सब कुछ के लिए प्रतीक्षा करें" दृष्टिकोण से आधुनिक कंसोल के साथ एक प्रमुख पुनरुत्थान हुआ है, जो एक पीसी की तुलना में स्मृति में बहुत सीमित था। और चूंकि पीसी और कंसोल दोनों पर बहुत सारे गेम पोर्ट किए गए कंसोल-> पीसी हैं, इसलिए प्रक्रिया में कुछ कंसोल सीमाएं विरासत में मिली हैं। स्किरीम या डार्क सोल के साथ डियाब्लो III या देवत्व की तुलना करें - अंतर स्पष्ट नहीं हैं।
लुआण

2
गेमिंग में धीमी लोडिंग मेनू एक वास्तविक समस्या है? नंबर
एलन बी

@AlanB केवल अगर उपभोग्य सामग्रियों तक पहुंचने का एकमात्र तरीका उस मेनू के माध्यम से हो। Xbox 360 / PS3 पर डेस्टिनी देखें और XB1 / PS4 संस्करणों की तुलना में एक बारूद का उपयोग करने में कितना समय लगता है।
एसजीआर

1
@SGR मैं डेस्टिनी को PS4 पर एक मेनू के उदाहरण के रूप में उपयोग करने वाला था जिसे अस्वीकार्य रूप से लंबे समय तक लोड करने के समय के साथ, मैं कल्पना नहीं कर सकता कि यह पिछले जीन कंसोल पर कितना बुरा है।
इल्युसिवब्रियन

5

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

कुछ हेलो गेम मल्टीप्लेयर गेम सेट करते समय पृष्ठभूमि में चयनित स्तर को लोड करना शुरू करते हैं। यह प्रतीक्षा समय कम कर देता है जब खिलाड़ी शुरू करने के लिए तैयार होते हैं, और संभवत: निकटतम व्यक्ति को ऐसा समाधान मिल सकता है जब खिलाड़ी स्वतंत्र रूप से पूरी तरह से अलग-अलग परिसंपत्तियों के साथ विभिन्न स्तरों का चयन कर सकता है।

बेशक, आपने कहा कि "पर्यावरण को बदले बिना", लेकिन मैं सिर्फ हेलो उदाहरण लाना चाहता था , क्योंकि यह कुछ ऐसा है जिसे मैं और देखना चाहता हूं।

एक निरंतर अभियान के भीतर, या जब भी डेवलपर के पास खिलाड़ी के स्थान पर बहुत अधिक नियंत्रण होता है, तो ऐसा समाधान निश्चित रूप से व्यवहार्य होता है, जैसा कि आप कहते हैं। शरारती डॉग लोडिंग समय के साथ दूर रहना पसंद करता है, जिसमें जेसी और डैक्सटर के पास प्रसिद्ध रूप से PS2 पर लोडिंग समय नहीं होता है, और अनचाहे गेम में शुरुआत में एक ही लोडिंग समय होता है।

हालाँकि, कई लोगों के लिए, लोडिंग समय सिर्फ एक समस्या नहीं है जिसे हल करने की आवश्यकता है । या यह एक समस्या है जो डेवलपर्स की प्राथमिकताओं पर बहुत कम है, जब हमेशा ऐसा होता है जो अब और रिलीज़ की तारीख के बीच हो सकता है ।


3
Jak और Daxter में लोडिंग समय होता है। वे एमई 1 लिफ्ट के समान विधि में, दरवाजे के पीछे छिपे हुए हैं और वे लोडिंग समय को कैसे छिपाते हैं।
नजल्ल

2
लेकिन लोडिंग समय एस-कर्व हॉल के पीछे छिपा हुआ है और ऐसा लोड बार की तरह नहीं लगता है
आलमो

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

1
नक्शों को लोड करने के लिए हमेशा के लिए क्या नहीं होता है - यह विशाल बनावट, मॉडल फाइलें, शेडर प्रोग्राम आदि हैं, जो एक स्तर या क्षेत्र के लिए विशिष्ट हैं।
टॉम बी

3

पहर।

आपको समय बचाने के लिए समय चाहिए। या समय की कमी के लिए आपको पैसा चाहिए। किसी भी मामले में, "कोई लोडिंग समय नहीं!" एक विशेषता यह है कि केवल उन लोगों के पास है जिनके पास इसे वहन करने की विलासिता है। यह बहुत सावधानी से योजना बनाता है, और आपको यह अच्छी तरह से समझने की ज़रूरत है कि आप क्या कर रहे हैं और सभी गेम डेवलपर्स के पास इस पर डालने के लिए संसाधन नहीं हैं।


2

अंततः, यह सीमित संसाधन हैं।

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

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

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


2

एक कारण डायनेमिक लोडिंग हमेशा आदर्श समाधान नहीं है कि अन्य उत्तर वास्तव में मेरे विचार से पॉप-इन और अन्य ग्राफिकल कलाकृतियों को भी नहीं मानते हैं।

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

ये समस्याएँ सिर्फ एक समस्या नहीं हैं सब कुछ प्रीलोडेड है।

कुछ पर विचार करना जरूरी नहीं है कि क्या लोड करना है, लेकिन क्या उतारना है। जब आपको केवल अंतरिक्ष के लिए इतना बजट मिला है, जब आप नई चीजों को लोड करते हैं, तो पुराने को हटाने के लिए क्या हैं? आप कितने निश्चित हैं कि उन संपत्तियों का अगले कुछ सेकंड में उपयोग नहीं होने जा रहा है? इन्हें हल करने में मुश्किल होती है।

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

मुझे लगता है कि यह तर्क देने के बारे में सोचने लायक है कि डायनामिक लोडिंग सिस्टम मूल रूप से क्यों बनाए गए थे, जिससे आप जानते हैं कि आपके कई गेमप्ले राज्यों में एक सामान्य सिस्टम के लिए बहुत बड़े हो सकते हैं और उस आकार का एक गेम पूरी तरह से प्रीलोड करना संभव नहीं है।


2

एक सामान्य कारण यह है कि निकट भविष्य में किसी संसाधन की आवश्यकता होने वाली है, यह निर्धारित करना हमेशा उतना आसान नहीं होता है।

चूँकि आपने एक उदाहरण के रूप में इलाके पेजिंग का उपयोग किया है, इसलिए मैं इसे जारी रखूंगा।

यह पूरी तरह से उचित है यदि आप किसी दिए गए मानचित्र ग्रिड में पृष्ठभूमि में सभी निकटवर्ती मानचित्र ग्रिड को लोड करने के लिए हैं। आप जानते हैं कि उपयोगकर्ता, सबसे अच्छे रूप में, उनमें से एक को दर्ज कर सकते हैं। जब वे करते हैं, तो आप उन लोगों को अनलोड नहीं कर सकते हैं जो आस-पास हैं और जो अब हैं उन्हें लोड कर सकते हैं। यह आपने नोट किया है।

अब तेज यात्रा की कल्पना करें। यह अनुमान लगाने का कोई तरीका नहीं है कि उपयोगकर्ता कहाँ जाना चुन सकता है। उनके पास (आमतौर पर) चुनने के लिए लगभग पूरा नक्शा है। सभी संभावित तेज़ यात्रा स्थानों को पूर्व-लोड करना बहुत अधिक मेमोरी लेगा (आप पहली जगह में पूरे मैप को मेमोरी में लोड कर सकते हैं) और बहुत अधिक समय तक (यह मानते हुए कि आपके पास पहले से लोड नहीं किया गया था)। यह कब होगा? जब वे तेजी से यात्रा संवाद खोलते हैं? समस्या केवल कई बार बदतर हो जाएगी!

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

अब कल्पना करें कि यह सामान्य रूप से गेम संसाधनों पर लागू होता है, जहां रिश्ते अक्सर स्पष्ट नहीं होते हैं। आप अंत में सभी संभावित विकल्पों को लोड करेंगे, या अनुमान लगाना शुरू करेंगे कि उपयोगकर्ता क्या करने जा रहा है। अनुमान लगाना महंगा है (दोनों विकास और सीपीयू में) और कार्यक्रम के लिए एक जटिल गड़बड़ है। विशिष्ट उदाहरण:

  • फ़ाइलें सहेजें: उपयोगकर्ता को बचाने के स्क्रीन तक पहुँचने से पहले आपको प्रत्येक सेव फ़ाइल को लोड करना होगा , या अनुमान लगा सकते हैं कि वे कौन सी फ़ाइल लोड कर सकते हैं (नवीनतम 5, आदि)।
  • यूआई: कई रणनीति गेम आपके यूआई को आपके गुट के आधार पर बदलते हैं। उपयोगकर्ता द्वारा अपना गेम शुरू करने से पहले आपको हर संभव UI डिज़ाइन लोड करना होगा।
  • खेल की दुनिया: प्रक्रियात्मक रूप से उत्पन्न गेमों में, जैसे कि Minecraft या RTS सभ्यता की तरह के खेल, दुनिया तब तक मौजूद नहीं है, जब तक कि विस्तार अलग-अलग होते हैं। पहले से लोड करना असंभव है क्योंकि वे शुरू करने के लिए मौजूद नहीं थे; पूर्व-गणना करने से उन्हें पूर्व-लोडिंग के समान सर्वोत्तम रूप से किया जा सकता है, और आरटीएस मामले में लागू नहीं होता है।

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

और ध्यान रखें, बैकग्राउंड लोडिंग फ्री नहीं है। पृष्ठभूमि-लोडिंग इलाके और कुछ मॉडल फ़ाइलों के आधुनिक उपयोग से आमतौर पर कम से कम प्रभाव पड़ता है, लेकिन अगर आप अचानक कई अलग-अलग संसाधनों के बारे में अनुमान लगा रहे हैं, खासकर यदि आपके पास विश्वसनीय मैट्रिक्स नहीं हैं और कई संसाधनों को अनलोड करना है और सुपरफ़्लस को लोड करना है , आप सिस्टम को धूल में पीस सकते हैं।

बैकग्राउंड लोडिंग का विचार बेहतर उपयोग के लिए मृत चक्र का उपयोग करना है, लेकिन उपयोग करने के लिए केवल इतने ही मृत चक्र हैं। वही मेमोरी के लिए जाता है - प्री-लोडिंग से किसी गेम की मेमोरी का उपयोग काफी हद तक बढ़ सकता है। एक लोडिंग स्क्रीन के साथ, आप मौजूदा संसाधनों को डंप करते हैं। पृष्ठभूमि लोडिंग के साथ ऐसा कोई लक्जरी नहीं है, जिसका अर्थ है कि यह अकेले उस गिनती पर गेम की मेमोरी आवश्यकता को दोगुना कर सकता है।


1

यह इस तथ्य से उपजा एक सामान्य मुद्दा है कि गेम सॉफ्ट-रियलटाइम उत्पाद हैं, जहां सामग्री की देर से डिलीवरी ऑन-टाइम डिलीवरी (हार्ड-रियलटाइम के साथ विपरीत, कंप्यूटर में कारों की तरह, जहां देर से वितरण के रूप में उपयोगी नहीं है) कोई वितरण से बेहतर हो सकता है)। आपको तय करना है कि क्या लोड करना है और कहां।

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

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

अक्षांश भी हमेशा स्वीकार्य नहीं होते हैं। मैंने Starcraft में ऐसे मामलों के बारे में सुना है, जहाँ आप एक मैप लोड करके अपने गेम को "वार्म अप" करेंगे, जिसमें हर डायनामिकली लोडेड मॉडल / इमेज को कैशिंग करने का साइड इफेक्ट होता है। आप तब बाहर निकलेंगे, और सामान्य रूप से खेल खेलेंगे। कुलीन गेमर्स के लिए, यह GUI का कम से कम हकलाना था जो वास्तव में उनके गेमप्ले को प्रभावित करता था। यह साबित करने की कोशिश की जा रही है कि कौन सा विलंब उपयोगकर्ताओं के लिए स्वीकार्य होगा और कौन सा मुश्किल नहीं है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.