MVC hoặc Thành phần, hoặc cả hai?

Tôi là một nhà phát triển có kinh nghiệm nhưng gần đây tôi đã muốn tham gia vào lập trình trò chơi nhưng như bạn biết phát triển trò chơi là một con thú hoàn toàn khác với hầu hết các hình thức lập trình khác (có lẽ chỉ tốt nhất khi phát triển hệ điều hành).

Điều đó đang được nói rằng tôi đã đọc Toàn bộ mã hóa trò chơi (ISBN 976-1-58450-680-5) của Mike McShaffry.

Ban đầu tôi sẽ thử phát triển với một mô hình thành phần với các loại thành phần thông thường (ví dụ SpacialComponent, VisualComponent, EntityLogicComponent, v.v.) tuy nhiên ông McShaffry khuyên bạn nên sử dụng mô hình MVC trông rất hấp dẫn nhưng tôi không chắc là tôi thế nào có thể làm cho nó hoạt động với mô hình thành phần nếu có thể, nhưng, không có các thành phần, mô hình MVC trông giống như quái vật thừa kế nguyên khối độc ác và không linh hoạt, điều mà tôi không thực sự quan tâm.

Tôi thực sự bối rối về nơi sẽ đi từ thời điểm này.

Bạn có nhiều kinh nghiệm về các chuyên gia voodoo mã hóa trò chơi có bất kỳ suy nghĩ hoặc khuyến nghị?

Cảm ơn bạn rất nhiều!

Câu hỏi hữu ích:

Kiến trúc công cụ trò chơi MVC (Model-View-Controller) - Có hay không?

Tại sao MVC & TDD không được sử dụng nhiều hơn trong kiến ​​trúc trò chơi?

MVC giống như khoang trong trò chơi?

Đối với tôi, tôi có một lớp cơ sở RenderComponent và sau đó một số lớp kế thừa từ đó (GameSprite, UISprite hoặc nếu bạn đang thực hiện 3d StaticModel, DynamicModel, BillboardModel, v.v.) và nếu đối tượng muốn tự kết xuất, đối tượng sẽ gửi nó Thành viên RenderComponent vào hệ thống kết xuất. Không cần hệ thống kết xuất để biết loại đối tượng nào đã gửi RenderComponent. Nó chỉ biết rằng nó có một cái gì đó để kết xuất và tốt hơn là làm điều đó, hoặc nếu không!

Giữ nó cơ bản và tập trung xung quanh thành phần hơn là kế thừa. Tách logic, dữ liệu và biểu diễn không tương thích với một hệ thống thành phần.

Tôi khuyên bạn nên bỏ qua các thành phần cho trò chơi đầu tiên của mình vì chúng giải quyết một số loại phức tạp bằng cách thêm độ phức tạp vào các khu vực khác và nếu bạn chưa tạo trò chơi, bạn sẽ không biết liệu sự đánh đổi này có đáng hay không.

Đối với hầu hết các phần, mặc dù, không bị sa lầy vào các mô hình lập trình và chỉ viết mã một trò chơi. Không có cách nào đúng hay sai, nếu không thì không ai cần phải hỏi loại câu hỏi này. Làm việc đó khi bạn đi cùng.

Tôi sẽ không sử dụng một mẫu MVC nghiêm ngặt, nhưng tôi sẽ tách kết xuất của bạn khỏi mô phỏng của bạn và dán nó vào một luồng khác.

Tôi nghĩ rằng các thành phần thực sự rất hữu ích, nhưng tôi thường thấy mọi người chỉ cần bỏ qua chúng và viết mã của chúng trực tiếp vào thành phần "chính" bất cứ điều gì có thể. Bạn phải nhớ rằng các trò chơi có rất nhiều hack vì thường được viết theo thời hạn với giả định rằng mã sẽ không được sử dụng lại.

Tôi hơi bối rối về lý do tại sao bạn nghĩ rằng các phương pháp này không tương thích. Bạn đã xem mã game nào?

Cá nhân, tôi nghĩ rằng các trò chơi đòi hỏi một số thiết kế phía trước. Tôi đã thấy một vài cơ sở mã là những cơn ác mộng vì "chỉ cần mã hóa tâm lý".

Điều đó nói rằng, tôi nghĩ rằng bạn chỉ nên nhảy vào và viết mã một trò chơi. Bạn sẽ phạm rất nhiều sai lầm khi viết trò chơi đầu tiên của bạn đến nỗi những loại vấn đề này không quan trọng lắm. Một khi bạn đã hiểu rõ hơn về những gì cần thiết, sau đó bạn có thể quay lại và bắt đầu nhìn vào kiến ​​trúc và xem cách nó giải quyết các vấn đề bạn gặp phải.