Làm thế nào để đối phó với các máy tính nhanh hơn trong trò chơi điện tử thời gian thực của máy khách / máy chủ

Tôi đang tạo trò chơi trực tuyến đầu tiên của mình bằng socket.io và tôi muốn đây là trò chơi nhiều người chơi thời gian thực như agar.io hoặc diep.io.

Nhưng tôi đã gặp phải vấn đề là cố gắng tìm ra cách để làm cho tất cả các máy tính hoạt động với cùng một tốc độ.

Tôi có ba ý tưởng cho các mô hình, nhưng không ai trong số chúng có vẻ đúng, và tôi tự hỏi làm thế nào các trò chơi video bình thường làm điều đó. (Bạn có thể bỏ qua việc đọc ý tưởng của tôi; họ chỉ cho bạn cách để xem những vấn đề tôi gặp phải.)

1. Máy chủ cho phép các máy khách tự chạy và chuyển các bản cập nhật đến máy chủ, sau đó chúng sẽ phát chúng cho các máy khách còn lại. Điều này có vấn đề là một số máy tính chạy nhanh hơn các máy tính khác, cho phép chúng cập nhật nhanh hơn và di chuyển trên màn hình nhanh hơn.

2. Có máy chủ báo cho khách hàng biết khi nào cần cập nhật. Sau đó tôi có thể đợi cho đến khi khách hàng cuối cùng phản hồi (một ý tưởng khủng khiếp trong trường hợp một người có máy tính chậm), đợi cho đến khi khách hàng đầu tiên phản hồi (một lần nữa, chờ liên lạc trước mỗi khung hình) hoặc chỉ cần gửi cho họ nhanh nhất có thể (mà dường như gặp vấn đề tương tự như số 1).

3. Khi bắt đầu trò chơi, hãy để máy chủ thông báo cho khách hàng cách cập nhật nhanh chóng. Điều này có nghĩa là khách hàng sẽ chịu trách nhiệm hạn chế di chuyển trong khoảng thời gian đó. Ví dụ: nếu ai đó bằng cách nào đó quản lý để nhấn một nút hai lần trong khoảng thời gian đó, thì nó sẽ chỉ gửi một sự kiện nhấn nút. Điều này có vấn đề là một số hành động sẽ bị bỏ qua (chẳng hạn như nhấn nút đôi) và tương tác sẽ phụ thuộc vào đồng hồ của máy khách, có thể không khớp với đồng hồ của máy chủ. Sau đó, máy chủ sẽ phải theo dõi từng khách hàng và đảm bảo rằng các cập nhật của họ đang được gửi vào đúng thời điểm.

Tôi đã thực hiện một số nghiên cứu , nhưng các bài báo tôi đọc dường như không đề cập cụ thể việc cần làm nếu khách hàng gửi cập nhật nhanh hơn các khách hàng khác.

Trong trường hợp cụ thể của tôi, tôi đang làm việc với những người có tốc độ bàn phím nhanh hơn (máy tính của họ sẽ gửi nhiều cập nhật bàn phím hơn các máy tính khác).

Làm thế nào để lập trình viên thường đối phó với điều này?

Ý tưởng thứ ba của bạn dường như là gần nhất với những gì tôi nghĩ là giải pháp công nghiệp cho loại vấn đề này.

Những gì bạn đang mô tả thường được gọi là Ticks . Trong mỗi đánh dấu, một số hành động cố định sẽ được xử lý cho từng máy khách nối tiếp. Thông thường, các máy chủ trò chơi sẽ có một số hành động song song khi có khả năng, nhưng đây là một vấn đề phức tạp hơn nhiều.

Một tích tắc có thể sẽ ở dạng 1 / N giây, N là số lượng bọ ve mỗi giây hoặc Tickrate. Đánh dấu này có thể rất thường xuyên hoặc không thường xuyên, tùy thuộc vào trường hợp sử dụng của bạn. Đề nghị cá nhân của tôi sẽ là tránh một tích tắc trên 60 tick / giây trừ khi bạn chắc chắn rằng bạn cần nhiều hơn. Bạn có thể không :)

Hành động nên là nguyên tử. Ví dụ: trong slither.io, một hành động như di chuyển không nên xử lý ngay lập tức một cái gì đó như phá vỡ chuỗi của bạn, trừ khi người chơi bạn đánh đã di chuyển. Điều này có vẻ tầm thường đối với một cái gì đó ở mức độ pixel, nhưng nếu bạn đang xử lý chuyển động dựa trên gạch, nó sẽ trở nên rõ ràng hơn nhiều và đảm bảo tính công bằng. Nếu Người chơi A di chuyển đến ô X, Y và Người chơi B hiện đang ở trên ô đó, bạn phải đảm bảo rằng khi hết dấu tích, người chơi B sẽ vẫn ở trên ô đó cho bất kỳ hành động nào xảy ra giữa họ.

Hơn nữa, tôi muốn tránh thực hiện bất kỳ tính toán nào của bạn được thực hiện ở phía máy khách trừ khi chúng được thực hiện độc lập ở phía máy chủ. Điều này trở nên phức tạp và tốn kém với vật lý (nhiều trò chơi chọn tỷ lệ đánh dấu vật lý thấp hơn so với nhiều hành động và sự kiện khác vì điều này)

Để tham khảo, đây là một liên kết tốt để bổ sung hiểu biết của bạn về máy chủ trò chơi và mạng nhiều người chơi.

Cuối cùng, tôi nói đừng để sự công bằng phá hỏng máy chủ của bạn. Nếu có những khai thác khiến trò chơi của bạn không công bằng, hãy sửa chúng. Nếu đó là vấn đề máy tính tốt hơn có lợi thế nhỏ, tôi có thể nói nó có thể không phải là vấn đề lớn.

Hệ thống sau đây đảm bảo tất cả khách hàng và máy chủ chia sẻ gần như cùng một trạng thái trò chơi bất cứ lúc nào.

Có trạng thái của trò chơi trên cả máy khách và máy chủ.

Khi khách hàng cố gắng sử dụng một lệnh (chuột, bàn phím, v.v. đầu vào khác), hãy xem trạng thái của trò chơi nếu nó hợp lệ.

Nếu có, hãy gửi lệnh đến máy chủ, mà không thực hiện nó trên máy khách gửi.

Khi máy chủ nhận được lệnh, hãy xem trạng thái của trò chơi nếu nó hợp lệ.

Nếu đúng như vậy, hãy gửi lệnh trở lại TẤT CẢ các máy khách với ngày chính xác trong tương lai sau khi hoàn thành việc thực hiện trên máy chủ, sau đó thực hiện các hành động được yêu cầu bởi lệnh sau thời gian trễ bằng với thời gian tối thiểu để gửi lệnh cho máy khách . sau đó ghi lại ngày tháng, điều này giúp đưa ra dự đoán trong tương lai. Nếu thời gian thay đổi quá nhiều, hãy làm cho hệ thống trò chơi của bạn có nhiều thời gian hơn.

Khi khách hàng nhận được lệnh từ máy chủ, hãy xem trạng thái của trò chơi nếu nó hợp lệ ngay lập tức thực hiện các hành động mà lệnh yêu cầu, sau đó xem ngày hiện tại và so sánh với dự đoán ngày nhận được. Nếu nó không hợp lệ, máy khách không đồng bộ. (Tất cả các máy khách có kết nối tương tự nhận cùng một lúc)

Nếu ngày là trước, bạn đã gặp sự cố ở bước trước, hãy khắc phục điều đó. Nếu ngày là hơi sau khi không làm gì, Nếu ngày dài sau đó, máy khách không đồng bộ, tức là máy khách bị chậm lại quá nhiều.

Khi một máy khách không đồng bộ, hãy yêu cầu một bản sao của toàn bộ trạng thái trò chơi của máy chủ và sử dụng trạng thái đó. Nếu điều đó xảy ra quá thường xuyên, hãy sửa nó vì nó đắt hơn gửi lệnh.

Trên máy khách, chỉ hiển thị nội dung trên màn hình khi không còn gì để làm. Trong các kịch bản đơn giản, chức năng kết xuất chỉ lấy trạng thái trò chơi hiện tại làm đầu vào.

Trên hết, bạn có thể tối ưu hóa rất nhiều, bằng cách sử dụng các hệ thống dự đoán, nhóm các lệnh, chỉ hiển thị các khác biệt, v.v ...

Xác thực sẽ khác nhau, ví dụ, tùy thuộc vào máy chủ để giới hạn các yêu cầu lệnh / đơn vị thời gian.

Tôi không biết đây có phải là vấn đề của thư viện hoặc môi trường bạn đang sử dụng không, nhưng tôi nghĩ rằng bạn đang tiếp cận nó hoàn toàn sai.

Trong phần lớn các trò chơi nhiều người chơi, chỉ có máy chủ thực hiện bất kỳ tính toán thực tế nào. Khách hàng chỉ là những máy IO câm, trong đó chỉ có vấn đề về hiệu năng thực sự là vẽ đồ họa 3D. Và trong trường hợp đó, không có vấn đề gì nếu máy khách có thể chạy ở tốc độ 20 hoặc 200 FPS, vì điều đó chỉ ảnh hưởng đến hình ảnh. Điều đó có nghĩa là "cập nhật máy khách" hoàn toàn không có ý nghĩa. Khách hàng có thể cố gắng "dự đoán" những gì máy chủ có thể tính toán, nhưng điều đó chỉ để làm dịu cảm giác chơi trò chơi và không có tác động thực sự đến chính trò chơi.

tốc độ bàn phím nhanh hơn

Tôi thậm chí không biết điều đó có nghĩa là gì. Hầu hết mọi người thậm chí không thể theo kịp tốc độ của bàn phím cấp thấp, vậy điều đó sẽ ảnh hưởng đến hiệu suất của người chơi như thế nào?

Mặt khác, câu hỏi có vẻ khá rộng và thay vào đó bạn nên tập trung vào một vấn đề thực tế, thay vì cố gắng giải quyết vấn đề "chung chung" mà bạn thậm chí không thể có.