Không phải mọi byte đều có quyền quyết định: Tối ưu hóa hệ thống Replay trong Game Engine

Trong phát triển game, việc xây dựng một hệ thống replay (phát lại) xác định (deterministic) là một thách thức kỹ thuật thú vị. Nguyên tắc cơ bản rất đơn giản: ghi lại các đầu vào (input), chạy lại các chu kỳ xử lý (tick) tương tự và so sánh kết quả. Tuy nhiên, câu hỏi khó không phải là "làm sao để chạy lại", mà là "cái gì cần được so sánh".

Khi bắt đầu tích hợp tính năng replay cho một engine game ARPG sử dụng ngôn ngữ Zig, phản xạ đầu tiên của tôi là: "Dễ thôi, hãy băm (hash) tất cả mọi thứ".

Ban đầu, cách tiếp cận này có vẻ hợp lý. Máu của nhân vật, vị trí đạn đạo, trạng thái của bộ tạo số ngẫu nhiên (RNG) — nếu bất kỳ cái nào trong số này thay đổi, quá trình chạy có lẽ đã bị lệch hướng. Nhưng sau đó, những trường dữ liệu ít rõ ràng hơn bắt đầu xuất hiện. AI có các dấu vết (trace) giải thích lý do nó rẽ trái. Bộ kết xuất (renderer) có trạng thái nội suy từ khung hình trước. Tìm đường (pathfinding) có bộ nhớ đệm đầy hướng dẫn. Các cấu trúc dữ liệu còn chứa byte đệm (padding bytes) chỉ vì... bộ nhớ là bộ nhớ.

Nếu áp dụng checksum một cách ngây thơ cho tất cả những thứ này, hệ thống sẽ coi mọi trường dữ liệu là có ý nghĩa như nhau. Nó bắt được sự phân kỳ thực sự, nhưng cũng biến những thay đổi trong triển khai (implementation) vô hại thành các lỗi replay.

Vấn đề của việc "Băm tất cả"

Một lỗi nhỏ đã làm rõ vấn đề này. Tôi đã thay đổi một trường dữ liệu phụ trợ dùng để kiểm tra, và checksum của replay thay đổi theo. Mô phỏng vẫn hoạt động y hệt, người chơi kết thúc ở cùng một vị trí, cùng kẻ địch bị tiêu diệt. Nhưng checksum nói "Không". Replay thất bại chỉ vì dữ liệu debug có bố cục khác nhau.

Câu hỏi trở nên hẹp hơn: Trạng thái nào có thể thay đổi gameplay trong tương lai?

• Máu của người chơi: Có.
• Vị trí đạn đạo: Có.
• Luồng RNG: Có.
• Sự kiện debug: Có lẽ không, chúng chỉ là quan sát.
• Nội suy render: Không, hữu ích nhưng không phải là sự thật gameplay.
• Cache tìm đường: Có thể. Hãy lưu nó hoặc xây dựng lại nó, nhưng phải chỉ rõ điều đó.

Phân loại trạng thái: Cái gì thực sự quan trọng?

Để giải quyết vấn đề này, tôi chia trạng thái thành các nhóm cụ thể trong engine Zig:

1. Trạng thái chính thức (Authoritative gameplay state): Đây là trạng thái mà các tick tương lai có thể dựa vào để ra quyết định. Ví dụ: vị trí thực tế, máu, RNG.
2. Cache dẫn xuất (Derived caches): Dữ liệu được tính toán từ trạng thái chính thức. Nếu cache được xây dựng lại một cách xác định trước khi bất kỳ hệ thống nào đọc nó, nó không cần nằm trong bề mặt checksum của replay.
3. Đầu ra quan sát (Observation/Debug output): Các sự kiện debug, trace của AI. Chúng là kết quả của gameplay, không phải nguyên nhân.
4. Trạng thái trình bày (Presentation state): Nội suy render, hiệu ứng hình ảnh. Chúng giúp game trông đẹp nhưng không ảnh hưởng đến logic lõi.

Vòng lặp Tick và Checksum

Tính xác định vẫn đòi hỏi các công việc thông thường: kích thước tick cố định, RNG rõ ràng, thứ tự lặp ổn định. Checksum chỉ cho tôi biết liệu hai lần chạy có đến cùng một trạng thái chính thức hay không.

Hàm tick được thiết kế với các giai đoạn rõ ràng: idle -> ingress -> control -> derive -> plan -> apply -> cleanup -> idle. Điều này tạo ra một điểm kiểm tra cụ thể để đo lường. Nếu một hàng đợi (queue) rò rỉ giữa các giai đoạn hoặc một hệ thống thay đổi trạng thái sai giai đoạn, việc gỡ lỗi sẽ trở nên khó khăn hơn rất nhiều.

Replay so với Snapshot

Replay và Save/Load (Snapshot) trả lời các câu hỏi khác nhau.

• Replay hỏi: Nếu tôi bắt đầu lại từ cùng một hạt giống (seed) và đầu vào, tôi có đến cùng một trạng thái chính thức không?
• Snapshot hỏi: Tôi có thể đóng băng thế giới này, ghi ra byte, khôi phục lại và tiếp tục không?

Chúng chồng lên nhau nhưng không giống nhau. Một checksum replay có thể bỏ qua một cache nếu cache đó được xây dựng lại xác định trước khi sử dụng. Tuy nhiên, một snapshot có thể vẫn cần lưu cache đó vì việc khôi phục nó rẻ hơn hoặc hữu ích cho việc debug. Việc lưu một trường không tự động biến nó thành quyền hạn replay.

Kết luận: Hạn chế nơi ẩn nấp của lỗi

Khi trạng thái mới xuất hiện, tôi sử dụng danh sách kiểm tra sau:

1. Trạng thái này có thể thay đổi gameplay trong tương lai không? Có -> Quyền hạn replay/checksum.
2. Nó có cần thiết để khôi phục và tiếp tục đúng không? Có -> Bề mặt snapshot.
3. Nó có phải là quan sát của gameplay đã cam kết không? Có -> Bề mặt sự kiện/debug/kiểm tra.
4. Nó chỉ là trình bày không? Có -> Trạng thái render/app.

Mục tiêu thiết kế khiêm tốn nhưng mạnh mẽ: các trường debug không nên phá vỡ replay, cache không nên tồn tại như nguồn ẩn của gameplay, và render không nên trở thành logic chiến đấu.

Không phải mọi byte đều có quyền quyết định. Bằng cách giới hạn những gì được coi là "bằng chứng" cho replay, chúng ta thu hẹp khu vực tìm kiếm khi có lỗi xảy ra, giúp quá trình phát triển engine game trở nên ổn định và hiệu quả hơn.