Cách tiếp cận hướng đối tượng chính xác để thiết kế lớp trong phát triển trò chơi là gì?

Tôi đang trong quá trình phát triển một trò chơi dựa trên sprite 2D cho Windows 7 Phone, sử dụng XNA. Việc đào tạo và hướng dẫn có sẵn cho nó khá hữu ích, nhưng vấn đề tôi gặp phải là mỗi người trong số họ tiếp cận thiết kế lớp học của họ khác nhau và mã không được đặc biệt chú ý. Kết quả là, tôi rất khó có được sự hiểu biết tốt về trách nhiệm nào tôi nên giao cho một lớp cụ thể.

Ví dụ, tôi có thể có một lớp sprite cơ sở BaseSpritebiết cách tự vẽ, kiểm tra va chạm, v.v. Sau đó tôi có thể có một AnimatedSpritelớp sẽ biết cách điều hướng bảng sprite của nó, một ExplodingSpritelớp, v.v. Kỹ thuật này được thể hiện trong ví dụ về Kẻ xâm lược không gian trong tài liệu Phiên bản khởi động 2 của Windows 7 Phone .

Ngoài ra, thay vào đó, tôi có thể đặt phần lớn kết xuất và chạy trách nhiệm trò chơi trong một GameScreenlớp; lớp đó và các lớp dẫn xuất của nó hoạt động giống như các biểu mẫu hoặc trang web về trách nhiệm của chúng. Các lớp Sprite là các thùng chứa đơn giản hơn với logic ít hơn nhiều.

Đây là kỹ thuật được sử dụng trong trò chơi Alien Sprite của Windows 7 Phone Kit và các ví dụ về trình quản lý trạng thái trò chơi khác.

Cách tiếp cận hướng đối tượng chính xác để thiết kế lớp trong phát triển trò chơi là gì?

Tôi sử dụng một cách tiếp cận hướng thành phần hơn, trong đó bạn sẽ có một lớp Sprite có các thành phần như Visual, Collision, Animation, Input, v.v. Với cách tiếp cận này, tôi không có hệ thống phân cấp lớp sâu (tốt) .

Đối với một số thông tin về Thiết kế định hướng thành phần xem tại đây .

Trong các trò chơi, mẫu Thành phần là một giải pháp phổ biến.

Các nguyên tắc RẮN áp dụng càng nhiều để thiết kế mã trò chơi như với bất kỳ ngành nghề khác - ít nhất là cho đến khi bạn đến tối ưu hóa, vì vậy tôi muốn sử dụng ví dụ đầu tiên của bạn như là một điểm khởi đầu.

Tôi sẽ đi xa hơn, bởi vì BaseSprite nghe có vẻ như có xu hướng trở thành một megaclass. Nguyên tắc trách nhiệm duy nhất cho rằng tất cả các xung đột, kết xuất và điều hướng phải được xử lý bởi các thành phần, thay vì các mục riêng lẻ trong hệ thống phân cấp lớp. Lớp giữ của tất cả các thành phần này chỉ nên xử lý các vị trí thế giới giữa chúng.

Đối với một vài dự án gần đây, tôi đã nghiêng nhiều hơn về cách tiếp cận theo phong cách MVC.

Lúc đầu, chúng tôi không chắc chắn nếu điều này sẽ làm việc, nhưng nó hoạt động hoàn hảo.

Mô hình

Các đối tượng dữ liệu. Chỉ là dữ liệu thuần túy. Không có hành vi, không kết xuất.

Quản lý dữ liệu. Chỉ cần xử lý "danh sách" các đối tượng dữ liệu. (Cũng có thể được tăng cường để hỗ trợ gộp.)

Lượt xem

Chúng tôi gọi chúng là renderer. Đối với mỗi loại đối tượng dữ liệu có một trình kết xuất. Khi được gọi với người quản lý, nó sẽ hiển thị tất cả các đối tượng trong danh sách đó.

Bộ điều khiển

Tương tự như trình kết xuất, nhưng kiểm soát hành vi.

Thí dụ

ShipManager có một danh sách các tàu. ShipContoder sẽ di chuyển Tàu theo trạng thái của họ. ShipRenderer sẽ kết xuất Tàu theo trạng thái của họ.

Tại sao

Bằng cách này, quan điểm và logic được tách biệt nghiêm ngặt. Nó làm cho việc chuyển sang một nền tảng mới khá dễ dàng. Tối ưu hóa bố cục dữ liệu bên trong XxxManager cũng rất dễ dàng.