Kiểm tra hướng phát triển cho các trò chơi phức tạp


8

Tôi đang viết mã một trò chơi trong thời gian rảnh rỗi, nhưng tôi hầu như vẫn là người mới bắt đầu lập trình. Tôi xin lỗi nếu câu hỏi này không có chủ đề hoặc nếu nó không hữu ích cho bất kỳ ai khác, nhưng hy vọng nó sẽ được.

Tôi đã dành rất nhiều thời gian để đọc sách về thiết kế mã, cũng như các phương pháp và cách tiếp cận khác nhau để mã hóa. Trong quá trình nghiên cứu này, tôi tiếp tục chạy theo khái niệm Phát triển hướng thử nghiệm. Những người tán thành ý tưởng này thường có vẻ rất say mê nó. Tôi tin rằng nó có thể giúp tốc độ và hiệu quả của việc viết phần mềm. Thời gian là một nguồn tài nguyên rất quý giá, vì vậy tôi thà học cách làm mọi thứ theo cách tốt nhất chứ không phải lầy lội mà không cố gắng mở rộng kiến ​​thức về nghề lập trình.

Dù sao, có thể vì tôi là người mới bắt đầu, tôi không thể tưởng tượng làm thế nào để áp dụng phát triển theo hướng thử nghiệm vào trò chơi. Tôi đã tìm thấy một vài bài viết về chủ đề này nhưng chúng không hữu ích lắm. Hầu hết các ví dụ về các bài kiểm tra đơn vị mà tôi đã thấy là các ví dụ mẫu đơn giản, hoặc các ví dụ từ phần mềm hoàn toàn không giống như một trò chơi.

Trong mã hóa của riêng tôi, tôi cố gắng tiếp cận nó với một tư duy tương tự để kiểm tra sự phát triển theo định hướng, mặc dù tôi chắc chắn rằng nó không thực sự đủ điều kiện là TDD. Tôi viết số lượng mã tối thiểu để cố gắng thực hiện bất kỳ tính năng nào tôi đang thêm vào trò chơi, và sau đó tôi ngay lập tức kiểm tra trò chơi để xem nó có hoạt động không. Nếu mọi thứ không xảy ra như tôi dự định, tôi lập tức thay đổi để đến gần hơn với những gì tôi muốn. Nếu nó không hoạt động hoặc bị hỏng và nếu tôi không thể tìm thấy lỗi bằng cách đọc mã, tôi sẽ thực hiện các phương thức trong trình gỡ lỗi cho đến khi tôi tìm thấy hành vi không mong muốn và sau đó tôi xóa nó. Điều tôi đang cố gắng nói là tôi liên tục thử nghiệm trò chơi, khá nhiều sau mỗi thay đổi gia tăng. Kiểm tra thúc đẩy sự phát triển của tôi. "Bài kiểm tra đơn vị" nằm trong đầu tôi,

Về câu hỏi thực tế của tôi. Làm thế nào một người có thể viết bài kiểm tra đơn vị cho một trò chơi phức tạp? Nói một cách phức tạp, ý tôi là với nhiều khía cạnh mới nổi của trò chơi, sao cho phần cốt lõi của trò chơi nổi lên từ sự tương tác giữa nhiều yếu tố khác nhau trong trò chơi kết hợp với lựa chọn của người chơi. Ví dụ, một rpguelike rpg với một thế giới thủ tục. Những loại bài kiểm tra đơn vị nào người ta sẽ viết cho một trò chơi như vậy? Làm thế nào người ta có thể áp dụng phát triển theo hướng thử nghiệm cho một trò chơi như vậy?


2
Vị vua của câu hỏi này có thể phù hợp hơn với phần Game Dev: gamedev.stackexchange.com
glampert

1
Điều đáng chú ý là sự phát triển theo hướng kiểm tra khuyến khích bạn chia thiết kế của mình thành các đơn vị nhỏ có thể quản lý được. Tôi sử dụng các bài kiểm tra đơn vị để kiểm tra logic có thể hoặc thậm chí không được sử dụng cho chức năng trong dự án, thay vào đó đôi khi mục đích của nó là để kiểm tra chính khái niệm đó. Tìm kiếm các trò chơi mã nguồn mở trưởng thành để biết các ví dụ hoạt động tốt về cách kiểm tra đơn vị có thể được sử dụng trong phát triển trò chơi
Keldon Alleyne

Câu trả lời:


12

Kiểm tra đơn vị không kiểm tra lối chơi . Không có tiêu chí lập trình để xem liệu một trò chơi có vui không, hay một cấp độ là độ khó phù hợp. Các bài kiểm tra đơn vị sẽ kiểm tra rằng mapgen roguelike của bạn thực sự tạo ra một cấp độ với một cầu thang lên và một cầu thang xuống. Nó sẽ kiểm tra các quy tắc mã hóa của bạn được thiết lập để nhân vật của bạn thực sự di chuyển chậm hơn khi có trọng số. Nó sẽ đảm bảo nhân vật của bạn không thể đội 50 chiếc mũ . Nó sẽ đảm bảo rằng tất cả các cơ học được thực hiện chính xác trong sự cô lập tương đối.


1
Câu trả lời của bạn giúp tôi hiểu mọi thứ tốt hơn một chút, nhưng không hoàn toàn. Theo hiểu biết của tôi, để nó thực sự được phát triển dựa trên thử nghiệm, các bài kiểm tra nên được viết trước. Vì vậy, viết các bài kiểm tra thất bại, viết mã để làm cho nó vượt qua, sau đó sửa mã. Làm thế nào điều này có thể được áp dụng để kiểm tra xem một mapgen có tạo ra một mức có cầu thang lên xuống không? Những loại bài kiểm tra đơn vị sẽ đáp ứng các yêu cầu TDD?
bazola

1
@bazola - Tôi sợ tôi không hiểu? Bạn viết một bài kiểm tra để gọi mapgen, sau đó kiểm tra xem kết quả có cầu thang lên và xuống cầu thang không. Điều đó không được biên dịch vì bạn có một mapgen cũng như khái niệm về cầu thang. Vì vậy, bạn làm cho những. Sau đó, bạn làm cho mapgen thực sự đáp ứng các tiêu chí ...
Telastyn

Điều đó có ý nghĩa. Nhiều đánh giá cao!
bazola

4
Có liên quan: TDD không nhất thiết có nghĩa là các bài kiểm tra đơn vị của bạn là trình điều khiển duy nhất trong quá trình phát triển. Bạn có thể bắt đầu "lái xe" bằng cách viết bài kiểm tra "chấp nhận" và / hoặc tích hợp không đạt mức độ cao, trong đó bạn có thể nghĩ ra một giải pháp và viết bài kiểm tra đơn vị thất bại đầu tiên của mình ... mặc dù vậy, tôi thực sự không chắc chắn điều gì cần phải viết một bài kiểm tra chấp nhận tự động, có ý nghĩa cho một trò chơi không tầm thường.
Svidgen

2

Thật khó để viết các bài kiểm tra đơn vị cho mã không xác định. Nếu bạn có mã liên quan đến các số ngẫu nhiên, bạn sẽ không thể viết một bài kiểm tra đơn vị xác nhận kết quả mong đợi.

Vì vậy, các bài kiểm tra đơn vị phù hợp hơn cho mã có tính xác định. Khi tôi đưa ra một phương thức các đầu vào này, tôi mong đợi các đầu ra này. Một ví dụ: khi một chiến binh có 15 sức mạnh sử dụng thanh kiếm hai tay của mình để đánh thành công một con ma cà rồng bất tử với 10 bộ giáp, tôi mong đợi 8 điểm sát thương. Phần không xác định (cho dù cú đánh có thành công hay không) không nhất thiết phải được kiểm tra đơn vị, nhưng điều gì xảy ra sau đó có thể xảy ra. Ngay cả khi lượng sát thương dự kiến ​​sẽ nằm trong phạm vi nào đó, bạn vẫn có thể kiểm tra mức độ đó.

Nếu bạn gặp khó khăn trong việc tìm mã để viết bài kiểm tra đơn vị, bạn cần cấu trúc lại để logic xác định được tách biệt trong các phương thức hoặc lớp. Trước tiên, lắc xí ngầu để xác định thành công, sau đó chuyển các đầu vào có liên quan (lớp, sức mạnh, áo giáp, v.v.) sang phương pháp thử nghiệm.

Đối với nhận xét của bạn về việc có bài kiểm tra đơn vị trong đầu, điểm kiểm tra đơn vị không chỉ là về mã mới được viết. Đó cũng là về sự tự tin rằng mã vẫn hoạt động sau khi thực hiện các thay đổi không thể tránh khỏi .


3
Một cách để mã kiểm thử đơn vị sử dụng tính ngẫu nhiên là chạy nó nhiều lần và kiểm tra xem kết quả có phù hợp về mặt thống kê với phân phối dự kiến ​​hay không. Vì vậy, khi một cuộc tấn công được cho là gây sát thương 10 + 2d6, bạn chạy mã 1000 lần và kiểm tra xem không có kết quả nào lớn hơn 22, không nhỏ hơn 12 và có phân phối hình chuông gần như trong phạm vi đó.
Philipp

1
Bạn cũng có thể áp dụng phương pháp này cho các tình huống phức tạp hơn, như đảm bảo rằng nhân vật cấp 1 chiến thắng trong cuộc chiến giả lập với yêu tinh khoảng 90% thời gian.
Philipp

3
Thông thường nếu một phần mã của bạn sử dụng các số ngẫu nhiên, bạn trừu tượng hóa trình tạo số ngẫu nhiên của mình thành một dịch vụ ( IRandomNumberGenerator) và bất cứ điều gì cần sử dụng các số ngẫu nhiên đều chấp nhận tham chiếu đến giao diện dịch vụ đó trong hàm tạo của chúng. Sau đó, khi thử nghiệm của bạn tạo ra đối tượng đó để chạy thử nghiệm đơn vị, nó sẽ tiêm một MockRandomNumberGeneratorluồng cung cấp một luồng số đã biết cố định. Sau đó, bạn có một bài kiểm tra lặp lại. Ý tưởng tương tự cũng hữu ích cho bất cứ điều gì cần để có được ngày / giờ hiện tại hoặc tải thông tin từ một dịch vụ web - chỉ cần tiêm một dịch vụ giả.
Scott Whitlock

... Sau đó, bạn có thể viết một bài kiểm tra riêng sử dụng các phương pháp thống kê để kiểm tra hoạt động thực tế của việc triển khai thực sự của bạn RandomNumberGenerator.
Scott Whitlock

Tôi sẽ downvote nếu tôi có thể. Các tính năng thống kê của shold kết quả sẽ được kiểm tra cho thuật toán ngẫu nhiên.
Riga
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.