MVC giống như khoang trong trò chơi? [đóng cửa]

Tôi đang suy nghĩ về thiết kế của một trò chơi (cụ thể là dịch một boardgame sang máy tính, mà tôi cho là có liên quan trong trường hợp này) và tôi nhận ra rằng việc xây dựng 'trò chơi' tách biệt với 'màn hình' là điều hợp lý.

Nó sẽ cho phép tôi tạo nguyên mẫu một cái gì đó nhanh chóng với giao diện văn bản đơn giản, và sau đó sẽ cải tiến nó sau. Nó cũng sẽ cho phép tôi chuyển trò chơi sang phương tiện khác dễ dàng hơn.

Đây có phải là loại ngăn xếp phổ biến trong các trò chơi? Tôi có nên cố gắng phá vỡ mọi thứ hơn nữa? Có những biến chứng tôi có thể bị mất?

Trò chơi bảng là một ví dụ điển hình về trò chơi có thể được tạo bằng MVC, vì logic trò chơi (mô hình) tồn tại khá độc lập với hình ảnh (chế độ xem). Tuy nhiên, nếu bạn xem xét một trò chơi hành động như Gears of War, hình học của các mô hình 3D thực chất là logic của trò chơi, do đó, việc tách biệt chế độ xem như thể nó có thể hoán đổi cho nhau trở nên vô nghĩa. Unity3D là một ví dụ tuyệt vời về cách tổ chức mã cụ thể hơn cho trò chơi. Bạn có một lớp thực thể cơ sở mà bạn thêm chức năng với các thành phần, trong đó một thành phần có thể xử lý việc vẽ thực thể, một xử lý logic trò chơi, v.v. Hãy xem các bài đăng blog nổi tiếng này về chủ đề:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://gameprogrammingpotypes.com/component.html

Tôi đảm nhận nó:

• Các mô hình là nơi mà hầu hết những lời dối trá dữ liệu và tất cả các logic diễn ra.
  Nó đọc một hàng các sự kiện đầu vào và sửa đổi trạng thái trò chơi tương ứng.
  Sau đó, nó xử lý những thứ như vật lý và các thành phần cốt lõi khác cũng cập nhật trạng thái trò chơi.
  Vòng lặp. Đó là tất cả.
  Mục tiêu là làm cho mô hình trở nên độc lập: nó không có bất kỳ sự phụ thuộc nào vào chế độ xem hoặc công cụ điều khiển: bạn sẽ có thể tạo một chương trình chỉ chạy một mô hình.
• Khung nhìn chỉ đơn giản là đọc trạng thái trò chơi của mô hình, cập nhật các thành phần riêng dành cho việc thể hiện dữ liệu và hiển thị mọi thứ trên màn hình.
  Nó không bao giờ viết bất cứ điều gì trên mô hình, đó là một quá trình chỉ đọc, ngoại trừ có thể đăng ký một số trình xử lý sự kiện (như "Hey Mister Model, khi bạn phát hiện ra một vụ va chạm giữa hai đối tượng đó, vui lòng gọi trình xử lý sự kiện của tôi phát ra âm thanh! ").
• Bộ điều khiển bắt các sự kiện đầu vào và chuyển chúng đến hàng đợi đầu vào của mô hình. Nó đọc khung nhìn (nhấp vào nút này có xảy ra trên nút UI không?).

Bằng cách đó, bạn có thể cắm bộ điều khiển giả đọc tệp chứa các sự kiện đầu vào được ghi trước.
Cũng tạo một chế độ xem đơn giản chỉ ghi nhật ký mọi thứ trên một tệp.
Rất hữu ích để thử nghiệm và gỡ lỗi.

Hãy nhớ thực hiện cập nhật mô hình ở tốc độ không đổi (bước thời gian cố định) và chế độ xem và bộ điều khiển càng nhanh càng tốt (nhưng không quá nhiều biến).

Kiểu ngăn xếp đó là sự phân chia giữa Engine và gamecode, và khá phổ biến. Có rất nhiều chỗ cho sự trừu tượng trên đường đi.

Công cụ của bạn và dữ liệu đồ họa cụ thể trong trò chơi của bạn có thể giống như Chế độ xem, mã hóa mô hình của bạn và bộ điều khiển sẽ là bất kỳ loại keo nào bạn sử dụng để cho công cụ của bạn biết kết cấu nào sẽ áp dụng cho thực thể nào trong mã trò chơi của bạn.