कैसे तय करें कि गेमऑबजेक्ट को टक्कर को संभालना चाहिए?

Question

किसी भी टकराव में, दो GameObjects सही शामिल हैं? जो मैं जानना चाहता हूं वह यह है कि मैं कैसे तय करूं कि किस वस्तु में मेरा अस्तित्व होना चाहिए OnCollision*?

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

OnCollisionEnter(Collision coll) {
    if (coll.gameObject.compareTag("Spike")) {
        Destroy(gameObject);
    }
}

बेशक, स्पाइक ऑब्जेक्ट पर एक स्क्रिप्ट होने के बजाय सटीक समान कार्यक्षमता प्राप्त की जा सकती है जिसमें इस तरह का कोड है:

OnCollisionEnter(Collision coll) {
    if (coll.gameObject.compareTag("Player")) {
        Destroy(coll.gameObject);
    }
}

जब भी दोनों वैध होते हैं, तो मेरे लिए प्लेयर पर स्क्रिप्ट होना ज्यादा मायने रखता है , क्योंकि इस मामले में, जब टक्कर होती है, तो प्लेयर पर एक कार्रवाई की जा रही है ।

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

OnCollisionEnter(Collision coll) {
    GameObject other = coll.gameObject;
    if (other.compareTag("Spike") || other.compareTag("Lava") || other.compareTag("Enemy")) {
        Destroy(gameObject);
    }
}

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

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

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

---

किसी भी जानकारी बहुत सराहना की है! अपना समय देने के लिए धन्यवाद :)

Comments

पहले टैग के लिए स्ट्रिंग शाब्दिक क्यों? एक एनुम बहुत बेहतर है क्योंकि एक टाइपो बग को ट्रैक करने के लिए कड़ी मेहनत के बजाय एक संकलन त्रुटि में बदल जाएगा (मेरी स्पाइक मुझे क्यों नहीं मार रही है?)।

— शाफ़्ट फ्रीक

क्योंकि मैं एकता ट्यूटोरियल का पालन कर रहा हूं और यही उन्होंने किया है। तो, क्या आपके पास टैग नाम का एक सार्वजनिक एनम होगा जिसमें आपके सभी टैग मूल्य शामिल हैं? तो इसके Tag.SPIKEबजाय यह होगा ?

— Redtama

दोनों दुनिया का सर्वश्रेष्ठ पाने के लिए, एक एनुम के साथ, साथ ही साथ स्थिर ToString और FromString विधियों के साथ एक संरचना का उपयोग करने पर विचार करें

— zcabjro

बहुत से संबंधित: शून्य व्यवहार OOP में वस्तुओं - मेरे डिजाइन दुविधा और एरिक Lippert के जादूगरों और योद्धाओं श्रृंखला: ericlippert.com/2015/04/27/wizards-and-warriors-part-one

Answer 1

मैं व्यक्तिगत रूप से ऐसे आर्किटेक्ट सिस्टम को पसंद करता हूं जो न तो टकराव में शामिल ऑब्जेक्ट को संभालता है, और इसके बजाय कुछ टकराव से निपटने वाले प्रॉक्सी को कॉलबैक के साथ संभालना पड़ता है HandleCollisionBetween(GameObject A, GameObject B)। इस तरह मुझे यह सोचने की ज़रूरत नहीं है कि तर्क कहाँ होना चाहिए।

यदि वह विकल्प नहीं है, जैसे कि जब आप टकराव-प्रतिक्रिया वास्तुकला के नियंत्रण में नहीं होते हैं, तो चीजें थोड़ी अस्पष्ट हो जाती हैं। आम तौर पर जवाब "यह निर्भर करता है।"

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

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

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

Comments

मुझे सभी के उत्तर वास्तव में मददगार लगे लेकिन इसकी स्पष्टता के लिए आपको स्वीकार करना होगा। आपका अंतिम पैराग्राफ वास्तव में इसे मेरे लिए सम्‍मिलित करता है :) बेहद मददगार! आपको बहुत - बहुत धन्यवाद!

— Redtama

Answer 2

टीएल; डॉ । टक्कर डिटेक्टर लगाने के लिए सबसे अच्छी जगह वह जगह है जहां आप मानते हैं कि यह टक्कर में सक्रिय तत्व है, टक्कर में निष्क्रिय तत्व के बजाय , क्योंकि शायद आपको इस तरह के सक्रिय तर्क में निष्पादित करने के लिए अतिरिक्त व्यवहार की आवश्यकता होगी (और, एसओएलआईडी जैसे अच्छे ओओपी दिशानिर्देशों का पालन करना, सक्रिय तत्व की जिम्मेदारी है )।

विस्तृत :

चलो देखते हैं ...

मेरा दृष्टिकोण जब मुझे एक ही संदेह है, खेल इंजन की परवाह किए बिना , यह निर्धारित करना है कि कौन सा व्यवहार सक्रिय है और कौन सा व्यवहार उस कार्रवाई के संबंध में निष्क्रिय है जिसे मैं संग्रह पर ट्रिगर करना चाहता हूं।

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

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

इस व्यवहार की कल्पना करें:

1. एक वस्तु को जमीन पर ढेर के रूप में निर्दिष्ट करने के लिए व्यवहार। आरपीजी खेल जमीन में मौजूद वस्तुओं के लिए इसका इस्तेमाल करते हैं।

   public class Treasure : MonoBehaviour {
       public InventoryObject inventoryObject = null;
       public uint amount = 1;
   }

2. क्षति का उत्पादन करने में सक्षम एक वस्तु निर्दिष्ट करने के लिए व्यवहार। यह लावा, एसिड, कोई भी विषाक्त पदार्थ, या एक उड़ने वाला प्रोजेक्टाइल हो सकता है।

   public class DamageDealer : MonoBehaviour {
       public Faction facton; //let's use it as well..
       public DamageType damageType = DamageType.BLUNT;
       public uint damage = 1;
   }

इस सीमा तक, विचार करें DamageTypeऔर InventoryObjectजैसा कि एनम हैं।

ये व्यवहार सक्रिय नहीं हैं , इस तरह से कि ज़मीन पर होने या इधर-उधर उड़ने से वे स्वयं कार्य नहीं करते हैं। वे कुछ नहीं करते। उदाहरण के लिए, यदि आपके पास एक आग का गोला खाली जगह में उड़ रहा है, तो यह नुकसान करने के लिए तैयार नहीं है (शायद दूसरों के व्यवहार को आग के गोले में सक्रिय माना जाना चाहिए, जैसे आग का गोला यात्रा करते समय अपनी शक्ति का उपभोग करता है और प्रक्रिया में अपनी क्षति शक्ति को कम करता है, लेकिन यहां तक ​​कि जब एक संभावित FuelingOutव्यवहार विकसित किया जा सकता है, तो यह एक और व्यवहार को डगमगाता है, और उसी डैमेजप्रोड्यूसर व्यवहार को नहीं), और यदि आप जमीन में कोई वस्तु देखते हैं, तो यह पूरे उपयोगकर्ताओं की जाँच नहीं कर रहा है और सोच सकता है कि क्या वे मुझे उठा सकते हैं?

हमें उसके लिए सक्रिय व्यवहार की आवश्यकता है । समकक्ष होंगे:

1. क्षति उठाने के लिए एक व्यवहार (इसमें जीवन और मृत्यु को संभालने के लिए एक व्यवहार की आवश्यकता होती है, क्योंकि जीवन को कम करने और क्षति प्राप्त करने के लिए आमतौर पर अलग-अलग व्यवहार होते हैं, और क्योंकि मैं इस उदाहरण को यथासंभव सरल रखना चाहता हूं) और शायद क्षति का विरोध करता हूं ।

   public class DamageReceiver : MonoBehaviour {
       public DamageType[] weakness;
       public DamageType[] halfResistance;
       public DamageType[] fullResistance;
       public Faction facton; //let's use it as well..
   
       private List<DamageDealer> dealers = new List<DamageDealer>(); 
   
       public void OnCollisionEnter(Collision col) {
           DamageDealer dealer = col.gameObject.GetComponent<DamageDealer>();
           if (dealer != null && !this.dealers.Contains(dealer)) {
               this.dealers.Add(dealer);
           }
       }
   
       public void OnCollisionLeave(Collision col) {
           DamageDealer dealer = col.gameObject.GetComponent<DamageDealer>();
           if (dealer != null && this.dealers.Contains(dealer)) {
               this.dealers.Remove(dealer);
           }
       }
   
       public void Update() {
           // actually, this should not run on EVERY iteration, but this is just an example
           foreach (DamageDealer element in this.dealers)
           {
               if (this.faction != element.faction) {
                   if (this.weakness.Contains(element)) {
                       this.SubtractLives(2 * element.damage);
                   } else if (this.halfResistance.Contains(element)) {
                       this.SubtractLives(0.5 * element.damage);
                   } else if (!this.fullResistance.Contains(element)) {
                       this.SubtractLives(element.damage);
                   }
               }
           }
       }
   
       private void SubtractLives(uint lives) {
           // implement it later
       }
   }

   यह कोड अप्रयुक्त है और एक अवधारणा के रूप में काम करना चाहिए । क्या उद्देश्य है? नुकसान कुछ ऐसा है जिसे कोई महसूस करता है , और वस्तु के सापेक्ष (या जीवित रूप) क्षतिग्रस्त हो रहा है, जैसा कि आप समझते हैं। यह एक उदाहरण है: नियमित रूप से आरपीजी गेम में, एक तलवार आपको नुकसान पहुंचाती है , जबकि इसे लागू करने वाले अन्य आरपीजी में (उदाहरण के लिए सुमोन नाइट स्वोर्डक्राफ्ट स्टोरी I और II ), एक तलवार भी एक कठिन हिस्से को मारकर या कवच को अवरुद्ध करके नुकसान प्राप्त कर सकती है, और इसकी आवश्यकता हो सकती है मरम्मत । इसलिए, चूंकि क्षति तर्क रिसीवर के सापेक्ष है और प्रेषक को नहीं है, इसलिए हम केवल प्रेषक और प्रासंगिक तर्क में प्रासंगिक डेटा डालते हैं।

2. यह एक इन्वेंट्री होल्डर पर लागू होता है (एक अन्य आवश्यक व्यवहार जमीन पर होने वाली वस्तु से संबंधित होगा, और इसे वहां से हटाने की क्षमता)। शायद यह उचित व्यवहार है:

   public class Inventory : MonoBehaviour {
       private Dictionary<InventoryObject, uint> = new Dictionary<InventoryObject, uint>();
       private List<Treasure> pickables = new List<Treasure>();
   
       public void OnCollisionEnter(Collision col) {
           Treasure treasure = col.gameObject.GetComponent<Treasure>();
           if (treasure != null && !this.pickables.Contains(treasure)) {
               this.pickables.Add(treasure);
           }
       }
   
       public void OnCollisionLeave(Collision col) {
           DamageDealer treasure = col.gameObject.GetComponent<DamageDealer>();
           if (treasure != null && this.pickables.Contains(treasure)) {
               this.pickables.Remove(treasure);
           }
       }
   
       public void Update() {
           // when certain key is pressed, pick all the objects and add them to the inventory if you have a free slot for them. also remove them from the ground.
       }
   }

Answer 3

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

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

तो, आपके पास स्पाइक्स हैं जो खिलाड़ी को नुकसान पहुंचाते हैं। अपने आप से पूछो:

• क्या खिलाड़ी के अलावा अन्य चीजें हैं जो स्पाइक्स को नुकसान पहुंचाना चाहते हैं?
• क्या स्पाइक्स के अलावा अन्य चीजें हैं जो खिलाड़ी को टक्कर से नुकसान उठाना चाहिए?
• क्या किसी खिलाड़ी के पास हर स्तर पर स्पाइक्स होंगे? क्या स्पाइक्स वाले हर स्तर पर एक खिलाड़ी होगा?
• क्या आपके पास स्पाइक्स पर भिन्नताएं हो सकती हैं जिन्हें अलग-अलग काम करने की आवश्यकता है? (जैसे? विभिन्न क्षति मात्रा / क्षति प्रकार?)

जाहिर है, हम इसके साथ दूर नहीं जाना चाहते हैं और एक अधिक-इंजीनियर प्रणाली का निर्माण करना चाहते हैं, जो हमें केवल एक मामले की बजाय एक लाख मामलों को संभाल सकती है। लेकिन अगर यह समान रूप से काम करता है (यानी इन 4 लाइनों को कक्षा ए बनाम कक्षा बी में डाल दिया जाए) लेकिन एक तराजू बेहतर है, तो यह निर्णय लेने के लिए अंगूठे का एक अच्छा नियम है।

इस उदाहरण के लिए, विशेष रूप से यूनिटी में, मैं स्पैक में क्षति-निपटने वाले तर्क को एक CollisionHazardघटक की तरह कुछ के रूप में रखने के लिए झुकूंगा , जो कि टकराव पर एक घटक में क्षति उठाने की विधि को कॉल करता हैDamageable । यहाँ पर क्यों:

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

Comments

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

— लुइस मूसली

Answer 4

यह वास्तव में कोई फर्क नहीं पड़ता कि टक्कर कौन संभालता है, लेकिन यह किसकी नौकरी के अनुरूप है।

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

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

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

public abstract class DamageController
{
    public Faction faction; //GOOD or BAD
    public abstract void ApplyDamage(float damage);
}

आप DamageControllerनुकसान को संभालने के लिए अपने खिलाड़ी GameObject में उपवर्ग कर सकते हैं , फिर Spikeटक्कर कोड में

OnCollisionEnter(Collision coll) {
    DamageController controller = coll.gameObject.GetComponent<DamageController>();
    if(controller){
        if(controller.faction == Faction.GOOD){
          controller.ApplyDamage(spikeDamage);
        }
    }
}

Answer 5

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

Answer 6

दोनों ऑब्जेक्ट टकराव को संभाल लेंगे।

टक्कर से कुछ वस्तुएं तुरंत ख़राब, टूटी या नष्ट हो जाएंगी। (गोलियां, तीर, पानी के गुब्बारे)

अन्य लोग बस उछलकर किनारे की तरफ लुढ़क जाएंगे। (चट्टानें) ये तब भी नुकसान उठा सकते हैं जब वे जिस चीज से टकराते हैं, वह काफी कठोर हो। चट्टानें एक मानव को मारने से नुकसान नहीं उठाती हैं, लेकिन वे एक स्लेज हथौड़ा से हो सकते हैं।

मनुष्यों जैसी कुछ स्क्विशी वस्तुओं को नुकसान होगा।

दूसरे एक दूसरे के लिए बाध्य होंगे। (मैग्नेट)

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

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

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

आपका गेम इंजन तब इंटरफेस के खिलाफ कोड करेगा, विशिष्ट वस्तु प्रकार नहीं।