Mức độ chi tiết thích hợp cho kiến ​​trúc dựa trên thành phần là gì?

Tôi đang làm việc trên một trò chơi có kiến ​​trúc dựa trên thành phần. An Entitysở hữu một tập hợp các Componentthể hiện, mỗi trường hợp có một tập hợp các Slotthể hiện để lưu trữ, gửi và nhận các giá trị. Các chức năng của nhà máy như Playersản xuất các thực thể với các thành phần cần thiết và các kết nối khe.

Tôi đang cố gắng xác định mức độ chi tiết tốt nhất cho các thành phần. Ví dụ, ngay bây giờ Position, Velocityvà Accelerationlà tất cả các thành phần riêng biệt, được kết nối theo chuỗi. Velocityvà Accelerationcó thể dễ dàng được viết lại thành một bộ đồng phục Deltathành phần, hay Position, Velocityvà Accelerationcó thể được kết hợp cùng với các thành phần như Frictionvà Gravitythành một khối Physicsthành phần.

Một thành phần nên có trách nhiệm nhỏ nhất có thể (với chi phí rất nhiều kết nối) hoặc các thành phần liên quan nên được kết hợp thành các thành phần nguyên khối (với chi phí linh hoạt)? Tôi đang nghiêng về phía trước, nhưng tôi có thể sử dụng ý kiến ​​thứ hai.

Có một ranh giới giữa độ chi tiết hoàn chỉnh, dẫn đến không lãng phí mã hoặc trạng thái giống như blob (đó là lý do tại sao kiến ​​trúc thành phần được ưa chuộng) và khả năng sử dụng.

Rõ ràng mọi thứ có thể có một Position, nhưng chúng không nhất thiết phải năng động (vậy tại sao lại có Velocityvà Acceleration?). Tuy nhiên, một cái gì đó với một Velocitysẽ là một đối tượng chuyển động, vì vậy nó cũng có ý nghĩa để Accelerationđược nhóm lại.

Bạn sẽ có một trường hợp cần v và a , nhưng bạn không muốn mô phỏng vật lý cho họ? Tương tự như vậy, sẽ có một điểm trong Gravitynếu chúng không phải là vật thể vật lý?

tl; dr Nhóm những gì có ý nghĩa.

Để tránh vi mô hóa từng biến mà tôi đề xuất bằng cách bắt đầu nặng nề, hãy chọn các phân chia xung quanh trách nhiệm và tái cấu trúc khi tình huống xuất hiện một cách hợp lý. Bạn có thể bắt đầu những thiết kế đầu tiên trên giấy. Tại một số điểm, các bộ phận trách nhiệm thô này sẽ trở thành các khối xây dựng của các thực thể của bạn.

Vì vậy, đối với một ví dụ vội vàng, bạn có Game. Trò chơi chia thành Môi trường + Nhà nước. Môi trường phân chia thành StaticWorld + MoveStuff. Trạng thái chia thành AIControlled + PlayerControlled. Ý tưởng tổng thể về Thiệt hại chia thành TakesDamage + GivesDamage.

Và như vậy.

Giống như lời khuyên phổ biến để "Xây dựng trò chơi, không phải động cơ!" Đối với các học viên mới, tôi khuyên bạn nên "Xây dựng trò chơi, không xây dựng các hệ thống thành phần!" bởi vì chỉ với kinh nghiệm cá nhân với một trò chơi đang chạy, bạn sẽ biết liệu một hệ thống thành phần phức tạp có được yêu cầu trong các tác phẩm trong tương lai hay không.

Tôi đoán sẽ kết hợp các thành phần, những người sẽ có nhiều tương tác. Trong trường hợp của bạn, tôi sẽ giữ vị trí trong một thành phần duy nhất và có vận tốc & gia tốc được giữ cùng nhau trong một thành phần vật lý.

Nhưng nó phụ thuộc rất nhiều vào tính năng trò chơi của bạn là gì (trừ khi bạn đang xây dựng một khung không có trò chơi cụ thể nào trong đầu).

Tôi nhận ra đây là một câu hỏi cũ nhưng có lẽ ai đó sẽ thấy câu trả lời này hữu ích.

Tôi tin rằng Systems sẽ giúp bạn hiểu rõ hơn về cách xây dựng Thành phần. Các hệ thống tồn tại trong các kiến ​​trúc nơi các thành phần không chứa logic riêng của chúng, ngoài các hàm getter / setters đơn giản và các hàm trợ giúp. Hệ thống hoạt động trên các Thực thể đáp ứng các yêu cầu Thành phần. Đây là lý do tại sao tốt nhất nên tách dữ liệu thành phần càng nhiều càng hợp lý khi dữ liệu đó được xử lý mà không có dữ liệu khác.

Ví dụ: bạn có thể MovementSystemcập nhật các Thực thể của nó Positiondựa trên thực thể của chúng Velocity. Điều này có thể dành cho các thực thể đơn giản trong trò chơi. Nhưng, đối với Người chơi và Kẻ thù, bạn có thể muốn chuyển động Accelerationđược xử lý AcceleratedMovementSystem. Nhưng đối với những trở ngại bạn có thể muốn Friction. Các địa hình cũng có thể có ma sát, nhưng nó sẽ không có một thành phần vận tốc. Nhưng còn cái gì Gravity? Chỉ cần thêm nó Người chơi, Kẻ thù và Trở ngại, và tạo một GravitySystemđể xử lý nó.

Điểm mấu chốt là rằng càng tách riêng của bạn Componentsthì càng mở rộng sự Entitiessẽ là khi sử dụng Systems.

Chỉnh sửa: Thực hiện tuyên bố cuối cùng rõ ràng hơn.

Chỉnh sửa: Ok, tôi đã làm việc trên Hệ thống của riêng mình và nhận ra điều này. Một ví dụ để phân chia Vị trí và Vận tốc là việc điều khiển Vận tốc làm cho Vị trí thay đổi với Hệ thống Chuyển động. Do đó, 'InputMovementSystem' không cần Vị trí để Trình phát di chuyển từ Đầu vào của người dùng vì MovementSystem sẽ chọn các thay đổi trong Vận tốc để áp dụng cho Vị trí. Cấp, nó vẫn hoạt động tốt để đặt chúng lại với nhau, nhưng đó là một ví dụ về lý do tại sao không cần phải như vậy.

Tôi đọc một bài đăng trên blog gần đây đã nói một cái gì đó như thế này:

"Nếu bạn có dữ liệu có thể được nhóm với 2 thành phần khác nhau, tốt nhất là tạo thành phần thứ ba với dữ liệu đó."