Xử lý sự kiện trong thiết kế công cụ trò chơi dựa trên thành phần

Question

Tôi tưởng tượng câu hỏi này hoặc các biến thể của nó được chuyển qua rất nhiều, vì vậy nếu những gì tôi nói là trùng lặp và câu trả lời nằm ở nơi khác, vui lòng thông báo cho tôi.

Tôi đã nghiên cứu thiết kế công cụ trò chơi và đã bắt gặp mô hình thực thể dựa trên thành phần. Nghe có vẻ đầy hứa hẹn, nhưng tôi vẫn đang triển khai thực hiện.

Tôi đang xem xét một hệ thống nơi động cơ được sắp xếp một số "hệ thống phụ", quản lý một số khía cạnh, như hiển thị, âm thanh, sức khỏe, AI, v.v. Mỗi hệ thống con có loại thành phần liên kết với nó. thành phần cho hệ thống con y tế. Một "thực thể", ví dụ như một NPC, một cánh cửa, một số hiệu ứng hình ảnh hoặc trình phát, chỉ đơn giản bao gồm một hoặc nhiều thành phần, khi cùng nhau cung cấp cho thực thể chức năng của nó.

Tôi đã xác định bốn kênh thông tin chính: một thành phần có thể phát tới tất cả các thành phần trong thực thể hiện tại, một thành phần có thể phát tới hệ thống con, một hệ thống con có thể phát tới các thành phần của nó và hệ thống phụ có thể phát tới các hệ thống phụ khác.

Ví dụ: nếu người dùng muốn di chuyển ký tự của họ, họ sẽ nhấn một phím. Nhấn phím này sẽ được chọn bởi hệ thống con đầu vào, sau đó phát sóng sự kiện và sẽ được chọn bởi hệ thống con của trình phát. Hệ thống con của trình phát sau đó gửi sự kiện này tới tất cả các thành phần của trình phát (và do đó các thực thể mà các thành phần đó tạo), và các thành phần trình phát đó sẽ liên lạc với thành phần vị trí của thực thể riêng của nó để tiếp tục và di chuyển.

Tất cả điều này cho một lần nhấn phím có vẻ hơi bị cuộn và tôi chắc chắn sẽ mở để cải thiện kiến ​​trúc này. Nhưng dù sao, câu hỏi chính của tôi vẫn theo sau.

Đối với chính các sự kiện, tôi đã xem xét vị trí một sự kiện hoạt động như trong mẫu khách truy cập. Tầm quan trọng của những gì tôi muốn là nếu một sự kiện đi qua một thành phần nó không hỗ trợ (như trong một sự kiện di chuyển không có gì trực tiếp để làm với AI hoặc sức khỏe), nó sẽ bỏ qua các thành phần. Nếu một sự kiện không tìm thấy thành phần nó đang diễn ra, điều đó không quan trọng.

Mẫu khách truy cập hầu như hoạt động. Tuy nhiên, nó sẽ yêu cầu tôi có các chức năng ảo cho mọi loại thành phần (ví dụ: truy cập HealthComponent, visitPositionComponent, v.v.) ngay cả khi nó không có liên quan gì đến chúng. Tôi có thể để trống các hàm này (vì vậy nếu nó đi qua các thành phần đó, nó sẽ bị bỏ qua), nhưng tôi sẽ phải thêm một hàm khác mỗi khi tôi thêm một thành phần.

Hy vọng của tôi là tôi có thể thêm thành phần mà không nhất thiết phải thêm nội dung vào các địa điểm khác và thêm sự kiện mà không gây rối với các nội dung khác.

Vì vậy, hai tôi hỏi:

1. Có bất kỳ cải tiến thiết kế của tôi có thể cho phép, về mặt hiệu quả, linh hoạt, vv?
2. Cách tối ưu để xử lý sự kiện là gì?

Answer 1

Tôi đã suy nghĩ về việc sử dụng hệ thống thực thể cho một trong các dự án của riêng mình và đã trải qua quá trình suy nghĩ tương tự. Suy nghĩ ban đầu của tôi là sử dụng một mẫu Observer để đối phó với các sự kiện - tôi cũng vậy, ban đầu được coi là kiểu khách truy cập nào đó, nhưng đã quyết định chống lại nó vì những lý do bạn đưa ra.

Suy nghĩ của tôi là các hệ thống phụ sẽ cung cấp giao diện đăng ký/đăng ký cụ thể của hệ thống phụ và do đó phụ thuộc hệ thống phụ sẽ được giải quyết theo kiểu kết hợp "bán lỏng lẻo".Bất kỳ hệ thống phụ nào phụ thuộc vào các sự kiện từ một hệ thống con khác sẽ biết về giao diện người đăng ký vào hệ thống con đó và do đó có thể sử dụng hiệu quả nó.

Thật không may, cách những người đăng ký này có được xử lý cho nhà xuất bản của họ vẫn còn là một vấn đề trong đầu tôi. Tại thời điểm này, tôi ưu tiên một số kiểu tạo động, trong đó mỗi hệ thống con được khởi tạo, và sau đó một pha thứ hai được sử dụng để giải quyết các phụ thuộc và đặt tất cả các hệ thống con vào một "trạng thái sẵn sàng".

Dù sao, tôi rất quan tâm đến những gì làm việc ra cho bạn và bất kỳ vấn đề bạn gặp phải trên dự án của bạn :)

Answer 2

Sử dụng một xe buýt sự kiện, aka aggregator sự kiện. Những gì bạn muốn là một cơ chế sự kiện không yêu cầu phải ghép nối giữa các hệ thống phụ và một bus sự kiện sẽ làm điều đó.

http://martinfowler.com/eaaDev/EventAggregator.html http://stackoverflow.com/questions/2343980/event-aggregator-implementation-sample-best-practices

vv

Answer 3

kiến ​​trúc này mô tả ở đây http://members.cox.net/jplummer/Writings/Thesis_with_Appendix.pdf Có ít nhất ba vấn đề Tôi đã gặp phải việc thực hiện điều này trong một dự án thực tế:

1. hệ thống không được thông báo khi có điều gì đó xảy ra - chỉ có cách để hỏi về điều đó - người chơi đã chết? tường không nhìn thấy được? và như vậy - để tránh điều này, bạn có thể sử dụng MVC đơn giản thay vì mẫu quan sát.
2. nếu đối tượng của bạn là một phần ghép (tức là bao gồm các đối tượng)? hệ thống sẽ đi qua tất cả các hệ thống phân cấp và hỏi về trạng thái thành phần.
3. Và bất lợi chính là kiến ​​trúc này kết hợp tất cả lại với nhau - ví dụ: tại sao người chơi cần biết rằng bạn đã nhấn một phím?

tôi nghĩ rằng câu trả lời đó là kiến ​​trúc lớp với đại diện trừu tượng ...

Answer 4

Excuse tiếng Anh xấu của tôi.

Tôi đang viết một công cụ trò chơi java 3d linh hoạt và có thể mở rộng dựa trên Hệ thống thành phần thực thể. Tôi đã hoàn thành một số phần cơ bản của nó.

Trước tiên tôi muốn nói điều gì đó về kiến ​​trúc ECS, tôi không đồng ý rằng một thành phần có thể giao tiếp với các thành phần khác trong cùng một thực thể. Các thành phần chỉ nên lưu trữ dữ liệu và hệ thống xử lý chúng.

Trong phần xử lý sự kiện, tôi cho rằng việc xử lý đầu vào cơ bản không nên được đưa vào ECS. Thay vào đó, tôi có một System gọi là Intent System và có một Component được gọi là Intent Component chứa nhiều intent. Mục đích có nghĩa là một thực thể muốn làm điều gì đó đối với một thực thể. Intent System xử lý tất cả các ý định, Khi nó xử lý một mục đích, nó phát sóng thông tin tương ứng với các hệ thống khác hoặc thêm các thành phần khác vào thực thể.

Tôi cũng viết một giao diện có tên là Intent Generator. Trong trò chơi địa phương, bạn có thể thực hiện một đầu vào bàn phím hoặc đầu vào chuột máy phát điện và trong trò chơi nhiều người chơi, bạn có thể thực hiện máy phát điện ý định mạng. Trong hệ thống AI, bạn cũng có thể tạo ra ý định.

Bạn có thể nghĩ Hệ thống ý định xử lý quá nhiều thứ trong trò chơi. Nhưng trên thực tế, nó chia sẻ nhiều chế biến cho các hệ thống khác Và tôi cũng viết một hệ thống tập lệnh. Đối với thực thể đặc biệt cụ thể, nó có một thành phần kịch bản làm những việc đặc biệt.

Ban đầu khi tôi phát triển thứ gì đó, tôi luôn muốn tạo ra một kiến ​​trúc tuyệt vời bao gồm mọi thứ. Nhưng đối với trò chơi phát triển đôi khi nó là rất kém hiệu quả. Đối tượng trò chơi khác nhau có thể có các chức năng hoàn toàn khác nhau. ECS rất tuyệt vời như hệ thống lập trình hướng dữ liệu. nhưng chúng tôi không thể bao gồm mọi thứ trong đó cho một trò chơi hoàn chỉnh.

Nhân tiện, công cụ trò chơi dựa trên ECS của chúng tôi sẽ là nguồn mở trong tương lai gần, sau đó bạn có thể đọc nó. Nếu bạn quan tâm đến nó, tôi cũng mời bạn tham gia với chúng tôi.