Tôi, và làm thế nào, tách biệt mối quan tâm của các đối tượng đầu vào và trò chơi?

20

Có lẽ trong mọi trò chơi, nhà phát triển phải bằng cách nào đó xử lý đầu vào, có thể đó là các sự kiện bàn phím và chuột đơn giản, các sự kiện chạm hoặc một cái gì đó như đầu vào gia tốc. Đầu vào này trực tiếp của các đối tượng ảnh hưởng gián tiếp trong trò chơi. Đôi khi cùng một đầu vào có thể ảnh hưởng đến các đối tượng khác nhau. Bây giờ tôi đã suy nghĩ về cách mô hình hóa này. Cách tôi nhìn thấy nó có hai cách tiếp cận khác nhau.

Hãy để đối tượng trò chơi tự xử lý nó, đăng ký các sự kiện và gọi phương thức riêng của nó. Điều này có lợi thế là để cho các đối tượng trò chơi tự quyết định đầu vào nào gây ra hành động nào. Một nhược điểm dường như là mã đầu vào bị sai lệch với mã đối tượng trò chơi "cốt lõi". Ngoài ra, các đối tượng trò chơi không biết về trạng thái của phần còn lại của trò chơi và đôi khi có thể không hành động theo các sự kiện đầu vào. Điều này có vẻ không đúng.
Có một bộ điều khiển đầu vào chung đảm nhiệm tất cả các đầu vào và đưa ra quyết định về việc ai sẽ xử lý sự kiện nào. Điều này dường như tách biệt mối quan tâm tốt hơn, nhưng kết hợp chặt chẽ lớp trình điều khiển đầu vào với các đối tượng trò chơi. Nó bằng cách nào đó cần biết ai muốn nhận sự kiện nào và ở trạng thái nào. Điều này cũng không đúng.

Những chiến lược nào bạn đang sử dụng để xử lý việc này?

architecture input events

— Robert Massa
nguồn

7

Tôi khuyên bạn nên tách các sự kiện đầu vào khỏi các đối tượng trò chơi để bạn có thể nhanh chóng thay đổi / nâng cấp các phương thức nhập liệu mà không phải chỉnh sửa và gỡ lỗi 10 lớp đối tượng. Các ví dụ đang chuyển từ các điều khiển chỉ bằng bàn phím sang chuột + bàn phím hoặc chỉ đơn giản là gán lại các phím.

Thay vì kết hợp chặt chẽ đầu vào với các đối tượng trò chơi riêng lẻ, chỉ gọi một phương thức cho mỗi tín hiệu đầu vào duy nhất trên đối tượng trò chơi và để nó quyết định cách thực hiện nó.

Sử dụng bộ điều khiển đầu vào để theo dõi trạng thái đầu vào:

Up press event   -> dir = up
Down press event -> dir = down

Bất cứ khi nào trạng thái đầu vào thay đổi, hãy đánh giá xem các đối tượng trò chơi đã sẵn sàng để được sửa đổi chưa:

set dir  ->  if gamestate != paused && battlemode == false
             ->  character.changeDir(dir);

Thực hiện các phương thức chung trên các đối tượng trò chơi của bạn, có thể được gọi bởi bộ điều khiển đầu vào hoặc các đối tượng trò chơi khác, khi cần:

changeDir (dir)
setSpeed (walk/run)

— Edwardian
nguồn

7

Tôi khuyên bạn nên tiếp cận MVC. Trong MVC, các đối tượng trò chơi chỉ phải lo lắng về việc mô hình hóa hệ thống trò chơi và cung cấp giao diện cấp cao như move_left. Sau đó, có một đối tượng điều khiển lo lắng về ánh xạ đầu vào cho các cuộc gọi mô hình. Không chỉ cho phép thay đổi điều khiển dễ dàng, nó còn mang lại giao diện tốt cho AI, chúng chỉ là một bộ điều khiển khác.

Trong tùy chọn thứ hai của bạn, tôi sẽ chia bộ điều khiển đầu vào thành hai phần, một phần xử lý cảm ứng thực tế của thiết bị, bàn phím, accel, bất cứ thứ gì bạn có thể ném vào nó, để nó ánh xạ chúng thành một bộ đầu vào chung. Sau đó, có một phần thứ hai ánh xạ các đầu vào chung cho các đầu vào cụ thể của trò chơi. Nói bàn phím lên mũi tên ánh xạ tới input1, sau đó chạm vào phía trên màn hình cảm ứng cũng ánh xạ tới input1 và bây giờ bạn viết một đoạn thứ hai ánh xạ đầu vào 1 để nhảy. Giờ đây, bạn có thể ánh xạ bất kỳ thiết bị IO nào cũng như phát lại được lưu trữ hoặc đầu vào AI vào hệ thống đầu vào chung này và có một phần cụ thể trò chơi nhỏ để tải đầu vào1 có nghĩa là gì cho mô hình.

— ném đá
nguồn

5

Có rất nhiều cuộc thảo luận ở nơi khác trên trang web này về lý do tại sao MVC thường không phải là một mô hình thích hợp cho các trò chơi; những gì theo mô tả không phải là MVC, nó chỉ là trừu tượng; và "Sử dụng MVC" không phải là một câu trả lời, vì MVC là một mô tả của cả một lớp kiến trúc và không phải là một cách cụ thể để phân tách các mối quan tâm (cũng không phải là cách duy nhất để làm điều đó).

2

MVC nên cung cấp cho anh ấy A) một bài viết trên wikipedia để đọc B) một số biến thể về cách tiếp cận giải pháp đã được hiển thị để hoạt động C) Tôi đề cập đến cách tôi sẽ thiết lập nó trong đó mô hình hiển thị giao diện cấp cao mà bộ điều khiển ánh xạ đầu vào mức thấp (thực hoặc tổng hợp) thành hành động cấp cao và trực tiếp thao tác mô hình thay vì một số hệ thống sự kiện.

— ném đá vào

1

Tôi sẽ đề nghị làm cho trò chơi của bạn ( Mô hình ) xác định danh sách các sự kiện đầu vào có thể (được triển khai dưới dạng enum hoặc các đối tượng có giao diện cơ bản chung). Những thứ như MovingRightStarted, MovingRightStopped, FiredWeapon1, Escape, vv ...

Trò chơi xác định cấu trúc dữ liệu (ví dụ a queue) mà mã đầu vào của bạn ( Bộ điều khiển ) có thể điền vào các sự kiện đầu vào.

Sau đó, trò chơi của bạn có thể thăm dò cấu trúc dữ liệu để có được các sự kiện đầu vào.

Bằng cách này, bạn có thể cắm các loại bộ điều khiển khác nhau để cung cấp cho mô hình:

Chỉ bàn phím
Bàn phím + chuột
Cần điều khiển
Màn hình cảm ứng
Trí tuệ nhân tạo

Bạn chỉ cần có chúng để đẩy các sự kiện đầu vào cho mô hình.

— Splo
nguồn

Tôi nghĩ tôi hiểu ý của bạn, ngoại trừ việc bạn chọn một queuekiểu dữ liệu để lưu trữ cái này. Bạn có thể giải thích tại sao?

— Robert Massa

Giữa hai lần thăm dò sự kiện đầu vào từ mô hình, bộ điều khiển có thể đã đẩy một số sự kiện hành động và điều quan trọng là phải giữ trật tự đầu vào của người dùng. Đó là lý do tại sao tôi chọn cấu trúc dữ liệu FIFO. Trên thực tế, bạn cũng có thể cần xác định chính xác thời điểm đầu vào xảy ra.

— Splo