सही उत्तर आपके द्वारा डिज़ाइन किए जा रहे वास्तविक गेम पर थोड़ा निर्भर करता है, और दूसरे को चुनने पर वास्तव में दोनों को लागू करने की आवश्यकता होती है और यह पता लगाने के लिए प्रोफाइलिंग करनी होती है कि आपके विशिष्ट गेम में कौन अधिक समय या स्थान कुशल है।
ग्रिड का पता लगाना केवल चलती वस्तुओं और स्थिर पृष्ठभूमि के बीच टकराव का पता लगाने के लिए लागू होता है। इसका सबसे बड़ा फायदा यह है कि स्थिर बैकग्राउंड को एक सन्निहित मेमोरी ऐरे के रूप में दर्शाया जाता है, और यदि आप कई रीड्स करना चाहते हैं, तो प्रत्येक टकराव लुकअप ओ (1) अच्छी लोकेशन के साथ होता है (क्योंकि इकाइयां ग्रिड में एक से अधिक सेल को कवर करती हैं)। नुकसान, अगर स्थैतिक पृष्ठभूमि बड़ी है, तो ग्रिड अंतरिक्ष के बजाय बेकार हो सकता है।
यदि इसके बजाय आप क्वाडट्री के रूप में स्टेटिक बैकग्राउंड का प्रतिनिधित्व करते हैं, तो व्यक्तिगत लुकअप की लागत बढ़ जाती है, लेकिन क्योंकि बैकग्राउंड के बड़े ब्लॉक थोड़ी मात्रा में जगह लेते हैं, मेमोरी आवश्यकताएं कम हो जाती हैं, और इसलिए बैकग्राउंड का अधिक हिस्सा अंदर बैठ सकता है। कैश। यहां तक कि अगर इस तरह की संरचना में एक लुकअप करने के लिए 10 बार लगता है, अगर यह कैश में है, तो यह अभी भी कैश मिस के साथ सिंगल लुकअप की तुलना में 10 गुना तेज होगा।
अगर मुझे पसंद का सामना करना पड़ा तो? मैं ग्रिड कार्यान्वयन के साथ जाऊंगा, क्योंकि यह करना आसान है, बेहतर है कि मैं अपना समय अन्य, अधिक दिलचस्प समस्याओं पर बिताऊँ। अगर मुझे लगता है कि मेरा खेल थोड़ा धीमा चल रहा है, तो मैं कुछ रूपरेखा तैयार करूंगा और देखूंगा कि कुछ मदद का उपयोग क्या हो सकता है। अगर ऐसा लगता है कि गेम टक्कर का पता लगाने में बहुत समय बिता रहा है, तो मैं एक और कार्यान्वयन की कोशिश करूंगा, एक क्वाडट्री की तरह (सभी आसान सुधारों को समाप्त करने के बाद), और पता करें कि क्या मदद की है।
संपादित करें: मुझे एक सुराग नहीं मिला है कि ग्रिड टकराव का पता लगाने के कई, मोबाइल संस्थाओं के टकराव का पता लगाने से संबंधित है, लेकिन इसके बजाय, मैं जवाब दूंगा कि कैसे एक स्थानिक सूचकांक (क्वाडट्री) पुनरावृत्ति समाधान पर पता लगाने के प्रदर्शन में सुधार करता है। भोली (और आमतौर पर पूरी तरह से ठीक है) समाधान इस तरह दिखता है:
foreach actor in actorList:
foreach target in actorList:
if (actor != target) and actor.boundingbox intersects target.boundingbox:
actor.doCollision(target)
यह स्पष्ट रूप से O (n ^ 2) के आसपास प्रदर्शन करता है, n के साथ अभिनेताओं की संख्या जो वर्तमान में खेल में जीवित हैं, जिसमें बुलेट और स्पेसशिप और एलियंस शामिल हैं। इसमें छोटी स्थिर बाधाएँ भी शामिल हो सकती हैं।
यह काल्पनिक रूप से इतनी अच्छी तरह से काम करता है जब तक कि इस तरह की वस्तुओं की संख्या यथोचित रूप से छोटी होती है, लेकिन जब जांच करने के लिए कुछ सौ से अधिक ऑब्जेक्ट होते हैं, तो थोड़ा गरीब लगने लगता है। 10 वस्तुओं का परिणाम सिर्फ 100 टकराव की जाँच में होता है, 100 परिणाम 10,000 जाँच में। एक लाख चेक में 1000 परिणाम।
एक स्थानिक सूचकांक (जैसे quadtrees) ज्यामितीय रिश्तों के अनुसार एकत्र की जाने वाली वस्तुओं की कुशलता से गणना कर सकता है। यह टकराव एल्गोरिथ्म को कुछ इस तरह से बदल देगा:
foreach actor in actorList:
foreach target in actorIndex.neighbors(actor.boundingbox):
if (actor != target) and actor.boundingbox intersects target.boundingbox:
actor.doCollision(target)
इसकी दक्षता (संस्थाओं के एक समान वितरण को मानते हुए): आमतौर पर O (n ^ 1.5 लॉग (n)) है, क्योंकि इंडेक्स लॉग के बारे में लेता है (n) ट्रैवर्स से तुलना, sqrt (n) पड़ोसियों की तुलना करने के बारे में होगा , और जाँच करने के लिए n अभिनेता हैं। वास्तविक रूप से, हालांकि, पड़ोसियों की संख्या हमेशा काफी सीमित होती है, क्योंकि यदि टक्कर होती है, तो अधिकांश समय वस्तुओं में से एक को हटा दिया जाता है, या टक्कर से दूर चला जाता है। इस प्रकार आपको सिर्फ O (n log (n)) मिलता है। 10 संस्थाओं के लिए, आप 10 (लगभग) 10 तुलना करते हैं, 100 के लिए, आप 200 करते हैं, 1000 के लिए आप 3000 करते हैं।
वास्तव में एक चतुर सूचकांक भी पड़ोसी खोज को थोक पुनरावृत्ति के साथ जोड़ सकता है, और प्रत्येक इंटरसेक्टिंग इकाई पर कॉलबैक कर सकता है। यह O (n) के बारे में एक प्रदर्शन देगा, क्योंकि सूचकांक को n के बजाय एक बार स्कैन किया जा रहा है।
