Tại sao một số trò chơi nối mạng sử dụng phép nội suy và một số sử dụng tính năng tìm đường cho chuyển động từ xa?

Đây là một chút của một câu hỏi mở nhưng tôi muốn thấy ai đó đóng góp một lý do tốt cho cả hai.

Để có một ví dụ nhanh về cả hai:

Mô hình nội suy

Hãy suy nghĩ mô hình Valve nơi khách hàng nhận được cập nhật vị trí thường xuyên và điều khiển từ xa cập nhật vị trí của họ bằng cách sử dụng phép nội suy trên dữ liệu này.

Tìm đường

Trong mô hình này, hãy nghĩ rằng người dùng sẽ gửi đích đến và mọi người tìm đường đến đó.

Những loại trò chơi phù hợp với từng loại và khi nào nên sử dụng mỗi loại?

Tôi đã làm việc về mã mạng cho hai trò chơi nối mạng AAA thời gian thực, một cho điện thoại thông minh và một cho bảng điều khiển cầm tay.

Để trả lời trực tiếp câu hỏi của bạn "tại sao", tốt, một số trò chơi sử dụng cái này hay cái kia bởi vì nó phù hợp với chúng hơn cái kia. Điều này không chỉ phụ thuộc vào loại trò chơi mà còn phụ thuộc vào loại mạng mà chúng ta đang nói đến (tủ arcade được liên kết có các điều kiện khác nhau so với các trò chơi được chơi qua 3G) Một số trò chơi thực sự sử dụng cả hai hoặc thậm chí hoàn toàn cách tiếp cận khác nhau để đồng bộ hóa dữ liệu!

Tôi muốn khái quát hóa và xem xét không chỉ dữ liệu vị trí, mà hầu như bất kỳ loại dữ liệu nào bạn có thể đồng bộ hóa giữa hai máy khách được nối mạng.

Thay vì hai khả năng, tôi muốn đề xuất một phổ giữa các bản cập nhật cứng và mềm.

• Các bản cập nhật rất khó là các sự kiện riêng biệt ngay lập tức thay đổi trạng thái trên máy khách khác, không có bất kỳ loại nội suy nào, vì dữ liệu có tính chất quan trọng (người chơi đã chết), vì đó không phải là loại dữ liệu áp dụng phép nội suy (trực tuyến trò chơi cờ vua, tin nhắn trò chuyện, v.v.) hoặc do mạng của bạn cho phép bạn làm điều đó (nghĩ rằng các tủ trò chơi được liên kết trong đó đáng tin cậy gửi toàn bộ trạng thái trò chơi 60 lần mỗi giây cũng nằm trong khả năng).

  Với phương pháp này, độ trễ của mạng sẽ luôn hiển thị dưới dạng cập nhật bị trì hoãn và biểu hiện khi các ký tự nhảy xung quanh.

• Khó với các bản cập nhật liên / ngoại suy tương tự như các bản cập nhật rất khó, nhưng đối với dữ liệu liên tục thay đổi, mà thực tế không thể gửi dữ liệu một cách đáng tin cậy mỗi khi nó thay đổi. Hãy nghĩ đến việc gửi một vị trí và một vectơ vận tốc; bạn sẽ có thể nội suy dữ liệu giữa hai điểm và ngoại suy dữ liệu đó sau chúng. Bạn nên có kế hoạch dự phòng nếu dữ liệu đến không đồng ý với phép ngoại suy của bạn. Tôi muốn nói rằng hầu hết các trò chơi yêu cầu cập nhật vị trí đều sử dụng phương pháp này.

• Cứng với các bản cập nhật đồng bộ hóa tương tự như cứng với phép ngoại suy / ngoại suy, nhưng chỉ yêu cầu hiếm khi đồng bộ hóa. Bạn nên sử dụng dữ liệu này cho dữ liệu thực sự tầm thường để ngoại suy / ngoại suy, chẳng hạn như đồng hồ trong trò chơi chiến đấu (một khi được đặt ở cả hai bên, không thực sự cần thiết phải đồng bộ hóa lại sau đó)

• Các bản cập nhật cứng bị trì hoãn tương tự như các bản cập nhật cứng, nhưng những gì bạn đang thấy là dữ liệu trong quá khứ. Tôi nghi ngờ rằng trong nhiều trò chơi arcade âm nhạc ở Nhật Bản nơi bạn có thể chơi một bài hát với người khác, bạn thực sự đang chơi với dữ liệu người chơi được ghi lại trong quá khứ, có thể là vài giờ hoặc thậm chí vài ngày trước đó. Tất nhiên, loại cập nhật này chỉ có thể sử dụng được khi bạn không thực sự tương tác với người chơi khác.

• Cập nhật mềm bao gồm gửi dữ liệu lập kế hoạch và chạy kế hoạch trên tất cả các máy chủ. Đây là những gì bạn gọi là "tìm đường". Lượng dữ liệu cần thiết để đồng bộ hóa dữ liệu như thế này thấp hơn nhiều; bạn có thể sử dụng các loại cập nhật này khi bạn có thể thoát khỏi những khác biệt nhất định về cách dữ liệu được trình bày cho người dùng, như khi đồng bộ hóa hàng trăm kẻ thù.

  Bản thân việc lập kế hoạch cập nhật dữ liệu cũng có thể cứng / mềm như bạn muốn.

• Các cập nhật rất mềm được sử dụng khi kết quả của một hành động có thể được tính toán đáng tin cậy trước khi nó xảy ra. Bạn chỉ cần gửi kết quả, và khách hàng khác chỉ phát lại. Ví dụ: một số trò chơi trên trình duyệt và điện thoại thông minh cho phép bạn chiến đấu với người khác, nhưng trận chiến thực sự cần nhiều giờ để giải quyết (nghĩ các trò chơi giống Travian). Rất có thể các trò chơi này tính toán kết quả tại thời điểm trận chiến được bắt đầu và bạn chỉ cần xem kết quả của trận chiến đó.

  Một ví dụ không nối mạng khác về điều này sẽ là trong Civilization 4 với hoạt hình chiến đấu được kích hoạt. Khi bạn tấn công ai đó, kết quả của trận chiến sẽ được tính toán ngay lập tức, nhưng bạn có thể thấy một hình ảnh động của nó đang phát lại. Tôi có thể đảm bảo với bạn rằng trận chiến không được tính toán vì nó đang được làm hoạt hình.

Như bạn có thể thấy, có nhiều cách để đồng bộ hóa dữ liệu và tôi chắc chắn bạn có thể tưởng tượng ra nhiều cách khác. Tất cả các trò chơi trực tuyến đơn giản nhất rất có thể sẽ sử dụng hỗn hợp các phương pháp này, tùy thuộc vào loại dữ liệu họ đang đồng bộ hóa, loại trò chơi và thậm chí trạng thái của mạng (sử dụng các bản cập nhật cứng khi độ trễ thấp và đi để cập nhật nhẹ nhàng hơn khi độ trễ tăng cao hơn).

Tôi không có cái nhìn sâu sắc về quá trình phát triển của Valve, vì vậy đây hoàn toàn là ý kiến ​​của tôi, nhưng:

Nội suy : Tôi muốn nói rằng sẽ tốt hơn cho các trò chơi có nhịp độ nhanh, chẳng hạn như FPS, trong đó việc có một vị trí nhất quán cho kẻ thù đúng giờ đối với người chơi là rất quan trọng. Nội suy có nghĩa là, ngay cả khi một số gói bị loại bỏ (AFAIK, hầu hết các FPS nhiều người sử dụng UDP thay vì TCP / IP, đảm bảo cả tính toàn vẹn cũng như thứ tự các gói đến), bạn sẽ có chuyển động mượt mà trên màn hình.

Tìm đường dẫn : Nếu thời gian không phải là yếu tố quan trọng trong lối chơi của bạn và thuật toán của bạn tìm thấy một đường dẫn nhất quán khi chạy lại, thì việc tìm đường có thể thú vị bởi vì nó không yêu cầu bạn gửi thường xuyên và do đó cập nhật nặng với vị trí của từng đơn thực thể. Tôi muốn nói rằng điều này dường như được trang bị cho một hệ thống theo lượt chẳng hạn, trong đó bạn có thể giới hạn số lượng yêu cầu mạng (một ở đầu lượt, một khi hết lượt để đảm bảo tất cả các máy khách đều ở trạng thái "lành mạnh" " tiểu bang.

Một lần nữa, tôi chưa bao giờ làm việc trên một trò chơi mạng hoặc cho một studio trò chơi lớn, nhưng từ những gì tôi đã đọc đôi khi đó là cách tôi sẽ làm về nó :)

Panda Pajama trả lời là khá tốt.

Về cơ bản, câu hỏi đặt ra là lượng dữ liệu tối thiểu bạn có thể gửi sẽ đưa nhiều khách hàng vào cùng một nhận thức về trạng thái của nhau và làm thế nào để bạn xử lý độ trễ trong đó các máy khách bị trễ có thể ở trạng thái khác.

Vì vậy, thủ tục được tạo ra, trong đó tất cả các tương tác được biết trước là dễ dàng nhất, vì nếu tất cả các biến được biết thì kết quả được biết đến. Ví dụ, cách ly một người nào đó trong phòng, rằng bạn biết các phương pháp xử lý và đưa cho anh ta một số dữ liệu, bạn có thể dự đoán chính xác kết quả. Do đó, bạn có thể cung cấp cho mọi khách hàng khác kết quả mà không cần phải đợi khách hàng đó hoàn thành tính toán của mình.

Tuy nhiên, ông không đề cập đến một phương pháp. Kết quả cưỡng bức.

Nếu hệ thống mong đợi một hành động của một thực thể và các hành động khác phụ thuộc vào hành động đó và các tính toán khác sẽ tính đến hành động đó và đã được xử lý trước với kết quả đó được mong đợi. Sau đó, để duy trì đồng bộ hóa, toàn bộ hệ thống bị dừng trong khi một thực thể không ở đúng vị trí được đặt lại chính xác trên đường dẫn của anh ta.

Một ví dụ trong thế giới thực là tất cả các thực thể khác trong mô hình nắm giữ để đảm bảo rằng khoản bồi thường thích hợp được gửi cho tôi.