Tôi biết rằng thiết lập nhiều người chơi siêu đơn giản của tôi có lẽ không phải là một ý tưởng tốt, nhưng tại sao?

Tôi đang làm một MOBA nhỏ đơn giản chỉ để cho vui. Tôi đang làm mọi thứ một người chơi sau đó tôi nhận ra "ôi tôi có lẽ nên thêm nhiều người chơi, huh."

Tôi chưa bao giờ làm bất cứ điều gì với mạng trước đây, vì vậy học cách tích hợp Lidgren vào trò chơi của tôi thật thú vị và tuyệt vời. Vấn đề là, tôi gần như biết cách tôi làm mọi thứ là sai, bởi vì nó không đủ mạnh để sử dụng các trò chơi chính thống, theo như tôi biết, nhưng có gì sai với nó?

Về cơ bản, những gì tôi đang làm là bất cứ khi nào người chơi thực hiện một hành động, nó sẽ gửi một thông điệp tới máy chủ nói rằng "này, tôi vừa mới làm điều này." Cả máy chủ và máy khách đều chạy cùng một mô phỏng. Sau đó, máy chủ sẽ gửi một tin nhắn cho tất cả các khách hàng khác nói với họ rằng anh chàng đó đã làm điều đó.

Đối với hầu hết các phần, ngoại trừ trong một vài trường hợp, khi người chơi làm một việc, khách hàng sẽ cho rằng nó thật tuyệt và tự mình tiếp tục với nó. Vì vậy, khi bạn nhấp chuột phải vào một nơi nào đó để di chuyển đến đó, khách hàng của người chơi đó sẽ bắt đầu di chuyển anh chàng của anh ta đến đó, và sau đó gửi tin nhắn đến máy chủ cho họ biết về điều đó.

Nên về cơ bản:

• Người chơi 1 sử dụng một câu thần chú để khiến anh ta di chuyển nhanh hơn 100% trong sáu giây
• Máy khách cục bộ của Người chơi 1 thêm buff đó vào đối tượng Đơn vị của mình
• Ứng dụng khách của Người chơi 1 gửi tin nhắn đến máy chủ với nội dung "hey tôi vừa mới sử dụng câu thần chú này"
• Máy chủ đảm bảo rằng anh ta thực sự đã có đủ mana để sử dụng câu thần chú đó và nếu vậy, hãy thêm buff đó vào bản sao của máy chủ của đối tượng Đơn vị đó
• Máy chủ gửi tin nhắn cho tất cả các khách hàng khác nói rằng "anh chàng này chỉ bỏ bùa này"
• Mọi khách hàng khác nhận được thông báo và "ah okay cool" và thêm buff đó vào đối tượng Đơn vị cục bộ của họ cho người chơi đó

Tôi đã lướt qua các công cụ để xem các trò chơi lớn làm nhiều người chơi như thế nào và thật khó hiểu cho những người mới bắt đầu tìm hiểu về công cụ này, nhưng có vẻ như Công cụ nguồn gửi một gói chứa tất cả các thay đổi cho mọi thứ trong thế giới nào tích tắc? Một lần nữa, hoàn toàn mới đối với công cụ này, nhưng bạn có thể thực sự đẩy nhiều dữ liệu đó thường xuyên không?

Xin lỗi nếu điều này hơi rắc rối, nhưng về cơ bản, tôi đã tự hỏi tại sao hệ thống đơn giản hơn của tôi không phải là cách phù hợp, bởi vì nếu đó là, các trò chơi khác sẽ sử dụng nó, phải không?

Ngoài câu trả lời của Byte56, có một vài điều nữa cần xem xét:

Làm thế nào bạn sẽ liên lạc giữa các khách hàng về chuyển động của người chơi? Không giống như hầu hết các hành động khác của người chơi, có xu hướng bị cô lập và có khả năng không thường xuyên, chuyển động là liên tục. Có giới hạn về tốc độ mà bạn có thể (và muốn, đối với vấn đề đó) gửi và nhận cập nhật. Dự đoán phía khách hàng mà Byte56 đề cập thường liên quan đến các cập nhật định kỳ về vị trí và vận tốc của khách hàng. Sau đó, khách hàng nội suy giữa chúng, sử dụng một cái gì đó giống như một Spline hình khối .

Một vấn đề thứ hai, kết nối trở lại những vấn đề trước đó, đó là UDP không được phân phối đảm bảo. Bạn không thể chắc chắn rằng mọi tin nhắn bạn gửi đến, hoặc thậm chí đến theo đúng thứ tự. Bạn có thể gửi các gói 1, 2 và 3 và máy chủ nhận được 3 rồi 1 chứ không phải 2. Thường thì chúng sẽ theo đúng thứ tự và thường thì chúng sẽ đến, nhưng không phải lúc nào cũng vậy. Vì vậy, bạn cần một hệ thống mạnh mẽ để mất các gói. Một hệ thống xác nhận đơn giản là đủ. Thông thường được sử dụng là một bitfield thông báo cho nút khác xem nó có nhận được 32 tin nhắn cuối cùng (đối với int 32 bit) hay không và tin nhắn cuối cùng nhận được là gì. Bằng cách này, bạn có thể gắn nhãn tin nhắn là quan trọng hay không, và gửi lại nếu chúng không nhận được tin nhắn quan trọng. Có một cuộc thảo luận khá tốt về nó ở đây .

Bạn cũng cần lưu ý, khi thực hiện điều này, khách hàng của bạn sẽ không đồng bộ với nhau. Mỗi người sẽ hiển thị các trình phát khác nội suy giữa hai khung mạng trước của họ trong khi bạn đang làm việc trên khung tiếp theo, trong trường hợp tốt nhất. Vì vậy, bạn cần một hệ thống có tính đến (công bằng) rằng những gì người chơi thấy khi anh ta thực hiện một hành động không phải là trạng thái thực tế của trò chơi khi anh ta thực hiện hành động đó. Anh ta đang phản ứng với một trạng thái trò chơi cũ, không đồng bộ.

Cuối cùng, nếu trò chơi này có ý định cạnh tranh, bạn cũng cần lo lắng về việc gian lận. Do đó, trong phạm vi có thể (và hợp lý), bạn phải mất lòng tin của khách hàng và xác minh hành động của họ là có thể. "Không, bạn không thể đi qua bức tường đó. Không, bạn không thể đi nhanh hơn tốc độ chạy của mình. Không, bạn không thể tuyên bố đã bắn trúng mục tiêu đó." Vân vân.

Để biết thêm ý tưởng, tôi khuyên bạn nên duyệt các bài viết khác trong liên kết thứ hai đó.

Chúc may mắn!

Những gì bạn đang mô tả về cơ bản là dự đoán phía khách hàng , nhưng bạn không nói điều gì xảy ra khi máy chủ và máy khách không đồng ý.

Nó phát triển từ những ngày mà máy khách chỉ là một thiết bị đầu cuối câm, gửi đầu vào của nó đến máy chủ và máy chủ báo cho khách hàng biết kết quả. Tuy nhiên, một khi các trò chơi vượt ra ngoài mạng LAN (và thường xuyên trước đó) thì độ trễ là đáng chú ý trong tình huống này. Những gì bạn đang mô tả, dự đoán phía khách hàng đã được giới thiệu để khắc phục điều đó. Bây giờ máy khách cũng mô phỏng chuyển động trong khi chờ máy chủ phản hồi. Sau đó, họ đi đến một thỏa thuận về kết quả. Với máy chủ là cơ quan có thẩm quyền.

Các bước tiếp theo là cách bạn phản ứng với những bất đồng. Nếu bạn không có bất cứ điều gì phù hợp cho điều đó, bạn sẽ có được dải cao su hoặc cổng tele của máy khách khi máy khách và máy chủ không đồng ý.

Thời gian. Các câu trả lời khác không đề cập đến thời gian của các sự kiện trên máy chủ và các máy khách khác nhau. Tùy thuộc vào trò chơi, đây có thể là một cái gì đó để coi chừng. Độ trễ (hay còn gọi là Lag) giới thiệu độ trễ thay đổi giữa thời điểm gói tin được gửi và khi nhận được. Thời gian có thể là khó khăn, nhưng tôi sẽ cố gắng giải thích các vấn đề tiềm năng tốt nhất có thể. Có một số trò chơi có thể nhận được mà không phải lo lắng về điều này, nhưng đây là một ví dụ đơn giản về nơi nó có thể gây ra vấn đề.

Giả sử rằng tất cả mọi người hành động trên các gói ngay khi họ đến.

@ Time 0 (wall time), Player 1 puts up a shield   (Message has been sent, but not received by anyone)
@ Time 1, Player 2 shoots player 1   (Message has been sent, but not received by anyone)

Giả sử Thời gian 0 (T0) và T1 gần nhau.

Điều gì xảy ra tiếp theo phụ thuộc vào người đang xem xét điều này và vào thứ tự các gói đến máy chủ. Các máy chủ phải luôn luôn có tiếng nói cuối cùng. NẾU máy chủ nhận được các gói theo thứ tự được đưa ra ở trên, thì máy chủ sẽ áp dụng lá chắn trước khi bắn và người chơi 1 (P1) sẽ sống sót. Từ góc nhìn của P1, khi tự mình dựng lên chiếc khiên, anh ta sẽ nhìn thấy chiếc khiên trước khi bắn và sống sót. Nhưng còn P2 thì sao? Họ sẽ thấy phát bắn ngay lập tức vì họ bắn nó, nhưng liệu họ có nhìn thấy tấm khiên trước không? Nếu(T0 + latency between P1 and the server + the latency between the server and P2) > T1 , khiên sẽ xuất hiện sau phát bắn và P2 sẽ nghĩ rằng phát bắn của chúng đã giết chết P1. Máy chủ sẽ phải sửa tình huống này bằng cách nào đó.

Tuy nhiên, nếu máy chủ nhận các gói theo thứ tự ngược lại (điều này hoàn toàn có thể, ngay cả khi T0 <T1), thì điều ngược lại xảy ra. P1 sai (và chết), trong khi P2 đúng (và chiến thắng).

Có một vài cách để xử lý các tình huống như thế này, nhưng cách dễ nhất là để máy chủ làm mọi thứ. Bạn có thể cố gắng mô phỏng điều này trên máy khách, nhưng không cho phép bất kỳ hành động vĩnh viễn nào, như cái chết. Người chơi sẽ phải chờ các xác nhận thay đổi trò chơi quan trọng từ máy chủ.

Gửi một dấu thời gian với các hành động có thể có lợi. NẾU bạn chủ yếu tin tưởng khách hàng, thì bạn có thể sử dụng các dấu thời gian này có thể được sử dụng để xác định hành động nào xảy ra trước, thay vì theo giả định đầu tiên của chúng tôi. Điều này có thể khó khăn, bởi vì nhận được tin nhắn từ quá khứ thường có nghĩa là bạn cần có thể đảo ngược thời gian.

Thời gian có vui không? Bất kể bạn đang làm gì, thật hữu ích khi nhận thức được những vấn đề thời gian này.