นี่เป็นสิ่งที่ยากมาก ฉันจะพยายามจัดการกับคำถามบางอย่างจากประสบการณ์ของฉัน (YMMV):
ส่วนประกอบต้องเข้าถึงข้อมูลของส่วนประกอบอื่น ๆ เช่นวิธีการดึงขององค์ประกอบการแสดงผลจะต้องเข้าถึงตำแหน่งขององค์ประกอบการแปลง สิ่งนี้สร้างการพึ่งพาในโค้ด
อย่าประมาทจำนวนและความซับซ้อน (ไม่ใช่ระดับ) ของการมีเพศสัมพันธ์ / การอ้างอิงที่นี่ คุณสามารถดูความแตกต่างระหว่างสิ่งนี้ (และแผนภาพนี้ได้ทำให้ง่ายขึ้นในระดับที่เหมือนของเล่นและตัวอย่างโลกแห่งความจริงจะมีส่วนต่อประสานเพื่อคลายข้อต่อ)
... และนี่:
... หรือนี่:
ส่วนประกอบต่างๆสามารถเป็นแบบโพลีมอร์ฟิคซึ่งจะนำเสนอความซับซ้อนเพิ่มเติม เช่นอาจมีสไปรต์การเรนเดอร์องค์ประกอบที่แทนที่เมธอดการวาดเสมือนของคอมโพเนนต์การเรนเดอร์
ดังนั้น? analogical (หรือตัวอักษร) ที่เทียบเท่ากับ vtable และ virtual dispatch สามารถเรียกใช้ผ่านระบบได้มากกว่าที่วัตถุจะซ่อนสถานะ / ข้อมูลพื้นฐานไว้ ความหลากหลายยังคงใช้งานได้จริงและเป็นไปได้ด้วยการนำ ECS "บริสุทธิ์" ไปใช้เมื่อ vtable แบบอะนาล็อกหรือตัวชี้ฟังก์ชั่นเปลี่ยนเป็น "ข้อมูล" สำหรับระบบที่จะเรียกใช้
เนื่องจาก behaivour polymorphic (เช่นสำหรับการเรนเดอร์) ต้องถูกนำไปใช้ที่ไหนสักแห่งจึงเป็นเพียงการเอาต์ซอร์ซเข้าสู่ระบบ (เช่นระบบเรนเดอร์เรนเดอร์สร้างโหนดเรนเดอร์เรนเดอร์ที่สืบทอดโหนดเรนเดอร์และเพิ่มไปยังเอ็นจิ้นการเรนเดอร์)
ดังนั้น? ฉันหวังว่าสิ่งนี้จะไม่หลุดออกมาเป็นคำพูดถากถาง (ไม่ใช่ความตั้งใจของฉันแม้ว่าฉันจะถูกกล่าวหาบ่อย แต่ฉันหวังว่าฉันจะสามารถสื่อสารอารมณ์ได้ดีขึ้นผ่านข้อความ) แต่พฤติกรรม "จ้าง" polymorphic ในกรณีนี้ไม่จำเป็นต้องเพิ่มเติม ต้นทุนต่อผลิตผล
การสื่อสารระหว่างระบบสามารถหลีกเลี่ยงได้ยาก เช่นระบบการชนอาจต้องใช้กล่องขอบเขตซึ่งคำนวณจากองค์ประกอบการเรนเดอร์ที่เป็นรูปธรรม
ตัวอย่างนี้ดูแปลกสำหรับฉันโดยเฉพาะ ฉันไม่รู้ว่าทำไมตัวแสดงผลจึงส่งออกข้อมูลกลับไปที่เกิดเหตุ (โดยทั่วไปฉันคิดว่าตัวแสดงผลเป็นแบบอ่านอย่างเดียวในบริบทนี้) หรือเพื่อให้ตัวแสดงผลหา AABB แทนระบบอื่นเพื่อทำสิ่งนี้ทั้งตัวแสดงผลและ การปะทะกัน / ฟิสิกส์ (ฉันอาจจะถูกแขวนบนชื่อ "องค์ประกอบการแสดงผล" ที่นี่) แต่ฉันไม่ต้องการที่จะวางสายเกินไปในตัวอย่างนี้เพราะฉันรู้ว่านั่นไม่ใช่จุดที่คุณพยายามทำ ยังคงเป็นการสื่อสารระหว่างระบบ (แม้ในรูปแบบทางอ้อมของการอ่าน / เขียนไปยังฐานข้อมูลกลาง ECS กับระบบที่ขึ้นอยู่กับการเปลี่ยนแปลงโดยตรงของผู้อื่น) ไม่ควรต้องเป็นประจำหากจำเป็น ที่'
สิ่งนี้อาจนำไปสู่ preblems หากไม่ได้กำหนดลำดับการเรียกใช้ฟังก์ชันการอัพเดตของระบบ
สิ่งนี้ควรถูกกำหนดอย่างแน่นอน ECS ไม่ใช่โซลูชันครบวงจรเพื่อจัดเรียงลำดับการประเมินผลการประมวลผลระบบของทุกระบบที่เป็นไปได้ในโค้ดเบสและรับผลลัพธ์แบบเดียวกันกลับไปยังผู้ใช้ปลายทางที่เกี่ยวข้องกับเฟรมและ FPS นี่คือสิ่งหนึ่งเมื่อออกแบบ ECS อย่างน้อยฉันควรแนะนำอย่างยิ่งควรได้รับการคาดการณ์ล่วงหน้า (แม้ว่าจะมีห้องหายใจให้อภัยจำนวนมากที่จะเปลี่ยนความคิดในภายหลังหากไม่ได้เปลี่ยนมุมมองที่สำคัญที่สุดของการสั่งซื้อของ การเรียกใช้ / ประเมินผลระบบ)
อย่างไรก็ตามการคำนวณใหม่ทั้งหมด tilemap ทุกเฟรมมีราคาแพง ดังนั้นรายการจะต้องติดตามการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นเพื่อปรับปรุงพวกเขาในระบบ ในทาง OOP สิ่งนี้อาจถูกห่อหุ้มโดยส่วนประกอบแผนที่ย่อย เช่นเมธอด SetTile () จะอัปเดตอาร์เรย์จุดสุดยอดทุกครั้งที่เรียกใช้
ฉันไม่เข้าใจเรื่องนี้มากนักยกเว้นว่ามันเป็นข้อกังวลที่มุ่งเน้นข้อมูล และไม่มีข้อผิดพลาดใด ๆ ในการเป็นตัวแทนและจัดเก็บข้อมูลใน ECS รวมถึงการบันทึกเพื่อหลีกเลี่ยงข้อผิดพลาดด้านประสิทธิภาพดังกล่าว (สิ่งที่ใหญ่ที่สุดที่มี ECS มักจะเกี่ยวข้องกับสิ่งต่าง ๆ เช่นระบบการสืบค้นอินสแตนซ์ สิ่งที่ท้าทายที่สุดในการเพิ่มประสิทธิภาพ ECS ทั่วไป ความจริงที่ว่าตรรกะและข้อมูลถูกแยกใน ECS "บริสุทธิ์" ไม่ได้หมายความว่าคุณต้องคำนวณสิ่งที่คุณอาจมีแคช / บันทึกในการเป็นตัวแทน OOP นั่นเป็นประเด็นที่สงสัย / ไม่เกี่ยวข้องเว้นแต่ฉันจะคัดสรรสิ่งที่สำคัญมาก
ด้วย ECS "บริสุทธิ์" คุณยังสามารถเก็บข้อมูลนี้ไว้ในองค์ประกอบแผนที่ย่อยได้ ข้อแตกต่างที่สำคัญคือตรรกะในการอัปเดตอาเรย์จุดสุดยอดนี้จะย้ายไปยังระบบที่ใดที่หนึ่ง
คุณยังสามารถยันบน ECS TileMapCacheเพื่อลดความซับซ้อนเป็นโมฆะและการกำจัดของแคชนี้จากกิจการถ้าคุณสร้างองค์ประกอบที่แยกต่างหากเช่น ณ จุดนั้นเมื่อต้องการแคช แต่ไม่มีในเอนทิตีที่มีTileMapส่วนประกอบคุณสามารถคำนวณและเพิ่มได้ เมื่อไม่ถูกต้องหรือไม่ต้องการอีกต่อไปคุณสามารถลบผ่าน ECS โดยไม่ต้องเขียนรหัสเพิ่มเติมโดยเฉพาะสำหรับการตรวจสอบความถูกต้องและการลบดังกล่าว
การพึ่งพาระหว่างส่วนประกอบยังคงมีอยู่แม้ว่าจะถูกซ่อนอยู่ในระบบ
ไม่มีการพึ่งพาระหว่างส่วนประกอบในตัวแทน "บริสุทธิ์" (ฉันไม่คิดว่ามันค่อนข้างถูกที่จะพูดว่าการพึ่งพาถูกซ่อนไว้ที่นี่โดยระบบ) ข้อมูลไม่ได้ขึ้นอยู่กับข้อมูลดังนั้นการพูด ตรรกะขึ้นอยู่กับตรรกะ และ ECS "บริสุทธิ์" มีแนวโน้มที่จะส่งเสริมตรรกะที่จะเขียนในทางที่จะขึ้นอยู่กับชุดย่อยของข้อมูลและตรรกะที่น้อยที่สุด (มักจะไม่มี) ระบบที่ต้องใช้ในการทำงานซึ่งแตกต่างจากทางเลือกมากมายที่มักจะสนับสนุน มีฟังก์ชั่นมากกว่าที่จำเป็นสำหรับงานจริง หากคุณใช้ ECS ที่ถูกต้องสิ่งแรกที่คุณควรชื่นชมคือผลประโยชน์การแยกในขณะที่ตั้งคำถามกับทุกสิ่งที่คุณเคยเรียนรู้ที่จะชื่นชมใน OOP เกี่ยวกับการห่อหุ้มและการซ่อนข้อมูลโดยเฉพาะ
เมื่อ decoupling ฉันหมายถึงข้อมูลที่ระบบของคุณต้องการในการทำงาน ระบบการเคลื่อนไหวของคุณไม่จำเป็นต้องรู้เกี่ยวกับสิ่งที่ซับซ้อนกว่าเช่นParticleหรือCharacter(ผู้พัฒนาระบบไม่จำเป็นต้องรู้แนวคิดเอนทิตีดังกล่าวแม้แต่ในระบบ) มันแค่ต้องรู้เกี่ยวกับข้อมูลขั้นต่ำที่เปลือยเปล่าเช่นองค์ประกอบตำแหน่งซึ่งอาจจะง่ายเหมือนลอยอยู่สองสามตัวในโครงสร้าง มันเป็นข้อมูลที่น้อยลงและการพึ่งพาจากภายนอกน้อยกว่าสิ่งที่อินเทอร์เฟซที่บริสุทธิ์อย่างIMotionมีแนวโน้มที่จะดำเนินการพร้อมกับมัน เป็นหลักเนื่องจากความรู้ขั้นต่ำนี้ที่แต่ละระบบต้องการทำงานที่ทำให้ ECS มักจะให้อภัยในการจัดการการเปลี่ยนแปลงการออกแบบที่ไม่คาดคิดในการเข้าใจถึงปัญหาหลังเหตุการณ์โดยไม่ต้องหันหน้าไปทางอินเตอร์เฟซที่เรียงซ้อนทั่ว
วิธีการ "ไม่บริสุทธิ์" ที่คุณแนะนำให้ลดประโยชน์นั้นบ้างตั้งแต่ตอนนี้ตรรกะของคุณไม่ได้แปลเป็นภาษาท้องถิ่นอย่างเคร่งครัดกับระบบที่การเปลี่ยนแปลงไม่ทำให้เกิดการแตกซ้อน ตรรกะจะถูกรวมอยู่ในระดับหนึ่งในองค์ประกอบที่เข้าถึงได้โดยหลายระบบซึ่งตอนนี้ต้องทำตามข้อกำหนดของอินเทอร์เฟซของระบบต่าง ๆ ที่สามารถใช้งานได้และตอนนี้มันก็เหมือนทุกระบบแล้วต้องมีความรู้เพิ่มเติม ข้อมูลมากกว่าที่จำเป็นในการทำงานกับองค์ประกอบนั้น
การพึ่งพาข้อมูล
หนึ่งในสิ่งที่ขัดแย้งกันเกี่ยวกับ ECS ก็คือมันมีแนวโน้มที่จะแทนที่สิ่งที่อาจจะเป็นการพึ่งพาอินเทอร์เฟซแบบนามธรรมด้วยข้อมูลดิบเท่านั้นและโดยทั่วไปถือว่าเป็นรูปแบบการแต่งงานที่น่าพึงพอใจน้อยกว่า แต่ในโดเมนประเภทต่าง ๆ เช่นเกมที่ ECS มีประโยชน์มากมักจะง่ายกว่าในการออกแบบการแสดงข้อมูลที่ตรงไปตรงมาและทำให้มันมีเสถียรภาพมากกว่าการออกแบบสิ่งที่คุณสามารถทำได้กับข้อมูลนั้นในระดับกลางของระบบ นั่นเป็นสิ่งที่ฉันสังเกตเห็นได้อย่างเจ็บปวดแม้ในหมู่ทหารผ่านศึกในฐานรหัสที่ใช้วิธีอินเตอร์เฟซบริสุทธิ์สไตล์ COM กับสิ่งต่าง ๆIMotionมากขึ้น
นักพัฒนาที่เก็บไว้หาเหตุผลที่จะเพิ่มลบหรือฟังก์ชั่นการเปลี่ยนแปลงอินเตอร์เฟซที่กลางนี้และการเปลี่ยนแปลงแต่ละครั้งก็น่ากลัวและค่าใช้จ่ายเพราะมันจะมีแนวโน้มที่จะทำลายทุกชั้นเดียวที่ดำเนินการพร้อมกับทุกคนตั้งแต่สถานที่ในระบบที่ใช้IMotion IMotionในขณะเดียวกันตลอดเวลาที่มีการเปลี่ยนแปลงอย่างเจ็บปวดและต่อเนื่องมากมายวัตถุที่นำมาใช้IMotionนั้นเพียงแค่ทำการจัดเก็บเมทริกซ์ 4x4 ของโฟลตและอินเทอร์เฟซทั้งหมดเกี่ยวข้องกับวิธีการแปลงและเข้าถึงลอยเหล่านั้น การแสดงข้อมูลมีเสถียรภาพตั้งแต่แรกและความเจ็บปวดมากมายสามารถหลีกเลี่ยงได้ถ้าอินเทอร์เฟซส่วนกลางนี้มีแนวโน้มที่จะเปลี่ยนไปตามความต้องการด้านการออกแบบที่ไม่คาดคิดไม่มีแม้แต่ในตอนแรก
สิ่งนี้อาจฟังดูน่าขยะแขยงเหมือนกับตัวแปรทั่วโลก แต่ลักษณะของการที่ ECS จัดระเบียบข้อมูลนี้เป็นส่วนประกอบที่ดึงมาอย่างชัดเจนตามประเภทผ่านระบบทำให้ในขณะที่คอมไพเลอร์ไม่สามารถบังคับใช้อะไรเช่นการซ่อนข้อมูลสถานที่ที่เข้าถึงและกลายพันธุ์ ข้อมูลโดยทั่วไปมีความชัดเจนและชัดเจนเพียงพอที่จะรักษาค่าคงที่ไว้ได้อย่างมีประสิทธิภาพและทำนายว่าการเปลี่ยนแปลงและผลข้างเคียงจากระบบหนึ่งไปสู่อีกระบบหนึ่ง (จริง ๆ แล้วในวิธีที่สามารถทำให้ง่ายขึ้นและคาดการณ์ได้มากกว่า OOP ในบางโดเมน ระบบจะเปลี่ยนเป็นระบบจัดเรียงแนวราบ)
สุดท้ายฉันอยากถามคำถามว่าฉันจะจัดการกับอนิเมชั่นใน ECS ที่บริสุทธิ์ได้อย่างไร ขณะนี้ฉันได้กำหนดภาพเคลื่อนไหวเป็น functor ที่จัดการเอนทิตีตามความคืบหน้าระหว่าง 0 และ 1 องค์ประกอบภาพเคลื่อนไหวมีรายการแอนิเมชั่นที่มีรายการภาพเคลื่อนไหว ในฟังก์ชั่นการอัพเดทมันจะใช้ภาพเคลื่อนไหวใดก็ตามที่เอนทิตีอยู่ในปัจจุบัน
พวกเราเป็นนักปฏิบัติทั้งหมดที่นี่ แม้ใน gamedev คุณอาจได้รับความคิด / คำตอบที่ขัดแย้งกัน แม้แต่ ECS ที่บริสุทธิ์ที่สุดยังเป็นปรากฏการณ์ที่ค่อนข้างใหม่ซึ่งเป็นดินแดนบุกเบิกที่ผู้คนไม่ได้กำหนดความคิดเห็นที่แข็งแกร่งที่สุดเกี่ยวกับวิธีการทำหนังแมว ปฏิกิริยา gut ของฉันคือระบบแอนิเมชันที่เพิ่มความคืบหน้าของแอนิเมชันประเภทนี้ในส่วนประกอบภาพเคลื่อนไหวเพื่อให้ระบบการแสดงผลปรากฏขึ้น แต่มันก็ไม่สนใจความแตกต่างของแอพพลิเคชั่นและบริบทเฉพาะมากนัก
ด้วย ECS ไม่ใช่ bullet เงินและฉันยังคงพบว่าตัวเองมีแนวโน้มที่จะเข้ามาและเพิ่มระบบใหม่ลบบางส่วนเพิ่มส่วนประกอบใหม่เปลี่ยนระบบที่มีอยู่เพื่อรับประเภทส่วนประกอบใหม่นั้น ฯลฯ ฉันไม่ได้รับ สิ่งที่ถูกต้องในครั้งแรกที่ยังคง แต่ความแตกต่างในกรณีของฉันคือฉันไม่ได้เปลี่ยนอะไรที่เป็นศูนย์กลางเมื่อฉันล้มเหลวในการคาดการณ์การออกแบบบางอย่างที่ต้องมีล่วงหน้า ฉันไม่ได้รับผลกระทบระลอกคลื่นของการแตกซ้อนที่ต้องการให้ฉันไปทั่วสถานที่และเปลี่ยนรหัสมากเพื่อจัดการกับความต้องการใหม่ ๆ ที่เพิ่มขึ้นและนั่นเป็นการประหยัดเวลา ฉันพบว่ามันง่ายขึ้นในสมองของฉันเพราะเมื่อฉันนั่งลงกับระบบใดระบบหนึ่งฉันไม่จำเป็นต้องรู้ / จำสิ่งต่าง ๆ นอกเหนือจากองค์ประกอบที่เกี่ยวข้อง (ซึ่งเป็นเพียงข้อมูล) เพื่อทำงานกับมัน