한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

Tần suất gửi snapshot thấp Low snapshot / update rate

ID nguyên nhân sy-low-send-rate · Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Phát triển client (Đội phát triển game)

Mở thẻ gốc có hình minh họa và thí nghiệm →

Nếu server chỉ gửi bản cập nhật vị trí (snapshot) vài lần trong 1 giây, bộ đệm nội suy phải đặt dài tương ứng, nên bạn thấy các nhân vật khác ở quá khứ xa hơn.

Vì sao Để tiết kiệm lưu lượng, chỉ gửi bản cập nhật vị trí 5–10 lần trong 1 giây → Dẫn đến Muốn vẽ mượt thì bộ đệm phải bằng 2 lần khoảng cách gói (200–400 ms), đặt ngắn thì chỉ lỡ một gói là đối tượng khựng lại → Trên màn hình Thấy đối thủ đổi hướng muộn và lệch với phán định. Bộ đệm ngắn thì giật khựng, khi mất gói thì dịch chuyển tức thời

Triệu chứng: Giật khựng, Dịch chuyển tức thời, Nuốt thao tác·rollback
Yếu tố: Độ trễ, Mất gói
Ai gặp phải: Cả server
Khi nào: Luôn luôn
Phụ trách: Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Phát triển client (Đội phát triển game)
Việc cần làm (Đội phát triển game): Server: đối tượng ở gần hoặc đang chiến đấu thì gửi thường xuyên, đối tượng ở xa thì gửi thưa, chỉ gửi phần thay đổi (nén delta) để giảm kích thước mỗi lần gửi và tăng tần suất. Client: tự động điều chỉnh độ dài bộ đệm nội suy theo khoảng cách gói.
Con số tham khảo: 10 lần trong 1 giây thì khoảng cách gói 100 ms, bộ đệm 200 ms. Cộng thêm độ trễ một chiều 75 ms của ping 150 ms thì bạn thấy đối thủ ở quá khứ khoảng 0,3 giây.
Trên đồ thị: Luôn cao ngay từ đầu · Khoảng cách gói tin tới theo client, độ dài bộ đệm nội suy
Chỗ cần xem: Trong bản bắt gói phía server, lọc riêng luồng gửi tới một người chơi rồi dùng I/O Graphs của Wireshark để xem số gói mỗi giây và khoảng cách giữa các gói. Nếu có log phía game: xem cùng khoảng cách cập nhật theo đối tượng và phần dư của bộ đệm nội suy phía client (thời gian còn lại đến khi snapshot tiếp theo tới)
Đúng nếu: bản cập nhật vị trí luôn thưa, 5–10 lần mỗi giây (khoảng cách 100–200 ms), và bộ đệm nội suy được đặt trên 200 ms hoặc phần dư của bộ đệm thường xuyên về 0
Loại trừ nếu: bản cập nhật được gửi dày mà chỉ khoảng cách tới dao động → xem jitter, mất gói. Khi đông người chỉ nhận thưa các đối tượng ở xa → ngân sách gửi và mức ưu tiên theo kết nối
Cách kiểm tra: Kiểm tra bằng công cụ hạ tầng (không cần code game)

Nguồn

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
Cập nhật 10 lần mỗi giây thì nội suy 200 ms chịu được một lần mất gói. Mặc định của Half-Life là 20 lần mỗi giây, nội suy 100 ms
Snapshot Interpolation Gaffer On Games
10 gói mỗi giây thì cần độ trễ 350 ms để chịu được mất 2 gói liên tiếp, 30 gói mỗi giây thì giảm còn 150 ms
State Synchronization Gaffer On Games
Dùng mức ưu tiên tích lũy để gửi các đối tượng quan trọng thường xuyên hơn, và gửi luân phiên các đối tượng còn lại trong giới hạn băng thông
8.8. The “I/O Graphs” Window Wireshark
Vẽ số gói và số byte khớp với bộ lọc hiển thị (display filter) thành đồ thị theo từng khoảng thời gian

Nguyên nhân nên xem cùng

Cùng tầng: Thiết kế đồng bộ

Nguyên nhân ở tầng khác gây cùng triệu chứng (Giật khựng)

Frame time vọt lên L1 Tiến trình game phía client
Thu gom rác (GC) phía client L1 Tiến trình game phía client
Tải đồng bộ trên main thread và biên dịch shader L1 Tiến trình game phía client
Ổ lưu trữ chậm khiến streaming asset không theo kịp L1 Tiến trình game phía client
Tải render khi đông người L1 Tiến trình game phía client
Bộ đệm nội suy không có hoặc quá ngắn L1 Tiến trình game phía client
Ngoại suy quá mức (dead reckoning) L1 Tiến trình game phía client
Fixed timestep chạy bù mất kiểm soát L1 Tiến trình game phía client

Xem thẻ gốc có hình minh họa và thí nghiệm