Vai trò của một trạng thái thực thể trong một hệ thống dựa trên thành phần?

8

Các hệ thống thực thể dựa trên thành phần là tất cả các cơn thịnh nộ ngày nay; mọi người dường như đồng ý rằng họ là con đường để đi, nhưng không ai thực sự có một triển khai dứt khoát của một hệ thống như vậy. Tôi đã tự hỏi, vai trò của các trạng thái thực thể (đi bộ trái, đứng, nhảy, v.v.) trong CBS là gì? Họ có hành động như các bộ điều khiển (tức là họ xử lý các sự kiện và thay đổi các thuộc tính của thực thể dựa trên các sự kiện đó)?

Điều gì về các trường hợp trong đó một trạng thái, ví dụ, yêu cầu thực thể vào chế độ không có clip? Nếu trạng thái đó, khi nó đi vào, có thể đặt CollisionComponent của thực thể thành một con trỏ null hay cái gì đó? (Sau đó, khi thoát, trạng thái sẽ khôi phục CollisionComponent của thực thể về trạng thái trước đó.)

Ngoài ra, tôi đoán đó là công việc của nhà nước hiện tại để thay đổi trạng thái của thực thể thành một thứ khác, phải không?

architecture component-based entity-system

— Paul Manta
nguồn

5

Tôi cho rằng không có "triển khai dứt khoát" bởi vì tất cả các trò chơi đều có những yêu cầu khác nhau và mỗi quyết định bạn đưa ra trong thiết kế hệ thống đều có sự đánh đổi riêng. Chỉ cần làm những gì có ý nghĩa với bạn, và chắc chắn tái cấu trúc khi mọi thứ trở nên lộn xộn.

— Tết

@The Vịt Cộng sản, là một chút thấp ... haha

— deceleratedcaviar

9

Tôi có ấn tượng rằng trong một thiết kế dựa trên các thành phần, các thực thể về cơ bản là các thành phần chứa (có thể có một số thông điệp được gửi vào). Nhìn từ góc độ này, mỗi thành phần sẽ lưu trữ một chút trạng thái. Chẳng hạn, nếu các thành phần hành vi ma quyết định nó cần vào chế độ vô hình, nó cũng sẽ gửi một thông điệp đến thành phần vật lý để bảo nó kích hoạt tính năng không có clip. Nó cũng có thể sẽ gửi một thông điệp đến các thành phần mô hình ma nói để khởi động alpha.

— deft_code
nguồn

2

Máy móc nhà nước và các thành phần là kỹ thuật trực giao. Bạn có thể có các trạng thái trong các thành phần của mình hoặc không, giống như bạn có thể có các trạng thái trong bất kỳ lớp nào. Bạn có thể có một quan sát thành phần (xem Mẫu quan sát) và thay đổi trạng thái của thành phần khác. Máy nhà nước có nhiều công dụng và việc thực hiện sẽ phụ thuộc vào nhu cầu của bạn.

Đối với nhân vật, trạng thái của nhân vật mà bạn mô tả (đi, đứng, nhảy), tôi đã thấy các triển khai trong đó các thành phần khác nhau đều duy trì các máy trạng thái của riêng họ ... vật lý, hoạt hình, điều khiển, ai. Các thành phần nên có thẩm quyền rõ ràng về các thành phần khác mà chúng phản ứng và trạng thái thành phần nào chúng có thể thay đổi.

— Evan Rogers
nguồn

2

Thiết kế Thành phần dưới dạng cấu trúc chỉ có dữ liệu, không có logic nào phức tạp hơn getters và setters. Không tạo ra sự phụ thuộc giữa các Thành phần hoặc bạn sẽ mất hầu hết các lợi ích của Hệ thống Thực thể.

Xem ví dụ về phương pháp này (gần với tầm nhìn của máy t) tại đây: https://github.com/thelinuxlich/starwar Warrior_CSharp

Và chính động cơ: https://github.com/thelinuxlich/artemis_CSharp

— thelinuxlich
nguồn

Tôi khá không đồng ý với "không logic phức tạp hơn getters và setters", nhưng tôi đến từ khung tham chiếu Unity nơi mọi thứ đều là một thành phần. Tôi sẽ nghĩ rằng các thành phần sẽ có thể tự quản lý.

— Tetrad

1

Đó là bởi vì Unity không có bất cứ thứ gì như Hệ thống gắn liền với trò chơi, nó xử lý các thực thể có các thành phần cấu thành khía cạnh hệ thống.

— thelinuxlich