Trò chơi: Ai chịu trách nhiệm hiển thị?

Question

Các thực thể có nên biết cách tự vẽ không? Tôi đã sử dụng cách tiếp cận này: nó đơn giản và nó hoạt động, nhưng sau khi học MVC-patterns tôi cảm thấy không thoải mái về điều này. Thật khó để thay đổi phong cách nghệ thuật khi tất cả logic hiển thị được chôn trong mô hình.

Có thể giới thiệu một lớp xem, lấy mức độ làm đối số và vẽ nó, nhưng điều này có nghĩa là phải xác định loại thực thể và giới thiệu "chuyển đổi", mà tôi đã học cũng kém.

Bạn nên đặt mã để vẽ ở đâu, theo cách có thể mở rộng, dễ thay đổi, sạch sẽ và khô?

Answer 1

Không có gì sai khi có phương thức Draw() trừu tượng trong thực thể cho phép họ quyết định cách vẽ, đặc biệt là đối với các trò chơi nhỏ hơn có thể sẽ không được mở rộng đáng kể. Tôi đã sử dụng phương pháp này trong một tấn các dự án nhỏ và nó hoạt động rất tốt.

Cải tiến bạn có thể thực hiện cho chiến lược đó là sử dụng tài nguyên trò chơi làm proxy cho các thao tác vẽ thực tế. Ví dụ một thực thể kẻ thù có thể trì hoãn tất cả các kết xuất thông qua một đối tượng tài nguyên mà nó sở hữu đại diện cho lưới; tương tự như vậy cho kết cấu/da và các hiệu ứng.

Gần đây tôi đã chuyển sang sử dụng các thực thể của mình làm vùng chứa 'câm' cho các giao diện xác định hành vi của chúng. Một thực thể người chơi có thể chứa IMoveable, IControllable, IRenderable và nhiều giao diện khác chỉ đơn giản là áp dụng một hoạt động chuyên biệt cho thực thể đó tùy thuộc vào dữ liệu chứa nó. Các thực thể không biết nhiều về điều này và tất cả các thực hiện xảy ra khi đồ thị cảnh đi ngang để hủy/render.

Answer 2

MVC không nhất thiết phải phù hợp với trò chơi. MVC được thiết kế cho các giao diện đồ họa truyền thống thường cập nhật thường xuyên dựa trên các sự kiện rời rạc, trong khi các trò chơi giống mô phỏng khi có cập nhật liên tục và bản trình bày cần phản ánh ngay lập tức.

Tuy nhiên, không có lý do gì khiến bạn không nên cố gắng tách biệt trạng thái khỏi bản trình bày. Các thực thể không cần biết cách vẽ bản thân như vậy - điều đó có nghĩa là họ biết về hoạt động dựng hình, điều không cần thiết - nhưng có thể hỏi họ cách họ xem xét thời điểm này và sau đó sử dụng thông tin đó hiển thị cảnh. ví dụ. một thực thể 2D sẽ có thể trả về khung hoạt ảnh hiện tại của nó. Hoặc một thực thể 3D sẽ có thể trả về lưới, vị trí và định hướng 3D của nó. Không cần báo cáo chuyển đổi ở đây, miễn là bạn có các biểu diễn chung mà bạn có thể quay lại trình kết xuất đồ họa. Các thực thể có thuật toán kết xuất cực kỳ khác nhau có thể phải trả về các đối tượng khá khác nhau tại thời điểm này.

Answer 3

Thông thường tôi giải quyết vấn đề này với thừa kế.

Ví dụ: trên một dự án tôi đang làm việc với tại thời điểm tôi đang sử dụng Phát triển theo hướng thử nghiệm để viết logic trò chơi, với thử nghiệm thủ công để hiển thị. Ví dụ dưới đây trong C# cho thấy ý tưởng thô.

class GameObjecet { 
    // Logic, nicely unit tested. 
} 

class DrawableGameObject : GameObject { 
    // Drawing logic - manual testing 
} 

Đây thường là những gì tôi đã tìm thấy là giải pháp tốt nhất. Điều này cho phép mã được kiểm tra, trong khi không làm lộn xộn logic trò chơi bằng mã trình bày như vẽ và tải mô hình, v.v ...

Answer 4

Câu hỏi này vẫn xuất hiện thường xuyên trong phát triển trò chơi khi các studio và nhóm khác nhau bắt đầu trên các công cụ mới.

Câu trả lời ngắn gọn là tùy thuộc vào mức độ phức tạp của các thực thể trò chơi của bạn. Đối với các thực thể đơn giản, nó không thực sự quan trọng.

Khi bạn tham gia vào các thực thể phức tạp hơn nhiều, bạn phải suy nghĩ lại cách tiếp cận của mình. Nói chung, bạn sẽ muốn chống lại sự thôi thúc có vòng lặp uber lặp lại trên mọi thực thể và gọi một số cập nhật/render/bất kỳ chức năng nào. Điều đó không quy mô chút nào, trừ khi mọi cập nhật, kết xuất hoặc bất kỳ cấu trúc phân cấp nào đều giống nhau. Đó là tốt cho một trò chơi như Geometry Wars, nhưng không phải cho bất cứ điều gì phức tạp hơn thế.

Những gì bạn muốn làm được cung cấp cho bộ sưu tập thực thể chung nhất trích xuất quá trình truyền tải sử dụng cụ thể. Ví dụ: nếu bạn muốn hiển thị cảnh, bạn nên có cách để trích xuất tất cả các thực thể có thể hiển thị từ bộ sưu tập thực thể và sau đó hiển thị tất cả chúng trong một số thứ tự tùy ý theo thứ tự. Cũng vậy với vật lý, va chạm, AI vv

Một số liên kết hữu ích:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

tôi khuyên bạn nên cả hai; đầu tiên đi vào lý do thiết kế để xây dựng các thực thể trò chơi trong số các thành phần, tức là, kết xuất thành phần, thành phần vật lý, thành phần AI. Thứ hai đi vào đặc điểm hiệu suất của các phương pháp tiếp cận thực thể trò chơi khác nhau.