องค์ประกอบของเกมผู้จัดการเกมและคุณสมบัติของวัตถุ

ฉันกำลังพยายามทำให้การออกแบบเอนทิตีอิงองค์ประกอบ

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

สิ่งต่อไปที่ฉันทำคือลบวัตถุออกและมีส่วนประกอบแต่ละอันที่มีรหัส ดังนั้นวัตถุจะถูกกำหนดโดยส่วนประกอบที่มีรหัสเดียวกัน

ตอนนี้ฉันกำลังคิดว่าฉันไม่ต้องการผู้จัดการสำหรับส่วนประกอบทั้งหมดของฉันเช่นฉันมี a SizeComponentซึ่งเพิ่งมีSizeคุณสมบัติ) ดังนั้นSizeComponentวิธีนี้จึงไม่มีวิธีการอัพเดทและวิธีการอัพเดทของผู้จัดการก็ไม่ได้ทำอะไรเลย

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

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

1. นี้คือ (มีObjectProperty, ObjectComponentและComponentManagerชั้นเรียน) มากกว่าวิศวกรรม?
2. อะไรจะเป็นทางเลือกที่ดี?

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

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

ดังนั้นต่อไปนี้เป็นตัวอย่างเส้นบอกแนวที่ฉันลองและทำตามเมื่อพัฒนาในระบบส่วนประกอบ:

• ไม่มีช้อน.
  • นี่คือขั้นตอนที่คุณทำไปแล้วเพื่อกำจัดวัตถุกลาง สิ่งนี้จะลบการอภิปรายทั้งหมดของสิ่งที่เข้าสู่ออบเจ็กต์ของเอนทิตีและสิ่งที่จะเข้าสู่องค์ประกอบเนื่องจากตอนนี้สิ่งที่คุณมีคือส่วนประกอบ
• ส่วนประกอบไม่ใช่โครงสร้าง
  • หากคุณแยกบางสิ่งบางอย่างลงในที่ซึ่งมันเพิ่งมีข้อมูลอยู่มันจะไม่เป็นองค์ประกอบอีกต่อไปมันเป็นเพียงโครงสร้างข้อมูล
  • ส่วนประกอบควรมีฟังก์ชั่นทั้งหมดที่จำเป็นในการทำงานที่เฉพาะเจาะจงในลักษณะที่เฉพาะเจาะจง
  • อินเทอร์เฟซ IRenderable ให้โซลูชันทั่วไปเพื่อแสดงอะไรในเกม CRenderableSprite และ CRenderableModel เป็นการใช้งานส่วนประกอบของส่วนต่อประสานที่ให้ข้อมูลเฉพาะในการเรนเดอร์ 2D และ 3D ตามลำดับ
  • IUseable เป็นอินเทอร์เฟซสำหรับสิ่งที่ผู้เล่นสามารถโต้ตอบได้ CUseableItem จะเป็นองค์ประกอบที่ยิงปืนที่ใช้งานอยู่หรือดื่มยาที่เลือกในขณะที่ CUseableTrigger อาจเป็นจุดที่ผู้เล่นกระโดดขึ้นไปบนป้อมปืนหรือโยนคันโยกลงสะพาน

ดังนั้นด้วยแนวทางของส่วนประกอบที่ไม่ได้เป็นโครงสร้างทำให้ SizeComponent ถูกทำลายจนเกินไป มันมีข้อมูลเท่านั้นและสิ่งที่กำหนดขนาดของสิ่งที่สามารถแตกต่างกันไป ตัวอย่างเช่นในองค์ประกอบการเรนเดอร์มันอาจเป็นสเกลาร์ 1d หรือเวกเตอร์ 2 / 3d ในองค์ประกอบทางฟิสิกส์มันอาจเป็นปริมาณขอบเขตของวัตถุ ในรายการสินค้าคงคลังอาจเป็นจำนวนพื้นที่ที่ใช้ในตาราง 2D

ลองวาดเส้นที่ดีระหว่างทฤษฎีและการปฏิบัติจริง

หวังว่านี่จะช่วยได้

คุณยอมรับคำตอบแล้ว แต่นี่คือการแทงฉันที่ CBS ฉันพบว่าทั่วไปComponentระดับมีข้อ จำกัด บางอย่างเพื่อให้ฉันไปกับการออกแบบการอธิบายโดยหัวรุนแรงความบันเทิงที่ GDC 2009 ที่เสนอแยกส่วนประกอบเข้าและAttributes Behaviors(" ทฤษฎีและการปฏิบัติของสถาปัตยกรรมองค์ประกอบวัตถุเกม ", Marcin Chady)

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

► http://www.pdf-archive.com/2012/01/08/entity-component-system/preview/page/1

นี่คือข้อความที่ตัดตอนมาจากเอกสาร:

คุณสมบัติและพฤติกรรมในระยะสั้น

Attributesจัดการข้อมูลหนึ่งประเภทและตรรกะใด ๆ ที่มี จำกัด ในขอบเขต ตัวอย่างเช่นHealthอาจตรวจสอบให้แน่ใจว่าค่าปัจจุบันไม่สูงกว่าค่าสูงสุดและสามารถแจ้งเตือนส่วนประกอบอื่น ๆ ได้เมื่อค่าปัจจุบันลดลงต่ำกว่าระดับวิกฤติบางระดับ แต่ไม่มีตรรกะที่ซับซ้อนมากขึ้น Attributesจะขึ้นอยู่กับไม่มีอื่น ๆหรือAttributesBehaviors

Behaviorsควบคุมวิธีที่เอนทิตีโต้ตอบกับเหตุการณ์ของเกมตัดสินใจและเปลี่ยนแปลงค่าAttributesตามที่ต้องการ Behaviorsจะขึ้นอยู่กับบางส่วนของAttributesแต่พวกเขาไม่สามารถโดยตรงโต้ตอบกับแต่ละอื่น ๆ - พวกเขาเท่านั้นที่ตอบสนองต่อวิธีการที่Attributes’ค่าที่มีการเปลี่ยนแปลงโดยที่คนอื่น ๆBehaviorsและเหตุการณ์ที่พวกเขาจะถูกส่ง

แก้ไข:และนี่คือแผนภาพความสัมพันธ์ที่แสดงให้เห็นว่าองค์ประกอบสื่อสารกันอย่างไร:

รายละเอียดการใช้งาน: ระดับเอนทิตีEventManagerถูกสร้างขึ้นเฉพาะเมื่อมีการใช้งาน Entityชั้นเพียงแค่เก็บชี้ไปยังEventManagerที่จะเริ่มต้นได้เฉพาะในกรณีที่บางคำขอองค์ประกอบมัน

แก้ไข:คำถามอื่นฉันให้คำตอบที่คล้ายกันนี้ คุณสามารถค้นหาได้ที่นี่เพื่อคำอธิบายที่ดีกว่าของระบบ:
► /gamedev//a/23759/6188

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

• คุณสมบัติที่ใช้โดยหลายองค์ประกอบ แต่ถูกแก้ไขโดยหนึ่งจะถูกเก็บไว้ในองค์ประกอบนั้น Shape เป็นตัวอย่างที่ดีในเกมที่ระบบ AI ระบบฟิสิกส์รวมถึงระบบการเรนเดอร์จำเป็นต้องเข้าถึงรูปร่างพื้นฐานมันเป็นคุณสมบัติที่หนักและควรอยู่ในที่เดียวหากเป็นไปได้
• คุณสมบัติเช่นตำแหน่งบางครั้งจำเป็นต้องทำซ้ำ ตัวอย่างเช่นหากคุณเรียกใช้หลาย ๆ ระบบพร้อมกันคุณต้องการหลีกเลี่ยงการแอบดูข้ามระบบและจะซิงค์ตำแหน่ง (คัดลอกจากองค์ประกอบหลักหรือซิงค์ผ่านเดลตาหรือด้วยการชนกันของข้อมูลหากจำเป็น)
• คุณสมบัติที่มาจากการควบคุมหรือ AI "ความตั้งใจ" สามารถเก็บไว้ในระบบเฉพาะเนื่องจากสามารถใช้กับระบบอื่นโดยไม่สามารถมองเห็นได้จากภายนอก
• คุณสมบัติอย่างง่ายอาจซับซ้อน บางครั้งตำแหน่งของคุณจะต้องการระบบเฉพาะถ้าคุณต้องการแบ่งปันข้อมูลจำนวนมาก (ตำแหน่ง, การวางแนว, เดลต้าเฟรม, การเคลื่อนไหวปัจจุบันของเดลต้ารวม, การเคลื่อนไหวเดลต้าสำหรับเฟรมปัจจุบันและสำหรับเฟรมก่อนหน้า, การหมุน ... ) ในกรณีนี้คุณจะต้องไปกับระบบและเข้าถึงข้อมูลล่าสุดจากส่วนประกอบเฉพาะและคุณอาจต้องเปลี่ยนผ่านตัวสะสม (เดลตา)
• บางครั้งคุณสมบัติของคุณสามารถเก็บไว้ในอาร์เรย์แบบ raw (double *) และส่วนประกอบของคุณจะมีตัวชี้ไปยังอาร์เรย์ที่ถือคุณสมบัติที่แตกต่างกัน ตัวอย่างที่ชัดเจนที่สุดคือเมื่อคุณต้องการการคำนวณแบบขนานขนาดใหญ่ (CUDA, OpenCL) ดังนั้นการมีระบบเดียวในการจัดการตัวชี้อย่างถูกต้องอาจมีจำนวนน้อยมาก

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

ไม่มีระบบที่สมบูรณ์แบบ และบางเกมจะดีขึ้นเมื่อใช้ระบบที่ง่ายกว่าในขณะที่เกมอื่น ๆ ต้องการการซิงโครไนซ์ที่ซับซ้อนมากขึ้นในระบบต่างๆ

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

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

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

เมื่อพูดถึงส่วนประกอบขนาดของคุณอาจรวมอยู่ในองค์ประกอบตำแหน่งของคุณ:

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

แทนที่จะเป็นขนาดที่คุณสามารถใช้ตัวปรับขนาดได้มันอาจเข้ากันได้ดีกว่า

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

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

ใน C ++ หรือ C # T GetComponent<T>()นี้มักจะหมายถึงคุณจะมีวิธีการที่แม่แบบนิติบุคคลเช่น และเมื่อคุณมีการอ้างอิงนั้นคุณจะรู้ได้อย่างชัดเจนว่าข้อมูลสมาชิกใดเก็บไว้ดังนั้นให้เข้าถึงได้โดยตรง

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

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

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

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

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

ไม่มีกฎทั่วไป ขึ้นอยู่กับคุณสมบัติเฉพาะ (ดูด้านบน)

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

ลำไส้ของคุณบอกคุณว่ามีThingProperty, ThingComponentและThingManagerทุกThingชนิดของส่วนประกอบเล็ก ๆ น้อย ๆ overkill ฉันคิดว่ามันถูกต้อง

แต่คุณต้องมีวิธีการติดตามส่วนประกอบที่เกี่ยวข้องในแง่ของระบบที่ใช้พวกเขาเป็นองค์กรที่พวกเขาเป็นเจ้าของ ฯลฯ

TransformPropertyจะเป็นเรื่องธรรมดา แต่ใครเป็นผู้รับผิดชอบระบบการเรนเดอร์? ระบบฟิสิกส์? ระบบเสียง? ทำไมTransformส่วนประกอบถึงต้องอัพเดทตัวเอง

วิธีแก้ไขคือการลบรหัสประเภทใด ๆ ออกจากคุณสมบัติของคุณนอก getters, setters และ initializers ส่วนประกอบคือข้อมูลซึ่งใช้โดยระบบในเกมเพื่อทำงานต่าง ๆ เช่นการเรนเดอร์ AI การเล่นเสียงการเคลื่อนไหว ฯลฯ

อ่านเกี่ยวกับอาร์ทิมิส: http://piemaster.net/2011/07/entity-component-artemis/

ดูรหัสและคุณจะเห็นว่ามันขึ้นอยู่รอบ ๆ ComponentTypesระบบที่อ้างอิงประกาศของพวกเขาเป็นรายชื่อของ คุณเขียนSystemคลาสแต่ละคลาสของคุณและในเมธอด Constructor / init ประกาศว่าระบบนั้นขึ้นอยู่กับประเภทใด

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

จากนั้นในระหว่างขั้นตอนการอัปเดตของลูปของคุณSystemตอนนี้รายการของเอนทิตีที่จะอัปเดต ตอนนี้คุณสามารถมีความละเอียดของส่วนประกอบเพื่อให้คุณสามารถประดิษฐ์ระบบบ้าสร้างหน่วยงานที่ออกมาจากModelComponent, TransformComponent, FliesLikeSupermanComponentและSocketInfoComponentและทำอะไรบางอย่างแปลก ๆ เช่นทำให้จานบินที่บินระหว่างลูกค้าเชื่อมต่อกับหลายเกม โอเคอาจไม่ใช่อย่างนั้น แต่ความคิดก็คือมันช่วยให้สิ่งต่าง ๆ แยกและยืดหยุ่นได้

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