Kết nối mạng

Tôi có các nguyên tắc cơ bản về ổ cắm TCP, giao tiếp UDP, v.v., nhưng không thể tìm thấy nhiều về cách áp dụng chúng vào môi trường trò chơi thời gian thực.

Tôi có một bản sao Pông, có 4 người chơi và cần đồng bộ hóa các vị trí chèo giữa ba máy khách và máy chủ (máy chủ là người chơi thứ tư). Hiện tại tôi sử dụng UDP để gửi các cập nhật theo thời gian thực (chuyển động chèo) và TCP để thiết lập sảnh trò chơi, v.v.

Đây có phải là một BAD THING để spam lượng lưu lượng UDP khổng lồ không? Tôi có nên xem xét một cái gì đó như DCCP cho các tính năng tắc nghẽn của nó không? Hay đây không thực sự là một vấn đề với một dự án quy mô nhỏ như thế này?

Khi nào nên đồng bộ hóa tin nhắn được gửi giữa máy khách / máy chủ? Hiện tại máy chủ đang spam các gói UDP với trạng thái trò chơi hiện tại nhanh nhất có thể quản lý và khách hàng đang spam vị trí mái chèo của họ trở lại máy chủ nhanh nhất có thể. Đây có phải là cách tốt nhất để làm điều đó? Có một số độ trễ tôi nên thêm để tin nhắn được gửi một lần sau mỗi X mili giây hay tôi chỉ nên gửi tin nhắn khi có sự kiện xảy ra? (ví dụ: vận tốc mái chèo thay đổi do đầu vào của người dùng)

Sẽ tốt hơn để làm cho khách hàng giao tiếp vị trí chèo của họ với nhau ngang hàng?

Tôi đang hỏi những câu hỏi này trong bối cảnh của Pong nhưng cũng quan tâm đến việc những vấn đề này sẽ được khắc phục như thế nào trong các trò chơi khác, hoặc các giải pháp tổng quát.

Có khoảng thời gian cập nhật có thể định cấu hình (để bạn có thể điều chỉnh và thử 5 gói mỗi giây hoặc 20) và mỗi khung hình xem có đến lúc gửi bản cập nhật không. Bạn có thể ổn với một trò chơi đơn giản gửi các gói cho mỗi sự kiện, nhưng trong một trò chơi phức tạp hơn thì điều này không thực tế. Ngoài ra, hãy nhớ rằng có một gói trên đầu vì vậy nếu bạn đang gửi một loạt các gói nhỏ, bạn sẽ lãng phí băng thông.

Mỗi khoảng thời gian cập nhật có mỗi máy khách gửi vị trí mái chèo của mình đến máy chủ hoặc tới từng máy khách (ngang hàng). Có máy chủ cũng gửi vị trí bóng và một vectơ vận tốc. Mỗi khách hàng có thể chạy cùng một mã vẽ màn hình giống như trong một người chơi để chuyển động của quả bóng sẽ được trơn tru. Trong chế độ nhiều người chơi, mặc dù bạn chỉ có máy chủ gửi các cập nhật vị trí / vận tốc cho quả bóng theo một khoảng thời gian thông thường (và nếu bạn thích mỗi lần nó chạm một cái gì đó).

Có các cập nhật vị trí bóng tham chiếu một thời gian trên tất cả các máy khách để bạn có thể loại bỏ các gói thứ tự và thậm chí làm cho phép nội suy của vị trí bóng chính xác hơn (bạn biết vị trí và vận tốc tại một thời điểm cụ thể trong quá khứ để bạn có thể nội suy mới Chức vụ).

Với mô hình này với một trò chơi lag, bạn có thể thấy quả bóng di chuyển ngược lại hoặc nhảy xung quanh một chút. Nhưng với một kết nối tốt, nó sẽ khá trơn tru.

Liên quan đến vấn đề giao thông - bạn muốn tránh gửi hơn 20-30 gói mỗi giây mỗi lần ngang hàng. Trong trường hợp chung, nếu bạn gửi các gói nhỏ hơn, ít hơn, bạn sẽ trải nghiệm độ trễ ít hơn (một chút) và giảm khả năng bị rớt gói.

Bạn chắc chắn không muốn gửi cập nhật với tốc độ nhanh hơn tốc độ khung hình, vì người chơi sẽ không thể nhận ra sự khác biệt - thực sự, nếu bạn chỉ gửi gói 10 lần một giây và nội suy / ngoại suy kết quả ở đầu nhận , hầu hết người chơi sẽ không nhận thấy sự khác biệt.

Đây là một câu hỏi khá rộng, nhưng tôi sẽ cố gắng tóm tắt các khía cạnh quan trọng.

Quyết định đầu tiên để đưa ra mã mạng cho trò chơi của bạn là liệu bạn có muốn thiết lập máy khách / máy chủ sắp xếp ngang hàng hay không. Hầu hết các trò chơi, với RTS có lẽ là ngoại lệ đáng chú ý duy nhất, có lẽ đang sử dụng kiến ​​trúc máy khách / máy chủ. Ưu điểm chính là sự sắp xếp này có khả năng chịu lỗi cao hơn và cung cấp nhiều quyền kiểm soát hơn đối với dữ liệu mà mỗi khách hàng nhận được. Ngang hàng ngang hàng cho phép gửi dữ liệu ít hơn rất nhiều, nhưng yêu cầu mỗi đồng đẳng phải mô phỏng hoàn toàn thế giới chính xác như mọi đồng nghiệp khác làm. Nếu một đồng đẳng bị chậm hoặc không đồng bộ hóa, mọi người phải đợi họ phục hồi hoặc đơn giản là họ bị mất.

UDP nói chung là sự lựa chọn chính xác, chắc chắn cho bất kỳ mô hình máy khách / máy chủ nào. TCP có thể thiết thực cho trò chơi ngang hàng, nhưng ngay cả khi đó UDP có thể là lựa chọn tốt hơn. Về cơ bản, UDP xử lý ít hơn cho bạn, điều đó có nghĩa là nhiều nỗ lực hơn nhưng cũng kiểm soát nhiều hơn về cách bạn xử lý các lỗi.

Đối với Pong, sự lựa chọn mà tôi sẽ đưa ra là máy khách / máy chủ, vì đây là một game hành động. Một điều cần lưu ý ở đây, mặc dù bạn nói rằng một người chơi "là máy chủ", tốt nhất bạn nên cấu trúc mã của mình sao cho chúng thực sự đang chạy một máy chủ cục bộ và kết nối với nó như một máy khách.

Bạn chắc chắn không muốn bị "spam" cập nhật theo bất kỳ hướng nào. Một bản cập nhật từ máy chủ trên mỗi khung là tất cả những gì cần thiết và máy chủ của bạn sẽ chạy ở tốc độ khung hình cố định. Điều đó là tùy thuộc vào bạn, nhưng không cần phải quá nhiệt tình. Khung hình 50ms (20 FPS) là rất nhiều để có được trò chơi mượt mà tuyệt vời. Để giữ mọi thứ trơn tru trên máy khách, bạn muốn sử dụng phép nội suy. Máy khách phải liên tục chuyển đổi giữa các ảnh chụp nhanh khung máy chủ, đây có thể dễ dàng là chủ đề của một câu hỏi riêng biệt.

Cập nhật ứng dụng khách cũng nên được giới hạn, mặc dù một khung hình trên mỗi khung hình có thể sẽ quá nhiều nếu máy khách của bạn đang chạy ở tốc độ khung hình khá.

Bạn có quan tâm đến gian lận?

Nếu không, đi ngang hàng sẽ giảm một nửa độ trễ của bạn, vì đó là A <-> C thay vì A <-> B <-> C. Nếu vậy, để công bằng trong việc đồng bộ hóa, bạn có thể muốn tạo phản hồi hơi chậm cho người chơi cục bộ hoặc hầu hết các trò chơi làm gì - hãy để người chơi làm bất cứ điều gì cục bộ và sau đó chụp lại nếu kết quả của máy chủ chuyển hướng khỏi mô phỏng cục bộ.

Một bản sao pong thực sự là một chút khó khăn, bởi vì không giống như hầu hết các trò chơi, bạn không thể (với tư cách là một nhà phát triển) gian lận bằng cách một bên nhìn thấy một hit và bên kia thì không.

Đối với một cái gì đó khái quát, một kỹ thuật tôi đã nghe nói nhưng chưa thấy cần thiết (có thể là cho các trò chơi hành động) là giữ hành động với dấu thời gian thực của chúng (nhận thời gian - ping / 2) và khiến máy chủ quay lại ( snap) nếu một sự kiện thời gian sớm đến, và sau đó áp dụng lại các hành động sau. Theo cách đó, mọi người đều thống nhất cục bộ trừ khi có một số xung đột do tương tác của người chơi khác nhau. Mối nguy hiểm duy nhất là khả năng 'quay ngược thời gian' nếu chúng giả mạo một kết nối chậm trễ.

Google tính toán chết. Gửi bản cập nhật cho 4 người chơi sẽ không đáng kể. Lượng dữ liệu được gửi sẽ theo thứ tự byte. Vì vậy, điều đó có nghĩa là cập nhật thường xuyên sẽ ổn. Với tính toán chết, bạn di chuyển người chơi trên máy khách và máy chủ. Máy chủ là cơ quan có thẩm quyền. Khi vị trí máy khách trở nên quá xa đồng bộ từ máy chủ, nó phải trôi ngược về vị trí. http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking Sử dụng UDP là cách tốt nhất. Bupdates sẽ được gửi đến thường xuyên rằng dữ liệu bị mất sẽ sớm được thay thế bằng dữ liệu đến. Gói truyền lại của TCP không xứng đáng với vị trí người chơi. Xem bài viết này để biết thêm thông tin về cách giữ cho máy khách và máy chủ được đồng bộ.

Tôi đã lập trình một trò chơi 2 người chơi cục bộ mạng vài tuần trước, đây là cách tôi đã làm:

-Một bên mở máy chủ, bên còn lại tự động kết nối - cả hai đều đang spam vị trí mái chèo x của họ về phía nhau @ 60fps hoặc ít hơn [UDP] -nếu một bên chạm bóng họ sẽ quyết định về quả bóng và vận tốc mới và gửi nó với một [TCP] khác - nếu quả bóng bay qua một mái chèo, người chơi đã bỏ lỡ nó sẽ liên lạc với người khác bằng thông báo tăng điểm và quả bóng được đặt lại [TCP] - quả bóng được mô phỏng độc lập mọi lúc, phù hợp với vật lý bóng đơn giản của pong

Điều này tạo ra khoảng 0,3 đến 0,5 KByte / giây lưu lượng ở tốc độ 60fps và người chơi không có độ trễ trong nhận thức của họ, nhưng chỉ khi ping ở dưới một ngưỡng nhất định, bởi vì các vị trí bóng mới cần được truyền đi.

Ngoài ra gian lận cũng dễ dàng với hệ thống này và có khả năng cao không đồng bộ với kết nối rất mất mát, nhưng ai quan tâm đến việc gian lận trong pong?!