Thay đổi trạng thái trong thực thể hoặc thành phần


9

Tôi đang gặp một số khó khăn khi tìm cách đối phó với quản lý nhà nước trong các thực thể của mình.

Tôi không gặp rắc rối với quản lý trạng thái Trò chơi, như tạm dừng và menu, vì chúng không được xử lý như một hệ thống thành phần thực thể; chỉ với trạng thái trong các thực thể / thành phần.

Vẽ từ Orcs Must Die làm ví dụ, tôi có các thực thể MainCharacter và Bẫy chỉ có các thành phần của chúng như PositionComponent, RenderComponent, ChemistryComponent.

Trên mỗi bản cập nhật, Thực thể sẽ gọi cập nhật trên các thành phần của nó. Tôi cũng có một EventManager chung với người nghe cho các loại sự kiện khác nhau.

Bây giờ tôi cần có khả năng đặt bẫy: đầu tiên chọn vị trí bẫy và bẫy sau đó đặt bẫy.

Khi đặt bẫy, nó sẽ xuất hiện trước MainCharacter, được hiển thị theo một cách khác và theo dõi nó xung quanh. Khi được đặt, nó chỉ cần phản ứng với các va chạm và được kết xuất theo cách thông thường.

Làm thế nào điều này thường được xử lý trong các hệ thống dựa trên thành phần?

(Ví dụ này là cụ thể nhưng có thể giúp tìm ra cách chung để đối phó với các trạng thái thực thể.)


1
Bạn có thể thêm và xóa các thành phần của thực thể dựa trên các sự kiện đầu vào không? Có lẽ bạn có thể thay đổi các thành phần của bẫy khi các trạng thái thay đổi. Ví dụ, trong khi đặt bẫy, nó sẽ có FollowComponent và RenderEffectComponnent. Khi nó được đặt, bạn xóa cả Thành phần và thêm CollisionComponent. (Chỉnh sửa: Được thể hiện rõ hơn bởi Martin Sojka)
Asakeron

Có, tôi có thể, mọi đầu vào được dịch từ "HumanView" thành các sự kiện trong trò chơi, phần lớn trong số chúng, được xử lý lần đầu bởi lớp GameLogic của tôi, sẽ kiểm tra ví dụ nếu MainCharacter có đủ tiền để đặt bẫy hay không, làm thế nào xảy ra sau đó là những gì tôi đang cố gắng để tìm ra.
GriffinHeart

Câu trả lời:


6

Một ứng dụng thú vị của hệ thống thành phần là bạn có thể thay đổi các thành phần của thực thể khi chạy nếu bạn thiết kế nó để có thể xử lý như vậy. Do đó, trạng thái của một thực thể trở thành tổng của cả hai thành phần nào được gán cho nó và giá trị nào được giữ.

Ví dụ của bạn, trước tiên bạn có thể tạo bẫy bằng một BuildControllerComponent(điều khiển phản ứng đối với các điều khiển của người chơi trong giai đoạn xây dựng), a PositionComponentvà a RenderComponent. Cái cuối cùng có một trường dữ liệu chi phối (các) trình tạo bóng pixel được sử dụng và một trong số chúng cung cấp cho cái bẫy để xây dựng một cái nhìn "ma quái". Bạn sẽ nhận thấy không có thành phần vật lý nào được chỉ định.

Khi đặt bẫy, các thành phần được trao đổi. Các BuildControllerComponentkhông cần thiết nữa, vì vậy nó được loại bỏ. Các RenderComponentshader của được thay thế bằng chế độ xem tiêu chuẩn thông thường của bạn về bẫy. Cuối cùng, PhysicsComponentcũng như bất cứ điều gì khác cần thiết để bẫy hoạt động được thêm vào thực thể.

Theo cách tiếp cận dựa trên thừa kế, điều này tương đương với việc có một hàm tạo cho một ActiveTrapEntitylớp lấy một BuildTimeTrapEntitylớp làm đối số của nó, lớp thứ hai được sử dụng để tạo ra cái bẫy trong khi xây dựng nó, cái đầu tiên được sử dụng cho cái bẫy sau khi nó được đặt .


Đây là thông minh.
Cypher

1
Đây là chiến lược tốt để áp dụng trạng thái của một thực thể. Nó không giải quyết vấn đề làm thế nào để theo dõi trạng thái của từng thực thể. Làm thế nào để bạn biết trạng thái hiện tại của thực thể?
MichaelHouse

@MartinSojka Điều này đến gần những gì tôi đã suy nghĩ sau khi đặt câu hỏi. Tôi đã xem xét việc thêm BuildTrapProcess (Thứ gì đó được cập nhật tại GameLogic) sẽ quản lý khía cạnh thời gian chạy của việc thay đổi các thành phần để đạt được các thay đổi trạng thái cần thiết để tạo bẫy. Khi nhấn nút xây dựng bẫy, logic trò chơi sẽ tạo ra Quá trình và khởi động nó. bất kỳ suy nghĩ về phương pháp này?
GriffinHeart

@ Byte56: Nói chung, bạn có thể truy vấn các thành phần liên quan và các giá trị của nó. Trong thực tế, bạn thường chỉ cần biết tập hợp con có liên quan của toàn bộ trạng thái, ví dụ "Thực thể này có BuildControllerComponentkhông?" hoặc "Vị trí của thực thể này như được ghi trong đó là gì PositionComponent, nếu nó có bất kỳ?" - những người bạn làm bằng cách kiểm tra danh sách thành phần cho những người bạn quan tâm và tùy ý truy vấn (một số) giá trị của họ.
Martin Sojka

1
@GriffinHeart: Tôi chỉ cần thực hiện bất cứ điều gì cần thiết để "xây dựng" cái bẫy trong hệ thống liên quan đến việc quản lý BuildControllerComponents. Nó đã cần xử lý các thay đổi quan điểm của nhân vật người chơi (hoặc máy ảnh) và các sự kiện nhấn phím và chuột.
Martin Sojka

5

Tôi không thích ý tưởng về các thực thể gọi các bản cập nhật trên các thành phần của chúng (các hệ thống nên thực hiện công việc) và điều đó sẽ dẫn đến các vấn đề với việc giữ cho các thành phần không biết về nhau.

Bạn có thể thêm một thành phần bổ sung gọi là "Bang". Nó sẽ được truy cập bởi hệ thống kết xuất và va chạm của bạn. Thành phần trạng thái chỉ là một cờ có nhiều trạng thái có sẵn cho nó. Đối với tình huống bạn mô tả các trạng thái sẽ PlayBuild. Khi hệ thống render thấy rằng trạng thái là Buildnó sẽ vẽ đối tượng mờ. Khi hệ thống va chạm nhìn thấy Buildtrạng thái, nó sẽ không xử lý va chạm với người chơi.

Nhưng thực sự, nếu bạn không có hệ thống và bạn đang dựa vào các thành phần để thực hiện tất cả công việc bạn sẽ gặp phải rất nhiều vấn đề. Các thành phần không nên biết về nhau và chúng không nên xử lý.


Những gì bạn đang nói là mâu thuẫn, đầu tiên họ nên không biết (mà tôi đồng ý) sau đó bạn làm theo bằng cách có một thành phần được người khác truy cập. Bạn có thể làm rõ? Tôi đang giữ các thành phần tách rời bởi hệ thống sự kiện.
GriffinHeart

Tôi đang nói cả hai. Tôi đang nói rằng họ không nên biết và cố gắng điều chỉnh phản ứng của tôi với cách tôi nghĩ bạn đang xử lý các thành phần. Khi bạn nói "Thực thể sẽ gọi cập nhật trên các thành phần của nó", điều đó khiến tôi tin rằng bạn không có các thực thể xử lý hệ thống. Tôi đã loại bỏ ngôn ngữ khó hiểu và chỉ nói nó là hệ thống. Tôi đã nói các thành phần bởi vì tôi hiểu rằng đó là cách bạn đang cập nhật.
MichaelHouse

Tôi thích ý tưởng về một StateComponenthệ thống có thể được sử dụng bởi nhiều hệ thống.
Cypher

1
Đó là lịch sự để cung cấp lý do cho downvote. Cảm ơn.
MichaelHouse

2
Một lưu ý khác, sự phản đối của bạn đối với cách tiếp cận của người hỏi dựa trên giả định rằng tất cả các thiết kế dựa trên thành phần phải cập nhật các thành phần từ các hệ thống riêng biệt (như thiết kế hệ thống thực thể). Đó là một cách để làm điều đó, nhưng chắc chắn không phải là cách duy nhất và không có lý do gì để từ chối cách tiếp cận như vậy đối với một trò chơi không cần vòng lặp cập nhật thành phần tối ưu hóa bộ đệm.
Sean Middleditch
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.