Glenn trong bài viết và bình luận của mình đưa ra một trường hợp rất mạnh để sử dụng UDP qua TCP, nhưng SC2 rõ ràng sử dụng TCP.
Glenn chủ yếu nói về các trò chơi điều khiển vật lý, tức là. game bắn súng góc nhìn người thứ nhất và lái xe. Chúng có các yêu cầu khác nhau đối với các trò chơi chiến lược thời gian thực trong đó vị trí đơn vị chính xác ở mỗi bước logic là quan trọng. Vì vậy, các chiến lược truyền thông nhất thiết phải khác nhau.
"Thời gian thực" có nghĩa là những thứ khác nhau trong các bối cảnh khác nhau. Các trò chơi không phải là "khó" thời gian thực ở chỗ nếu một tin nhắn bị trễ, toàn bộ sự việc sẽ bị phá vỡ. (Ít nhất, không có lý do chính đáng nào để một trò chơi đòi hỏi khắt khe như vậy, vì một hệ thống chỉ có phần mềm sẽ có thể phục hồi sau khi xử lý sự chậm trễ, không giống như một nhà máy điện hạt nhân hoặc một thiết bị y tế chẳng hạn.) 'mềm' hoặc 'vững chắc' thời gian thực. ( Định nghĩa tại Wikipedia như bình thường .) Loại trò chơi tạo ra sự khác biệt về việc bạn cần thông tin nhanh như thế nào, liệu bạn có thể mất thông tin và thoát khỏi nó hay không, v.v. Đủ để nói rằng TCP đủ tốt cho nhiều trò chơi, nhưng đối với các trò chơi khác, UDP là thích hợp hơn.
Tôi đoán rằng cách tiếp cận của anh ta là gửi trạng thái trò chơi đầy đủ của mọi đơn vị trên mỗi khung.
Anh ta sẽ gửi đủ thông tin để xây dựng lại trạng thái trò chơi có liên quan của bất kỳ đơn vị nào đã thay đổi.
- Bạn không cần phải gửi bất kỳ thông tin nào về điều gì đó không thay đổi.
- Bạn không cần gửi trạng thái đầy đủ nếu bạn có thể gửi đủ thông tin cho người nhận để xây dựng trạng thái mới từ trạng thái cũ. (ví dụ: Chỉ cần gửi một giá trị delta liên quan đến trạng thái cũ. Hoặc chỉ gửi các phần của trạng thái đã thay đổi và không phải phần còn lại.)
- Nếu hai trò chơi chạy chính xác cùng một thuật toán và có cùng một dữ liệu thì bạn chỉ cần gửi đầu vào và người nhận sẽ mô phỏng lại các hiệu ứng cục bộ để lấy trạng thái mới.
Hầu hết các trò chơi không đáp ứng các tiêu chí cho 3, vì vậy chúng sử dụng 1 và 2 thay thế. Tuy nhiên, nhiều trò chơi RTS có thể và sử dụng 3.
Ngoài ra, nó không nhất thiết phải là "mọi khung hình". Khái niệm về một khung hình cũng mơ hồ. Có phải là một khung của kết xuất? Có phải là một lô logic? Đây có phải là một khung dữ liệu mạng được gửi không? Cả ba luôn luôn căn chỉnh từng cái một hay bạn có nhận được tốc độ đồ họa thay đổi với tốc độ logic cố định không? Một số trò chơi, đặc biệt là các trò chơi chiến lược thời gian thực như Starcraft 2 hoặc các trò chơi có khả năng chơi lại (khi bạn chạm vào) muốn giữ mọi thứ ở trạng thái khóa hoàn hảo bằng cách cập nhật mạng thường xuyên (có thể khớp hoặc không khớp với 'khung hình' theo các giác quan khác) nhưng đây không phải là một yêu cầu cho tất cả các trò chơi Nhiều trò chơi chỉ gửi thông tin cập nhật trên cơ sở bán định kỳ, tùy thuộc vào mức độ phía sau họ sẵn sàng để khách hàng chạy.
Đầu vào của người chơi rất quan trọng và trình tự đầu vào thậm chí còn quan trọng hơn. Tôi không nghĩ việc SC2 gửi trạng thái trò chơi từ 200 đơn vị trở lên là khả thi với 30 - 60 FPS.
Nhiều trò chơi sẽ không nhất thiết coi khung kết xuất là khung logic. Chúng có thể có 60FPS trong đồ họa nhưng chỉ có 10 bản cập nhật logic một giây và gửi 1 bản cập nhật mạng cho mỗi bản. Nhưng thậm chí 30 cập nhật mạng mỗi giây là hợp lý nếu bạn sử dụng phương thức 'gửi đầu vào', chắc chắn.
Tôi đã cố gắng xác định 2 loại dữ liệu có thể. Các kỹ thuật khác là gì? Sẽ tốt để định tuyến trò chơi nếu bạn muốn.
Không có nhiều kỹ thuật riêng biệt, nhưng một số hạn chế khác nhau trên các hệ thống và tầm quan trọng của từng ràng buộc sẽ khác nhau tùy theo từng trò chơi. Vì vậy, bạn chỉ cần chọn một hệ thống phù hợp với bạn.
- Rất ít đơn vị, di chuyển nhanh và thất thường qua đầu vào của người dùng, độ trễ là nhạy cảm, đồng bộ hóa chính xác giữa các hệ thống không quan trọng - vị trí phát qua một giao thức không đáng tin cậy (ví dụ: UDP) để có tốc độ tối đa và các tin nhắn bị bỏ lỡ sẽ không thành vấn đề Đến sớm. Mô phỏng vật lý cục bộ để cải thiện chất lượng kết xuất nhưng sửa các vị trí khi có thông tin mới. Tốt cho game bắn súng và lái xe trò chơi.
- Nhiều đơn vị, nhưng hầu hết đều không liên quan và chúng di chuyển chậm - chỉ gửi cập nhật cho các đơn vị gần người nhận, gửi chúng dưới dạng thay đổi trạng thái đầy đủ, gửi chúng tương đối không thường xuyên và gửi qua giao thức đáng tin cậy (ví dụ: TCP) để tránh lo lắng về cách xử lý các bản cập nhật bị bỏ lỡ. Tốt cho MMO.
- Nhiều đơn vị, được di chuyển bởi AI dựa trên đầu vào của người dùng trước, đồng bộ hóa chính xác giữa các hệ thống rất quan trọng - gửi đầu vào của người dùng được đóng dấu thời gian qua một giao thức đáng tin cậy và mô phỏng lại cục bộ để thuật toán trò chơi được đồng bộ hóa trạng thái. Tốt cho RTSes và các trò chơi theo lượt.