Các cuộc gọi chức năng theo từng khung so với nhắn tin hướng sự kiện trong thiết kế trò chơi

Các thiết kế trò chơi truyền thống , như tôi biết điều đó, sử dụng đa hình và chức năng ảo để cập nhật trò chơi đối tượng tiểu bang. Nói cách khác, cùng một tập hợp các hàm ảo được gọi theo các khoảng thông thường (ví dụ: mỗi khung hình) trên mọi đối tượng trong trò chơi.

Gần đây, tôi phát hiện ra rằng có một hệ thống nhắn tin hướng sự kiện khác có sẵn để cập nhật trạng thái của các đối tượng trò chơi. Ở đây, các đối tượng thường không được cập nhật trên cơ sở mỗi khung hình. Thay vào đó, một hệ thống nhắn tin sự kiện hiệu quả cao được xây dựng và các đối tượng trò chơi chỉ được cập nhật sau khi nhận được thông báo sự kiện hợp lệ.

Kiến trúc trò chơi hướng sự kiện được mô tả tốt trong: Hoàn thành mã hóa trò chơi của Mike McShaffry .

Tôi có thể vui lòng yêu cầu giúp đỡ với các câu hỏi sau đây:

• Những lợi thế và bất lợi của cả hai phương pháp là gì?
• Đâu là cái tốt hơn cái kia?
• Là thiết kế trò chơi hướng sự kiện phổ quát và tốt hơn trong tất cả các lĩnh vực? Do đó, nó có được khuyến khích sử dụng ngay cả trong các nền tảng mombile không?
• Cái nào hiệu quả hơn và cái nào khó phát triển hơn?

Để làm rõ, câu hỏi của tôi không phải là loại bỏ hoàn toàn đa hình khỏi thiết kế trò chơi. Tôi chỉ đơn giản muốn hiểu sự khác biệt và lợi ích từ việc sử dụng tin nhắn hướng sự kiện so với các cuộc gọi thông thường (theo khung) đến các chức năng ảo để cập nhật trạng thái trò chơi.

Ví dụ: Câu hỏi này gây ra một chút tranh cãi ở đây, vì vậy hãy để tôi cung cấp cho bạn ví dụ: Theo MVC, công cụ trò chơi được chia thành ba phần chính:

1. Lớp ứng dụng (Giao tiếp phần cứng và hệ điều hành)
2. Logic trò chơi
3. Chế độ xem trò chơi

Trong một trò chơi đua xe, Game View chịu trách nhiệm hiển thị màn hình nhanh nhất có thể, ít nhất là 30 khung hình / giây. Chế độ xem trò chơi cũng lắng nghe ý kiến ​​của người chơi. Bây giờ điều này xảy ra:

• Người chơi nhấn bàn đạp nhiên liệu đến 80%
• GameView xây dựng một thông báo "Bàn đạp nhiên liệu trên xe hơi được nhấn tới 80%" và gửi nó đến Game Logic.
• Game Logic nhận được thông báo, đánh giá, tính toán vị trí và hành vi của xe mới và tạo các thông báo sau cho GameView: "Draw Car 2 Fuel Đạp ép 80%", "Tăng tốc âm thanh trên xe 2", "Xe 2 tọa độ X, Y" .. .
• GameView nhận được tin nhắn và xử lý chúng phù hợp

Tôi là một người hoàn toàn tin tưởng vào sự cần thiết phải là mẹ của sáng chế. Tôi không thích mã hóa bất cứ điều gì trừ khi nhu cầu của nó rõ ràng và được xác định rõ. Tôi nghĩ rằng nếu bạn bắt đầu dự án của mình bằng cách thiết lập một hệ thống nhắn tin sự kiện, bạn đã làm sai. Tôi tin rằng chỉ khi bạn đã tạo và kiểm tra cơ sở hạ tầng của mình và có tất cả các phần trong dự án của bạn, các mô-đun làm việc được xác định rõ, bạn nên tập trung vào cách bạn sẽ kết nối các mô-đun này với nhau. Cố gắng thiết kế một hệ thống nhắn tin sự kiện trước khi bạn hiểu hình dạng và nhu cầu của từng mô-đun là không đúng.

Những lợi thế và bất lợi của cả hai phương pháp là gì?

Tôi nghĩ rằng một số người sẽ tranh luận rằng có những hệ thống nhắn tin tốt ngoài kia đã sẵn sàng để được cài đặt và sử dụng. Có lẽ điều này là đúng. Chắc chắn hiệu suất của một giải pháp xây dựng tùy chỉnh được thiết kế riêng cho nhu cầu của bạn sẽ lớn hơn một xe buýt tin nhắn đa năng. Câu hỏi lớn là - bạn sẽ dành bao nhiêu thời gian để xây dựng một hệ thống nhắn tin thay vì sử dụng một cái gì đó đã được xây dựng. Rõ ràng, nếu bạn có thể tìm thấy một số loại hệ thống sự kiện với chính xác bộ tính năng bạn cần, thì đó là một quyết định khá dễ dàng. Đây là lý do tại sao tôi đảm bảo rằng tôi hiểu chính xác những gì tôi cần trước khi tôi đưa ra quyết định đó.

Đâu là cái tốt hơn cái kia?

Chúng ta có thể nói về bộ nhớ và tài nguyên ở đây. Nếu bạn đang phát triển cho bất kỳ phần cứng nào có tài nguyên hạn chế, chắc chắn việc sử dụng một hệ thống sự kiện sẽ bị cắt giảm đáng kể. Thực sự, mặc dù, tôi nghĩ rằng vấn đề liên quan đến những gì bạn cần, như tôi đã đề cập là một cái gì đó mà bạn không biết cho đến khi bạn thấy tất cả các mảnh trông như thế nào. Nếu bạn có đủ kinh nghiệm xây dựng các hệ thống này mà bạn biết trước chính xác tất cả các phần sẽ trông như thế nào, thì bạn cũng có thể trả lời trước câu hỏi này. Tôi đoán bạn không có kinh nghiệm này, vì bạn sẽ không hỏi câu hỏi này nếu bạn đã làm.

Là thiết kế trò chơi hướng sự kiện phổ quát và tốt hơn trong tất cả các lĩnh vực? Do đó, nó có được khuyến khích sử dụng ngay cả trong các nền tảng di động không?

Phổ cập và tốt hơn trong tất cả các lĩnh vực? Một tuyên bố chăn đẹp như thế dễ dàng bị từ chối. Bất cứ điều gì thêm chi phí cần phải được thực hiện phần của khối lượng công việc. Nếu bạn không sử dụng các sự kiện đủ để đảm bảo chi phí thiết kế thì đó là thiết kế sai.

Cái nào hiệu quả hơn và cái nào khó phát triển hơn?

Hiệu quả phụ thuộc vào cách thức thực hiện của nó. Tôi nghĩ rằng một thiết kế truyền thống được phát triển tốt sẽ thực hiện tốt hơn một hệ thống dựa trên sự kiện vào bất kỳ ngày nào trong tuần. Điều này là do giao tiếp giữa các phần có thể được quản lý vi mô và được thực hiện siêu hiệu quả. Tất nhiên, điều này cũng khiến việc thiết kế từ quan điểm kinh nghiệm và thời gian cần thiết để hoàn thành nó trở nên khó khăn hơn và làm cho nó hiệu quả hơn. Mặt khác, nếu bạn thiếu kinh nghiệm này hoặc không có thời gian để phát triển ứng dụng tốt, thì sử dụng thiết kế dựa trên sự kiện phù hợp với nhu cầu của bạn sẽ hiệu quả hơn. Nếu bạn có nhu cầu sự kiện tùy chỉnh không dễ dàng phù hợp với cấu trúc dựa trên sự kiện, điều này có thể làm cho cấu trúc dựa trên sự kiện rất khó thiết kế - đặc biệt là để giữ cho thiết kế hiệu quả.

Tôi nghĩ rằng bạn đang so sánh táo và cam ở đây. Đa hình không được thay thế bằng tin nhắn cả. Bạn có thể muốn các sự kiện / nhắn tin kết nối các thành phần được ghép lỏng lẻo. Ví dụ. để gửi tin nhắn từ một thực thể khi xảy ra va chạm, để cập nhật điểm người chơi hoặc có thể để kích hoạt hiệu ứng âm thanh. Vì vậy, các lớp riêng lẻ này không biết các lớp khác và chỉ gửi và / hoặc xử lý tin nhắn.

Nhưng trò chơi của bạn rất có thể sẽ có một vòng cập nhật ở đâu đó và vì bạn có vòng cập nhật đó, nên nó có thể dễ dàng được sử dụng để cập nhật tất cả các thực thể trò chơi cũng cần được cập nhật mọi khung hình. Điều này không ngăn bạn sử dụng tin nhắn mặc dù ...

Nếu bạn có một số loại cấu trúc nơi bạn thêm / xóa thực thể trò chơi, bạn cũng có thể đưa chúng vào vòng cập nhật thay vì gửi thông báo cập nhật tới chúng theo từng khung. Vậy tại sao không gọi cập nhật trực tiếp trên các thực thể trò chơi của bạn trong khi bạn đang sử dụng tin nhắn để kết nối các hệ thống phụ khác nhau trong trò chơi của mình? Tôi cũng thích khái niệm Tín hiệu / Khe cắm ( xem ví dụ qt ) cho các hệ thống giống như sự kiện.

Điểm mấu chốt: Không có cách tiếp cận nào tốt hơn, cũng không phải là độc quyền.

Điều này bắt đầu như một bình luận cho câu trả lời của bummzack, nhưng đã lâu.

Trừ khi bạn thực sự làm cho nó không đồng bộ (gửi các sự kiện trên một luồng mới), các đối tượng của bạn vẫn nhận được bản ghi nhớ một cách đồng bộ. Giả sử bộ điều phối sự kiện của bạn sử dụng bảng băm cơ bản với danh sách được liên kết trong một ô, thứ tự sẽ là thứ tự các đối tượng được quảng cáo đến ô đó.

Hơn nữa, trừ khi bạn quyết định sử dụng các con trỏ hàm vì một số lý do, bạn vẫn đang sử dụng các lệnh gọi hàm ảo vì mỗi đối tượng nhận được thông báo phải triển khai IEventListener (hoặc bất cứ điều gì bạn gọi nó). Sự kiện là một sự trừu tượng hóa ở mức độ cao mà bạn xây dựng bằng cách sử dụng đa hình.

Sử dụng các sự kiện mà bạn thấy mình phải gọi một danh sách các phương pháp giặt ủi cho các sự kiện khác nhau trong trò chơi để đồng bộ hóa các hệ thống khác nhau trong trò chơi hoặc khi các phản ứng khác nhau của các đối tượng và hệ thống không thể xác định rõ ràng các sự kiện xảy ra hoặc bạn muốn để thêm nhiều phản ứng cho những diễn biến đã nói trong tương lai.

Chúng là một công cụ tuyệt vời, nhưng như bummzack đã nói, đừng cho rằng tính đa hình và các sự kiện giải quyết cùng một vấn đề.

Tôi sẽ nói rằng chọn cái này hay cái kia là khá sai. Một số đối tượng cần gọi mọi khung hình - một số thì không. Nếu bạn có một đối tượng bạn muốn kết xuất, bạn cần thực hiện một cuộc gọi kết xuất tới nó mỗi khung hình. Sự kiện không thể thay đổi. Điều này cũng đúng với mọi đối tượng vật lý dựa trên thời gian - bạn phải gọi chúng là mọi khung.

Tuy nhiên, tôi không thực hiện cuộc gọi mỗi khung hình tới các đối tượng quản lý đối tượng hoặc đối tượng nhập người dùng của tôi hoặc bất cứ điều gì tương tự. Cuộc gọi ảo hàng loạt đến mọi đối tượng trên khung là một ý tưởng khủng khiếp.

Thiết kế được sử dụng cho bất kỳ đối tượng cụ thể nào phải dựa trên nhu cầu của các đối tượng đó và không dựa trên một số ý thức hệ cho toàn bộ hệ thống.

Chỉnh sửa để rõ ràng hơn trong câu đầu tiên của tôi.