ลงทะเบียนส่วนประกอบเกมวัตถุในระบบย่อยเกม? (การออกแบบวัตถุเกมตามส่วนประกอบ)

ฉันกำลังสร้างระบบเกมวัตถุ component-based เคล็ดลับบางอย่าง:

1. GameObjectComponentsเป็นเพียงรายการ
2. GameSubsystemsมี ยกตัวอย่างเช่นการแสดงผลฟิสิกส์ ฯลฯ แต่ละมีตัวชี้ไปยังบางส่วนของGameSubsystem เป็นนามธรรมที่ทรงพลังและยืดหยุ่นมาก: มันแสดงถึงส่วนใด ๆ ของเกม (หรือแง่มุม)ComponentsGameSubsystem

มีความต้องการในกลไกของการลงทะเบียนComponentsในGameSubsystems(เมื่อGameObjectถูกสร้างและสงบ) มี4 วิธีคือ:

• 1: รูปแบบของความรับผิดชอบ ทุกคนมีให้แก่ทุกคนComponent ตัดสินใจในการลงทะเบียน (และวิธีการจัดระเบียบ) ตัวอย่างเช่น GameSubsystemRender สามารถลงทะเบียน Renderable Components ได้GameSubsystemGameSubsystemComponents

มือโปร. Componentsไม่รู้อะไรเกี่ยวกับวิธีการใช้งาน คลัปต่ำ A.GameSubsystemเราสามารถเพิ่มใหม่ ตัวอย่างเช่นให้เพิ่ม GameSubsystemTitles ที่ลงทะเบียน ComponentTitle ทั้งหมดและรับประกันว่าทุกชื่อจะไม่ซ้ำกันและมีส่วนต่อประสานในการสอบถามวัตถุตามชื่อ แน่นอน ComponentTitle ไม่ควรเขียนใหม่หรือสืบทอดในกรณีนี้ B.GameSubsystemsเราสามารถจัดระเบียบที่มีอยู่ ตัวอย่างเช่น GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter สามารถผสานเข้ากับ GameSubsystemSpatial (เพื่อวางเสียง emmiter ทั้งหมดให้Componentsอยู่ในลำดับชั้นเดียวกันและใช้การแปลงแบบญาติสัมพันธ์)

แย้ง ทุกการตรวจสอบ ไม่มีประสิทธิภาพมาก

แย้ง รู้เกี่ยวกับSubsystemsComponents

• 2: Subsystemการค้นหาแต่ละComponentsประเภทที่เฉพาะเจาะจง

มือโปร. Approach 1ประสิทธิภาพที่ดีขึ้นกว่าใน

แย้ง ยังรู้เกี่ยวกับSubsystemsComponents

• 3: ลงทะเบียนตัวเองในComponent GameSubsystem(s)เรารู้เวลารวบรวมว่ามี GameSubsystemRenderer ดังนั้น ComponentImageRender จะเรียกสิ่งที่เรียกว่า GameSubsystemRenderer :: register (ComponentRenderBase *)

มือโปร. ประสิทธิภาพ. Approach 1ไม่มีการตรวจสอบที่ไม่จำเป็นในขณะที่

แย้ง เป็นคู่ที่ไม่ดีด้วยComponentsGameSubsystems

• 4: รูปแบบคนกลาง GameState(ที่มีGameSubsystems) สามารถใช้ registerComponent (Component *)

มือโปร. ComponentsและGameSubystemsไม่รู้อะไรเกี่ยวกับกันและกัน

แย้ง ใน C ++ มันจะดูน่าเกลียดและช้า typeid-switch

คำถาม: วิธีใดดีกว่าและส่วนใหญ่ใช้ในการออกแบบที่อิงส่วนประกอบ สิ่งที่ฝึกพูด ข้อเสนอแนะใด ๆ เกี่ยวกับการใช้Approach 4?

ขอขอบคุณ.

ประตูหมายเลข 3 ... ส่วนประกอบลงทะเบียนตัวเองใน GameSubsystem (s)

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

การมีเพศสัมพันธ์ไม่ใช่เรื่องเลวร้ายในกรณีนี้

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

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