Truyền thông hướng sự kiện trong Game Engine: Có hay không?

Tôi đang đọc Toàn bộ mã hóa trò chơi và tác giả khuyến nghị giao tiếp theo hướng sự kiện giữa các đối tượng và mô-đun trò chơi.

Về cơ bản, tất cả các diễn viên trò chơi sống nên giao tiếp với các mô-đun chính (Vật lý, AI, Logic trò chơi, Chế độ xem trò chơi, v.v.) thông qua hệ thống nhắn tin sự kiện nội bộ. Điều này có nghĩa là phải thiết kế một người quản lý sự kiện hiệu quả. Một hệ thống được thiết kế tồi sẽ ăn chu kỳ CPU, đặc biệt ảnh hưởng đến nền tảng di động.

Đây có phải là một cách tiếp cận đã được chứng minh và đề nghị? Làm thế nào tôi nên quyết định có nên sử dụng nó?

Đây là một bản mở rộng nhận xét của tôi để trả lời đầy đủ, như được đề xuất.

Vâng , đơn giản và đơn giản. Giao tiếp cần phải xảy ra và trong khi có những tình huống 'Chúng ta đã ở đó chưa?' bỏ phiếu -type là bắt buộc, có những thứ kiểm tra xem liệu họ có nên làm việc gì khác thường làm lãng phí thời gian không. Thay vào đó, bạn có thể khiến họ phản ứng với những việc họ được bảo phải làm. Thêm vào đó, một lộ trình giao tiếp được xác định rõ giữa các đối tượng / hệ thống / mô-đun giúp tăng đáng kể các thiết lập song song.

Tôi đã cung cấp tổng quan cấp cao về hệ thống nhắn tin sự kiện trên Stack Overflow . Tôi đã sử dụng nó từ trường học vào các tựa game chuyên nghiệp và bây giờ là các sản phẩm không chơi game, phù hợp với trường hợp sử dụng mỗi lần tất nhiên.

EDIT : Để giải quyết một câu hỏi bình luận về cách bạn biết đối tượng nào sẽ nhận được thông báo : Bản thân các đối tượng cần Requestđược thông báo về các sự kiện. Của bạn EventMessagingSystem(EMS) sẽ cần một Register(int iEventId, IEventMessagingSystem * pOjbect, (EMSCallback)fpMethodToUseForACallback)cũng như phù hợp Unregister(làm cho một mục duy nhất cho một iEventIdra khỏi con trỏ đối tượng và gọi lại). Bằng cách này, khi một đối tượng muốn biết về một thông điệp có thể Register()với hệ thống. Khi nó không còn cần biết về các sự kiện, nó có thểUnregister(). Rõ ràng, bạn muốn có một nhóm các đối tượng đăng ký gọi lại này và một cách hiệu quả để thêm / xóa chúng khỏi danh sách. (Tôi thường sử dụng các mảng tự đặt hàng; một cách thú vị để nói rằng họ theo dõi phân bổ của riêng mình giữa một nhóm các đối tượng không sử dụng và các mảng thay đổi kích thước của chúng tại chỗ khi cần).

EDIT : Đối với một trò chơi hoàn toàn hoạt động với vòng lặp cập nhật và hệ thống nhắn tin sự kiện, bạn có thể muốn kiểm tra một dự án trường học cũ của tôi . Bài viết Stack Overflow được liên kết ở trên cũng đề cập đến nó.

Ý kiến ​​của tôi là bạn nên bắt đầu thực hiện trò chơi của mình và thực hiện những gì bạn thấy thoải mái. Khi bạn làm điều đó, bạn sẽ thấy mình sử dụng MVC ở một số nơi, nhưng không phải ở những nơi khác; sự kiện một số nơi, nhưng không phải những nơi khác; thành phần một số nơi, nhưng thừa kế những người khác; thiết kế sạch sẽ một số nơi, và thiết kế tồi tàn khác.

Và điều đó không sao, bởi vì khi bạn hoàn thành, bạn thực sự sẽ có một trò chơi, và một trò chơi tuyệt vời hơn một hệ thống truyền tin nhắn.

Một câu hỏi tốt hơn là, có những lựa chọn thay thế nào? Trong một hệ thống phức tạp như vậy với các mô-đun được phân chia hợp lý cho vật lý, AI, v.v., làm thế nào khác bạn có thể bố trí các hệ thống này?

Truyền tin nhắn dường như là giải pháp "tốt nhất" cho vấn đề này. Tôi không thể nghĩ ra các lựa chọn thay thế ngay bây giờ. Nhưng có rất nhiều ví dụ về thông điệp truyền qua trong thực tế. Trong thực tế, các hệ điều hành sử dụng thông điệp truyền cho một số chức năng của chúng. Từ Wikipedia :

Thông điệp cũng thường được sử dụng theo nghĩa tương tự như một phương tiện giao tiếp giữa các quá trình; kỹ thuật phổ biến khác là luồng hoặc đường ống, trong đó dữ liệu được gửi dưới dạng một chuỗi các mục dữ liệu cơ bản thay thế (phiên bản cấp cao hơn của mạch ảo).

(Giao tiếp giữa các quá trình là giao tiếp giữa các quy trình (tức là chạy các chương trình) trong môi trường hệ điều hành)

Vì vậy, nếu nó đủ tốt cho một hệ điều hành, nó có thể đủ tốt cho một trò chơi, phải không? Cũng có những lợi ích khác, nhưng tôi sẽ để bài viết Wikipedia về tin nhắn đi qua giải thích.

Tôi cũng đã hỏi một câu hỏi về Stack Overflow, "Cấu trúc dữ liệu cho thông điệp truyền trong một chương trình?" , mà bạn có thể muốn đọc qua.

Tin nhắn thường hoạt động tốt khi:

1. Điều gửi tin nhắn không quan tâm nếu nó nhận được.
2. Người gửi không cần nhận được phản hồi ngay lập tức từ người nhận.
3. Có thể có nhiều người nhận lắng nghe một người gửi.
4. Tin nhắn sẽ được gửi không thường xuyên hoặc không thể đoán trước. (Nói cách khác, nếu mọi đối tượng cần nhận thông báo "cập nhật" từng khung hình, tin nhắn sẽ không thực sự mua cho bạn nhiều.)

Nhu cầu của bạn càng phù hợp với danh sách đó, thông điệp phù hợp sẽ càng tốt. Ở cấp độ rất chung, chúng khá tốt. Họ làm tốt công việc không lãng phí chu kỳ CPU chỉ để không làm gì khác với bỏ phiếu hoặc các giải pháp toàn cầu khác. Chúng rất tuyệt vời trong việc tách các phần của một cơ sở mã, điều này luôn hữu ích.

Câu trả lời tuyệt vời cho đến nay từ James và Ricket, tôi chỉ trả lời để thêm một lưu ý thận trọng. Truyền thông / truyền thông hướng sự kiện chắc chắn là một công cụ quan trọng trong kho vũ khí của nhà phát triển, nhưng nó có thể dễ dàng bị lạm dụng. Khi bạn có một cái búa, mọi thứ trông giống như một cái đinh, vân vân.

Bạn hoàn toàn, 100%, nên suy nghĩ về luồng dữ liệu xung quanh tiêu đề của bạn và nhận thức đầy đủ về cách thông tin được truyền từ hệ thống con này sang hệ thống con khác. Trong một số trường hợp, tin nhắn đi qua rõ ràng là tốt nhất; ở những người khác, có thể thích hợp hơn cho một hệ thống con hoạt động trên một danh sách các đối tượng được chia sẻ, cho phép các hệ thống con khác cũng hoạt động trên cùng một danh sách được chia sẻ; và nhiều phương pháp khác bên cạnh.

Tại mọi thời điểm, bạn nên biết hệ thống con nào cần truy cập vào dữ liệu nào và khi nào chúng cần truy cập vào dữ liệu đó. Điều này ảnh hưởng đến khả năng song song và tối ưu hóa của bạn, cũng như giúp bạn tránh được các vấn đề quỷ quyệt hơn khi các bộ phận khác nhau trong động cơ của bạn trở nên quá chặt chẽ. Bạn cần suy nghĩ về việc giảm thiểu việc sao chép dữ liệu không cần thiết xung quanh dữ liệu và cách bố trí dữ liệu của bạn ảnh hưởng đến việc sử dụng bộ đệm của bạn. Tất cả sẽ hướng dẫn bạn giải pháp tốt nhất trong từng trường hợp.

Điều đó đang được nói, gần như mọi trò chơi tôi từng làm việc đều có một hệ thống thông báo sự kiện / thông báo không đồng bộ vững chắc. Nó cho phép bạn viết mã ngắn gọn, hiệu quả có thể bảo trì, ngay cả khi đối mặt với nhu cầu thiết kế phức tạp và nhanh chóng thay đổi.

Chà, tôi biết rằng bài đăng này khá cũ, nhưng tôi không thể cưỡng lại.

Gần đây tôi đã xây dựng một công cụ trò chơi. Nó sử dụng các thư viện bên 3d để kết xuất và vật lý, nhưng tôi đã viết phần cốt lõi, định nghĩa và xử lý các thực thể và logic trò chơi.

Động cơ chắc chắn theo một cách tiếp cận truyền thống. Có một vòng cập nhật chính gọi chức năng cập nhật cho tất cả các thực thể. Va chạm được báo cáo trực tiếp bằng cách gọi lại trên các thực thể. Giao tiếp giữa các thực thể được thực hiện bằng cách sử dụng con trỏ thông minh trao đổi giữa các thực thể.

Có một hệ thống tin nhắn nguyên thủy, Điều đó chỉ xử lý một nhóm nhỏ thực thể cho các thông điệp động cơ. Những thông báo đó được ưu tiên xử lý khi kết thúc tương tác trò chơi (ví dụ là tạo hoặc hủy thực thể) vì chúng có thể gây rối với danh sách cập nhật. Vì vậy, vào cuối mỗi vòng lặp trò chơi, một danh sách nhỏ các tin nhắn được tiêu thụ.

Mặc dù hệ thống thông điệp nguyên thủy, tôi sẽ nói rằng hệ thống này chủ yếu là "cập nhật dựa trên vòng lặp".

Tốt. Sau khi sử dụng hệ thống này, tôi nghĩ rằng nó rất đơn giản, nhanh chóng và được tổ chức tốt. Logic trò chơi có thể nhìn thấy và khép kín bên trong các thực thể, không năng động như một thông điệp. Tôi thực sự sẽ không làm cho nó bị điều khiển bởi vì theo ý kiến ​​của tôi, các hệ thống sự kiện đưa ra sự phức tạp không cần thiết cho logic trò chơi và làm cho mã trò chơi trở nên rất khó hiểu và gỡ lỗi.

Nhưng, tôi cũng nghĩ rằng một hệ thống "cập nhật dựa trên vòng lặp" thuần túy như của tôi cũng có một số vấn đề.

Ví dụ: Trong một số thời điểm, một thực thể có thể ở trạng thái "không làm gì cả", có thể đang chờ người chơi tiếp cận hoặc một cái gì đó khác. Trong hầu hết các trường hợp đó, thực thể đốt cháy thời gian của bộ xử lý mà không có gì và tốt hơn là tắt thực thể đó và bật nó khi một sự kiện nào đó xảy ra.

Vì vậy, trong công cụ trò chơi tiếp theo của tôi, tôi sẽ áp dụng một cách tiếp cận khác. Các thực thể sẽ tự đăng ký cho các hoạt động của động cơ, như cập nhật, vẽ, phát hiện va chạm và như vậy. Mỗi sự kiện này sẽ có danh sách các giao diện thực thể riêng biệt cho các thực thể thực tế.

Đúng. Đó là một cách rất hiệu quả để các hệ thống trò chơi giao tiếp với nhau. Các sự kiện giúp bạn tách rời nhiều hệ thống và thậm chí có thể biên dịch mọi thứ một cách riêng biệt mà không cần biết đến sự tồn tại của nhau. Điều này có nghĩa là các lớp của bạn có thể được tạo mẫu dễ dàng hơn và thời gian biên dịch nhanh hơn. Quan trọng hơn, bạn kết thúc với một thiết kế mã phẳng thay vì một mớ hỗn độn phụ thuộc.

Một lợi ích lớn khác của các sự kiện là chúng dễ dàng được truyền phát qua mạng hoặc kênh văn bản khác. Bạn có thể ghi lại chúng để phát lại sau. Các khả năng là vô tận.

Một lợi ích khác: Bạn có thể có một số hệ thống con lắng nghe cho cùng một sự kiện. Ví dụ: tất cả các chế độ xem từ xa (người chơi) của bạn có thể tự động đăng ký vào sự kiện tạo thực thể và sinh ra các thực thể trên mỗi máy khách với rất ít công việc từ phía bạn. Hãy tưởng tượng bạn sẽ làm việc nhiều hơn thế nào nếu bạn không sử dụng các sự kiện: bạn sẽ phải thực hiện Update()các cuộc gọi ở đâu đó hoặc có thể gọi view->CreateEntitytừ logic Trò chơi (nơi kiến ​​thức về chế độ xem và thông tin mà nó yêu cầu không thuộc về). Thật khó để giải quyết vấn đề đó mà không có sự kiện.

Với các sự kiện, bạn có được một giải pháp thanh lịch và tách rời, hỗ trợ vô số đối tượng các loại không giới hạn, tất cả chỉ có thể đăng ký vào các sự kiện và thực hiện công việc của chúng khi có điều gì đó xảy ra trong trò chơi của bạn. Đó là lý do tại sao các sự kiện là tuyệt vời.

Thêm chi tiết và thực hiện ở đây .

Từ những gì tôi đã thấy, dường như không phổ biến lắm khi có một công cụ hoàn toàn dựa trên tin nhắn. Tất nhiên, có những hệ thống con cho vay rất tốt cho một hệ thống nhắn tin như mạng, GUI và có thể cả những hệ thống khác. Nói chung, có một vài vấn đề tôi có thể nghĩ đến:

• Công cụ trò chơi đối phó với số lượng lớn dữ liệu.
• Các trò chơi phải nhanh (20-30 FPS nên là tối thiểu).
• Thường thì cần phải biết nếu một cái gì đó đã được thực hiện hoặc khi nào nó sẽ được thực hiện.

Với cách tiếp cận phổ biến của nhà phát triển trò chơi "nó phải hiệu quả nhất có thể", hệ thống nhắn tin như vậy không phải là phổ biến.

Tuy nhiên, tôi đồng ý rằng bạn chỉ nên tiếp tục và thử nó. Chắc chắn có rất nhiều lợi thế với một hệ thống như vậy và sức mạnh tính toán có sẵn ngày nay.