Gửi khác biệt trạng thái (deltas) và kết nối không đáng tin cậy


8

Chúng tôi đang xây dựng một trò chơi nhiều người chơi trong thời gian thực, trong đó mỗi người chơi chịu trách nhiệm báo cáo trạng thái của nó trên mỗi lần lặp của vòng lặp trò chơi.

Các cập nhật trạng thái được phát bằng UDP không đáng tin cậy .

Để giảm thiểu việc gửi dữ liệu trạng thái, chúng tôi đã đưa ra một hệ thống sẽ chỉ gửi deltas (bất kỳ dữ liệu trạng thái nào đã được thay đổi).

Tuy nhiên, phương pháp này còn thiếu sót, vì một gói bị mất sẽ có nghĩa là những người chơi khác sẽ không nhận được delta, khiến trò chơi hoạt động theo cách không mong muốn.

Ví dụ:

Giả sử trạng thái đó bao gồm: {vị tríX, vị trí, sức khỏe}

Frame 1  - positionX changed --> send a packet with positionX only.
Frame 2 - health changed // lost !
Frame 3 - positionY changed --> send a packet with positionY only.

// Người chơi khác không biết về thay đổi sức khỏe.

Làm thế nào một người có thể khắc phục vấn đề này sau đó? gửi toàn bộ dữ liệu không phải lúc nào cũng khả thi.

Câu trả lời:


7

Mặc dù bạn đang gửi dữ liệu bằng UDP, bạn vẫn sẽ cần phải thêm vào dạng tin cậy của riêng mình để xử lý các tình huống như thế này. UDP chỉ mang đến cho bạn sự linh hoạt để thực hiện những gì bạn muốn, thay vì xử lý định dạng truyền thông TCP đáng tin cậy nhưng kém linh hoạt. Tin nhắn xác nhận hoặc gói xác nhận nên được sử dụng khi nhận thông tin là cần thiết, nếu không, khách hàng của bạn không có cách nào để biết liệu dữ liệu mà nó gửi có cần phải được gửi lại hay không. Chẳng hạn, nếu bạn gửi thông tin quan trọng và không thấy phản hồi trong một khoảng thời gian xác định xác nhận việc nhận dữ liệu đó, hãy gửi lại.


2
Đánh tôi với nó Tuy nhiên, cần lưu ý rằng các giá trị khá biến động, như vị trí và dữ liệu vật lý khác, không cần phải được đảm bảo. Ngay cả trong trường hợp không may là nó sai trên một khung nhất định, nó sẽ được sửa trong mọi khung hình tiếp theo.
jmegaffin

1
Điểm hay, điều này được thấy thường xuyên nhất trong các trò chơi khi đột nhiên một nhân vật di chuyển đến một vị trí mới rất nhanh (hoặc dịch chuyển tức thời tất cả cùng nhau). Hầu hết các trò chơi xử lý nó theo một vài cách khác nhau, nhưng mục tiêu là như nhau. Máy chủ chỉ cần cập nhật vị trí thực thể và khách hàng của bạn sẽ cập nhật ngay lập tức hoặc cập nhật vị trí đó với thời gian delta rất cao qua một vài khung hình.
Evan

3

Bạn cũng có thể giải quyết vấn đề bằng cách gửi cập nhật trạng thái đầy đủ từ máy chủ đến máy khách, nói mỗi giây. Nếu một khách hàng không nhận được một gói, nó sẽ hoạt động không chính xác cho đến khi nhận được cập nhật trạng thái đầy đủ. Sau đó, nó sẽ được đồng bộ một lần nữa.


3

Nhiều trò chơi sử dụng cả UDP và TCP / IP để gửi / nhận dữ liệu và tùy thuộc vào tần suất dữ liệu được gửi, giao thức khác nhau được sử dụng.

Ví dụ:

UDP: cập nhật vị trí và bất kỳ thứ gì khác có khả năng có thể được gửi / nhận nhiều lần trong một giây.

TCP / IP: hành động kiểm kê, hành động chính tả / khả năng, (hầu hết các hành động do người dùng thực hiện)

Nó thực sự phụ thuộc vào số lượng lưu lượng của từng mục. Nếu bạn thấy bạn đang gửi các bản cập nhật HP khá thường xuyên thì có lẽ chúng cần phải có trên UDP.


1
TCP thường không được sử dụng cho bất cứ điều gì đòi hỏi độ chính xác theo thời gian thực vì khả năng gây ra độ trễ lớn.
TheNickmaster21

Thật tốt nếu bạn muốn đảm bảo rằng gói của bạn đến đó. Những thứ như cập nhật vị trí không tốt cho điều đó nhưng nếu bạn muốn chắc chắn rằng người dùng của bạn đã nhấn nút vào một thời điểm cụ thể TCP xử lý tất cả các kiểm tra lỗi và những thứ khác mà bạn sẽ phải thực hiện cho UDP để tránh mất gói.
UnderscoreZero

Điểm hợp lệ; Tôi chỉ muốn sửa đổi UDP.
TheNickmaster21

1

Nếu bạn đọc bài đánh giá mã nguồn Quake 3 , anh ta giải thích mô hình mạng rất giống với thiết kế của bạn, nhưng với một giải pháp cho các gói bị bỏ.

Về cơ bản, trong mô hình của bạn, bạn đang gửi deltas chống lại trạng thái trực tiếp trước đó. Trong mô hình quake3, bạn gửi deltas chống lại trạng thái xác nhận cuối cùng từ bạn bè.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.