Phát lại hệ thống: ghi lại đầu vào hoặc sự kiện?

Tôi đọc điều này: Làm thế nào để thiết kế một hệ thống phát lại Nhưng nó không thực sự trả lời câu hỏi của tôi.

Trò chơi của tôi được xây dựng với ứng dụng khách "xem" trò chơi dưới dạng một chương trình riêng biệt với "mô hình" và "bộ điều khiển" của máy chủ. (hơi giống với mmo, hoặc bất kỳ trò chơi nhiều người chơi nào được xây dựng theo cách này). Phía máy chủ luôn là "sự thật" của trò chơi, nó chỉ chấp nhận các yêu cầu hành động như đầu vào từ máy khách và các sự kiện đầu ra và thông báo "trạng thái hiện tại".

Mô hình và quy tắc trò chơi hoàn toàn xác định với chu kỳ cập nhật "đánh dấu" cố định, vì vậy về phía máy chủ tôi có thể ghi lại cả các sự kiện được gửi đến chế độ xem của khách hàng và các yêu cầu hành động. Cả hai đều được liên kết với số chu kỳ cụ thể.

Câu hỏi là: trong trường hợp này, để thiết lập hệ thống phát lại, tôi nên sử dụng đầu vào hoặc yêu cầu hành động của người dùng (như được đề xuất trong đó) hoặc các sự kiện?

Theo tôi, cả hai sẽ cho cùng một đầu ra. Sự khác biệt duy nhất tôi có thể thấy là:

• Sự kiện cho đầu ra thực trong khi các yêu cầu hành động phải được xử lý để đưa ra sự kiện.
• Yêu cầu hành động có thể là dữ liệu ít hơn nhiều để ghi lại.

Có những thứ khác để xem xét?

Với một hệ thống xác định, chúng tương đương về mặt logic nên tóm tắt của bạn khá chính xác. Tuy nhiên, có 2 điều nữa sẽ khiến tôi phải ghi lại các hành động đầu vào thay vì các sự kiện đầu ra:

1. Nếu bạn lưu các hành động, bạn có thể sử dụng chúng làm dữ liệu thử nghiệm sau này, vì chúng thực hiện nhiều mã của bạn hơn là chỉ phát lại các sự kiện. Điều này có thể giúp chẩn đoán lỗi sự cố, tìm hồi quy hành vi giữa các bản dựng, v.v.
2. Trong tương lai, bạn có thể thay đổi các sự kiện mà bạn gửi cho một hành động nhất định hoặc bạn có thể gửi các sự kiện khác nhau cho các khách hàng khác nhau vì một số lý do. Trong trường hợp này, phát lại có thể trở nên không hợp lệ hoặc không đầy đủ. Về mặt lý thuyết, vấn đề tương tự có thể áp dụng cho đầu vào, nhưng thông thường, miền đầu vào bị ràng buộc nhiều hơn đầu ra và do đó ít có khả năng thay đổi và dễ dàng phù hợp với khả năng tương thích ngược khi thực hiện. (Đầu vào được giới hạn ở những gì người chơi và các nguồn đầu vào khác (ví dụ: trình tạo số ngẫu nhiên) có thể làm, trong khi đầu ra bao gồm tất cả kết quả của các đầu vào đó cộng với bất kỳ đầu ra nào khác được tạo bởi quy tắc trò chơi, như gợi ý trình bày, máy chủ định kỳ- sự kiện bên lề, v.v.)

Hoặc là hoạt động, mặc dù có một vài điều cần xem xét.

Đầu tiên, hãy nhớ rằng bạn cần ghi lại thông tin thời gian. Đối với các trò chơi có bất kỳ loại tốc độ khung hình thay đổi, điều này có thể đặc biệt khó khăn; bạn cần đảm bảo dữ liệu phát lại của mình có thể cung cấp thông tin chính xác về thời gian mà trò chơi ban đầu được sử dụng để mô phỏng.

Bạn cũng cần tính đến các chỉnh sửa cho hành vi của trò chơi. Nếu bạn ghi lại đầu vào và sau đó điều chỉnh bất kỳ phần nào về cách xử lý đầu vào, cách xử lý vật lý, v.v., bản ghi của bạn trở nên không hợp lệ. Ngay cả khi bạn ghi lại các sự kiện trong trò chơi, nếu bất kỳ phần nào trong số các sự kiện đó được thay đổi diễn giải, bạn vẫn bị mắc kẹt.

Nếu bạn chỉ muốn phát lại, một cách tiếp cận tốt là ghi lại một danh sách cụ thể các vị trí và góc quay cho thực thể người chơi cùng với thông tin về thời gian. Vô hiệu hóa càng nhiều vật lý và logic trò chơi khác trong khi chạy phát lại như bạn có thể. Việc này dễ dàng hay khả thi như thế nào tùy thuộc vào số lượng đối tượng khác bạn cần đồng bộ hóa.