2011-02-04 16 views
10

मैं एक साधारण टाइल-आधारित 2 डी गेम विकसित कर रहा हूं। मेरे पास एक स्तर है, जो वस्तुओं के साथ आबादी है जो टाइल्स और एक दूसरे के साथ बातचीत कर सकते हैं। टाइलमैप के साथ टकराव की जांच करना आसान है और यह रैखिक जटिलता वाले सभी वस्तुओं के लिए किया जा सकता है। लेकिन अब मुझे वस्तुओं के बीच टकराव का पता लगाना है और अब मुझे हर वस्तु को हर दूसरे वस्तु के खिलाफ जांचना है, जिसके परिणामस्वरूप वर्ग जटिलता है।टकराव का पता लगाने के लिए ओ (एन^2) जटिलता से बचें

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

उदाहरण के लिए, स्तर में वस्तुओं की कुल संख्या लगभग 500 है, के बारे में उनमें से 50 एक समय में स्क्रीन पर देखा जाता है ...

धन्यवाद!

+0

क्या आप सभी के लिए टकराव का पता लगाना चाहते हैं या सिर्फ दृश्य वस्तुओं के लिए? –

+0

एचएम। अभी तक यकीन नहीं। मुझे लगता है कि मैं स्क्रीन – SadSido

+0

के बाहर ऑब्जेक्ट्स के साथ टकरावों को अनदेखा कर सकता हूं, उस स्थिति में आप केवल दृश्यमान वस्तुएं एकत्र कर सकते हैं और उन पर टकराव का पता लगा सकते हैं। अभी भी ओ (एन^2) समय जटिलता। –

उत्तर

9

आप क्या वस्तुओं उन्हें कब्जा के बारे में टाइल्स स्टोर जानकारी क्यों न दें। तब टकराव का पता लगाया जा सकता है जब भी कोई ऑब्जेक्ट एक नए टाइल पर ले जाया जाता है, यह देखकर कि उस टाइल में पहले से ही कोई अन्य वस्तु है या नहीं।

इससे लगभग कुछ भी लागत नहीं होगी।

+2

+1 यह एक ट्रैक्टर पेड़ का उपयोग करने से एक बहुत ही सरल समाधान है। –

+1

और भी तेज़। – Peladao

+0

यह बुरा नहीं है, आप ऐसे मानचित्रों पर ए * भी चला सकते हैं। लेकिन ध्यान दें कि इससे बग और अन्य सीमाएं हो सकती हैं, उदा। यदि आप एक टाइल या ऐसी चीजों पर एक से अधिक ऑब्जेक्ट चाहते हैं। यह इस प्रतिबंध को भी ले जाता है कि सभी ऑब्जेक्ट्स को टाइल में फिट होना चाहिए, अन्यथा यह 2x1 टाइल ओबीजे को संभालने के लिए जटिल होगा। और ऐसा। – InsertNickHere

4

आप quadtree का उपयोग अंतरिक्ष विभाजित और वस्तुओं आप टक्कर के लिए जांच करने की जरूरत की संख्या को कम कर सकते हैं।

See this article - Quadtree demonstration.

And perhaps this - Collision Detection in Two Dimensions.

Or this - Quadtree (source included)

यह लग सकता है - पहली नजर में - कि यह पेड़ बनाए रखने के लिए CPU शक्ति का एक बहुत लेता है, लेकिन यह भी काफी जांच की संख्या कम कर देता है (पहले लिंक में प्रदर्शन देखें)।

+1

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

0

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

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

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

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

संबंधित मुद्दे