Đồng bộ hóa trò chơi nhiều người

Question

Tôi đã triển khai kiến ​​trúc máy chủ/máy khách, nơi tất cả thay đổi trạng thái được gửi đến chức năng, được xác thực và phát cho tất cả khách hàng được kết nối. Điều này hoạt động khá tốt, nhưng hệ thống không duy trì đồng bộ hóa giữa các trường hợp khách hàng của trò chơi như của bây giờ.

Nếu xảy ra trễ 5 giây giữa máy chủ và máy khách cụ thể thì anh ta sẽ nhận được thay đổi trạng thái 5 giây sau khi phần còn lại của khách hàng khiến anh không đồng bộ. Tôi đã tìm kiếm nhiều cách khác nhau để thực hiện một hệ thống đồng bộ hóa giữa các máy khách nhưng không tìm thấy nhiều cho đến nay.

Tôi mới làm quen với lập trình mạng và không quá ngây thơ khi nghĩ rằng mình có thể tự mình phát minh ra một hệ thống làm việc mà không dành nhiều thời gian cho nó. Tuy nhiên, những ý tưởng tôi đã có là giữ một số loại hệ thống thời gian, vì vậy mỗi thay đổi trạng thái sẽ được kết nối với một dấu thời gian cụ thể trong trò chơi. Bằng cách đó, khi một khách hàng nhận được một sự thay đổi trạng thái, nó sẽ biết chính xác trong đó thời gian của trò chơi thay đổi xảy ra, và lần lượt có thể tương quan với độ trễ. Vấn đề với phương pháp này là trong thời gian n giây, trò chơi sẽ tiếp tục ở phía máy khách và do đó khách hàng sẽ phải quay lại kịp thời để cập nhật thay đổi trạng thái chắc chắn sẽ lộn xộn.

Vì vậy, tôi đang tìm kiếm các bài báo thảo luận về các chủ đề hoặc thuật toán giải quyết nó. Có lẽ toàn bộ thiết kế của tôi về cách thức hoạt động của hệ thống nhiều người là thiếu sót, theo nghĩa là cá thể trò chơi của một khách hàng không nên cập nhật trừ khi nhận được khái niệm từ máy chủ? Ngay bây giờ các khách hàng chỉ cập nhật chính mình trong vòng lặp trò chơi của họ giả định rằng bất kỳ trạng thái nào không thay đổi.

Answer 1

Cách tiếp cận cơ bản cho điều này là một cái gì đó gọi là Dead Reckoning và một bài viết khá tốt đẹp về nó có thể được tìm thấy ở đây. Về cơ bản nó là một thuật toán dự đoán cho vị trí thực thể nơi sẽ được đoán tại thời gian giữa các bản cập nhật máy chủ.

Có nhiều phương pháp nâng cao hơn dựa trên khái niệm này, nhưng đó là điểm khởi đầu tốt.

---

Cũng là một mô tả về cách này được xử lý trong công cụ mã nguồn (động cơ của Valve cho các trò chơi Cuộc sống nửa đầu) có thể được tìm thấy here, nguyên tắc cơ bản là giống nhau - cho đến khi máy chủ sẽ cho bạn biết nếu không sử dụng một dự đoán thuật toán để di chuyển thực thể dọc theo đường dẫn mong đợi - nhưng bài viết này xử lý hiệu ứng này có trên cố gắng quay một thứ gì đó sâu hơn.

Answer 2

Tùy chọn tốt nhất của bạn là gửi các thay đổi lại cho khách hàng trong tương lai, từ đó đến khách hàng tại cùng một thời điểm với các khách hàng khác không gặp sự cố.

Answer 3

Các nguồn lực tốt nhất mà tôi đã tìm thấy trong lĩnh vực này là hai bài báo này từ Valve Software:

• Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization
• Source Multiplayer Networking

Answer 4

Nếu khách hàng xem các sự kiện xảy ra theo tỷ lệ máy chủ cho anh ta, đó là cách bình thường để làm điều đó (tôi đã làm việc với các giao thức của Ultima Online, KalOnline và một chút World of Warcraft), thì sự chậm trễ 5 giây này sẽ khiến anh ta nhận được 5 giây của sự kiện này l cùng một lúc và thấy những sự kiện đó thực sự trôi qua nhanh chóng hoặc gần như ngay lập tức, vì những người chơi khác sẽ thấy anh ta "đi bộ" rất nhanh trong khoảng cách ngắn nếu kết quả đầu ra của anh cũng bị chậm trễ. Sau đó tất cả mọi thứ chảy bình thường trở lại.Trên thực tế, ngoại trừ chuẩn hóa đồ họa và vật lý, tôi không thể thấy bất kỳ nhu cầu đặc biệt nào để đồng bộ hóa đúng cách, nó chỉ đồng bộ hóa chính nó.

Nếu bạn từng chơi trò chơi Valve ở hai máy tính gần bạn sẽ nhận thấy họ không quan tâm nhiều về các chi tiết nhỏ như "địa điểm chính xác nơi bạn đã chết" hoặc "nơi bạn chết cơ thể đã bay tới". Đó là tất cả lên phía khách hàng và hoàn toàn bị ảnh hưởng bởi độ trễ, nhưng điều này là không thích hợp.

Sau khi tất cả, người chơi bị trễ phải chấp nhận điều kiện của họ hoặc đóng eMule chết tiệt của họ.

Answer 5

Sẽ không bao giờ có một cách để đảm bảo đồng bộ hóa hoàn hảo trên nhiều quan điểm trong thời gian thực - các định luật vật lý làm cho nó không thể. Nếu mặt trời phát nổ, làm thế nào bạn có thể đảm bảo rằng các nhà quan sát trên Alpha Centauri thấy siêu tân tinh cùng lúc với Trái Đất? Thông tin cần có thời gian để đi du lịch. Vì vậy, lựa chọn của bạn là mô hình hóa mọi thứ chính xác với độ trễ có thể khác với người xem (bạn hiện có) hoặc lập mô hình không chính xác mà không có độ trễ và được đồng bộ hóa rộng rãi trên người xem (đó là nơi dự đoán/đã chết). reckoning/extrapolation đi vào). Trò chơi chậm hơn như chiến lược thời gian thực có xu hướng đi theo lộ trình đầu tiên, trò chơi nhanh hơn sẽ đi tuyến thứ hai.

Cụ thể, bạn không bao giờ nên giả định rằng thời gian cần để đi lại sẽ không đổi. Điều này có nghĩa rằng chỉ đơn thuần là gửi bắt đầu và dừng tin nhắn để di chuyển các thực thể sẽ không bao giờ đủ theo một trong hai mô hình. Bạn cần gửi các cập nhật định kỳ về trạng thái thực tế (thường là vài lần trong một giây cho các trò chơi nhanh hơn) để người nhận có thể sửa lỗi trong các dự đoán và nội suy của nó.