Trong Công cụ hệ thống thực thể-thành phần, làm thế nào để tôi đối phó với các nhóm thực thể phụ thuộc?

Sau khi xem qua một vài mẫu thiết kế trò chơi, tôi đã giải quyết với Entity-Element-System (ES System) cho công cụ trò chơi của mình. Tôi đã đọc các bài viết (chủ yếu là T = Machine ) và xem xét một số mã nguồn và tôi nghĩ rằng tôi đã có đủ để bắt đầu.

Chỉ có một ý tưởng cơ bản mà tôi đang đấu tranh. Làm thế nào để tôi đối phó với các nhóm thực thể phụ thuộc lẫn nhau?

Hãy để tôi sử dụng một ví dụ:

Giả sử tôi đang thực hiện một game bắn súng trên cao tiêu chuẩn (nghĩ Jamestown ) và tôi muốn xây dựng một "thực thể ông chủ" với nhiều phần riêng biệt nhưng được kết nối. Sự đổ vỡ có thể trông giống như thế này:

• Thân tàu: Chuyển động, kết xuất
• Pháo: Vị trí (bị khóa tương đối với thân tàu), Theo dõi \ Bắn vào anh hùng, Nhận sát thương cho đến khi bị vô hiệu hóa
• Lõi: Vị trí (bị khóa so với thân tàu), Theo dõi \ Bắn vào anh hùng, Gây sát thương cho đến khi bị vô hiệu hóa, Vô hiệu hóa (er ... phá hủy) tất cả các thực thể khác trong nhóm tàu

Mục tiêu của tôi sẽ là thứ gì đó sẽ được xác định (và thao túng) như một yếu tố trò chơi riêng biệt mà không phải viết lại hệ thống con tạo thành nền tảng mỗi khi tôi muốn xây dựng một Thành phần tổng hợp mới.

Làm cách nào để triển khai loại thiết kế này trong Hệ thống ES?

1. Tôi có thực hiện một số loại quan hệ thực thể cha-con (thực thể có thể có con) không? Điều này dường như mâu thuẫn với phương pháp luận rằng các Thực thể chỉ là vật chứa rỗng và khiến nó cảm thấy OOP nhiều hơn.
2. Tôi có triển khai chúng dưới dạng các thực thể riêng biệt, với một số loại kết nối Thành phần (BossComponent) và hệ thống liên quan (BossSubSystem) không? Tôi không thể không nghĩ rằng điều này sẽ khó thực hiện vì cách các thành phần giao tiếp dường như là một cái bẫy lớn.
3. Tôi có triển khai chúng dưới dạng một Thực thể, với một bộ sưu tập các thành phần (ShipComponent, CannonComponents, CoreComponent) không? Điều này dường như xoay quanh ý định của Hệ thống ES (các thành phần ở đây có vẻ quá giống các thực thể nặng), nhưng tôi biết điều này nên tôi nghĩ rằng tôi sẽ đưa nó ra ngoài đó.
4. Tôi có thực hiện chúng như một cái gì đó khác mà tôi đã đề cập không?

Tôi biết rằng điều này có thể được thực hiện rất dễ dàng trong OOP, nhưng việc tôi chọn ES trên OOP là một điều mà tôi sẽ gắn bó. Nếu tôi cần phải phá vỡ lý thuyết ES thuần túy để thực hiện thiết kế này thì tôi sẽ (không giống như tôi chưa phải thỏa hiệp thiết kế thuần túy trước đây), nhưng tôi thích làm điều đó vì lý do hiệu suất hơn là bắt đầu với thiết kế xấu.

Để có thêm tín dụng, hãy nghĩ về cùng một thiết kế, nhưng, mỗi "thực thể ông chủ" thực sự được kết nối với một "thực thể BigBoss" lớn hơn được tạo thành từ một cơ thể chính, lõi chính và 3 "Thực thể ông chủ". Điều này sẽ cho tôi thấy một giải pháp cho ít nhất 3 chiều (ông bà-cha mẹ-con) ... là quá đủ cho tôi.

Nếu tôi ở trong tình huống này, tôi sẽ tạo ra từng bộ phận của ông chủ như một thực thể riêng biệt. Những "thực thể phụ" này sẽ bao gồm một số loại AttachmentPointhoặc ParentEntitythành phần. Thành phần này sẽ bao gồm một tham chiếu đến thực thể cha mẹ và phần bù từ vị trí cha mẹ. Khi cập nhật vị trí, họ kiểm tra vị trí cha mẹ và áp dụng bù để tạo vị trí riêng của họ. Ngoài ra, nó có thể thực hiện kiểm tra để đảm bảo thực thể mẹ vẫn tồn tại. Hơn nữa, bạn có thể có một SubEntitythành phần theo dõi sự tồn tại của các thực thể phụ cho thực thể mẹ. Điều này cho phép bạn làm những việc như chỉ khiến lõi của ông chủ dễ bị tổn thương khi những cánh tay có khiên bị phá hủy.

Tôi hiện đang sử dụng một TargetEntitythành phần trong trò chơi của mình, được sử dụng để theo dõi tháp pháo và khi yêu tinh sẽ lấy tài nguyên. Nó có thể kiểm tra vị trí của thực thể mục tiêu và thay đổi hành vi của nó cho phù hợp. Các thực thể không có vị trí không bao giờ được thêm làm mục tiêu, vì vậy không có lo lắng ở đó. Tuy nhiên, khi tìm hiểu sâu hơn, như kiểm tra sức khỏe của thực thể cha mẹ hoặc con cái, lá chắn, dự trữ năng lượng hoặc bất cứ điều gì, bạn sẽ phải đảm bảo thực thể cha mẹ hoặc con cái thực sự có thành phần liên quan.

Làm cho mỗi bộ phận, thực thể riêng của nó duy trì tính linh hoạt của khung thực thể / thành phần bằng cách cho phép bạn thêm các thành phần bổ sung và khác nhau cho từng bộ phận của ông chủ. Ví dụ, một phần của boss có thể có thành phần súng và thành phần sức khỏe trong khi phần khác sẽ có thành phần khiên và thành phần sức khỏe.

Tôi tìm thấy một cuộc thảo luận về chủ đề này ở đây . Trong đó người dùng đang thảo luận về việc thêm nhiều thành phần cùng loại vào một thực thể (có vẻ như đó là một ý tưởng tồi đối với tôi). Có vẻ như một cuộc trò chuyện hữu ích, mặc dù tôi chưa đọc toàn bộ cuộc thảo luận.

Không biết quá nhiều chi tiết về các hệ thống hiện tại của bạn, cách tôi sẽ mô hình hóa hệ thống này (và ở một mức độ nào đó trong hệ thống thực thể của riêng tôi) là có một thành phần như AttachedTo (ParentEntity). Bất kỳ đứa trẻ nào sau đó cũng có thể được cung cấp thành phần Đính kèm (ông chủ).

Sau đó, hệ thống kết xuất (hoặc bất cứ thứ gì) lấy các thực thể với các thành phần: Position, AttachedTo, v.v. và tạo thành hệ thống phân cấp thích hợp.

Nếu bạn muốn có một thực thể được đại diện chỉ bằng một ID, thì việc ngăn chặn các thực thể có thể được thực hiện thông qua một thành phần đặc biệt. Bạn có thể gọi nó là CompositeComponent và nó chứa danh sách ID thực thể con và giao diện để thêm / xóa con khỏi danh sách đó.

Rõ ràng bất kỳ thành phần nào phụ thuộc vào vị trí, vv sẽ cần phải làm việc với cái này để đặt thực thể đúng cách. Cách thực hiện điều này sẽ phụ thuộc phần nào vào cách bạn triển khai định vị hiện tại.

Nhân tiện, không có "lý thuyết ES thuần túy" - làm cho các thực thể ra khỏi các thành phần là một cách tiếp cận phổ biến nhưng phương pháp chính xác vẫn chưa được chuẩn hóa.