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

ดูเหมือนว่า ECS จะแยกข้อมูล (E & C) ออกจากพฤติกรรม (S) เป็นหลักฐาน :

แนวคิดคือไม่มีวิธีการฝังเกมในเอนทิตี

และ :

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

ระบบคือฟังก์ชั่นวัตถุประสงค์เดียวที่ใช้ชุดของเอนทิตีที่มีองค์ประกอบเฉพาะ

ฉันคิดว่านี่ไม่ใช่เชิงวัตถุเพราะส่วนใหญ่ของการมุ่งเน้นวัตถุคือการรวมข้อมูลและพฤติกรรมของคุณเข้าด้วยกัน เป็นหลักฐาน :

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

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

บทนำ

ระบบส่วนประกอบ - Entity เป็นเทคนิคสถาปัตยกรรมเชิงวัตถุ

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

มันเป็นรูปแบบวัตถุที่แตกต่างจาก "คลาสและการสืบทอด" ซึ่งคุณมักคุ้นเคยกับการทำงานใน C ++ หรือ Java เอนทิตีมีความหมายเหมือนกับคลาสเช่นเดียวกับต้นแบบใน JavaScript หรือ Self ระบบทั้งหมดเหล่านี้สามารถนำไปใช้ในแง่ของกันและกัน

ตัวอย่าง

พูดเถอะว่าPlayerเป็นนิติบุคคลที่มีPosition, VelocityและKeyboardControlledส่วนประกอบซึ่งทำสิ่งที่เห็นได้ชัด

entity Player:
  Position
  Velocity
  KeyboardControlled

เรารู้ว่าPositionจะต้องได้รับผลกระทบจากVelocityและโดยVelocity KeyboardControlledคำถามคือเราต้องการจำลองลักษณะพิเศษเหล่านั้นอย่างไร

เอนทิตีส่วนประกอบและระบบ

สมมติว่าส่วนประกอบไม่มีการอ้างอิงถึงสิ่งอื่น PhysicsระบบภายนอกสำรวจVelocityองค์ประกอบทั้งหมดและอัพเดทPositionเอนทิตีที่เกี่ยวข้อง Inputระบบลัดเลาะทุกชิ้นส่วนและปรับปรุงKeyboardControlledVelocity

          Player
         +--------------------+
         | Position           | \
         |                    |  Physics
       / | Velocity           | /
  Input  |                    |
       \ | KeyboardControlled |
         +--------------------+

สิ่งนี้เป็นไปตามเกณฑ์:

• ไม่มีเอนทิตีของเกม / ตรรกะทางธุรกิจ

• คอมโพเนนต์จัดเก็บข้อมูลที่อธิบายพฤติกรรม

ระบบอยู่ในขณะนี้รับผิดชอบในการจัดการเหตุการณ์และตัวประกันพฤติกรรมการอธิบายโดยส่วนประกอบ พวกเขายังรับผิดชอบในการจัดการปฏิสัมพันธ์ระหว่างเอนทิตีเช่นการชนกัน

เอนทิตีและส่วนประกอบ

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

class Player:
  construct():
    this.p = Position()
    this.v = Velocity(this.p)
    this.c = KeyboardControlled(this.v)

ตอนนี้เอนทิตีอาจส่งอินพุตและอัพเดตเหตุการณ์ไปยังคอมโพเนนต์โดยตรง Velocityจะตอบสนองต่อการปรับปรุงและKeyboardControlledจะตอบสนองต่อการป้อนข้อมูล สิ่งนี้ยังคงเป็นไปตามเกณฑ์ของเรา:

• เอนทิตีเป็นคอนเทนเนอร์“ dumb” ซึ่งส่งต่อเหตุการณ์ไปยังคอมโพเนนต์เท่านั้น

• แต่ละองค์ประกอบตราพฤติกรรมของตนเอง

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

การโต้ตอบสามารถจัดการได้ในระดับของเอนทิตี (“ เมื่อมีการPlayerชนกับEnemy…”) หรือในระดับของแต่ละองค์ประกอบ (“ เมื่อเอนทิตีที่มีการLifeชนกับเอนทิตีที่มีStrength... ”)

ส่วนประกอบ

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

function Player():
  t = Tag("Player")
  p = Position()
  v = Velocity(p)
  c = KeyboardControlled(v)
  return {t, p, v, c}

• เอนทิตีเป็นใบ้เท่าที่จะทำได้ - เป็นเพียงชุดของส่วนประกอบ

• ส่วนประกอบตอบสนองโดยตรงกับเหตุการณ์เหมือนเมื่อก่อน

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

ข้อสรุป

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

NO และฉันก็ประหลาดใจว่ามีคนโหวตกี่คน!

ตัวอย่าง

มันเป็นData-OrientedหรือData-Drivenเพราะเรากำลังพูดถึงสถาปัตยกรรมและไม่ใช่ภาษาที่ถูกเขียนขึ้นสถาปัตยกรรมคือการตระหนักถึงรูปแบบการเขียนโปรแกรมหรือกระบวนทัศน์ซึ่งมักจะทำงานโดยไม่ตั้งใจในภาษา

การทำงาน?

การเปรียบเทียบของคุณกับการเขียนโปรแกรมเชิงฟังก์ชัน / ขั้นตอนเป็นการเปรียบเทียบที่เกี่ยวข้องและมีความหมาย แต่โปรดทราบว่า "หน้าที่" ภาษาที่แตกต่างกันจาก "ขั้นตอน" กระบวนทัศน์ และคุณสามารถใช้ ECS ในภาษาที่ใช้งานได้เช่นHaskellซึ่งผู้คนได้ทำไปแล้ว

ในกรณีที่การทำงานร่วมกันเกิดขึ้น

การสังเกตของคุณเกี่ยวข้องและตรงประเด็น :

"... [ECS] ไม่ได้ป้องกันคุณจากการใช้งานในภาษา OO แต่มันจะไม่เป็นเรื่องแปลกที่จะทำอย่างนั้นในทาง OO"

ECS / ES ไม่ใช่ EC / CE

มีความแตกต่างระหว่างสถาปัตยกรรมที่ยึดตามส่วนประกอบ "Entity-Component" และ "Entity-Component-System" เนื่องจากนี่เป็นรูปแบบการออกแบบที่มีการพัฒนาฉันได้เห็นคำจำกัดความเหล่านี้ใช้แทนกันได้ "EC" หรือหรือ "ซีอี" หรือ "Entity-Component" สถาปัตยกรรมนำพฤติกรรมในส่วนขณะที่ "ES" หรือ "ECS" สถาปัตยกรรมนำพฤติกรรมในระบบ ต่อไปนี้เป็นบทความ ECS บางส่วนซึ่งทั้งสองอย่างใช้ศัพท์ที่ทำให้เข้าใจผิด แต่เข้าใจความคิดทั่วไป:

• http://www.richardlord.net/blog/what-is-an-entity-framework (Ash framework)
• http://en.wikipedia.org/wiki/Entity_component_system

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

ระบบคอมโพเนนต์ของเอ็นติตี้ (ECS) สามารถตั้งโปรแกรมในแบบ OOP หรือลักษณะการทำงานขึ้นอยู่กับวิธีการกำหนดระบบ

วิธี OOP:

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

วิธีการทำงานเพิ่มเติม:

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

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

TLDR: คุณสามารถทำได้ทั้งสองทาง แต่ฉันขอยืนยันว่าประโยชน์ของระบบส่วนประกอบที่ดีนั้นมาจากลักษณะการใช้งานที่มากกว่า

Data-Oriented Entity Component Systems สามารถอยู่ร่วมกับกระบวนทัศน์ Object-Oriented: - ระบบ Component ยืมตัวเองไปสู่ ​​polymorphism - ส่วนประกอบสามารถเป็นได้ทั้ง POD (ข้อมูลเก่าธรรมดา) และ ALSO Objects (ที่มีคลาสและวิธีการ) และสิ่งทั้งหมดยังคงเป็น 'data oriented' โดยที่วิธี Component Class จะจัดการข้อมูลที่เป็นวัตถุท้องถิ่นเท่านั้น

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

ตัวอย่างเช่น vec2 หรือ vec3 ซึ่งเป็น data container ที่มีวิธีการบางอย่างในการสัมผัสข้อมูลนั้นและไม่มีอะไรเพิ่มเติม

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

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

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

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

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

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

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

และในกรณีของฉันอย่างน้อย ECS SDK พร้อม API และส่วนประกอบทั้งหมดจะถูกนำไปใช้จริงใน C และไม่มีความคล้ายคลึงกันของ OOP ฉันได้พบ C มากกว่าเพียงพอสำหรับวัตถุประสงค์ดังกล่าวเนื่องจากการขาด OO ในสถาปัตยกรรม ECS และความปรารถนาที่จะมีสถาปัตยกรรมปลั๊กอินซึ่งสามารถใช้งานได้ในหลากหลายภาษาและคอมไพเลอร์ ระบบยังคงใช้งานใน C ++ เนื่องจาก C ++ ทำให้สิ่งนั้นสะดวกมากและระบบจำลองโมเดลของความซับซ้อนเป็นจำนวนมากและฉันพบว่ามีการใช้งานสำหรับสิ่งต่าง ๆ มากมายที่อาจได้รับการพิจารณาใกล้เคียงกับ OOP แต่สำหรับรายละเอียดการใช้งาน การออกแบบสถาปัตยกรรมยังคงคล้ายกับขั้นตอน C มาก

อย่างน้อยที่สุดก็พยายามที่จะพูดว่า ECS คือ OO โดยคำจำกัดความ อย่างน้อยที่สุดพื้นฐานก็ทำสิ่งต่าง ๆ ที่สมบูรณ์หัน 180 องศาจากหลักการพื้นฐานทั่วไปที่เกี่ยวข้องกับ OOP เริ่มต้นด้วยการห่อหุ้มและอาจลงท้ายด้วยสิ่งที่จะพิจารณาลักษณะที่ต้องการมีเพศสัมพันธ์