Tôi đoán tôi đã quyết định rằng tôi thực sự thích xử lý sự kiện. Tôi có thể bị một chút do tê liệt phân tích, nhưng tôi lo lắng về việc làm cho thiết kế của tôi khó sử dụng hoặc gặp phải một số hậu quả không lường trước khác đối với các quyết định thiết kế của tôi.

Công cụ trò chơi của tôi hiện đang thực hiện kết xuất dựa trên sprite cơ bản với một camera trên cao. Thiết kế của tôi trông hơi giống thế này:

CảnhHandler

Chứa danh sách các lớp thực hiện giao diện SceneListener (hiện chỉ có Sprites). Gọi render () một lần mỗi lần đánh dấu và gửi onCameraUpdate (); tin nhắn đến SceneListener.

Bộ xử lý đầu vào

Thăm dò đầu vào một lần mỗi lần đánh dấu và gửi một thông báo "onKeyPression" đơn giản đến InputListener. Tôi có Camera InputListener chứa phiên bản SceneHandler và kích hoạt updateCamera (); các sự kiện dựa trên những gì đầu vào là.

Đặc vụ

Gọi các hành động mặc định trên bất kỳ Đại lý (AI) một lần mỗi lần đánh dấu và sẽ kiểm tra một ngăn xếp cho bất kỳ sự kiện mới nào đã được đăng ký, gửi chúng đến các Đại lý cụ thể khi cần.

Vì vậy, tôi có các đối tượng sprite cơ bản có thể di chuyển xung quanh một cảnh và sử dụng các hành vi lái thô sơ để đi du lịch. Tôi đã nhận được phát hiện va chạm, và đây là nơi tôi không chắc hướng thiết kế của mình sẽ tốt. Đó có phải là một thực hành tốt để có nhiều, xử lý sự kiện nhỏ? Tôi tưởng tượng theo cách mà tôi phải thực hiện một số loại CollisionHandler.

Tôi có thể tốt hơn với một EntityHandler hợp nhất xử lý AI, cập nhật va chạm và các tương tác thực thể khác trong một lớp không? Hoặc tôi sẽ ổn khi chỉ thực hiện nhiều hệ thống con xử lý sự kiện khác nhau truyền thông điệp cho nhau dựa trên loại sự kiện đó là gì? Tôi có nên viết EntityHandler chịu trách nhiệm phối hợp tất cả các trình xử lý sự kiện phụ này không?

Tôi nhận ra trong một số trường hợp, chẳng hạn như InputHandler và SceneHandler của tôi, đó là những loại sự kiện rất cụ thể. Một phần lớn mã trò chơi của tôi sẽ không quan tâm đến đầu vào và một phần lớn sẽ không quan tâm đến các cập nhật diễn ra hoàn toàn trong kết xuất cảnh. Vì vậy, tôi cảm thấy sự cô lập của tôi đối với các hệ thống đó là hợp lý. Tuy nhiên, tôi đang hỏi câu hỏi này cụ thể tiếp cận các sự kiện loại logic trò chơi.

Thiết kế dựa trên sự kiện chủ yếu liên quan đến việc thực hiện mẫu thiết kế Lò phản ứng .

Trước khi bắt đầu thiết kế các thành phần, bạn nên xem xét các hạn chế của mẫu đó (bạn có thể tìm thấy nhiều thông tin về điều này).

Vấn đề đầu tiên và quan trọng nhất là các trình xử lý phải quay trở lại nhanh chóng , vì mọi người đã làm một số serius làm việc trên các khung dựa trên GUI và các ứng dụng dựa trên javascript đều biết rõ.

Khi bạn phát triển mọi ứng dụng với độ phức tạp khá cao , sớm hay muộn, bạn sẽ phải đối mặt với một số trình xử lý thực hiện một công việc phức tạp đòi hỏi thời gian .

Trong những trường hợp này, bạn có thể phân biệt hai tình huống (không nhất thiết phải loại trừ lẫn nhau):

Các trách nhiệm liên quan đến sự kiện phức tạp và các trách nhiệm phức tạp không liên quan đến sự kiện .

Các trách nhiệm liên quan đến sự kiện phức tạp:

Trong trường hợp đầu tiên, bạn đã hợp nhất quá nhiều trách nhiệm vào một trình xử lý thành phần duy nhất : có quá nhiều hành động được thực hiện để đáp ứng với một sự kiện hoặc đang chạy đồng bộ hóa chẳng hạn.

Trong trường hợp này, giải pháp là chia bộ xử lý thành các bộ xử lý khác nhau (trong các đối tượng khác nhau nếu cần thiết) và để một tay cầm để bắn các sự kiện thay vì gọi trực tiếp mã xử lý. Điều này sẽ cho phép bạn cho phép quản lý một sự kiện ưu tiên cao hơn trước khi trình xử lý chính của bạn đã trở lại sau khi thêm các sự kiện vào hàng đợi sự kiện.

Một giải pháp khác là để cho một thực thể bên ngoài thực hiện các sự kiện và cho phép những người khác đăng ký nếu quan tâm (sự kiện thời gian là ví dụ tầm thường nhất mà bạn có thể khái quát).

Các trách nhiệm phức tạp không liên quan đến sự kiện:

Trường hợp thứ hai xảy ra khi có một sự phức tạp nội tại trong hành động cần thực hiện sau một sự kiện: bạn phải tính toán một số lượng của Wikipedia sau một sự kiện chẳng hạn.

Ở đây, mô hình Lò phản ứng về cơ bản thất bại , rất ít để chia thuật toán tạo thế hệ thành các phần nhỏ tạo ra các sự kiện khi chấm dứt để kích hoạt bước tiếp theo.

Ở đây, giải pháp là trộn một thiết kế có ren với lò phản ứng , tin tốt là nếu sự phức tạp là nội tại (vì vậy bạn đang đọc đúng phần) thì rất có khả năng có thể bắt đầu và luồng độc lập thực hiện công việc và cần biết ít hoặc không biết gì về phần còn lại của các thành phần liên quan đến Lò phản ứng.

Để xử lý loại tình huống này, tôi thấy hữu ích khi áp dụng một hàng đợi công việc trên một nhóm luồng linh hoạt .

Khi một người xử lý cần bắt đầu một hành động dài, nó sẽ gói hành động đó vào một đơn vị công việc để được đưa vào hàng đợi công việc. Hành động được đóng gói này cần phải có một phương tiện để kích hoạt các sự kiện vào luồng của lò phản ứng. Trình quản lý hàng đợi công việc có thể chạy vào luồng của chính nó hoặc trong luồng của lò phản ứng và phản ứng với sự kiện "newJob".

Người quản lý hàng đợi công việc thực hiện như sau:

• nó phân bổ một đơn vị công việc cho một luồng từ nhóm luồng linh hoạt bằng thuật toán shedule của nó nếu nhóm đó có thể cung cấp một luồng (có một luồng tự do hoặc cho phép tạo luồng mới)

• lắng nghe nhóm chính để xem nếu một đơn vị công việc kết thúc để một chuỗi có thể được phục hồi để thực thi thêm một đơn vị đang chờ xử lý, nếu có.

Sử dụng cơ chế bắn sự kiện, một đơn vị công việc có thể kích hoạt các sự kiện để thông báo về việc hoàn thành, trạng thái cập nhật, cảnh báo, lỗi hoặc bất cứ khi nào cần thiết. Nhóm luồng linh hoạt đảm bảo sử dụng tốt các tài nguyên trong khi tránh luồng chết để treo toàn bộ hệ thống; hàng đợi công việc cho phép bạn chọn loại ưu tiên nào được gán cho các loại hành động khác nhau vì bạn biết rằng chúng sẽ yêu cầu một lượng tài nguyên tính toán nhất quán.

Trong hầu hết các tình huống sử dụng các sự kiện trên các tùy chọn khác thường có thể cải thiện tốc độ và phân cấp. Tôi nghĩ rằng nếu bạn có thể sử dụng nhiều sự kiện bạn nên đi cho nó.