Làm cách nào tôi có thể ngăn người chơi bị trôi do dự đoán đầu vào cục bộ khi họ dừng lại?

Tôi đang làm việc trên một công cụ trò chơi nhiều người chơi máy chủ 2D (mà bạn có thể thử ở đây ). Nó sử dụng WebRTC DataChannels. (Các kết nối là ngang hàng, nhưng máy chủ ngang hàng vẫn hoạt động như một máy chủ.)

Vấn đề lớn nhất (ngoài kết nối) là dự đoán đầu vào cục bộ. Chúng tôi làm như thường lệ: Khi nhấn phím, người chơi di chuyển ngay lập tức, báo cho chủ nhà biết phím nào được nhấn, nhận lại dữ liệu từ máy chủ và so sánh với vị trí lịch sử. Vị trí được điều chỉnh theo thời gian nếu có sự khác biệt. Điều này hoạt động tốt với mất gói hoặc PDV thấp , ngay cả khi ping cao.

Nếu có mất hoặc PDV, độ lệch có thể lớn hơn. Tôi nghĩ điều này là do nếu gói đầu tiên biểu thị thay đổi đầu vào bị trì hoãn hoặc bị hủy, máy chủ sẽ phát hiện ra sau đó và bắt đầu thay đổi trình phát đó muộn hơn so với dự đoán đầu vào cục bộ của chúng.

Nếu người chơi đang di chuyển, chúng tôi sẽ tăng số lượng hiệu chỉnh được áp dụng, vì nó ít gây chú ý hơn. Điều này dường như để che lấp những khoảng trống khi bắt đầu di chuyển và trong khi di chuyển. Tuy nhiên, bất kỳ sự điều chỉnh nào cũng đáng chú ý hơn nếu chúng dừng đột ngột. Sau đó, nếu PDV hoặc mất có nghĩa là máy chủ nghĩ rằng họ dừng lại sau đó, máy chủ sẽ ghi đè, gửi lại dữ liệu nói rằng họ tiến xa hơn một chút và việc sửa lỗi khiến người chơi bị trôi đi một chút. Trên các kết nối không ổn định, người chơi thường trôi dạt đáng chú ý sau khi dừng lại.

Tôi đã không nhận thấy điều này trong các trò chơi khác. Làm thế nào điều này có thể được giảm nhẹ?

Lớp mạng cần phải có đồng hồ theo thỏa thuận. Họ có thể đồng ý với giá trị đồng hồ sớm trong trò chơi (và đồng bộ lại theo định kỳ trong trường hợp trôi dạt) để chủ nhà biết được bất kỳ gói tin cụ thể nào sẽ thực sự đến và khi khách hàng thực hiện hành động đó và ngược lại.

Xem bài viết này để biết một cách có thể để đồng bộ hóa đồng hồ trong các trò chơi. Co nhung nguoi khac. Các phương tiện cụ thể không quan trọng.

Nửa sau của vấn đề là máy chủ đang áp dụng đầu vào quá thời gian máy khách ngừng áp dụng đầu vào. Điều này đòi hỏi một bộ đệm của các chuyển động trong quá khứ trên máy chủ và một số logic trên máy khách để bỏ qua các đầu vào chuyển động từ máy chủ qua chuyển động đã biết trước.

Đầu tiên, bộ đệm máy chủ. Máy chủ cần theo dõi tem đồng hồ của đầu vào cuối cùng nhận được từ người chơi. Nó cũng cần tất cả các chuyển động nó áp dụng cho một người chơi, dấu đồng hồ của phong trào. Nếu một đầu vào được nhận, tất cả các chuyển động gần đây được áp dụng với tem đồng hồ mới hơn gói đầu vào sẽ bị loại bỏ và tất cả các chuyển động được áp dụng lại từ gói đầu vào. Do đó, nếu máy chủ di chuyển quá mức trình phát dựa trên một số đầu vào, đầu vào được cập nhật sẽ hủy bỏ các di chuyển đó và vị trí mới của người chơi sẽ dựa trên kiến ​​thức đầu vào gần đây nhất mà máy chủ có.

Về phía khách hàng, khách hàng biết khi nào lần gửi đầu vào đến máy chủ. Vì mỗi bản cập nhật người chơi từ máy chủ nên được gắn thẻ với đồng hồ của đầu vào cuối cùng mà máy chủ biết đến, khách hàng có thể bỏ qua các bản cập nhật máy chủ có thẻ đầu vào đã hết hạn và chỉ cần theo dự đoán của máy khách. Cuối cùng, các bản cập nhật máy chủ mới sẽ đến với đầu vào cập nhật và khách hàng có thể sửa lỗi đối với những cập nhật đó.

Máy chủ cần xác thực các đồng hồ đầu vào và đảm bảo rằng chúng không bị trôi quá nhiều so với mong đợi để tránh gian lận. Đồng hồ đầu vào không được lớn hơn thời gian nửa chuyến bạn nên tính. Kẹp bất kỳ cái nào vào một phạm vi hợp lý ([Now-2*RTT,Now] ví dụ).

Khách hàng sẽ thấy rất nhiều người thích ảnh đại diện của người chơi khác nếu độ trễ cao vì họ sẽ nhận được cập nhật từ máy chủ dựa trên đầu vào cũ nhưng không có cách nào để biết rằng nó cũ và sau đó máy chủ có thể bắt đầu gửi các vị trí khá khác nhau dựa trên đầu vào được cập nhật mà nó nhận được (và nó bỏ một phần lịch sử của nó và phát lại nó với đầu vào mới). Vấn đề cuối cùng này với những người chơi khác thấy jitter avatar của bạn không thực sự có thể sửa được. Độ trễ hút và các game thủ bị mắc kẹt trên các kết nối có độ trễ cao sẽ chứng kiến ​​rất nhiều sự hốt hoảng của những người chơi khác, ngay cả khi người chơi của họ đang di chuyển trơn tru. Điều chỉnh duy nhất là chơi trên các kết nối tốt hơn hoặc với các máy ngang hàng / máy chủ có độ trễ ít hơn.

Tôi đã sử dụng tin nhắn UDP đáng tin cậy để chỉ ra các thay đổi trạng thái nút và tin nhắn UDP không đáng tin cậy để điều chỉnh vị trí. Về cơ bản, các bài viết sau đã giúp tôi rất nhiều: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Nó nói về dự đoán chuyển động bằng cách lưu trữ trạng thái của người chơi trong các khoảng thời gian không đổi theo các thông báo điều chỉnh vị trí đến trong khoảng 20 hoặc 30 trạng thái lưu. Vì vậy, có vẻ như người chơi từ xa của bạn sẽ sống trong một thực tế không quá xa bằng cách liên tục áp dụng kỹ thuật dự đoán :) Dựa vào độ trễ của tin nhắn mạng, bạn có thể nhận được vị trí đối tượng của mình trong khoảng thời gian khi tin nhắn vừa được gửi từ máy chủ.

Vị trí "trên màn hình" hiện tại có thể được dịch trơn tru sang vị trí dự đoán bằng toán học Lerp (nội suy tuyến tính). Ý tưởng là nội suy các giá trị trong khoảng cách thời gian giữa các gói hiệu chỉnh. Vì vậy, có vẻ như đối tượng được hiển thị luôn di chuyển về phía một số vị trí dự đoán. Đối với giá trị nội suy, tôi lấy 1 chia cho "độ trễ tin nhắn trung bình" chia cho "thời gian kết xuất khung trung bình" để chuyển động trông mượt mà.

Trong kịch bản này, trò chơi sẽ tính toán trên tất cả các máy khách và máy chủ sửa các giá trị như vận tốc và vị trí theo thời gian.

Một điều nữa giúp ích rất nhiều trong trường hợp này: tối ưu hóa logic trò chơi của bạn để bạn có thể dễ dàng phủ nhận các hiệu ứng trễ bằng cách đảm bảo rằng máy chủ và máy khách có thể mô phỏng hành vi gần tương tự dựa trên đầu vào của người chơi.

Tôi đã mô tả toàn bộ chương trình tôi đã sử dụng trong dự án của mình vì vậy tôi hy vọng bạn sẽ tìm thấy câu trả lời cho câu hỏi của mình.