องค์ประกอบ OOP หนักเทียบกับระบบส่วนประกอบของเอนทิตีบริสุทธิ์? [ปิด]

ฉันยอมรับว่าฉันได้ทำบาปมากเกินไปและแม้กระทั่งการละเมิดมรดก โครงการเกมแรก (ข้อความ) ที่ฉันทำเมื่อฉันเรียนหลักสูตร OOP ไปจนถึง "ล็อคประตู" และ "ปลดล็อคประตู" จาก "ประตู" และ "ห้องที่มีประตูเดียว", "ห้องที่มีสองประตู" และ ต่อจาก "ห้อง"

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

ฉันคิดว่าฉันยังคงทำสิ่งผิดปกติและหลังจากค้นหาทางออนไลน์ฉันพบว่าฉันไม่ใช่คนเดียวที่มีปัญหานี้ มันเป็นวิธีการที่ฉันค้นพบระบบ Entity หลังจากการวิจัยอย่างละเอียด (อ่าน: googlefu)

เมื่อฉันเริ่มอ่านมันฉันก็สามารถเห็นได้อย่างชัดเจนว่ามันสามารถแก้ปัญหาที่ฉันมีกับลำดับชั้นของ OOP ดั้งเดิมที่มีส่วนประกอบ สิ่งเหล่านี้อยู่ในการอ่านครั้งแรกอย่างไรก็ตาม เมื่อผมเจอมากขึ้น ... “รุนแรง” ES แนวทางดังกล่าวเป็นหนึ่งในT-เครื่อง

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

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

ตัวอย่างต่อไปนี้แสดงสิ่งที่ฉันหมายถึง (เป็นแรงบันดาลใจจากตัวอย่างที่ฉันพบใน Game Engine Architecture ตอนที่ 14)

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

จากนั้นรถถัง subclass ของยานพาหนะจะสืบทอดส่วนประกอบเหล่านั้นจากนั้นและจะได้รับมันเป็นองค์ประกอบ "ปืนใหญ่" ของตัวเอง

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

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

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

ความคิดเห็นของคุณ?

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

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

ลองพิจารณาตัวอย่างนี้:

คุณกำลังทำ RTS ในแบบของตรรกะเสร็จสมบูรณ์คุณตัดสินใจที่จะทำให้ชั้นฐานGameObjectแล้วสอง subclasses, และBuilding Unitมันใช้งานได้ดีแน่นอนและคุณจะจบลงด้วยสิ่งที่มีลักษณะเช่นนี้:

• GameObject
  • ModelComponent
  • CollisionComponent
  • ...
• Building
  • ProductionComponent
  • ...
• Unit
  • AimingAIComponent
  • WeaponComponent
  • ParticleEmitterComponent
  • AnimationComponent
  • ...

ตอนนี้คลาสย่อยของUnitคุณที่ทำไปแล้วมีส่วนประกอบทั้งหมดที่คุณต้องการแล้ว และเป็นโบนัสที่คุณต้องเป็นสถานที่เดียวที่จะนำรหัสการตั้งค่าทั้งหมดที่น่าเบื่อที่news ค่าWeaponComponentเชื่อมต่อไปยังAimingAIComponentและParticleEmitterComponent-wonderful!

และแน่นอนเพราะมันยังคงใช้เหตุผลเป็นส่วนประกอบในที่สุดเมื่อคุณตัดสินใจว่าคุณต้องการเพิ่มTowerคลาสนั่นคือสิ่งปลูกสร้าง แต่มีอาวุธคุณสามารถจัดการมันได้ คุณสามารถเพิ่มAimingAIComponentการWeaponComponentและParticleEmitterComponentการ subclass Buildingของคุณ แน่นอนว่าคุณต้องผ่านและขุดรหัสการเริ่มต้นจากUnitชั้นเรียนและวางไว้ที่อื่น แต่นั่นไม่ใช่การสูญเสียครั้งใหญ่

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

if (myGameObject instanceof Unit)
    doSomething(((Unit)myGameObject).getWeaponComponent());

สิ่งนี้จะไม่ทำงานในTowerอาคารของคุณแม้ว่าคุณจะต้องการให้มันทำงานด้วยอาวุธก็ตาม ตอนนี้มันต้องมีลักษณะดังนี้:

WeaponComponent weapon = myGameObject.getComponent(WeaponComponent.class);
if (weapon)
    doSomething(weapon);

ดีกว่ามาก! มันเกิดขึ้นกับคุณหลังจากเปลี่ยนสิ่งนี้ซึ่งวิธีการเข้าถึงใด ๆที่คุณเขียนอาจสิ้นสุดในสถานการณ์นี้ ดังนั้นสิ่งที่ปลอดภัยที่สุดที่จะทำคือดึงพวกเขาออกทั้งหมดและเข้าถึงทุกส่วนประกอบผ่านทางนี้getComponentวิธีการที่สามารถทำงานร่วมกับประเภทรองใด ๆ (อีกวิธีหนึ่งคุณสามารถเพิ่มทุกประเภทของget*Component()ซูเปอร์GameObjectคลาสและแทนที่พวกเขาในคลาสย่อยเพื่อส่งกลับองค์ประกอบฉันจะถือว่าเป็นคนแรก)

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

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

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

เมื่อมาถึงการบูรณาการองค์ประกอบตามระบบการเล่นเกมที่มีอยู่ขึ้นอยู่กับเกมวัตถุที่มีบทความที่เขียนโปรแกรมคาวบอยhttp://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ซึ่งอาจทำให้คุณชี้บางอย่างเกี่ยวกับ วิธีการเปลี่ยนสามารถทำได้

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

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

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

มันสามารถทำงานได้สำหรับคุณ แต่ฉันไม่ได้ผสมทั้งสองอย่างนอกช่วงการเปลี่ยนภาพจากสถาปัตยกรรมหนึ่งไปอีกสถาปัตยกรรมหนึ่ง

ป.ล. เขียนบนโทรศัพท์ดังนั้นฉันจึงลำบากในการเชื่อมโยงไปยังแหล่งข้อมูลภายนอก