कार्ट्रिज-आधारित गेम कैसे प्रोग्राम किए गए थे? [बन्द है]

Question

मैं SNES, N64, अटारी की तरह सोच रहा हूं ... यहां तक ​​कि आज भी डीएस, मुझे लगता है।

एसएनईएस खेल आमतौर पर 4 एमबी से अधिक जगह नहीं लेते थे, और एन 64 गेम आमतौर पर 32 से 64 एमबी मूल्य के डेटा थे।

इन दिनों, आप मुश्किल से एक "हैलो वर्ल्ड" संकलित कर सकते हैं! परिणाम के संकलन के बिना कार्यक्रम 1.21 गीगाबाइट पैदा !! आंकड़े का। (एक तरफ मजाक करते हुए, फाइलें आज फिर से कुछ प्रौद्योगिकी की तुलना में टन और अंतरिक्ष के टन उठाती हैं।)

तो वो यह कैसे करते हैं?

• उन्होंने इन खेलों में क्या कार्यक्रम किया? एएसएम? एएसएम में पूरी बात ?!
• ग्राफिक्स कैसे बनाए गए? स्प्रैट शीट बनाने के लिए और कुछ मामलों में (N64 की तरह), 3 डी मॉडल को किस तकनीक से बनाया गया था?
• वे इन कारतूसों पर इतने स्तर, पात्र, quests और आइटम कैसे फिट हुए? मेरा मतलब है, लगभग 1 एमबी में एसएनईएस घड़ियों पर सुपर मारियो वर्ल्ड, और इसमें 96 निकास हैं! Ocarina of Time, Banjo-Kazooie, DK64 और कुछ अन्य खेलों में 64 एमबी से कम का समय था और इसमें विशाल दुनिया, सामग्री और 3 डी मॉडल थे!

क्षमा करें, अगर मेरे प्रश्न थोड़े से बाहर हैं, तो मुझे बहुत आश्चर्य हुआ कि इस तरह के छोटे स्टोरेज स्पेस में बहुत सारे महान शीर्षक फिट होने में सफल रहे।

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

Comments

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

— कोरी

संभावित डुप्लिकेट: gamedev.stackexchange.com/questions/443/…

एनईएस (एमडीबी में मेट्रॉइड स्रोत देखें) और एसएनईएस (वेब ​​पर कुछ यादृच्छिक 3 पार्टी गेम का स्रोत कोड बाहर है) का उपयोग एएसएम, एन 64 (ज़ेल्डा: एमएम की डिबग स्क्रीन दुर्घटना सी में फ़ाइल नाम का उपयोग करता है। सी

— Ivo वेटज़ेल

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

— वॉल्फडाउन

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

— भेड़ियाडॉन

Answer 1

यह कला और ऑडियो संसाधन हैं जो अंतरिक्ष में ले जाते हैं, प्रोग्रामिंग भाषा का विकल्प हार्डवेयर से सबसे अधिक प्राप्त करने के बारे में अधिक था।

एक उदाहरण के रूप में N64 का उपयोग करते हुए, अधिकांश 3 पार्टी गेम्स 8, 12 या 16Mb थे। 32 और 64Mb का खेल ज्यादातर निन्टेंडो से था क्योंकि गाड़ियों पर जहाज चलाना इतना महंगा था कि बाकी सभी के लिए बड़ा। यह छोटा लगता है, लेकिन फिर कला संपत्ति और अंतिम दृश्य आउटपुट थे। आपको यह याद रखना होगा कि अधिकांश N64 गेम 320x240 में 1280x760 या आज से अधिक नहीं हैं। इतने छोटे आउटपुट रिज़ॉल्यूशन के साथ, बनावट और स्प्राइट आज की तुलना में बहुत छोटे थे।

N64 पर छोटे बनावट कैश के कारण, अधिकांश बनावट 4x / 8bit पैलेट (उर्फ 16/256 रंग) के साथ 32x64 पिक्सेल थे। अतिरिक्त रंग विस्तार अक्सर बनावट और शीर्ष रंगों को मिलाकर किया जाता था। बैंजो खेल इसका एक अच्छा उदाहरण हैं।

आज एक अवास्तविक इंजन गेम में एक सिंगल रॉक में कई 512x512x24bpp या 32bpp होंगे। इसके अलावा सिर्फ एक फैलाने वाली बनावट के बजाय, अब आपको सामान्य नक्शे, स्पेकुलर मास्क, रिफ्लेक्शन मास्क, रिफ्लेक्शन क्यूबैप्स और बहुत कुछ मिला है। तो एक वस्तु जो 4Kb का उपयोग करती थी वह अब कई एमबी डेटा में आच्छादित है।

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

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

Comments

आह, एक तार्किक व्याख्या के साथ मारियो झाड़ियों / पेड़ों अनाचार! अति उत्कृष्ट।

— कजकाई

यह इंगित करने के लायक है कि गाड़ियां अक्सर मेगा बिट्स में आकार में होती थीं , मेगा बाइट्स में नहीं । वे 64Mb गाड़ियां केवल 8MB की थीं।

— डैश-टॉम-बैंग

N64 में आउटपुट 320 x 240 नहीं था। विवरण गलत हैं। ज्यादातर खेल शायद उपयोग कर रहे थे 256 × 224। यहाँ देखें

— wolfdawn

Answer 2

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

प्रोग्रामिंग लैंग्वेज के लिए: हाँ, यह सब असेंबली था। NES का मतलब है हार्डवेयर इंटरप्ट, DMA पोर्ट, बैंक स्विचिंग आदि के साथ सीधे काम करना। सौभाग्य से, 6502 (या यों कहें, 2A03) की प्रोग्रामिंग काफी आसान है [1]:

• कुछ रजिस्टर हैं: ए, एक्स और वाई मुख्य रूप से, बाद के दो केवल अनुक्रमण और पुनरावृत्ति के लिए उपयोग करने योग्य हैं
• निर्देश सेट छोटा है और ज्यादातर सीधा है
• बहुत सारी मेमोरी नहीं: मुख्य रैम 2KB है, जिसमें वैकल्पिक बैटरी समर्थित 8KB एक्सटेंशन है। उस 2KB में से 256 बाइट्स स्टैक और पेज 0 (पहले 256 बाइट्स) के लिए आरक्षित हैं, जहाँ आप कुछ विशेष एड्रेसिंग मोड्स के कारण अपने सबसे अधिक इस्तेमाल किए जाने वाले पॉइंटर्स और वैल्यूज़ को स्टोर करना चाहते हैं।

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

आपके कार्ट्रिज डेटा सीपीयू की पता योग्य सीमाओं से परे जाते ही यह थोड़ा चकरा जाता है। यह 64KB है, जिसका निचला 32KB पत्थर में सेट है और सभी प्रकार के हार्डवेयर पोर्ट और RAM में मैप किया गया है। यह वह जगह है जहाँ बैंक-स्विचिंग खेल में आती है, जिसका अर्थ है कि ROM के एक हिस्से को मैप करना (उच्चतर) 32KB पता स्थान।

यह प्रोग्रामर चाहता है, लेकिन इसका इस्तेमाल किया जा सकता है, लेकिन एक उदाहरण का उपयोग 3 स्तरों के साथ एक खेल हो सकता है, सभी स्तर के डेटा, मेटा डेटा और प्रत्येक स्तर के लिए कोड कारतूस पर अलग-अलग 8KB स्मृति क्षेत्रों में crammed। स्तर के लिए कॉलबैक हो सकता है जैसे कि इनिशियल इनिशियलाइज़ेशन, प्रति फ्रेम अपडेट इत्यादि। "लोड हो रहा है" का अर्थ होगा कि 8xB चंक मेमोरी का उदाहरण जैसे 0xC000। आप तब निर्दिष्ट कर सकते हैं कि init दिनचर्या हमेशा 0xC000 पर होती है, फ्रेम अपडेट दिनचर्या 0xC200 पर होती है और स्तर का डेटा 0xC800 से शुरू होता है। गेम का मुख्य कोड एक अन्य मेमोरी चंक में रखा गया है, तो सही चंक में स्वैप करके और उचित समय पर 0xC000 और 0xC200 पर जाकर पते में स्तर परिवर्तन को नियंत्रित करता है।

राइट ग्राफिकल डेटा: NES के टाइल डेटा 2-बिट 8x8 पिक्सेल नक्शे हैं। पृष्ठभूमि के लिए उन्हें 1/4 रिज़ॉल्यूशन 2-बिट परत के साथ जोड़ा जाता है। इन 4-बिट मूल्यों को तब 16-प्रविष्टि पैलेट में अनुक्रमित किया गया था, मेरा मानना ​​है कि 53 प्रभावी अद्वितीय रंग उपलब्ध हैं। स्प्राइट्स ने 2-बिट पिक्सेल डेटा का भी उपयोग किया और प्रत्येक स्प्राइट ने अपने 2-बिट समूह इंडेक्स को फिर से 4-बिट पाल इंडेक्स बनाते हुए निर्दिष्ट किया। स्क्रीन पर बीजी की छवि 32x30 सरणी की टाइल सूचकांक संख्या है।

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

देव वातावरण के रूप में, मैंने कुछ तस्वीरें देखीं, जहाँ लोगों ने काम के लिए EEPROM बर्नर तक जाने के लिए कुछ प्रमाणित प्राचीन कंप्यूटरों पर काम किया। SNES उम्र [2] के बाद तक टूल-असिस्टेड डिबगिंग वास्तव में एक संभावना नहीं थी। यह मुख्य कारण है कि इतने सारे पुराने खेलों में "स्पष्ट" कीड़े हैं और गेमशार्क जैसी चीजें वे क्यों कर सकते हैं; खिलाड़ी का स्वास्थ्य हमेशा मेम-लोकेशन X पर रहेगा, इसलिए आप इसे हर समय 100 पर रहने के लिए बाध्य कर सकते हैं।

अगर आपको ये बातें दिलचस्प लगती हैं तो मैं आपको उदाहरण के लिए देखने के लिए प्रोत्साहित करता हूँ जैसे कि http://wiki.nesdev.com/w/index.php/Nesdev_Wiki NES के लिए कुछ प्रोग्रामिंग कोर्स ऑनलाइन भी हैं।

मुझे उम्मीद है कि इस सरलीकृत अवलोकन ने 80 के दशक के खेल के विकास में कुछ अंतर्दृष्टि दी।

[१] अपेक्षाकृत बोलना। साथ ही मैं पक्षपाती हूं क्योंकि मैंने लगभग 85% पावरपीसी असेंबली में ग्रेबॉक्स लिखा था। [२] FF6 लेख बनाना देखें: http://www.edge-online.com/features/the-making-of-final-fantasy-vi/

Answer 3

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

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

अक्सर सामान्य ज्ञान का एक कलात्मक मिश्रण होता है, हालांकि खेल या शैली के लिए "ट्रिक्स" और "हैक्स" विशिष्ट होते हैं। अक्सर इसमें "किस्मत" का एक सा हिस्सा होता है, और एक टीम जो सीमा के लिए काम कर रही होती है, (शायद पूरी तरह से प्रक्रिया के दौरान उन सीमाओं के साथ हेडिंग जानकर), उनके उपलब्ध ट्रेड-ऑफ्स को जानकर, और कुछ आवश्यक व्यापार करने के लिए तैयार रहें -ऑफ्स और बलिदान उनकी सीमा को पूरा करने के लिए।

यहां कुछ चीजें दी गई हैं, जिनके बारे में मैं सोच सकता हूं कि टीम को छोटे आकार में एक खेल प्राप्त करने में मदद मिल सकती है:

• पुन: उपयोग करें आप क्या कर सकते हैं: एक ही स्प्रिट का पुन: उपयोग कर रहे हैं, और विविधताएँ जिन्हें आप आसानी से एक एकल स्प्राइट छवि (जैसे प्रतिबिंब, घुमाव, पैलेट शिफ्ट) से बचा सकते हैं, आपको स्थान बचाएंगे। एक ही कोड, संगीत, और एक खेल में लगभग सब कुछ के लिए चला जाता है।
• आप क्या कर सकते हैं संपीड़ित करें: वहाँ कई संपीड़ित योजनाएं हैं, और यह जानना कि कौन से उपयोग करना एक बड़ी जगह बचत हो सकती है। यहां तक ​​कि कभी-कभी सरल संपीड़न योजनाएं जैसे रन-लंबाई एन्कोडिंग एक आश्चर्यजनक अंतर बना सकती हैं। इतना ही नहीं, लेकिन व्यक्तिगत फ़ाइल प्रकारों के लिए संपीड़न योजनाएं (और वैकल्पिक प्रारूप जो बिल्कुल संपीड़न नहीं हैं), अक्सर गुणवत्ता व्यापार-नापसंद होती हैं। उदाहरण के लिए, तरंग / सीडी ऑडियो फाइलों को एमपी 3 फाइलों में जानकारी के कुछ मामूली नुकसान के साथ, संकुचित किया जा सकता है। इसके अलावा, MIDI और नमूना-आधारित MOD जैसे फ़ाइल प्रारूप वैकल्पिक प्रारूप हैं जो बहुत कम जगह लेते हैं, लेकिन संगीत को पूरी तरह से अलग करते हैं और उन्हें अच्छा बनाने के लिए विभिन्न कौशल की आवश्यकता होती है।
• क्या आप की जरूरत नहीं खोना: क्या आप इसे सस्ता कर सकते हैं? उदाहरण के लिए, क्या आप अभी भी कम पिक्सेल (या बहुभुज) में एक चरित्र के "व्यक्तित्व" को प्राप्त कर सकते हैं? क्या टाइलों की नियुक्ति को एक डिजाइनर द्वारा बिल्कुल परिभाषित करने की आवश्यकता है या क्या वे आपके प्रोग्राम कोड में अनियमित रूप से उत्पन्न हो सकते हैं?
• कोड अक्सर सस्ता होता है: हालाँकि आपने इस बात का मज़ाक बनाया था कि आमतौर पर एक कोड संकलन के लिए कितनी जगह होती है, अब विचार हो जाते हैं (और इस कारण हैं कि यह 'प्लेटफ़ॉर्म' पिछले कुछ वर्षों में क्यों बढ़ा है, और जब आपको बिल्कुल ज़रूरत हो तो इसे सिकोड़ने के तरीके)। लेकिन आम तौर पर यदि आप कुछ एल्गोरिदम / प्रक्रियात्मक / इन-कोड आसानी से कर सकते हैं, तो उस दृष्टिकोण को ट्वीक और अन्य समान लेकिन अलग दिखने वाली / महसूस करने वाली संपत्ति के लिए पुन: उपयोग करना आसान होगा। Fractals उदाहरण देखने के लिए एक विशेष रूप से आसान है: आपके पास एक जटिल भग्न की छवि हो सकती है जो गणितीय सूत्र की तुलना में बहुत अधिक जगह लेता है जो इसे उत्पन्न करता है। गणितीय सूत्र, इसके अतिरिक्त, ऐसे पैरामीटर हो सकते हैं जो समान उत्पन्न कर सकते हैं, लेकिन कभी-कभी आश्चर्यजनक रूप से अलग-अलग दिखने वाले चित्र।

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

Comments

इसके अलावा, कम जगह का उपयोग करने वाली तकनीक का उपयोग करें।

— स्पीड

(क्षमा करें, समस्या फिर से दर्ज करें ... इसे अक्षम करने का एक तरीका है? मुझे नफरत है कि हर बार जब मैं टिप्पणी सबमिट करता हूं तो प्रेस सबमिट करें)।

— स्पीड

एक और प्रवेश: / वैसे भी, कम अंतरिक्ष का उपयोग करने वाली तकनीक का उपयोग करें, जैसे प्रक्रियात्मक नक्शे (नोक्टिस में कई मिलियन सौर प्रणालियों के साथ एक पूरी आकाशगंगा है, ग्रहों के साथ कि आप जीवन, पेड़, खंडहर, भवन ... 3MB से कम में देख सकते हैं ), मॉड्यूल संगीत (.Mod, .xm, .it ... जैसे प्रारूपों में संगीत), प्रक्रियात्मक बनावट (werkkzeug, mapzone, और कुछ अन्य सॉफ्टवेयर देखें), प्रक्रियात्मक ध्वनि प्रभाव (लगभग कोई भी ध्वनि प्रभाव गणित से संभव है) समीकरण, या बुनियादी ध्वनि तरंगों का हेरफेर), और इसी तरह।

— स्पीड

@speeder आकस्मिक टिप्पणियों पर 'संपादित करें' या 'हटाएं' पर क्लिक करना आसान है ...

— डैश-टॉम-बैंग

पुन: "जो आप कर सकते हैं उसे संपीड़ित करें", पुराने हार्डवेयर पर आप आमतौर पर जो भी हार्डवेयर को संभाल सकते हैं उसे संपीड़ित करेंगे। आप ऑडियो को कभी भी एमपी 3 में संपीड़ित नहीं करेंगे, क्योंकि ऑडियो हार्डवेयर ने इसे मूल रूप से नहीं संभाला है और आप सीपीयू पर इसे डिकम्प्रेसिंग समय बर्बाद नहीं करना चाहेंगे, जब आप इसे मीडिया से सीधे ऑडियो हार्डवेयर में स्ट्रीम कर सकते हैं। मिडी महान था, हालांकि सभी के पास (और है) बोर्ड पर एक वेवटेबल सिंथ; बस अपने नमूने लोड और वहाँ तुम जाओ।

— डैश-टॉम-बैंग

Answer 4

एक बात मुझे यकीन नहीं है अगर यह अभी भी N64 युग के बाद में खड़ा है, लेकिन SNES और N64 अक्सर अन्य 3D वस्तुओं पर बनावट का पुन: उपयोग करते हैं जो अक्सर काफी जगह और पूर्व गाया कला को बचाते हैं जो पृष्ठभूमि अक्सर नकली होती हैं। एक और ट्रिक यह थी कि बॉर्डर बैकग्राउंड फॉग का इस्तेमाल किया जाए।

सैन फ्रांसिस्को रश एन ६४ में हमेशा कुछ कोहरा था, हालांकि सेटिंग घनत्व में बदलाव कर सकती है जहां सैन फ्रांसिस्को रश आर्केड में कोई भी नहीं था और आप एन १६ संस्करण की तुलना में ट्रैक १ पर गोल्डन गेट ब्रिज देख सकते थे।

इसके अलावा खेल अक्सर संगीत का पुन: उपयोग करते हैं जैसे समय का ज़ेल्डा ओकारिना संगीत का बहुत अधिक उपयोग करता है जो मुझे कष्टप्रद लगता है क्योंकि बैंजो काजू / डीके 64 जैसे विषयों के भीतर अक्सर विषयों के साथ बेहतर काम किया जा सकता था!

यदि आप पानी के भीतर जाते हैं या शॉप थीम में यंत्र बनाते हैं, तो समय का ज़ेल्डा ओकारिना ह्युरल ओवरवर्ल्ड और फिर थीम का एक अंडरवाटर संस्करण हो सकता है, कोकरी फ़ॉरेस्ट शॉप और सींगों के लिए बांसुरी और फ़िडल्स का इस्तेमाल किया जाएगा। Hyrule Castle Town की दुकान के लिए तुरही और Goron गांव में ड्रम

पीसी के 3 डी मॉड्यूल पुस्तकालयों में संकलित किए जाते हैं ताकि वे इसे अनपैक करने के लिए किसी प्रोग्राम का उपयोग करके उन्हें जल्दी से एक्सेस कर सकें लेकिन मुझे यकीन नहीं है कि निनटेंडो के साथ ऐसा ही है जो रोम आधारित है। पीसी की रैम एक गन्दे कमरे में जाने की तरह है जिसमें चीजें हमेशा नहीं रहती हैं जहाँ उन्हें माना जाता है और कंप्यूटर को शुरू नहीं होने की जानकारी को अधिलेखित किया जा सकता है!

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