Kiến trúc trò chơi ngang hàng tốt nhất


10

Xem xét một thiết lập nơi khách hàng trò chơi:

  1. có tài nguyên điện toán khá nhỏ (thiết bị di động, điện thoại thông minh)
  2. tất cả đều được kết nối với một bộ định tuyến chung (LAN, hotspot, v.v.)

Người dùng muốn chơi một trò chơi nhiều người chơi mà không cần máy chủ bên ngoài.

Một giải pháp là lưu trữ một máy chủ có thẩm quyền trên một điện thoại, trong trường hợp này cũng sẽ là một máy khách. Xem xét điểm 1, giải pháp này không được chấp nhận vì tài nguyên điện toán của điện thoại là không đủ.

Vì vậy, tôi muốn thiết kế một kiến ​​trúc ngang hàng sẽ phân phối tải mô phỏng của trò chơi giữa các khách hàng. Do điểm 2, hệ thống không cần phức tạp về tối ưu hóa; độ trễ sẽ rất thấp. Mỗi khách hàng có thể là một nguồn dữ liệu có thẩm quyền về bản thân và môi trường trực tiếp của mình (ví dụ như đạn.)

Điều gì sẽ là cách tiếp cận tốt nhất để thiết kế một kiến ​​trúc như vậy? Có bất kỳ ví dụ đã biết nào về giao thức ngang hàng cấp LAN như vậy không?

Ghi chú:

Một số vấn đề được giải quyết ở đây , nhưng các khái niệm được liệt kê ở đó quá cao đối với tôi.

Bảo vệ

Tôi biết rằng không có một máy chủ có thẩm quyền là một vấn đề bảo mật, nhưng nó không liên quan trong trường hợp này vì tôi sẵn sàng tin tưởng khách hàng.

Biên tập:

Tôi quên đề cập: nó sẽ là một trò chơi có nhịp độ khá nhanh (một game bắn súng).

Ngoài ra, tôi đã đọc về kiến ​​trúc mạng tại Gaffer trên Games .

Câu trả lời:


10

Hãy xem bài viết này về kiến ​​trúc mạng của Age of Empires II.

Họ quản lý để tạo ra một trò chơi nhiều người chơi chạy tuyệt vời trên Pentium 90 với RAM 16 MB và kết nối modem 28,8 kB / s. Họ đã làm điều này bằng cách cho mỗi người chơi chạy mô phỏng của riêng họ, nhưng đồng bộ hóa các lệnh của họ.

Họ có một số thủ thuật thông minh trong đó, tôi đánh giá cao nó.


5

Tôi đã thực hiện điều này cho một trò chơi đua xe PSP thương mại, hoạt động trên cả mạng ad hoc và thông qua một điểm truy cập không dây. (Hoặc đến một máy chủ tĩnh trên Internet, nếu muốn)

Do điểm 2, hệ thống không cần phức tạp về tối ưu hóa

Theo kinh nghiệm của tôi, điều này không đúng. Các thiết bị không dây (đặc biệt là các thiết bị cầm tay nhỏ) không giống như các máy tính có kết nối mạng có dây - điện thoại thông minh và máy chơi game không dây có xu hướng có giao diện mạng chậm cho mục đích trò chơi.

Đừng hiểu sai ý tôi - thông lượng của chúng thường tốt (nghĩa là lượng dữ liệu mỗi giây; tuyệt vời để phát trực tuyến phim hoặc v.v.), nhưng độ trễ khi phân phối một gói cụ thể có thể rất tệ và có thể rất tệ rất khác nhau, rất khó để ước tính bất kỳ gói cá nhân nào sẽ mất trong bao lâu. Sự biến đổi này càng trở nên tồi tệ hơn khi nhiều thiết bị không dây được tập hợp lại thành một khu vực chung, khi các tín hiệu của chúng bắt đầu giao thoa với nhau. Do đó, khá nhiều thời gian của tôi đã dành cho việc giảm số lượng các gói cần gửi, vì vậy chúng tôi sẽ có ít va chạm gói hơn. (Lưu ý rằng đây là một vấn đề ít xảy ra trong trường hợp có liên quan đến điểm truy cập mạng được hỗ trợ, thay vì để các thiết bị nói chuyện trực tiếp với nhau qua mạng ad hoc)

Như một ví dụ về loại tối ưu hóa này, trò chơi đua xe của chúng tôi đã diễn ra trong một thế giới có đèn giao thông. Hàng ngàn người trong số họ. Và chúng tôi cần đảm bảo rằng tín hiệu của chúng được đồng bộ giữa tất cả các trình phát trong phiên mạng. Thay vì cố gắng gửi các gói xung quanh để nói cho mọi người biết đèn nào ở trạng thái nào, chúng tôi đã xác định lịch biểu tĩnh cho tất cả các đèn giao thông, và sau đó chỉ đảm bảo rằng tất cả các khách hàng đồng ý về "thời gian trò chơi" hiện tại. Vì tất cả họ đều biết thời gian trò chơi và tất cả các trạng thái của đèn giao thông có thể được xác định từ thời gian trò chơi, chúng tôi đã đồng bộ hóa tất cả dữ liệu trạng thái đó mà không thực sự gửi bất kỳ dữ liệu đặc biệt nào. Sự thay đổi này đã tạo ra một sự khác biệt lớn cho hiệu suất mạng của chúng tôi.

Những gì đã nói, thiết lập đồng bộ đồng hồ đáng tin cậy giữa nhiều thiết bị không dây (với thời gian ping rất khác nhau do phần lớn mất gói) là một thách thức lớn. Rất vui được nói thêm về điều đó nếu bạn quan tâm.

Mỗi khách hàng có thể là một nguồn dữ liệu có thẩm quyền về bản thân và môi trường trực tiếp của mình (ví dụ như đạn.)

Đây là những gì chúng tôi đã làm, và nó hoạt động tốt cho chúng tôi trong tình huống của chúng tôi (xe hơi). Dĩ nhiên, phần có vấn đề là khi một đối tượng dừng lại gần người chơi 'a' hơn là người chơi 'b' và do đó quyền sở hữu của nó chuyển từ người chơi này sang người chơi khác.

Đây thực sự là một cuộc đàm phán phức tạp đáng ngạc nhiên giữa những người chơi, trong đó trò chơi 'a' đề xuất trò chơi 'b': "Tôi nghĩ đối tượng này gần gũi với bạn hơn. Bạn nên kiểm soát nó." Và sau đó, trò chơi 'b' có thể chấp nhận hoặc có thể từ chối, dựa trên quan điểm riêng của mình về tình huống. Sự khác biệt về trạng thái trò chơi được nhận thức giữa 'a' và 'b', và sự thay đổi thời gian giữa khi yêu cầu và phản hồi được gửi và nhận khiến điều này trở thành một cuộc đàm phán nhỏ đặc biệt khó chịu để trở nên đáng tin cậy và nó có thể dễ dàng thoái hóa thành một trò chơi "Khoai tây nóng", với quyền sở hữu đối tượng nảy liên tục giữa nhiều người chơi. Và ngay cả khi nó hoạt động bình thường, khi được nhìn từ điểm thuận lợi của trò chơi 'c', có '

Trực giác của tôi là cách tiếp cận "sở hữu đối tượng" này có thể quá cồng kềnh đối với các vật thể nhỏ, có thời gian sống ngắn như đạn. Chúng tôi đã sử dụng nó cho xe ô tô giao thông và các tay đua AI, những người có xu hướng sống trong mô phỏng trong một thời gian tương đối dài. Có vẻ như một cách tiếp cận hiệu quả hơn, nếu bạn sẵn sàng tin tưởng khách hàng, sẽ khiến mỗi trò chơi của người chơi sở hữu vị trí và đạn của họ, và tuyên bố khi người chơi đó bị trúng đạn của người khác. (Vì vậy, là "trò chơi A", tôi chịu trách nhiệm cho biết vị trí của người chơi A và người chơi A, nhưng người chơi B có trách nhiệm cho biết tôi đã đánh người chơi B chưa). Với một số tính toán chết tốt, bạn sẽ có thể có được hành vi khá hợp lý từ một hệ thống như thế này.


1

Tôi khuyên bạn nên sử dụng khóa bước ngang với kiến ​​trúc ngang hàng.

Bạn bắt đầu bằng cách đếm các khung trò chơi của bạn sau khi trò chơi bắt đầu. Một khách hàng kết xuất khung đầu tiên sau đó gửi tin nhắn sẵn sàng cho các khách hàng khác và chờ để nhận tin nhắn sẵn sàng từ các khách hàng khác.

Bây giờ tất cả các khách hàng có thể đi cho khung thứ 2. Kết xuất khung, gửi và nhận lệnh, cập nhật thế giới, cập nhật vật lý và ... sau đó gửi tin nhắn sẵn sàng cho nhau.

Giải pháp này rất tốt cho các trò chơi LAN và tất cả các khách hàng của bạn sẽ được đồng bộ hóa.

với loại mạng này, bạn có thể chắc chắn rằng tất cả các khách hàng của mình đều đồng bộ để bạn có thể kiểm tra cách tốt nhất phù hợp với nhu cầu của mình.

Cách thứ nhất là chỉ gửi đầu vào cho người khác và mỗi khách hàng mô phỏng chạy, bắn, phát hiện va chạm, v.v ... Cách thứ 2 là mỗi khách hàng gửi thông tin về nhân vật của mình cho người khác như vị trí, góc quay, trạng thái, khung hình động, v.v. tính toán công cụ của họ và gửi chúng qua mạng nhưng cách đầu tiên là an toàn hơn.


1
Câu trả lời này dường như là về vòng lặp trò chơi. Tôi nghĩ rằng OP đang hỏi về hệ thống phân phối tải; cụ thể, ai mô phỏng những gì và làm thế nào khách hàng giao tiếp. Bạn có thể đi vào một số chi tiết? Tôi quan tâm đến vấn đề này là tốt.
Wackidev

@Wackidev với loại mạng này, bạn có thể chắc chắn tất cả các khách hàng của mình đều đồng bộ để bạn có thể kiểm tra cách tốt nhất phù hợp với nhu cầu của mình. Cách thứ nhất là chỉ gửi đầu vào cho người khác và mỗi khách hàng mô phỏng chạy, bắn, phát hiện va chạm, v.v ... Cách thứ 2 là mỗi khách hàng gửi thông tin về nhân vật của mình cho người khác như vị trí, góc quay, trạng thái, khung hình động, v.v. tính toán công cụ của họ và gửi chúng qua mạng nhưng cách đầu tiên là an toàn hơn.
kochol

Vì vậy, xin vui lòng đặt nó trong câu trả lời của bạn. Ngay bây giờ tôi không nghĩ rằng nó trả lời câu hỏi. Ngoài ra, xin vui lòng xóa bình luận trùng lặp đầu tiên. Cảm ơn. Theo ý tưởng, không phải tùy chọn đầu tiên bạn liệt kê yêu cầu mô phỏng phải có tính xác định?
Wackidev
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.