Làm cách nào để thiết kế phần mềm của trò chơi sao cho dễ kiểm tra đơn vị?

Có thực tế không khi sử dụng một khung thử nghiệm như JUnit trong tình huống phát triển trò chơi? Những loại cân nhắc thiết kế nào bạn có thể làm theo để làm cho trò chơi của bạn dễ kiểm tra hơn? Những phần nào của trò chơi có thể / nên được thử nghiệm và những phần nào nên / phải để lại cho thử nghiệm của con người?

Ví dụ, nếu vòng lặp trò chơi được gói gọn trong một chức năng, có vẻ như sẽ rất khó để kiểm tra. Tôi muốn cấu trúc lại một chức năng "cập nhật" mất một khoảng thời gian và tiến về phía trước logic trò chơi; điều này cho phép một số thủ thuật thú vị như khả năng làm chậm trò chơi bằng cách cho nó ăn giả, thời gian chậm hơn.

Một trong những nguyên lý của TDD là bạn để TDD trong một số trường hợp ảnh hưởng đến thiết kế của bạn. Bạn viết một bài kiểm tra cho hệ thống, sau đó viết mã để thực hiện bài kiểm tra đó, giữ cho các phụ thuộc càng nông càng tốt.

Đối với tôi, chỉ có hai điều tôi không kiểm tra như một phần của kiểm tra đơn vị:

Đầu tiên, tôi không kiểm tra các yếu tố thị giác và mọi thứ trông như thế nào. Tôi kiểm tra và vật thể sẽ ở đúng vị trí sau khi nó cập nhật, rằng một camera sẽ loại bỏ một vật thể bên ngoài giới hạn của nó, biến đổi (ít nhất là những vật được thực hiện bên ngoài shader) được thực hiện đúng trước khi đưa vào công cụ đồ họa , nhưng một khi nó chạm vào hệ thống đồ họa, tôi vẽ đường thẳng. Tôi không thích thử chế giễu những thứ như DirectX.

Thứ hai, tôi không thực sự kiểm tra chức năng vòng lặp trò chơi chính. Tôi kiểm tra rằng mọi hệ thống sẽ hoạt động khi được thông qua một delta hợp lý và các hệ thống đó hoạt động chính xác khi chúng cần. Sau đó, tôi chỉ cập nhật từng hệ thống với delta chính xác trong vòng lặp trò chơi. Tôi thực sự có thể có một thử nghiệm để chỉ ra rằng mỗi hệ thống được gọi với delta chính xác, nhưng trong nhiều trường hợp tôi thấy rằng quá mức cần thiết (trừ khi bạn đang thực hiện logic phức tạp để có được delta của mình, thì nó không quá mức cần thiết).

Noel Llopis đã bảo hiểm thử nghiệm đơn vị ở mức độ mà tôi tin rằng bạn đang tìm kiếm:

• http://gamesfromwithin.com/stepping-ENC-the-looking-lass-test-driven-game-development-part-1
• http://gamesfromwithin.com/stepping-ENC-the-looking-lass-test-driven-game-development-part-2
• http://gamesfromwithin.com/stepping-ENC-the-looking-lass-test-driven-game-development-part-3
• http://gamesfromwithin.com/backwards-is-forward-making-better-games-with-test-driven-development
• (anh ấy cũng có nhiều bài viết khác về TDD)

Đối với việc kiểm tra toàn bộ vòng lặp trò chơi, có một kỹ thuật khác để ngăn chặn hồi quy chức năng trong mã của bạn. Ý tưởng là để trò chơi của bạn tự chơi thông qua một hệ thống phát lại (ví dụ: đầu tiên ghi lại đầu vào của người chơi, sau đó phát lại chúng qua một lần chạy khác). Trong quá trình phát lại, bạn tạo một ảnh chụp nhanh về trạng thái của từng đối tượng cho mỗi khung hình. Bộ sưu tập nhà nước này sau đó có thể được gọi là "hình ảnh vàng". Khi cấu trúc lại mã của bạn, bạn chạy lại phát lại và so sánh từng trạng thái của khung hình với trạng thái hình ảnh vàng. Nếu nó khác, thử nghiệm đã thất bại.

Mặc dù lợi ích của kỹ thuật này là rõ ràng, có một số điều bạn cần cẩn thận:

• Trò chơi của bạn cần có tính xác định, vì vậy bạn cần cẩn thận với những việc như tùy thuộc vào đồng hồ hệ thống, sự kiện hệ thống / mạng, trình tạo số ngẫu nhiên không được xác định hạt giống. v.v.
• thay đổi nội dung sau khi hình ảnh vàng được tạo có thể gây ra sự khác biệt hợp pháp với hình ảnh vàng của bạn. Không có cách nào khắc phục điều này - khi thay đổi nội dung của bạn, bạn cần tạo lại hình ảnh vàng của mình.

Tôi đồng ý với cả ý kiến ​​của Jeff và jpaver. Tôi cũng muốn thêm rằng việc áp dụng một mô hình thành phần cho kiến ​​trúc của bạn làm tăng đáng kể khả năng kiểm tra của nó. Với một mô hình thành phần, mỗi thành phần sẽ thực hiện một đơn vị công việc duy nhất và có thể kiểm tra được trong sự cô lập (hoặc với các đối tượng giả có giới hạn).

Tương tự như vậy, các phần khác của trò chơi dựa vào các thực thể chỉ nên dựa vào một tập hợp con của các thành phần để hoạt động. Trong thực tế điều này có nghĩa là bạn thường có thể giả lập một vài thành phần giả để tạo điều kiện kiểm tra các khu vực này hoặc bạn chỉ có thể soạn các thực thể một phần cho mục đích thử nghiệm. ví dụ: bạn bỏ qua các thành phần kết xuất và đầu vào vì chúng không cần thiết để kiểm tra vật lý.

Cuối cùng, tôi sẽ bỏ qua lời khuyên xung quanh hiệu suất mà bạn nhận được từ một số người trong cộng đồng trò chơi liên quan đến giao diện. Viết mã tốt với các giao diện và nếu bạn gặp vấn đề về hiệu năng, bạn có thể dễ dàng cấu hình, xác định và cấu trúc lại để giải quyết vấn đề. Tôi đã không bị thuyết phục bởi những lo ngại của Noel xung quanh tác động hiệu năng của các giao diện hoặc chi phí phức tạp mà họ đã thêm vào.

Điều đó nói rằng, đừng quá nhiệt tình cố gắng kiểm tra mọi thứ một cách độc lập. Giống như hầu hết mọi thứ kiểm tra và thiết kế là về sự cân bằng phù hợp.

Tôi nghĩ rằng tôi sẽ thêm câu trả lời thứ hai trả lời bình luận của OP rằng người dùng có thể thay thế các bài kiểm tra đơn vị. Tôi tin rằng điều đó là hoàn toàn sai lầm vì mục đích của các bài kiểm tra đơn vị không phải là để đảm bảo chất lượng. Nếu bạn muốn kiểm tra tại chỗ để đảm bảo chất lượng chương trình của mình, bạn có thể nên điều tra kiểm tra kịch bản hoặc đầu tư vào giám sát tuyệt vời.

(Với sự giám sát tuyệt vời và một sản phẩm hoạt động như một dịch vụ, thực sự có thể đẩy một số "thử nghiệm" đến khách hàng nhưng bạn cần có một hệ thống tinh vi giúp phát hiện lỗi nhanh chóng và đẩy lùi các thay đổi có trách nhiệm. một nhóm phát triển nhỏ.)

Đơn vị kiểm tra lợi ích chính là họ buộc nhà phát triển viết mã được thiết kế tốt hơn. Hành động thử nghiệm thách thức nhà phát triển tách biệt mối quan tâm và đóng gói dữ liệu. Nó cũng khuyến khích nhà phát triển sử dụng các giao diện và các khái niệm trừu tượng khác để anh ta chỉ kiểm tra một thứ.