Làm thế nào mạnh mẽ một động cơ một người chơi từ chối dữ liệu không hợp lệ?


11

Trong trò chơi một người chơi, khi cố gắng xây dựng một thực thể từ các thành phần được chỉ định trong các tập lệnh bên ngoài, bạn nghĩ điều gì sẽ xảy ra hơn khi một trong các thành phần không được định dạng:

  • Động cơ có nên bỏ qua thành phần đó và để thực thể sống trong thế giới trò chơi chỉ với các thành phần được viết tốt không?
  • Hoặc nó không nên thêm thực thể vào thế giới nếu một trong những thành phần không được định hình?

Lưu ý, tôi không nói về việc ghi lại các lỗi - điều đó sẽ đến mà không cần nói - chỉ về những gì sẽ xảy ra với thực thể.


Chúng ta đang nói về người chơi đơn hay nhiều người chơi?
o0 '.

@Lohoris Người chơi đơn.
Paul Manta

2
Như hầu hết các câu trả lời đã ám chỉ, khán giả của bạn là ai? Bạn đang làm một trò chơi có thể sửa đổi hoặc bạn đang nói về mục đích phát triển nội bộ?
Tetrad

@Tetrad Tôi muốn trò chơi trở nên thân thiện với modder nhất có thể.
Paul Manta

Câu trả lời:


11

Nếu bạn đang nói về một trò chơi có thể sửa đổi, thì bạn có thể muốn làm theo một trong những gợi ý của bạn ở trên. Nhưng nếu bạn lo lắng về việc khắc phục lỗi của mình, tôi sẽ nói đừng làm điều đó. Tôi đã trở thành một người ủng hộ Fail-Fast . Nếu đây là lỗi mà bạn đã tạo và phải khắc phục trước khi phát hành, bạn nên làm cho lỗi rõ ràng. Bài viết được liên kết ở dưới cùng của trang wiki là một bài đọc tốt về chủ đề này tại sao thất bại nhanh là tốt, và khi nào nên và không nên sử dụng nó.


2
Tôi nghĩ rằng đây là một sự phân đôi tuyệt vời, phân biệt giữa lỗi người dùng và lỗi nhà phát triển. Điều này có lý do cho cùng một lý do chính xác rằng các lỗi trình biên dịch thường khá dễ sửa nhưng lỗi thời gian chạy / ngữ nghĩa là ma quỷ.
jhocking

Nếu công cụ bao gồm một cách để sửa đổi các thực thể khi trò chơi đã bắt đầu, ít nhất bạn nên cho mình cơ hội sửa lỗi trước khi bạn thất bại.
Blecki

7

Sự khác biệt giữa người dùng và nhà phát triển không phải lúc nào cũng rõ ràng trong phát triển trò chơi. Các kỹ thuật lập trình tiêu chuẩn như "thất bại nhanh" không phải lúc nào cũng thuận lợi, đặc biệt là khi quy mô nhóm phát triển.

Ví dụ: có lẽ nghệ sĩ kỹ thuật của bạn đã làm hỏng trình tạo bóng cho phác thảo nhắm mục tiêu - đã phá vỡ dự phòng, giả sử, vì vậy nó chỉ tải trên các hệ thống SM4 và anh ta đã không chú ý vì anh ta có một hệ thống hàng đầu. Điều này dẫn đến một số hình ảnh động không tải. Những hình ảnh động được tham chiếu bởi một câu thần chú cụ thể mà nhà thiết kế chiến đấu của bạn đã viết. Cuối cùng, nhà thiết kế cấp độ của bạn đang cố gắng tạo ra các sinh sản và tất cả những sinh sản đó đều có thể sử dụng câu thần chú đó - nhưng giờ cô ấy không thể đặt bất kỳ ai trong số họ lên thế giới vì phép thuật của họ không hợp lệ vì các hiệu ứng phát sinh Không hợp lệ vì các shader sẽ không tải vì các nhà thiết kế luôn có những máy tính tệ nhất.

Vì vậy, bản demo của bạn chưa sẵn sàng trước 2 giờ chiều và các nhà đầu tư của bạn tự hỏi tại sao bạn thậm chí không thể có được một kẻ thù trong trò chơi và dự án của bạn bị tắt.

Hoặc bạn chọn tùy chọn nơi bạn ghi lại thất bại nhưng tiếp tục thử và trò chơi vẫn hoạt động tốt ngoại trừ một số hiệu ứng chính tả của kẻ thù không xuất hiện - nhưng các nhà đầu tư không biết những gì được cho là trông như thế nào, vì vậy họ không để ý.

Vì lý do đó, tôi hầu như luôn luôn ủng hộ lựa chọn đầu tiên - sinh ra càng nhiều thực thể càng tốt. Có những trường hợp không nhanh - như nếu dữ liệu không bao giờ được chỉnh sửa trừ những người có khả năng thực hiện các bản dựng (tức là lập trình viên và nhà sản xuất kỹ thuật) và luôn được kiểm tra 100% khi tải hoặc nếu bạn chắc chắn là người chịu trách nhiệm vấn đề là người sử dụng trình soạn thảo - nhưng đó không phải là những trường hợp thông thường và đòi hỏi nhiều cơ sở hạ tầng kỹ thuật, mà bạn có thể chưa sẵn sàng đầu tư.


1
Tôi muốn nghĩ rằng kịch bản bạn đề xuất có thể được ngăn chặn bằng các hệ thống kiểm soát nguồn tốt. Trong kịch bản của bạn, nghệ sĩ đã "phá vỡ bản dựng". Bất cứ ai khác làm việc với trình đổ bóng bị hỏng sẽ có thể đưa trình tạo bóng trở lại bản sửa đổi trước đó cho đến khi vấn đề được giải quyết.
John McDonald

1
@John Mặc dù việc kiểm soát nguồn tốt là bắt buộc và đôi khi cần phải khôi phục phần còn lại của dự án về trạng thái làm việc cho đến khi thất bại được giải quyết cục bộ, hiếm khi nó hữu ích như một cơ chế phòng ngừa và không nên dựa vào như vậy .

@ John: Trên các dự án lớn, việc xây dựng có thể mất nhiều giờ (hoặc cả ngày). Vì vậy, bạn thực sự cần một cách tiếp cận hai hướng - bạn không chỉ cần kiểm soát nguồn, mà còn kiểm soát nhị phân, để một người không lập trình có thể quay lại toàn bộ các bản dựng trước đó. Nhưng tất nhiên, có rủi ro và chi phí riêng của mình, bởi vì bây giờ bạn đang phát triển nội dung mới chống lại khác nội dung out-of-date, với thực thi mà có thể có khác lỗi xấu. Và thậm chí việc tìm kiếm bản dựng phù hợp để quay trở lại có thể mất hơn 30 phút - nếu tất cả các nhà thiết kế của bạn phải dừng lại trong nửa giờ và miệt mài với các bản dựng, đó là khoản tiền lớn bị lãng phí.

@Joe Wreschnig: Điều đó có ý nghĩa. Vì vậy, tôi đoán rằng phải có một điểm mà thất bại nhanh không còn là tài sản. Hoặc trong các loại người sử dụng nó, hoặc trên các dự án có quy mô nhất định. Tôi cho rằng tùy thuộc vào những người trong nhóm quyết định những gì phù hợp với họ.
John McDonald

2
Tôi không chắc chắn nhanh cứng thất bại, mà thực sự là những gì các câu hỏi là về, không bao giờ là một tài sản. Ngay cả với một "đội" duy nhất, có lẽ tôi không muốn đối phó với mã shader bởi vì tôi thực sự phải hoàn thành cấp độ này. Chắc chắn viết xử lý lỗi tốt và ghi lại tất cả các lỗi, nhưng tôi hầu như luôn có một ý tưởng tốt hơn về những gì quan trọng ngay bây giờ so với khi tôi viết mã lỗi sáu tháng trước.

1

Người dùng sẽ có thể xem trước thực thể mình sẽ nhập và biết trước nếu có lỗi.

Bạn nên bằng cách nào đó quyết định những lỗi nào sẽ gây tử vong, ngăn chặn nó được thêm vào trò chơi và có thể được loại bỏ dưới dạng cảnh báo .

Tất nhiên, nếu vì bất kỳ lý do nào, thực thể nhập khẩu có thể bằng cách nào đó có thể thay đổi dữ liệu lưu trữ một cách không thể đảo ngược, bạn nên yêu cầu nó hoàn hảo hơn.


0

Tôi sẽ đề nghị rằng trong quá trình phát triển, nó sẽ ồn ào về dữ liệu không hợp lệ. tức là đăng nhập mọi thứ ở đâu đó nó sẽ được đọc. Tuy nhiên, nếu động cơ của bạn có thể bỏ qua điều này và tiếp tục thì nó nên làm như vậy. Bạn có thể có logic như

void setValue(int value) {
    if (value < MIN_VALUE) {
       log(value + " is too low, using " + MIN_VALUE);
       value = MIN_VALUE;
    }
    if (value > MAX_VALUE) {
       log(value + " is too high, using " + MAX_VALUE);
       value = MAX_VALUE;
    }
}

Ngay cả trong một trò chơi nhiều người chơi, điều này có thể chấp nhận được trừ khi bạn cho rằng một người chơi đang cố gắng gian lận hệ thống.

Sau khi phát hành phần mềm, bạn có thể muốn tắt ghi nhật ký này theo mặc định với giả định người chơi sẽ không đọc các nhật ký này.


Giả sử nhật ký không có vấn đề về hiệu năng, bạn nên tiếp tục đăng nhập vào các bản dựng phát hành và gửi báo cáo lại cho nhóm phát triển. (Tất nhiên là thông báo cho người chơi, tất nhiên.)

Bạn sẽ có thể ghi lại các bản ghi ngắn gọn hơn để phát hành. Trong sự phát triển, bạn có thể có xu hướng dài dòng hơn.
Peter Lawrey
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.