एक मूल looping 2D मल्टीप्लेयर स्तर बनाना?

Question

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

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

इस विचार को जोड़ने के लिए और इस मुद्दे को ठीक करने के लिए मैं निम्नलिखित आया हूं: एक ट्रिगर ज़ोन (छवि में लाल वर्ग) है जहां खिलाड़ी "क्लोन ज़ोन" (हरा वर्ग) देख पाएंगे। इस हरे रंग के वर्ग में, ट्रिगर ज़ोन के विपरीत तरफ की वस्तुओं को इसके संबंधित क्लोन ज़ोन में कॉपी किया जाएगा (A & आकृतियों के साथ देखा जा सकता है)। जब एक खिलाड़ी "क्लोन ज़ोन" के शुरुआती किनारे पर पहुंच जाता है, तो उन्हें नक्शे के दूसरी तरफ टेलीपोर्ट किया जाता है।

इस उदाहरण में खिलाड़ी 2 को लगता है कि वे खिलाड़ी 1 देख रहे हैं, हालांकि वे वास्तव में उसके क्लोन और इसके विपरीत देख रहे होंगे।

यह हाथ में समस्या के लिए थोड़ा चरम और जटिल लग रहा था। मेरा प्रश्न अब यह जानना है कि क्या यह समाधान समस्या से निपटने के लिए एक अच्छा तरीका है, या इस समस्या को हल करने का एक सरल तरीका है?

Comments

क्या खिलाड़ियों को पिछले क्षेत्र में पीछे जाने की अनुमति है?

— जिओचुआन यू जूल

हाँ, आगे और पीछे तो यह "दुनिया भर में घूमना" प्रभाव देता है। स्टारबाउंड में एक दुनिया कैसी है

— केनक्यूयूएसो

क्या आपने सिर्फ दुनिया को एक बड़ा दायरा बनाने पर विचार किया है? या एक बड़े सर्कल के रूप में स्तर का इलाज करना और इसे एक फ्लैट 2 डी चरण में अनुवाद करना?

— नजूल

क्या आप हमेशा खिलाड़ी की स्थिति को नियंत्रित करने के साथ कैमरा स्थिति संरेखित नहीं कर सकते हैं?

— अली

Answer 1

इन सभी ट्रिगर्स के साथ यह सिस्टम थोड़ा बहुत जटिल और त्रुटि प्रवण लगता है।

आप मॉडुलो का उपयोग करके खिलाड़ी की स्थिति को कुछ इस तरह से लपेट सकते हैं playerPositionX = playerPositionX % mapWidth

इस तरह से जब अपने खिलाड़ी पहुंचता है 0 वापस करने के लिए रीसेट कर देगा।playerPosition == mapWidthplayerPosition

यह समाधान पूरे प्रतिपादन प्रणाली के साथ बढ़ाया जा सकता है।

Comments

क्या खिलाड़ियों के पास ऐसे खिलाड़ियों को देखने का मुद्दा नहीं होगा, जिनकी स्थिति दूर हो जाएगी?

— KenQueso

आप इसे रेंडरिंग सिस्टम में कैसे विस्तारित करेंगे?

— मिकेल हॉजस्ट्रम

आप हमेशा कैमरे के केंद्र में एक खिलाड़ी रख सकते हैं और मानचित्र को चारों ओर से लपेट सकते हैं। पृथ्वी मोड पर सभ्यता में एक नक्शे की तरह। एक अन्य दृष्टिकोण खिलाड़ी के दृश्य भाग को मानचित्र के दोनों ओर प्रस्तुत करना हो सकता है।

— एक्सैला जूल

@ MikaelHögström बस हमेशा की तरह प्रस्तुत करना, लेकिन दाएं किनारे के करीब की चीजों को दूसरी बार बाईं ओर (यानी pos - map_width) पर प्रदान करना होगा।

— मारियो

आपके कोड में कहीं भी आप 'इस ऑब्जेक्ट में क्या वस्तु देख रहे हैं' या 'इस ऑब्जेक्ट के निर्देशांक क्या हैं', आप इसे xcoord% mapWidth बना देंगे। यह आपके कोड के बिना कहना मुश्किल है, लेकिन यह संभवतः इसे सही ढंग से प्रस्तुत करना होगा।

— टिन मैन

Answer 2

पोर्टल का उपयोग करने के लिए विहित समाधान है । आपके उदाहरण में, केवल एक स्तर है, सिवाय एक पोर्टल है जो बाएं और दाएं छोर को जोड़ता है।

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

आपके कैमरे को पोर्टल्स का भी समर्थन करने की आवश्यकता है; यदि पोर्टल कैमरे के अंदर है, तो उसे पोर्टल के दोनों ओर के स्तर के भागों को प्रस्तुत करना होगा। यदि आप सीमलेस टाइल ग्राफिक्स के लिए छवि संपादकों से परिचित हैं, तो यह वही सौदा है।

कठिन बात यह है कि सब कुछ दूरी या पथ के साथ काम करेंगे भी समर्थन पोर्टल की जरूरत है। इसमें AI, लाइन-ऑफ-विज़न एल्गो, साउंड एटेन्यूएशन आदि शामिल हैं।

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

Comments

यदि आप पोर्टल गेम की कमेंट्री सुनते हैं, तो पोर्ट के काम का हिस्सा छेद के माध्यम से दिखाई देने वाले व्हाट्स द्वारा क्लोन करके लागू किया जाता है। (लेकिन भौतिकी के कारणों के बजाय प्रतिपादन)

— मूइंग डक

Answer 3

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

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

इसका मतलब है कि क्लोन बनाने या किसी को टेलीपोर्ट करने की कोई आवश्यकता नहीं है। अनिवार्य रूप से आप क्लोन बना रहे हैं, सिर्फ पात्रों को एक-दूसरे की स्क्रीन पर रेंडर करके।

Answer 4

दुनिया से प्रतिपादन को डिस्कनेक्ट करें और आप किसी भी क्लोनिंग या टेलीपोर्टिंग कलाकृतियों का सहारा लिए बिना रैपराउंड और सही प्रतिपादन कर सकते हैं।

सबसे पहले, अपनी दुनिया में आप से एक निश्चित आकार दुनिया है, 0के लिए Width। जब भी कोई वस्तु 0 से नीचे जाती है तो आप उसे अंत तक लपेटते हैं, और कभी भी कोई वस्तु Widthशुरू होने पर उसे लपेट देती है। इसका मतलब है कि आपकी दुनिया की सभी तार्किक वस्तुएँ हमेशा सीमा के भीतर होती हैं 0...Width।

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

खोज करते समय चाल को ऑब्जेक्ट की स्थिति Baseको बाईं ओर के सापेक्ष वापस करना है । यह स्क्रीन के स्थानीय निर्देशांक में परिवर्तित हो जाता है, इसलिए रेंडरर को मोड्यूलो के बारे में चिंता करने की आवश्यकता नहीं है, केवल लुकअप करता है।

आपको कुछ भी क्लोन करने की आवश्यकता नहीं है क्योंकि प्रत्येक रेंडरर केवल एक ही स्थान पर ऑब्जेक्ट के साथ व्यवहार करता है।

यदि आपकी दुनिया सेगमेंट में या 3D संरचनाओं का उपयोग करके बनाई गई है, तो आपको इसे सेगमेंट करना होगा। इस प्रकार यह एक सामान्य ब्लॉक नहीं है, लेकिन इस प्रतिपादन को समायोजित करने के लिए स्थानांतरित किया जा सकता है। आपको न्यूनतम 2 पर, कई ब्लॉक की आवश्यकता नहीं है।

Answer 5

मुझे लगता है कि खेल और उपयोगकर्ता के लिए पूरी तरह से पारदर्शी एक अंतर्निहित डेटा संरचना में अपनी लिपटी दुनिया को लागू करने के लिए एकमात्र उचित दृष्टिकोण होगा। तो कुछ लो-लेवल पर आपके पास एक फंक्शन mapCoordinate () है, जो आपके वास्तविक निर्देशांक को आपके अंतर्निहित मैप-रिसोर्स पर लपेटता है ...

इसलिए यदि आपकी वास्तविक दुनिया केवल 10units चौड़ी है, तो खिलाड़ी और खेल इसे नहीं जान पाएंगे। खिलाड़ी के लिए दुनिया अनंत है - और अगर खेल पूछता है कि स्थिति 15 में क्या है - अंतर्निहित फ़ंक्शन इस अनुरोध का अनुवाद करेगा, modulo10 और स्थिति 5 पर आइटम को पैक करेगा।

तो पूरे खेल तर्क और बाकी सभी चीजों के लिए यह ठीक उसी तरह है जैसे आपके पास एक अनंत बड़ी दुनिया है, जहां सिर्फ हर चीज की प्रतियां होती हैं।

Answer 6

यह बिल्कुल समान नहीं है, लेकिन मैंने गेम जाम पर कुछ समान लागू किया। खेल में खिलाड़ी एक छोटे से गोलाकार स्तर पर घूम रहे थे, जब खिलाड़ी पी के 'x' स्थिति में पहुँच गया था। रेंडर करना आसान था क्योंकि हमने अभी सब कुछ प्रस्तुत किया और फिर एक ऑफसेट कैमरा घुमाया जो कि चल रहा था। आप कुछ ऐसा ही लागू कर सकते हैं, जैसा कि ऊपर बताया गया है:

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