2 डी गेम के लिए एक नक्शा बनाने का सबसे अच्छा तरीका?


16

मैं व्यक्तिपरक "सर्वश्रेष्ठ" कीवर्ड के लिए माफी माँगता हूँ।

मेरे दोस्त और मैंने एक 2 डी साहसिक खेल का निर्माण शुरू किया है। यह पोकेमॉन या ज़ेल्डा (सिर्फ परिप्रेक्ष्य) की शैली में ऊपर-नीचे होगा। हम एक बड़े विश्व-मानचित्र बनाने के तरीकों पर चर्चा कर रहे हैं जो खिलाड़ी हमारी मशीन की मेमोरी क्षमताओं को बिना तनाव के पार कर सकता है।

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

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

आज, उसने मुझे बताया कि वह एक साधारण 2D सरणी मैप बनाना चाहता था [WIDTH] [HEIGHT] जिसमें गेम के हर ग्रिड के बारे में डेटा है और डेटा के लिए एक निरंतर सेव-टू-डिस्क ऑपरेशन है जिसकी हमें आवश्यकता नहीं है।

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


आप किस मशीन का उपयोग कर रहे हैं?
डेविड तितरेंको

SFML का उपयोग करके C ++ के साथ विंडोज अब तक (SFML परिवर्तन के अधीन है; C ++ नहीं है)। हम पोर्टेबिलिटी एटीएम के लिए लक्ष्य नहीं कर रहे हैं।
IAE

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

जवाबों:


27

सबसे पहले, अपने मानचित्र के आकार का अनुमान लगाएं। बस यह मत समझो कि एक "बड़ी दुनिया" स्मृति में फिट होने वाली नहीं है। आजकल, मेमोरी में 10 mb से ऊपर की तरफ ले जाने वाला नक्शा बिलकुल स्वीकार्य है, और आप एक साधारण टाइल-आधारित 2D दुनिया में 10 mb में LOT भर सकते हैं।

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

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


6
कुछ चित्रण गणित: 10MB का टाइल * आपको प्रति वर्ग 1619 टाइल्स के साथ एक वर्ग मिलता है। मूल ज़ेल्डा के नक्शे लंबे किनारे पर 256 टाइल थे और आधे से कम थे जो छोटी तरफ - इसलिए आपका नक्शा उस मेमोरी उपयोग के साथ पहले ज़ेल्डा की तुलना में 36x बड़ा हो सकता है। क्या आप वास्तव में इतनी सामग्री बनाने के लिए तैयार हैं ? (नहीं।)

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

5

व्यक्तिगत रूप से, मैं टाइलईड जैसे नामित टाइल-संपादक का उपयोग करके मानचित्र का निर्माण करूंगा । इस दृष्टिकोण से कई लाभ मिलते हैं:

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

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

टाइल्स को स्क्रीन पर ब्लिट करना संभवतः आपके नक्शे को प्रस्तुत करने का सबसे तेज़ तरीका है। मुझे एसएफएमएल का पता नहीं है, लेकिन उनकी साइट पर डॉक्स से आपको Spriteक्लास में देखना चाहिए या क्लास के Copyफंक्शन का इस्तेमाल करना चाहिए Image

अद्यतन: मैं सिर्फ SFML डॉक्स में से कुछ पढ़ता हूं और आपको प्रदर्शन के लिए छवियों का हेरफेर करने के बजाय निश्चित रूप से उपयोग करना चाहिए Drawableया करना चाहिए Sprite। जाहिरा तौर पर वहाँ एक टाइलयुक्त SFML लोडर है। यह शायद कुछ पाने और तेजी से चलने का एक अच्छा तरीका है।


1

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


0

मेरी राय में व्यक्तिगत टाइलों के 2 डी सरणी का उपयोग करना सबसे अच्छा है। आपके पास पूरे पूरे बड़े मानचित्र को एक 2 डी सरणी के रूप में हो सकता है और केवल इसका हिस्सा खींच सकते हैं जिसे किसी भी समय प्रदर्शित करने की आवश्यकता है। निम्नलिखित टैबेजोस (tbgs.js) HTML5 गेम लाइब्रेरी के साथ 2 डी मैप ऐरे का उपयोग करने का एक उदाहरण है; http://actiontad.com/tabageosHTML5/Examples/BlitMathCameraAndTravelers/


-3

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

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

मैं आपको बता सकता हूं कि मेरे लिए, मैं iPhone के लिए एक छोटा ओब्ज-सी परिवाद लिख रहा हूं जो एक 32x32 टाइलसेट लेता है और इसे एक NSImage में खींचता है। मुझे इस तरह से लगभग 10fps मिलता है, और मुझे शायद ओपनजीएल का उपयोग करना चाहिए, लेकिन मुझे केवल फिर से ड्रॉ करने की ज़रूरत है अगर चरित्र जड़ से निकल जाता है।

आपको मानचित्र को 9 स्क्रीन-आकार में विभाजित करना चाहिए (मेरे लिए यह 960x640 ब्लॉक है) यदि चरित्र केंद्र ब्लॉक से बाहर जाता है, तो मैं 9-स्क्रीन को एक बड़ी छवि (लगभग 1.2 एमबी) में फिर से खींचता हूं - बहुत कुछ देता है आईफोन 3 जी पर 20 एमबी की सीमा के तहत कमरा)। यह काफी धीरे-धीरे होता है (10fps की तुलना में बहुत धीमा) ताकि फिर से ड्राइंग खेलने के दौरान ध्यान देने योग्य न हो।

मैं कुछ बिंदु पर OpenGL ES की ओर बढ़ने की संभावना रखता हूं, लेकिन अभी के लिए यह ठीक काम करता है।


[संपादित करें]

मुझे स्पष्ट करने की अनुमति दें।

9-स्क्रीन पृष्ठभूमि के लिए ड्राइंग एल्गोरिथ्म 0.1 सेकंड (10fps फ्लैट-आउट) लेता है। जब तक आपका खिलाड़ी एक सेकंड के दसवें हिस्से से कम में पूरे स्क्रीन को नहीं खींच सकता, तब तक खेलने के दौरान रिड्राइविंग अगोचर होना चाहिए।


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

@ जो रेचनगिज ... ??? मैंने कहा कि यह मांग पर आकर्षित करता है, जब खिलाड़ी स्क्रीन को स्थानांतरित करता है, अन्यथा UIImageView के लिए पृष्ठभूमि की छवि को फिर से तैयार नहीं किया जाता है , इस प्रकार प्रसंस्करण शक्ति की बचत होती है। आपकी टिप्पणी का कोई मतलब नहीं है।
स्टीफन फुरलानी

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

@ हाँ, मुझे अभी भी यकीन नहीं है कि आप क्या कह रहे हैं। यह एक छवि बनाता है। फिर छवि को अकेला छोड़ दिया जाता है जब तक कि खिलाड़ी एक सीमा तक नहीं पहुंचता है, और फिर एक नई छवि को फिर से खींचता है। बैटरी जीवन कैसे बर्बाद करता है? यह केवल मांग पर "ड्रा" करता है, और बाकी समय UIImageView के मूल ड्राइंग एल्गोरिदम का उपयोग करके दृश्य तैयार किया जाता है।
स्टीफन फुरलानी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.