Tôi hiện đang lên kế hoạch cho một trò chơi trực tuyến nhiều người chơi đơn giản. Và đây là câu hỏi. Liệu nó có ý nghĩa để làm cho toàn bộ logic trò chơi trên máy chủ và chỉ gửi đầu vào từ máy khách đến máy chủ? Đó là những ưu và nhược điểm hoặc có bất kỳ lý do tại sao tôi không nên làm điều đó?
Câu trả lời:
Bạn không muốn gửi đầu vào của người chơi đến máy chủ. Những gì bạn có thể muốn làm là gửi một đại diện trừu tượng về những gì người chơi muốn làm cho máy chủ, và sau đó chạy logic trên đó.
Tương tự như vậy, bạn không nhất thiết muốn gửi lại mọi thứ khách hàng cần làm. Ví dụ: bạn có thể gửi một số loại thông báo có nội dung "NPC X đã chết" và ứng dụng khách xác định hoạt hình / âm thanh nào sẽ phát. Những thứ như thế.
Bí quyết là tìm dòng nơi băng thông và sức mạnh xử lý (trên máy chủ) bị tấn công bằng cách ngăn chặn mọi người gian lận. Thông thường, bạn chỉ đưa ra bất kỳ loại quyết định có thẩm quyền thay đổi trò chơi nào trên máy chủ và để lại tất cả các công cụ trực quan phụ trợ cho khách hàng.
Có rất nhiều câu hỏi cụ thể hơn về chủ đề này trên tất cả các trang web. Ví dụ:
Nên phát hiện va chạm phía máy chủ hoặc hợp tác giữa máy khách / máy chủ?
Người chủ trì trò chơi nên là người có thẩm quyền, hay một khách hàng câm khác?
Chà, bạn đã có câu trả lời nhưng câu trả lời thực sự của bạn là "hãy tự thử". Những điều khác nhau từ trò chơi này đến trò chơi khác.
Tôi đã làm vài trò chơi nhiều người cho một số khóa học thiết kế trò chơi mạng phân tán. Thử thách lớn nhất là thực hiện một game hành động thời gian thực, nơi nhiều người chơi tham gia và gửi đầu vào như địa ngục. Khi nói đến điểm đó, mọi thứ trở thành vấn đề. Khi bạn thấy liên kết đầu tiên mà Tetrat gửi, thậm chí việc xác định thông đồng cũng trở thành một vấn đề. Và bạn sẽ đọc các thuật ngữ nghe như lag, nội suy, ngoại suy, dự đoán ... Nhưng nếu bạn chưa bao giờ thử tự viết mã từ đầu, bạn sẽ chỉ chấp nhận những từ này và sẽ không biết ý nghĩa thực sự của chúng.
Đề nghị của tôi là:
Bước 1
Chỉ cần bắt đầu với thiết kế dựa trên máy chủ được ủy quyền hoàn toàn ngay bây giờ. Như bạn đã nói, chỉ cần gửi đầu vào của người dùng đến máy chủ và để máy chủ thực hiện mọi thứ và khách hàng nhận được kết quả. Trò chơi của bạn sẽ hoạt động hoàn toàn phù hợp. Nhưng khi bạn nhìn vào khách hàng của mình, bạn sẽ nhận thấy một số độ trễ, một số vấn đề dịch chuyển tức thời, không chuyển động trơn tru ... ect.
Bước 2
Bắt đầu sửa các vấn đề về phía khách hàng. Các vấn đề dịch chuyển tức thời chẳng hạn. Nhân vật của bạn đã ở (0,0) và máy chủ cho biết bây giờ bạn đang ở (100.100). Nhân vật của bạn sẽ chỉ dịch chuyển đến (100.100), điều này không tốt. Có nội suy. Bạn nên có một mã ở phía máy khách sẽ trượt ký tự từ (0,0) đến (100, 100) một cách trơn tru. Có, bạn sẽ chuyển nhân vật của mình từ (0,0) sang (100.100) nhưng nhanh như thế nào? Bây giờ bạn chỉ có thể sử dụng chênh lệch thời gian giữa mỗi lần cập nhật máy chủ. Nếu máy chủ của bạn gửi 10 gói trong một giây, nghĩa là độ trễ 100 ms giữa mỗi gói.
Bước 3
Bây giờ trò chơi của bạn đã tốt cho các mạng nhanh, nơi có độ trễ là (1-50) ms. Nhưng nó sẽ bị tiêu diệt nếu mất gói, độ trễ cao hoặc tính toán mất nhiều thời gian trong máy chủ ... ect. Trong những tình huống bạn sẽ nhận thấy khi nhấn mũi tên trái, bạn sẽ thấy nhân vật của mình di chuyển sang trái với độ trễ 200 ms. Sự chậm trễ giữa gói của bạn đến máy chủ, thời gian tính toán và quay lại với bạn với vị trí cuối cùng của bạn. Điều này là xấu, nhược điểm tồi tệ nhất của thiết kế ủy quyền máy chủ. Người chơi muốn nhân vật của mình di chuyển sang trái ngay khi anh ta nhấn trái, bạn không thể khiến anh ta chờ đợi. May mắn là máy khách cũng có mã giống như máy chủ, vậy tại sao không thực thi nó trên máy khách ngay lập tức và sửa kết quả cuối cùng với câu trả lời từ máy chủ? Đó là những gì cơ bản dự đoán đầu vào là. Khách hàng nhấn trái, mã bên cạnh anh ta sẽ di chuyển anh ta sang trái, sau một thời gian cho phép 200 ms, vị trí thực sự đến từ máy chủ và máy khách sẽ điều chỉnh vị trí của nó với nó. Nếu mọi thứ đều ổn, khách hàng sẽ không nhận thấy bất cứ điều gì, "bước 2" cũng sẽ giúp chúng tôi thực hiện điều này.
Vâng, net có nhiều hướng dẫn và những điều về chủ đề này. Nhưng có 2 cái tôi rất thích:
Thực sự tốt, bao gồm các điểm tối: Mạng nhiều người chơi Valve-Source Engine
Lịch sử, thú vị để đọc và đáng giá: 1500 Archers vào ngày 28.8 ,
Ưu điểm:
Nhược điểm:
Logic phía máy chủ cũng tạo ra các vấn đề về khả năng mở rộng - bạn phải thực hiện tất cả công việc cho tất cả các máy khách trên máy chủ của mình - các câu cho phép mỗi máy khách tự chia sẻ toàn bộ công việc của mình.
Phụ thuộc vào trò chơi bạn muốn tạo và phần nào của trò chơi. Nếu phát triển RTS (hoặc bất kỳ trò chơi nào có mô hình khóa), thì bạn chắc chắn chỉ nên gửi đầu vào và bước mô phỏng nào mà đầu vào được nhận.
Nếu bạn muốn làm một game bắn súng, bạn có thể sử dụng cả hai chức năng đầu vào và trừu tượng. Nếu bạn chọn Unreal Tourathon 3 như trường hợp, họ đã tạo nhiều người chơi chủ yếu thông qua các cuộc gọi chức năng được nhân rộng.
Để di chuyển, họ lấy đầu vào của người chơi (được nén thành một bit cho mỗi hành động) xoay delta, tăng tốc & dấu thời gian và gửi nó đến máy chủ.
Đối với các mục đích khác như vũ khí chúng đồng bộ hóa khi bạn bắn (AFAIK, chưa nhìn sâu vào phần này).
Đối với các giá trị tĩnh / ít thay đổi thường xuyên hơn như sức khỏe, họ gửi biến đến máy khách hoặc máy chủ tùy thuộc vào những gì lập trình viên đã chỉ định.
Và đối với các trò chơi không phải RTS, hãy nhớ dự đoán của khách hàng.