จะตัดสินใจได้อย่างไรว่า GameObject ควรจัดการกับการชนกันอย่างไร

ไม่ว่าจะเกิดการชนกัน GameObjects สองรายการมีส่วนเกี่ยวข้องหรือไม่ สิ่งที่ฉันต้องการที่จะรู้คือผมจะตัดสินใจอย่างไรว่าวัตถุที่ควรมีของฉันOnCollision*?

ตัวอย่างเช่นสมมติว่าฉันมีวัตถุผู้เล่นและวัตถุเข็ม ความคิดแรกของฉันคือการวางสคริปต์บนโปรแกรมเล่นที่มีรหัสดังนี้:

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

แน่นอนว่าฟังก์ชั่นเดียวกันนี้สามารถทำได้โดยแทนที่จะมีสคริปต์บนออบเจ็กต์ Spike ที่มีรหัสดังนี้:

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

ขณะที่ทั้งสองมีความถูกต้องมันจะทำให้รู้สึกมากขึ้นกับผมที่จะมีสคริปต์ในการเล่นเพราะในกรณีนี้เมื่อการปะทะกันเกิดขึ้นการดำเนินการจะถูกดำเนินการบนเครื่องเล่น

อย่างไรก็ตามสิ่งที่ทำให้ฉันสงสัยว่านี่คือในอนาคตคุณอาจต้องการเพิ่มวัตถุอื่น ๆ ที่จะฆ่าผู้เล่นในการปะทะกันเช่นศัตรู, ลาวา, ลำแสงเลเซอร์ ฯลฯ วัตถุเหล่านี้อาจมีแท็กที่แตกต่างกัน ดังนั้นสคริปต์บน Player จะกลายเป็น:

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

ขณะที่ในกรณีที่สคริปต์ที่อยู่บนเข็มทั้งหมดที่คุณจะต้องทำคือการเพิ่มว่าสคริปต์เดียวกันกับวัตถุอื่น ๆ KillPlayerOnContactที่สามารถฆ่าผู้เล่นและชื่อสิ่งที่สคริปต์เหมือน

นอกจากนี้ถ้าคุณมีการปะทะกันระหว่างผู้เล่นและศัตรู AA, แล้วคุณจะต้องการดำเนินการกับทั้งสอง ดังนั้นในกรณีนั้นวัตถุใดที่ควรจัดการกับการชน? หรือทั้งสองควรจัดการกับการชนกันและดำเนินการที่แตกต่างกันอย่างไร

ฉันไม่เคยสร้างเกมที่มีขนาดพอสมควรมาก่อนและฉันสงสัยว่ารหัสอาจยุ่งและยากที่จะรักษาตามที่มันโตขึ้นถ้าคุณได้รับสิ่งผิดประเภทนี้ในตอนแรก หรืออาจเป็นวิธีที่ถูกต้องและไม่เป็นไร

ความเข้าใจใด ๆ ที่ชื่นชมมาก! ขอขอบคุณสำหรับเวลาของคุณ :)

โดยส่วนตัวแล้วผมชอบที่จะออกแบบระบบที่วัตถุไม่เกี่ยวข้องกับการชนกันของมันและพร็อกซีที่จัดการการชนกันของข้อมูลกลับมาจัดการกับการโทรกลับเช่นHandleCollisionBetween(GameObject A, GameObject B)กัน ด้วยวิธีนี้ฉันไม่ต้องคิดว่าตรรกะควรอยู่ตรงไหน

หากนั่นไม่ใช่ตัวเลือกเช่นเมื่อคุณไม่ได้อยู่ในการควบคุมของสถาปัตยกรรมตอบสนองการชนสิ่งต่าง ๆ จะเลือนไปเล็กน้อย โดยทั่วไปคำตอบคือ "ขึ้นอยู่กับ"

เนื่องจากวัตถุทั้งสองจะได้รับการเรียกกลับที่ขัดแย้งกันฉันจึงใส่รหัสลงในทั้งคู่ แต่เฉพาะรหัสที่เกี่ยวข้องกับบทบาทของวัตถุนั้นในโลกของเกมในขณะที่พยายามรักษาความสามารถในการขยายให้มากที่สุด ซึ่งหมายความว่าหากตรรกะบางอย่างมีความหมายเท่าเทียมกันในวัตถุใดวัตถุหนึ่งให้วางไว้ในวัตถุที่อาจนำไปสู่การเปลี่ยนแปลงรหัสน้อยลงในระยะยาวเมื่อมีการเพิ่มฟังก์ชันการทำงานใหม่

ใส่อีกวิธีหนึ่งระหว่างประเภทวัตถุสองประเภทที่สามารถชนกันโดยทั่วไปประเภทวัตถุประเภทใดประเภทหนึ่งนั้นมีผลเหมือนกันกับชนิดของวัตถุมากกว่าประเภทอื่น การใส่รหัสสำหรับเอฟเฟกต์นั้นในประเภทที่มีผลต่อประเภทอื่น ๆ มากขึ้นหมายถึงการบำรุงรักษาน้อยลงในระยะยาว

ตัวอย่างเช่นวัตถุผู้เล่นและวัตถุกระสุน อาจกล่าวได้ว่า "การได้รับความเสียหายจากการชนด้วยกระสุน" ทำให้รู้สึกสมเหตุสมผลในฐานะเป็นส่วนหนึ่งของผู้เล่น "การใช้ความเสียหายกับสิ่งที่กระทบ" ทำให้เกิดความรู้สึกเชิงตรรกะในฐานะส่วนหนึ่งของกระสุน อย่างไรก็ตามกระสุนมีแนวโน้มที่จะใช้ความเสียหายกับวัตถุประเภทต่าง ๆ มากกว่าผู้เล่น (ในเกมส่วนใหญ่) ผู้เล่นจะไม่ได้รับความเสียหายจากสิ่งกีดขวางภูมิประเทศหรือ NPC แต่กระสุนอาจใช้ความเสียหายกับสิ่งเหล่านั้น ดังนั้นฉันอยากจะจัดการการชนกันเพื่อให้เกิดความเสียหายในกระสุนในกรณีนั้น

TL; DRสถานที่ที่ดีที่สุดในการวางเครื่องตรวจจับการชนคือสถานที่ที่คุณคิดว่ามันเป็นองค์ประกอบที่ใช้งานอยู่ในการปะทะแทนที่จะเป็นองค์ประกอบที่แฝงอยู่ในการปะทะเพราะบางทีคุณอาจต้องการพฤติกรรมเพิ่มเติมเพื่อดำเนินการในตรรกะที่ใช้งาน (และปฏิบัติตามแนวทาง OOP ที่ดีเช่น SOLID เป็นความรับผิดชอบขององค์ประกอบที่ใช้งานอยู่ )

รายละเอียด :

มาดูกัน ...

แนวทางของฉันเมื่อฉันมีข้อสงสัยเหมือนกันโดยไม่คำนึงถึงเอ็นจิ้นเกมคือการพิจารณาว่าพฤติกรรมใดที่ทำงานอยู่และพฤติกรรมใดที่แฝงไปด้วยการกระทำที่ฉันต้องการให้เกิดการสะสม

โปรดทราบ: ฉันใช้พฤติกรรมที่แตกต่างเป็นนามธรรมของส่วนต่าง ๆ ของตรรกะของเราเพื่อกำหนดความเสียหายและ - เป็นอีกตัวอย่าง - สินค้าคงคลัง ทั้งสองเป็นพฤติกรรมแยกกันฉันจะเพิ่มในภายหลังกับผู้เล่นและไม่ถ่วงผู้เล่นที่กำหนดเองของฉันด้วยความรับผิดชอบแยกต่างหากซึ่งยากที่จะรักษา เมื่อใช้คำอธิบายประกอบเช่น RequireComponent ฉันจะต้องแน่ใจว่าพฤติกรรมผู้เล่นของฉันมีเช่นเดียวกันกับพฤติกรรมที่ฉันกำหนดไว้ตอนนี้

นี่เป็นเพียงความคิดของฉัน: หลีกเลี่ยงการดำเนินการตรรกะขึ้นอยู่กับแท็ก แต่แทนที่จะใช้พฤติกรรมและค่านิยมที่แตกต่างกันเช่น enums ที่จะเลือกระหว่าง

ลองนึกภาพพฤติกรรมนี้:

1. พฤติกรรมการระบุวัตถุว่าเป็นกองซ้อนบนพื้น เกม RPG ใช้สิ่งนี้สำหรับไอเท็มในพื้นดินที่สามารถหยิบขึ้นมาได้

   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เป็น enums

พฤติกรรมเหล่านี้ไม่ได้ใช้งานในทางที่อยู่บนพื้นดินหรือบินไปรอบ ๆ พวกเขาไม่ได้กระทำด้วยตนเอง พวกเขาไม่ทำอะไรเลย เช่นถ้าคุณมีลูกไฟลอยอยู่ในที่ว่างมันก็ยังไม่พร้อมที่จะทำความเสียหาย (บางทีพฤติกรรมอื่น ๆ ควรได้รับการพิจารณาว่าเป็นลูกไฟเช่นลูกไฟกินไฟในขณะเดินทางและลดพลังทำลายในกระบวนการ แต่แม้ เมื่อมี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
       }
   }
   

   รหัสนี้ยังไม่ทดลองและควรจะทำงานเป็นแนวคิด จุดประสงค์คืออะไร? ความเสียหายคือสิ่งที่บางคนรู้สึกและสัมพันธ์กับวัตถุ (หรือสิ่งมีชีวิต) ที่ได้รับความเสียหายตามที่คุณพิจารณา นี่คือตัวอย่าง: ในเกม RPG ปกติดาบจะสร้างความเสียหายให้คุณในขณะที่เกม RPG อื่นใช้งาน (เช่นSummon Night Swordcraft Story 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.
       }
   }
   

ดังที่คุณเห็นจากคำตอบที่หลากหลายที่นี่มีระดับความเป็นส่วนตัวที่เกี่ยวข้องกับการตัดสินใจเหล่านี้และการตัดสินใจขึ้นอยู่กับความต้องการของเกมของคุณ - ไม่มีวิธีการใดที่ดีที่สุดแน่นอน

คำแนะนำของฉันคือคิดในแง่ของวิธีการของคุณในการพัฒนาเมื่อคุณขยายเกมเพิ่มและทำซ้ำในฟีเจอร์ต่างๆ การวางตรรกะการจัดการการชนในที่เดียวจะนำไปสู่รหัสที่ซับซ้อนมากขึ้นในภายหลังหรือไม่ หรือมันรองรับพฤติกรรมแบบแยกส่วนมากขึ้น?

ดังนั้นคุณมีหนามแหลมที่สร้างความเสียหายให้กับผู้เล่น ถามตัวเอง:

• มีสิ่งอื่นนอกเหนือจากผู้เล่นที่แหลมอาจต้องการสร้างความเสียหาย?
• มีสิ่งอื่นนอกเหนือจากหนามที่ผู้เล่นควรได้รับความเสียหายจากการชนหรือไม่?
• ทุกระดับกับผู้เล่นจะมีหนามแหลมหรือไม่? ทุกระดับที่มีหนามแหลมจะมีผู้เล่นหรือไม่?
• คุณอาจมีรูปแบบที่แหลมที่ต้องทำสิ่งที่แตกต่างกันอย่างไร (เช่นจำนวนความเสียหาย / ประเภทความเสียหายแตกต่างกันอย่างไร)

เห็นได้ชัดว่าเราไม่ต้องการทำอะไรกับสิ่งนี้และสร้างระบบที่มีการออกแบบทางวิศวกรรมมากเกินกว่าที่จะสามารถจัดการกรณีได้นับล้านกรณีแทนที่จะเป็นกรณีเดียวที่เราต้องการ แต่ถ้ามันเท่ากันทั้งสองวิธี (เช่นใส่ 4 บรรทัดนี้ในคลาส A กับคลาส B) แต่หนึ่งสเกลที่ดีกว่ามันเป็นกฎง่ายๆที่ดีสำหรับการตัดสินใจ

สำหรับตัวอย่างนี้ใน Unity โดยเฉพาะฉันจะเอนตัวไปวางตรรกะการจัดการความเสียหายในเดือยในรูปแบบของบางอย่างเช่นCollisionHazardส่วนประกอบซึ่งเมื่อชนกันจะเรียกวิธีการทำความเสียหายในDamageableส่วนประกอบ นี่คือเหตุผล:

• คุณไม่จำเป็นต้องจัดเตรียมแท็กสำหรับผู้เข้าร่วมการชนที่แตกต่างกันทุกคนที่คุณต้องการแยกแยะ
• ในขณะที่คุณเพิ่มความหลากหลายของการโต้ตอบที่ปะทะกันได้ (เช่นลาวา, กระสุน, สปริง, powerups ... ) คลาสผู้เล่นของคุณ (หรือส่วนประกอบที่เสียหาย) ไม่ได้สะสมชุดยักษ์ของกรณี / อื่น ๆ / สลับเพื่อจัดการกับแต่ละคน
• หากครึ่งระดับของคุณจบลงด้วยการไม่มีหนามแหลมในพวกเขาคุณจะไม่เสียเวลาในการจัดการการชนของผู้เล่นตรวจสอบว่ามีหนามแหลมที่เกี่ยวข้อง พวกเขาเสียค่าใช้จ่ายเมื่อมีส่วนร่วมในการปะทะ
• หากคุณตัดสินใจในภายหลังว่าสไปค์ควรฆ่าศัตรู & อุปกรณ์ประกอบฉากเช่นกันคุณไม่จำเป็นต้องทำซ้ำรหัสจากคลาสเฉพาะของผู้เล่นเพียงแค่ติดDamageableส่วนประกอบไว้บนพวกมัน (ถ้าคุณต้องการให้บางคนมีภูมิคุ้มกันต่อแหลมเท่านั้นคุณสามารถเพิ่ม ประเภทความเสียหาย & ให้Damageableส่วนประกอบจัดการภูมิคุ้มกัน)
• หากคุณกำลังทำงานเป็นทีมบุคคลที่ต้องการเปลี่ยนพฤติกรรมที่ขัดขวางและตรวจสอบระดับอันตราย / สินทรัพย์ไม่ได้ปิดกั้นทุกคนที่ต้องการอัปเดตการโต้ตอบกับผู้เล่น นอกจากนี้ยังง่ายสำหรับสมาชิกในทีมใหม่ (โดยเฉพาะนักออกแบบระดับ) ซึ่งสคริปต์ที่พวกเขาต้องการดูเพื่อเปลี่ยนพฤติกรรมที่ขัดขวาง - มันเป็นสิ่งที่แนบมากับเดือย!

มันไม่สำคัญว่าใครจะจัดการกับการชน แต่ให้สอดคล้องกับงานที่เป็นอยู่

ในเกมของฉันฉันพยายามเลือกสิ่งGameObjectที่ "ทำ" กับวัตถุอื่น ๆ เป็นผู้ควบคุมการชน IE Spike ทำความเสียหายแก่ผู้เล่นดังนั้นจึงสามารถจัดการการชนได้ เมื่อวัตถุทั้งคู่ "ทำ" บางสิ่งซึ่งกันและกันให้แต่ละคนจัดการกับการกระทำกับวัตถุอื่น

นอกจากนี้ฉันขอแนะนำให้ลองออกแบบการชนของคุณเพื่อให้การชนนั้นได้รับการจัดการโดยวัตถุที่ตอบสนองต่อการชนด้วยสิ่งต่าง ๆ น้อยลง เข็มจะต้องรู้เกี่ยวกับการชนกับผู้เล่นเท่านั้นทำให้รหัสการชนในสคริปต์ Spike นั้นดีและกะทัดรัด วัตถุผู้เล่นสามารถชนกับสิ่งอื่น ๆ อีกมากมายซึ่งจะทำให้สคริปต์การปะทะกันป่อง

ท้ายสุดพยายามทำให้ตัวจัดการการชนของคุณเป็นนามธรรมมากขึ้น สไปค์ไม่จำเป็นต้องรู้ว่ามันชนกับผู้เล่นมันแค่ต้องรู้ว่ามันชนกับบางสิ่งที่มันต้องสร้างความเสียหาย ให้บอกว่าคุณมีสคริปต์:

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);
        }
    }
}

ฉันมีปัญหาเดียวกันเมื่อฉันเริ่มต้นจากที่นี่มันจะไป: ในกรณีนี้ใช้ศัตรู คุณมักจะต้องการการชนที่จัดการโดยวัตถุที่ดำเนินการ (ในกรณีนี้ - ศัตรู แต่ถ้าผู้เล่นของคุณมีอาวุธแล้วอาวุธควรจัดการการปะทะ) เพราะถ้าคุณต้องการปรับแต่งคุณสมบัติ (เช่นความเสียหาย ของศัตรู) คุณต้องการเปลี่ยนแน่นอนใน enemyscript และไม่ใช่ใน Playerscript (โดยเฉพาะถ้าคุณมีผู้เล่นหลายคน) ในทำนองเดียวกันหากคุณต้องการเปลี่ยนความเสียหายของอาวุธใด ๆ ที่ผู้เล่นใช้คุณไม่ต้องการเปลี่ยนในทุกศัตรูของเกม

วัตถุทั้งสองจะจัดการกับการชนกัน

วัตถุบางอย่างจะถูกทำให้พิการแตกหักหรือถูกทำลายทันทีโดยการชน (กระสุน, ลูกศร, ลูกโป่งน้ำ)

คนอื่น ๆ ก็จะกระเด้งออกแล้วหมุนไปด้านข้าง (หิน) สิ่งเหล่านี้ยังสามารถสร้างความเสียหายได้หากสิ่งที่พวกเขาตีนั้นหนักพอ หินไม่ได้รับความเสียหายจากมนุษย์ชนพวกเขา แต่พวกเขาอาจมาจากค้อนเลื่อน

วัตถุที่อ่อนนุ่มอย่างมนุษย์จะได้รับความเสียหาย

คนอื่น ๆ จะผูกพันซึ่งกันและกัน (แม่เหล็ก)

การชนทั้งสองจะถูกวางในคิวการจัดการเหตุการณ์สำหรับนักแสดงที่ทำหน้าที่วัตถุในเวลาและสถานที่เฉพาะ (และความเร็ว) เพียงจำไว้ว่าตัวจัดการควรจัดการกับสิ่งที่เกิดขึ้นกับวัตถุเท่านั้น เป็นไปได้ที่ผู้จัดวางตัวจัดการอีกตัวในคิวเพื่อจัดการเอฟเฟกต์เพิ่มเติมของการชนโดยยึดตามคุณสมบัติของนักแสดงหรือวัตถุที่กำลังทำอยู่ (ระเบิดระเบิดขึ้นและการระเบิดที่เกิดขึ้นตอนนี้ต้องทดสอบการชนกับวัตถุอื่น ๆ )

เมื่อสคริปต์ให้ใช้แท็กที่มีคุณสมบัติที่จะถูกแปลเป็นการใช้งานอินเตอร์เฟซโดยรหัสของคุณ จากนั้นอ้างอิงอินเทอร์เฟซในรหัสการจัดการของคุณ

ตัวอย่างเช่นดาบอาจมีแท็กสำหรับระยะประชิดซึ่งแปลเป็นอินเทอร์เฟซชื่อ Melee ซึ่งอาจขยายส่วนต่อประสาน DamageGiving ที่มีคุณสมบัติสำหรับประเภทความเสียหายและจำนวนความเสียหายที่กำหนดโดยใช้ค่าคงที่หรือช่วง ฯลฯ และอาจมีระเบิด แท็ก Explosive ที่มีส่วนต่อประสาน Explosive ยังขยายส่วนต่อประสาน DamageGiving ที่มีคุณสมบัติเพิ่มเติมสำหรับรัศมีและอาจเป็นไปได้ว่าความเสียหายจะกระจายอย่างรวดเร็วเพียงใด

เอ็นจินเกมของคุณจะใช้รหัสกับส่วนต่อประสานไม่ใช่วัตถุเฉพาะ