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

Sách trắng lag game › Thiết kế đồng bộ

Chỉ hiển thị sau khi server phản hồi (mô hình yêu cầu-phản hồi) Request-response (no client-side feedback)

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

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

Khi bấm nút, không có animation hay âm thanh nào cho đến khi server trả lời. Ping trở thành chính tốc độ phản hồi.

Vì sao Skill, di chuyển, nhặt đồ chỉ được phát sau khi server xác nhận → Dẫn đến Từ lúc bấm, không có phản hồi nào trong khoảng thời gian bằng thời gian khứ hồi + thời gian chờ tick → Trên màn hình Ping 150 ms thì hành động nào cũng chậm mất 0,2 giây

Triệu chứng
Trễ thao tác
Yếu tố
Độ trễ
Ai gặp phải
Chỉ mình tôi
Khi nào
Luôn luôn, Khi làm một thao tác nhất định
Phụ trách
Phụ trách chính Phát triển client (Đội phát triển game) · Phối hợp Phát triển server (Đội phát triển game)
Việc cần làm (Đội phát triển game)
Client: animation, âm thanh, hiệu ứng bắt đầu ngay khi bấm (hiển thị trước), chỉ kết quả (sát thương, phần thưởng) mới hiển thị sau khi server xác nhận, di chuyển và đòn đánh thường thì dự đoán rồi phản ánh ngay, khi nhận hiệu chỉnh vị trí từ server thì áp dụng lại các input chưa được xác nhận tính từ vị trí đó. Server: tự tính di chuyển từ input nhận được, chỉ gửi giá trị hiệu chỉnh khi chênh lệch với vị trí client dự đoán vượt ngưỡng.
Con số tham khảo
Thời gian phản hồi ≈ ping + nửa khoảng cách tick + một khung hình. 20 tick, ping 150 ms thì khoảng 190 ms.
Trên đồ thị
Luôn cao ngay từ đầu · Thời gian từ input đến khi bắt đầu hiển thị, RTT (ping)
Chỗ cần xem
Ghi vào log client của bản build dev thời điểm bấm nút, thời điểm animation hoặc âm thanh đầu tiên bắt đầu, thời điểm phản hồi server tới, rồi đặt cạnh RTT trong game. Dùng mô phỏng mạng của engine (Unreal NetEmulation.PktLag) hoặc Linux tc netem trên server thử nghiệm để thêm độ trễ, đổi ping rồi đo lại
Đúng nếu
hiển thị luôn bắt đầu đúng lúc phản hồi server tới, thời gian từ input đến hiển thị bằng khoảng RTT + thời gian chờ tick, và tăng đúng bằng độ trễ đã thêm vào
Loại trừ nếu
hiển thị bắt đầu ngay khi bấm, chỉ kết quả như số sát thương đến muộn → thiết kế bình thường. Ở nơi ping thấp mà vẫn trễ hơn một khoảng cách tick → vấn đề chờ tick hai lần hoặc khung hình phía client
Cách kiểm tra
Cần log và chỉ số của server, client game
Tìm hiểu thêm
Với các game không cần phản hồi nhanh như game theo lượt, game thẻ bài, game idle, cách này đơn giản và an toàn nhất. Vấn đề phát sinh khi game có điều khiển thời gian thực mà làm cả di chuyển lẫn đòn đánh thường theo cách này.

Nguồn

  1. Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
    Client chỉ chờ kết quả từ server thì khi độ trễ là 500 ms, mọi hành động đều phải 500 ms sau mới thấy. Giải quyết bằng dự đoán phía client và hiệu chỉnh theo server
  2. Using Gameplay Abilities in Unreal Engine Epic Games
    Local Predicted thực thi ngay khi bấm và server quyết định cuối cùng; Server Initiated không có dự đoán nên người tung skill thấy độ trễ
  3. Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
    Client dự đoán và lưu lại các bước di chuyển, chỉ hiệu chỉnh khi sai lệch với server vượt ngưỡng cho phép (MAXPOSITIONERRORSQUARED), sau khi hiệu chỉnh thì áp dụng lại các bước di chuyển đã lưu
  4. Using Network Emulation in Unreal Engine Epic Games
    Thử nghiệm bằng cách đặt độ trễ tối thiểu, tối đa và tỷ lệ mất gói cho server và client; trên console thì cấu hình như NetEmulation.PktLag
  5. tc-netem(8) — Linux manual page iproute2
    Công cụ thử nghiệm giả lập mạng thực bằng cách thêm độ trễ, jitter (delay TIME JITTER) và mất gói (loss random PERCENT) vào gói tin đi ra

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 (Trễ thao tác)

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