Tùy chọn thực thi XNA GameComponent ...?

Question

Gần đây tôi đã nhảy vào hồ bơi XNA, và đang học tất cả các phần trong và ngoài của khung công tác trong C#. Một điều tôi đã nhận thấy trong nghiên cứu của tôi là dường như không có cách nào được chấp nhận rộng rãi để triển khai GameComponents.

Sau khi đọc this thread (trong số những người khác), tôi đã phát hiện ra một phổ rộng các tùy chọn giữa các nhà phát triển trò chơi. Tôi đã nhìn thấy một số người ủng hộ không bao giờ sử dụng GameComponents ở tất cả (hoặc chỉ một cách tiết kiệm), trong khi những người khác yêu cầu sử dụng chúng cho mọi thứ, ngay xuống máy nghe nhạc/kẻ thù, tên lửa, v.v. phương pháp tiếp cận và dự trữ kiến ​​trúc GameComponent cho các thực thể ở mức trung đến cao như màn hình, trình kết xuất, cảnh, v.v. do đó chứa và điều khiển các đơn vị trò chơi chi tiết hơn.

Vào cuối ngày, tùy thuộc vào nhà phát triển trò chơi để xác định cách tốt nhất để triển khai khung. Kể từ khi StackOverflow được đóng gói với các nhà phát triển hiểu biết đã quên nhiều hơn tôi sẽ biết, tôi muốn có được một cảm giác về sự đồng thuận ở đây trước khi tôi tiếp tục xuống con đường này với việc sử dụng của riêng tôi của khuôn khổ.

Bất cứ ai quan tâm để trò chuyện với suy nghĩ của họ? Cảm ơn trước!

Answer 1

Tôi cũng khá mới với XNA, vì vậy hãy trả lời câu hỏi này bằng một hạt muối.

Tôi nghĩ rằng nó có thể đun sôi xuống tùy chọn kiểu. Tôi không chắc chắn về đặc tính hiệu suất giữa việc sử dụng GameComponent so với các cách thủ công hơn, nhưng tôi biết rằng đối với cá nhân tôi, tôi nhanh chóng thất vọng khi cố gắng sử dụng GameComponent vì nó không thực sự hợp với phong cách suy nghĩ hoặc lập trình của tôi. Trái tim tôi là một sự pha trộn của những thứ tôi đã chọn từ các mô hình lập trình OOP, thủ tục, chức năng và lập trình khác. GameComponent dường như đang sử dụng cách tiếp cận OOP nghiêm ngặt.

Nhưng tôi sẽ nói rằng làm cho mọi thứ mọi thứ một GameComponent hoặc thậm chí là một lớp học nói chung, có thể trở thành vấn đề khi hiệu năng liên quan. Các câu hỏi về khả năng đọc và bảo trì tối đa dường như nằm trên cạnh của một con dao trong thế giới phát triển trò chơi, nơi đôi khi bạn thực sự chỉ phải siết chặt tối ưu hóa mã của bạn. Ví dụ, đôi khi tốt hơn là biến một trong các đối tượng trò chơi của bạn thành một cấu trúc (kiểu giá trị) để bạn có thể tiết kiệm bộ nhớ và ngăn chặn trình thu thập rác pesky khỏi làm chậm trễ trò chơi của bạn (như tôi đã học trong this question I asked).