Xử lý vấn đề nhóm thành phần - Hệ thống con thực thể

Mô tả kiến ​​trúc

Tôi đang tạo (thiết kế) một hệ thống thực thể và tôi gặp phải nhiều vấn đề. Tôi đang cố gắng giữ cho nó hướng đến dữ liệu và hiệu quả nhất có thể. Các thành phần của tôi là các cấu trúc POD (chính xác là các byte) được phân bổ trong các nhóm đồng nhất. Mỗi nhóm có một ElementDescriptor - nó chỉ chứa tên thành phần, loại trường và tên trường.

Thực thể chỉ là một con trỏ tới mảng các thành phần (trong đó địa chỉ hoạt động như một ID thực thể). EntityPrototype chứa tên thực thể và mảng các tên thành phần. Cuối cùng là Hệ thống con (Hệ thống hoặc Bộ xử lý) hoạt động trên nhóm thành phần.

Vấn đề thực tế

Vấn đề là một số thành phần phụ thuộc vào các thành phần khác (Model, Sprite, PhysBody, Animation phụ thuộc vào thành phần Transform), điều này gây ra nhiều vấn đề khi xử lý chúng.

For example, lets define some entities using [S]prite, [P]hysicalBody and [H]ealth:
Tank:   Transform, Sprite, PhysicalBody
BgTree: Transform, Sprite
House:  Transform, Sprite, Health

and create 4 Tanks, 5 BgTrees and 2 Houses and my pools will look like:

TTTTTTTTTTT // Transform pool
SSSSSSSSSSS // Sprite pool
PPPP        // PhysicalBody pool
HH          // Health component

Không có cách nào để xử lý chúng bằng cách sử dụng các chỉ số. Tôi dành 3 ngày để làm việc với nó và tôi vẫn không có ý tưởng nào. Trong các thiết kế trước đây TransformComponent bị ràng buộc với thực thể - nhưng đó không phải là một ý tưởng tốt. Bạn có thể cho tôi một số lời khuyên làm thế nào để xử lý chúng? Hoặc có lẽ tôi nên thay đổi thiết kế tổng thể? Có lẽ tôi nên tạo các nhóm quyền (nhóm nhóm thành phần) - nhưng tôi đoán nó sẽ là cơn ác mộng đối với bộ nhớ CPU.

Cảm ơn

Disclaimer: Hoàn toàn đi ra khỏi kiến ​​thức lớp hệ thống của tôi.

Ban đầu tôi nghĩ, tại sao không sử dụng hàm băm trên ID thực thể cho chỉ mục của bạn?

Bằng cách đó bạn sẽ nhận được

T[A]nk:   Transform, Sprite, PhysicalBody
B[G]Tree: Transform, Sprite
H[O]use:  Transform, Sprite, Health

and create 4 Tanks, 5 BgTrees and 2 Houses and my pools will look like:

OGAGAGGOGGG // Entity pool (letters corresopnding to entity type)
TTTTTTTTTTT // Transform pool
SSSSSSSSSSS // Sprite pool
P P P  P    // PhysicalBody pool
H      H    // Health component

Hoặc tuy nhiên đó là các thực thể đã được đặt. Bạn có thể có các nhóm cho tất cả các thành phần và cho các thực thể và sử dụng nhóm thực thể làm "chủ", sao cho các xung đột được kiểm tra đối với mảng thực thể. Nhưng tất nhiên bạn nhận được vấn đề tái chế các thành phần và thực thể.

Nếu thiết kế trò chơi của bạn cho phép, bạn có thể lên kế hoạch trước từng loại thực thể để bạn có thể đóng gói hiệu quả nhất có thể. Giả sử các thực thể 0-20 được dành riêng cho xe tăng, thực thể 21-30 cho nhà ở và 31-60 cho BGTrees. Bạn có thể không thể sinh ra các baddos vô hạn một cách hiệu quả và có thể đánh bại tính năng động của các hệ thống thành phần, nhưng nó sẽ giải quyết được vấn đề. Tôi không thấy cách để có bánh của bạn và cũng ăn nó.

Tôi đã suy nghĩ về các cách có thể tăng tốc độ kết xuất trong đó bạn có một RenderingComponentdữ liệu chứa tất cả dữ liệu mà hệ thống kết xuất cần để nó có thể thổi qua một loạt những thứ này, nhưng sau đó có quá trình sao chép dữ liệu. Ngoài ra, bất cứ khi nào bạn bỏ qua một con trỏ bạn đang nghĩ về việc nó có còn trong bộ đệm hay không.

Nếu bạn muốn một trò chơi siêu tốc độ, tôi muốn nói lên kế hoạch phân bổ của bạn. Nếu bạn muốn một kiến ​​trúc trò chơi linh hoạt, hãy tung ra các hashtables và ID chuỗi. Bất cứ lúc nào bạn muốn linh hoạt, bạn cần xây dựng sự trừu tượng, và do đó sẽ phải chịu chi phí.

TL; DR;
Dựa trên những gì bạn mô tả, tôi sẽ tạo một mức cao hơn RenderComponentvới các con trỏ Spritevà Transformcác thành phần và cung cấp cho nó các tham chiếu cần thiết khi bạn khởi tạo thực thể.

(Xin lỗi vì bất kỳ sự lan man nhận thức nào, tôi cũng đã suy nghĩ về điều này trong hệ thống của mình, vì vậy đây là cơ hội để suy nghĩ về nó)