Bù lại với các trò chơi 2D nối mạng


31

Tôi muốn tạo ra một trò chơi 2D về cơ bản là một trò chơi hoạt động / hộp cát điều khiển vật lý. Có một cái gì đó tôi thực sự không hiểu mặc dù. Từ nghiên cứu, có vẻ như các bản cập nhật từ máy chủ chỉ nên trong khoảng 100ms. Tôi có thể thấy cách thức hoạt động của một người chơi vì họ có thể mô phỏng đồng thời vật lý và bù độ trễ thông qua phép nội suy.

Những gì tôi không hiểu là làm thế nào điều này hoạt động để cập nhật từ những người chơi khác. Nếu khách hàng chỉ được thông báo về vị trí người chơi cứ sau 100ms, tôi không thấy điều đó hoạt động như thế nào vì rất nhiều điều có thể xảy ra trong 100ms. Người chơi có thể đã thay đổi hướng hai lần hoặc lâu hơn trong thời gian đó. Tôi đã tự hỏi nếu có ai có một cái nhìn sâu sắc về vấn đề này.

Về cơ bản làm thế nào để nó hoạt động để chụp và những thứ như vậy?

Cảm ơn

Câu trả lời:


58

Tóm tắt cho những người không thích câu trả lời dài ...

Nó có thể được thực hiện nhưng không thể thực hiện vật lý nhiều người chơi hoàn hảo nếu có bất kỳ độ trễ nào. Tại sao độ trễ ảnh hưởng đến vật lý được giải thích, và sau đó các mẹo để giảm tác động của độ trễ đối với mô phỏng vật lý của bạn được đưa ra.


Tạo một trò chơi vật lý nhiều người chơi có thể đầy nguy hiểm. Không thể tạo ra trải nghiệm vật lý trực tuyến nhiều người chơi "hoàn hảo". Có những điều bạn có thể làm để làm cho nó tốt hơn, nhưng không có cách nào để làm cho vật lý hoàn hảo giả định bất kỳ độ trễ nào.

Vấn đề là, vật lý phải nhanh và nhạy để trở thành hiện thực, nhưng đồng thời phải được tính toán dựa trên các hành động kết hợp của TẤT CẢ các yếu tố - nghĩa là hành động kết hợp của tất cả người chơi. Và nếu có độ trễ, điều này không thể được thực hiện trong thời gian thực.

Với tư cách là nhà phát triển, bạn phải quyết định xem bạn có thể kiểm soát các yếu tố khác nhau hay không và để hiểu rằng trải nghiệm của người chơi sẽ giảm nếu độ trễ trở nên quá cao. Nếu bạn có thể sống với điều đó (và người chơi của bạn có thể), thì hãy tiếp tục. Xem đến cuối bài này để biết một số lưu ý về cách bạn có thể giữ mọi thứ chạy trơn tru hơn.

Một ví dụ để cho thấy mọi thứ có thể bị rối tung như thế nào

Hãy tưởng tượng một trò chơi trong đó hai người chơi (khách hàng) được kết nối với một máy chủ. Phải mất 100 mili giây (1/10 giây) để một tin nhắn đi qua internet từ máy khách đến máy chủ. Khi người chơi làm điều gì đó, một tin nhắn được gửi đến máy chủ cho biết họ đã làm gì. Sau đó, máy chủ sẽ phát thông báo cho những người chơi khác để tất cả họ biết người chơi diễn xuất đã làm gì.

Bây giờ tạo một kịch bản trong đó hai người chơi có một cái thùng trên mặt đất là một vật thể. Người chơi A đánh nó về một phía, khiến nó di chuyển theo một hướng nào đó. Tuy nhiên, cùng lúc đó, người chơi B đánh nó sang một mặt khác, gửi nó theo hướng khác.

Hãy xem xét các cách khác nhau để xử lý vấn đề này và kết quả sẽ như thế nào ...

Điều gì nếu vật lý được tính toán chỉ trên máy chủ?

Giả sử chúng ta có tính toán vật lý chỉ trên máy chủ. Người chơi A gửi tin nhắn "Tôi nhấn thùng theo cách này" đến máy chủ, 1/10 giây sau đó máy chủ nhận được tin nhắn. Người chơi B gửi tin nhắn "Tôi nhấn thùng theo cách khác" của họ. Máy chủ tính toán sự thay đổi vật lý từ sự kết hợp của hai hành động và gửi tin nhắn lại cho cả hai người chơi nói, "OK nó di chuyển như thế này." Vật lý hoàn hảo được thực hiện, dựa trên hành động của cả hai người chơi kết hợp.

Nhưng vấn đề là, nó sẽ là 2/10 giây trước khi một trong hai người chơi thấy thùng phản ứng. Các tin nhắn từ cả hai người chơi mất 1/10 giây để đến máy chủ, sau đó 1/10 giây để kết quả tính toán của máy chủ được gửi cho cả hai người chơi.

Điểm mấu chốt, lối chơi lag.

Điều gì xảy ra nếu vật lý chỉ được tính trên máy khách?

Giả sử chúng ta có tính toán vật lý chỉ trên máy khách. Chúng ta hãy nhìn nó từ quan điểm của Người chơi A. Người chơi A đánh thùng và nó ngay lập tức bắt đầu đi theo hướng của họ. Một tin nhắn cũng được gửi đến máy chủ cho biết Người chơi A đã làm gì.

Tuy nhiên, cùng lúc đó, B đã thực hiện cú đánh của họ và thấy cái thùng đi theo hướng của họ và gửi một thông điệp tới máy chủ về những gì họ đã làm.

2/10 giây sau, một tin nhắn đến từ máy chủ đến máy khách. A được cho biết những gì B đã làm, và B được cho biết những gì A đã làm. Vấn đề là, cả hai khách hàng đều nói, "Người chơi X có thể đã thực hiện cú đánh đó tại điểm này, nhưng không còn một cái thùng nào ở vị trí đó nữa, vì vậy cú đánh của họ không làm gì cả."

Điểm mấu chốt là, hai trò chơi không đồng bộ và người chơi không có trải nghiệm chia sẻ. Điểm của nhiều người chơi là gì nếu cả hai đều nhìn thấy những thứ khác nhau?

Điều gì xảy ra nếu tính toán vật lý trên cả máy khách và máy chủ?

Trong trường hợp này, vật lý được tính toán trên máy khách để người chơi thấy phản ứng không có độ trễ ngay lập tức, nhưng nó cũng được tính toán trên máy chủ để nó "chính xác" cho tất cả người chơi.

Cả hai người chơi đánh vào thùng theo hướng tương ứng của họ và mỗi người chỉ nhìn thấy di chuyển thùng chỉ dựa vào cú đánh của họ. Nhưng sau đó 2/10 giây, máy chủ quay lại và nói, "Thực ra, cả hai bạn đều sai. Thùng đã đi theo hướng này." Đột nhiên cả hai người chơi nhìn thấy cái thùng thay đổi hướng mạnh mẽ và chuyển sang một vị trí mới.

Điểm mấu chốt là, một trò chơi rối mắt.

Phần kết luận

Về cơ bản không có cách nào để tạo ra một trò chơi vật lý hoàn hảo với nhiều người chơi khi có bất kỳ loại độ trễ nào tồn tại. Bạn có thể tạo ra một trò chơi khá hay, nhưng bạn sẽ luôn có nguy cơ độ trễ quá mức tạo ra trải nghiệm xấu cho một số người chơi. Tuy nhiên, có những điều bạn có thể làm để giữ cho trải nghiệm trò chơi của bạn tốt.

Những điều bạn có thể làm để làm cho trò chơi nhiều người chơi chạy tốt

Sử dụng khối lượng va chạm đơn giản. Đừng bận tâm mô hình hóa từng chi tiết của hình dạng với vật lý khi hình dạng khối đơn giản sẽ làm. Một quả bóng nhọn không cần phải được mô phỏng như một quả bóng nhọn cho vật lý. Thay vào đó chỉ mô hình nó như một hình cầu.

Làm cho các đối tượng không quan trọng nhỏ các mục chỉ dành cho khách hàng. Một ví dụ có thể là các mảnh kính vỡ từ cửa sổ bị vỡ. Bạn có thể để mỗi khách hàng tự mô phỏng nó và họ sẽ không thực sự quan trọng nếu họ khác nhau.

Chỉ tạo các đối tượng vật lý đối tượng nếu chúng cần là đối tượng vật lý để giữ cho số lượng đối tượng vật lý hoạt động thấp.

Chạy trò chơi của bạn trong chuyển động chậm khi làm vật lý nhiều người chơi. Hãy nghĩ "thời gian đạn" có thể. Trò chơi chuyển động chậm bù cho độ trễ và cho phép nhiều người chơi tương tác với vật lý cùng nhau.

Cho phép người chơi thiết lập một tình huống nào đó cùng nhau, và sau đó trên một số gợi ý, vật lý được mô phỏng cho cả người chơi và cả hai xem kết quả của các hành động kết hợp của họ. Người chơi có thể không can thiệp vào chuỗi cho đến khi nó được hoàn thành.

Phân biệt tâm lý người chơi để họ không thể can thiệp lẫn nhau. Điều này sẽ rất tuyệt cho một trò chơi như bowling hoặc bi-a, nơi chỉ có một người chơi tại một thời điểm có quyền kiểm soát hoặc mỗi người chơi có "hộp cát" riêng (như một đường bowling).

Nếu bạn không thể đánh bại họ, hãy tham gia cùng họ và làm cho độ trễ vật lý trở thành một phần của trò chơi của bạn. Hãy tưởng tượng một câu chuyện về việc ở trong một vũ trụ rối mắt với các định luật vật lý bị phá vỡ hoặc một cái gì đó :)

Phụ lục: Cách trò chơi bắn súng đối phó với nó

Trò chơi bắn súng đối phó với nó bằng cách không làm vật lý quá phức tạp. Họ sử dụng các hiệu ứng phụ của máy khách để người chơi thấy mọi thứ nhanh chóng, nhưng sau đó máy chủ thực hiện cuộc gọi cuối cùng về những gì đã xảy ra.

Hãy tưởng tượng một kịch bản trong đó người chơi A bắn người chơi B. Trò chơi bắn súng điển hình của bạn sẽ làm một cái gì đó như thế này ...

  1. A sẽ tính toán cục bộ nếu họ đánh B, và nếu có vẻ như có một cú đánh, thì nó sẽ tạo ra hiệu ứng "đánh" như một vết máu. Điều này được thực hiện phía khách hàng để người chơi ngay lập tức thấy phản ứng với hành động của họ. Nếu bạn không làm điều này, trò chơi sẽ cảm thấy chậm trễ.
  2. A cũng gửi một tin nhắn đến máy chủ nói rằng: "Tôi đã bắn theo vectơ này"
  3. Khi máy chủ nhận được thông báo, nó sẽ xem CNTT nghĩ người chơi đang ở đâu và quyết định xem vectơ bắn của A có trúng B.
  4. Nếu máy chủ quyết định A đánh B, nó sẽ quyết định B bị tấn công và gửi tin nhắn cho cả hai khách hàng nói điều gì đã xảy ra.
  5. Nếu máy chủ quyết định A KHÔNG nhấn B, B vẫn ổn và A "bỏ lỡ". Nó có thể trông giống như A họ đã đánh ("Tôi thấy máu phồng lên!") Nhưng đó là các máy chủ gọi rằng họ đã bỏ lỡ.

Vậy làm thế nào A có thể bỏ lỡ B khi có vẻ như họ đánh chúng? Bởi vì B có thể đã di chuyển, nhưng A chưa thấy nó vì máy chủ chưa gửi tin nhắn "B chuyển đến đây" cho khách hàng.

Valve có một bài viết tốt trên trang web của họ về điều này. Xem http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking


2
Điều đó đúng trên một máy chủ có kết nối tốt. Có nhiều trường hợp vật lý trong các trò chơi nhiều người chơi thất bại và tôi chắc chắn có rất nhiều trải nghiệm vật lý tồi tệ trong các trò chơi Mod của Garry. Tuy nhiên, nếu có độ trễ, các vấn đề tôi vạch ra sẽ tồn tại. Bạn không thể hiểu được thực tế rằng vật lý cần phải được tính toán rất nhanh để được thông suốt. Và nếu bạn có độ trễ, sẽ có độ trễ. Trì hoãn có nghĩa là trễ.
Tim Holt

1
Bạn có thể muốn quay lại và đọc lại bài viết của tôi. Trừ một số ý kiến ​​ở phần đầu về phía tôi, tôi đang mô tả chính xác những gì xảy ra trong một mô phỏng vật lý với nhiều người chơi - bao gồm các phiên trò chơi Mod của Garry của bạn. Bạn không thể tìm hiểu sự thật.
Tim Holt

2
Ok, tôi đã thay đổi downvote của tôi thành một upvote. Nhưng bạn vẽ một bức tranh thực sự tiêu cực cho các trò chơi nhiều người chơi bằng vật lý, khi nó thực sự đã được thực hiện trước đó và tương đối ổn.
Tấn

7
@AttackingHobo: "Trục trặc miễn phí" là tương đối. Đã từng làm việc trong một trò chơi với dự đoán mạng tốt, bây giờ tôi thấy những trục trặc mà trước đây tôi không làm được. Chúng hiếm khi ảnh hưởng đến cơ học một cách có ý nghĩa, nhưng chúng có mặt. Toàn bộ dự đoán là một sự thiếu chính xác nhỏ trong thời gian thực tốt hơn độ chính xác bị trì hoãn; điều đó không thay đổi sự thật rằng bạn luôn không chính xác.

1
+1 cho "Hãy tưởng tượng một câu chuyện về việc ở trong một vũ trụ rối rắm với các định luật vật lý bị phá vỡ hoặc một cái gì đó".
Patryk Czachurski

13

Tôi đã viết một loạt các bài viết về chủ đề ở đây: http://www.gabrielgambetta.com/fpm1.html

Ba bài viết đầu tiên liên quan đến phần giới thiệu về chủ đề, dự đoán phía khách hàng, đối chiếu máy chủ và nội suy thực thể (đây là phần trả lời câu hỏi cụ thể của bạn). Bài viết thứ 4 (sắp ra mắt) sẽ đề cập đến "công cụ chụp hình" :)

Câu trả lời của Tim Holt là khá nhiều. Các bài viết của tôi có một vài sơ đồ có thể giúp bạn hiểu những gì đang diễn ra, nhưng Tim và tôi về cơ bản đang nói điều tương tự.


Tốt ggambett!
Tim Holt

2
Vì vậy, nhiều người chơi không hiểu cách thức hoạt động của công cụ này, nhưng nó rất quan trọng để hiểu được sự vĩnh cửu, "WTF TẠI SAO TÔI BỎ LISS?" câu hỏi
Tim Holt

Hoặc "tại sao nhân vật của tôi gắn liền với cột đó bằng một dải cao su khổng lồ?" trên một kết nối bị mất :)
ggambett

Wiki của Valve có một bài viết cũng đi sâu vào những vấn đề này. Trang này có tại developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Tim Holt

1
Tôi yêu bản Demo trực tiếp. Thật là một cách tuyệt vời để hình dung những gì đang xảy ra.
Richard Marskell - Drackir

2

Không phải là không có lý khi đưa ra dự đoán đầy đủ về nhân vật của chính bạn để đáp ứng và để các nhân vật khác bị tụt lại sau 100ms vì tính nhất quán. Nếu điều này có vẻ tệ thì hãy cân nhắc việc nhân vật của bạn bị trễ một chút để giữ chúng đồng bộ. Dù bằng cách nào, bạn vẫn sẽ cần các cơ chế điều chỉnh để giải quyết các dự đoán không chính xác trong trường hợp độ trễ tăng vọt và hệ thống đó sẽ xử lý các tình huống như mô tả của bạn. Không có vấn đề gì cho dù độ trễ là 100ms hay 1ms - khách hàng của bạn luôn bị "trễ" theo một cách nào đó và do đó luôn phải hành động như đang xử lý dữ liệu cũ và áp dụng các hiệu ứng mỹ phẩm như nội suy để làm cho nó trông hợp lý.


0

Cuối cùng, tất cả về việc thực hiện với các tài nguyên mạng có sẵn. Lý tưởng nhất là chúng ta sẽ sống trong một thế giới có độ trễ bằng không và mọi thứ đều có thể được đồng bộ hóa hoàn hảo. Trên thực tế, bạn cập nhật các máy khách cứ sau 100, 200, 300 ms và trong máy khách cần phải có logic để làm cho những gì đã xảy ra trở nên trơn tru. "Độ mượt" là rất quan trọng, cuối cùng, trò chơi chỉ cần cảm thấy mượt mà ngay cả khi ở phía sau có một số đồng bộ hóa hỗn loạn xảy ra giữa máy khách và máy chủ.

Một bài viết tốt và câu trả lời tốt hơn có thể được tìm thấy:

Làm thế nào để viết một trò chơi mạng?


0

Vấn đề không thực sự là độ trễ. Nó có thể được bù và dự đoán khá tốt để che giấu bất kỳ vấn đề gây ra nó. Mất gói cũng không phải là vấn đề - hệ thống mạng phải được viết là mạnh mẽ và có thể chịu được khi mất gói. Tuy nhiên, vấn đề là độ trễ tăng đột biến và độ trễ không thể đoán trước. Các gói không đồng bộ, một số trong số chúng bị rơi chỉ vì dao động độ trễ, không có khả năng dự đoán và nội suy vì dao động độ trễ, v.v.

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.