Những cạm bẫy điển hình khi viết trò chơi với Ngôn ngữ được quản lý như C # là gì? [đóng cửa]

Những cạm bẫy nào bạn gặp phải khi viết trò chơi cho PC với Ngôn ngữ được quản lý như C # và bạn đã giải quyết chúng như thế nào?

Tôi không biết nhiều về Java, vì vậy đây là từ quan điểm của một nhà phát triển .net.

Cái lớn nhất cho đến nay là rác. Trình thu gom rác .NET trên Windows thực hiện công việc tuyệt vời và bạn có thể thoát khỏi mà không cần cho bé ngồi phần lớn. Trên Xbox / Windows Phone 7, đó là một vấn đề khác. Nếu bạn nhận được quầy hàng cứ sau vài khung hình, bộ sưu tập rác có thể gây ra sự cố cho bạn. Tại thời điểm này, nó kích hoạt sau mỗi phân bổ 1MB.

Dưới đây là một số mẹo để xử lý rác. Bạn không cần phải lo lắng về hầu hết những điều này trong thực tế, nhưng chúng có thể có ích vào một ngày nào đó.

• Vẽ nội dung của GC.GetTotalMemory()màn hình. Điều này cung cấp cho bạn một xấp xỉ số lượng byte được phân bổ mà trò chơi của bạn sử dụng. Nếu nó hầu như không di chuyển, bạn đang làm tốt. Nếu nó tăng nhanh, bạn có vấn đề.
• Cố gắng phân bổ tất cả các đối tượng heap của bạn lên phía trước. Nếu bạn không phân bổ mọi thứ trước khi trò chơi bắt đầu, mỗi khi bạn đạt được một meg phân bổ, bạn sẽ bị đình trệ. Không phân bổ, không có bộ sưu tập. Đơn giản vậy thôi.
• Sau khi tải, gọi GC.Collect(). Nếu bạn biết hầu hết các khoản phân bổ lớn của mình đều nằm ngoài dự đoán, thật tuyệt khi cho hệ thống biết.
• KHÔNG GỌI GC.Collect()mọi khung hình. Nó có vẻ như là một ý tưởng tốt, giữ lại rác của bạn và tất cả những thứ đó, nhưng hãy nhớ rằng chỉ có điều tồi tệ hơn một bộ sưu tập rác là trên bộ sưu tập rác.
• Tìm nơi rác của bạn đến từ. Có một số nguyên nhân phổ biến như nối chuỗi thay vì sử dụng StringBuilder(hãy cẩn thận, StringBuilderkhông phải là viên đạn ma thuật và vẫn có thể gây ra sự phân bổ! Điều này có nghĩa là các thao tác đơn giản như thêm số vào cuối chuỗi có thể tạo ra lượng rác đáng ngạc nhiên) hoặc sử dụng foreachcác vòng lặp trên các bộ sưu tập sử dụng IEnumerablegiao diện cũng có thể tạo rác mà bạn không biết (ví dụ: foreach (EffectPass pass in effect.CurrentTechnique.Passes)là một phổ biến)
• Sử dụng các công cụ như trình lược tả bộ nhớ CLR để tìm ra nơi bộ nhớ được phân bổ. Có rất nhiều hướng dẫn về cách sử dụng công cụ này.
• Khi bạn biết nơi phân bổ của mình trong khi chơi trò chơi, hãy xem liệu bạn có thể sử dụng các thủ thuật như gộp các đối tượng để giảm số lượng phân bổ đó không.
• Nếu vẫn thất bại, làm cho bộ sưu tập của bạn chạy nhanh hơn! GC trên khung nhỏ gọn tuân theo mọi tham chiếu trong mã của bạn để tìm ra những đối tượng nào không được sử dụng nữa. Tái cấu trúc mã của bạn sử dụng ít tài liệu tham khảo!
• Hãy nhớ sử dụng IDisposabletrên các lớp có chứa tài nguyên không được quản lý. Bạn có thể sử dụng những thứ này để dọn sạch bộ nhớ, GC không thể tự giải phóng.

Điều khác cần suy nghĩ là hiệu suất điểm nổi. Mặc dù .NET JITer thực hiện một số lượng tối ưu hóa cụ thể của bộ xử lý, nhưng nó không thể sử dụng SSE hoặc bất kỳ bộ hướng dẫn SIMD nào khác để tăng tốc các phép toán dấu phẩy động của bạn. Điều này có thể gây ra sự chênh lệch tốc độ khá lớn giữa C ++ và C # cho các trò chơi. Nếu bạn sử dụng đơn âm, họ có một số thư viện toán học SIMD đặc biệt mà bạn có thể tận dụng.

Một cạm bẫy hiệu suất đỉnh cao là không xem xét bộ thu gom rác trong thiết kế / phát triển của trò chơi. Sản xuất quá nhiều rác thải có thể dẫn đến "trục trặc" trong trò chơi, điều này xảy ra khi GC chạy trong một thời gian dài đáng kể.

Đối với C #, sử dụng các đối tượng giá trị và câu lệnh "sử dụng" có thể giảm bớt áp lực từ GC.

Tôi muốn nói rằng vấn đề lớn nhất mà tôi gặp phải khi viết trò chơi trong C # là thiếu thư viện phong nha. Hầu hết tôi đã tìm thấy là các cổng trực tiếp, nhưng không đầy đủ hoặc bao bọc trong thư viện C ++ phải chịu một hình phạt hiệu năng nặng cho việc sắp xếp theo thứ tự. (Tôi đang nói cụ thể về MOgre và Axiom cho thư viện OGRE và BulletSharp cho thư viện vật lý Bullet)

Các ngôn ngữ được quản lý (khác với Phiên dịch - cả Java và C # không thực sự được giải thích nữa) có thể nhanh như ngôn ngữ bản địa nếu bạn hiểu rõ về những gì thực sự làm cho chúng chậm (thu thập dữ liệu, thu gom rác). Vấn đề thực sự, tôi nghĩ, là các nhà phát triển thư viện chưa nhận ra điều đó.

Giống như những người khác đã nói, tạm dừng bộ sưu tập GC là vấn đề lớn nhất. Sử dụng nhóm đối tượng là một giải pháp điển hình.

C # và Java không được giải thích. Chúng được biên dịch thành mã byte trung gian, sau JIT , trở nên nhanh như mã gốc (hoặc gần đủ để không đáng kể)

Cạm bẫy lớn nhất mà tôi tìm thấy là giải phóng tài nguyên ảnh hưởng trực tiếp đến trải nghiệm người dùng. Các ngôn ngữ này không tự động hỗ trợ hoàn thiện xác định như C ++, điều mà nếu bạn không mong đợi nó có thể dẫn đến những thứ như lưới nổi về cảnh sau khi bạn nghĩ rằng chúng bị phá hủy. (C # hoàn thành quyết toán xác định thông qua IDis Dùng , tôi không chắc Java làm gì.)

Ngoài ra, các ngôn ngữ được quản lý thực sự có khả năng xử lý loại hiệu suất mà các trò chơi yêu cầu nhiều hơn so với tín dụng. Mã được quản lý tốt được viết nhanh hơn nhiều so với mã gốc được viết kém.

Cả Java và C # đều không được giải thích. Cả hai đều được biên dịch thành mã máy riêng.

Vấn đề lớn nhất với cả hai và trò chơi là phải viết mã theo cách mà chúng không bao giờ thu gom rác trong khi chơi trò chơi. Số lượng hoops bạn phải nhảy qua để hoàn thành gần như vượt xa lợi ích của việc sử dụng chúng ở nơi đầu tiên. Hầu hết các tính năng làm cho những ngôn ngữ đó trở nên thú vị để sử dụng cho lập trình ứng dụng hoặc máy chủ phải được tránh để lập trình trò chơi nếu không bạn sẽ bị tạm dừng lâu trong khi chơi trò chơi khi chúng tắt và thu gom rác.

Một cạm bẫy lớn mà tôi thấy từ việc tạo ra các trò chơi với các ngôn ngữ như thế này (hoặc sử dụng các công cụ như XNA, TorqueX engine, v.v.) là bạn sẽ khó tìm được một đội ngũ những người giỏi có chuyên môn cần thiết để tạo ra một trò chơi tương đương với những gì sẽ khá dễ dàng để tìm thấy mọi người trong C ++ và OpenGL / DirectX.

Ngành công nghiệp phát triển trò chơi vẫn còn rất nặng về C ++ vì hầu hết các công cụ và đường ống được sử dụng để đẩy ra các trò chơi nhỏ lớn hoặc được đánh bóng tốt đều được viết bằng C ++, và theo như tôi biết thì TẤT CẢ các bộ dụng cụ phát triển chính thức bạn có thể get for XBox, PS3 và Wii chỉ được phát hành với khả năng tương thích với C ++ (bộ công cụ XBox có thể được quản lý nhiều hơn hiện nay, có ai biết nhiều hơn không?)

Nếu bạn muốn phát triển trò chơi dành cho bảng điều khiển ngay bây giờ, bạn có khá nhiều XNA và C # trên XBox và sau đó chỉ trong một phần phụ của thư viện trò chơi có tên XBox Live Indie Games. Một số người chiến thắng trong các cuộc thi, v.v. được chọn để chuyển trò chơi của họ sang XBox Live Arcade thực sự. Khác với kế hoạch làm một trò chơi cho PC.