Có thể tạo một trò chơi nối mạng, trong đó mỗi máy khách hiển thị một mảng pixel được gửi đến nó bởi máy chủ và gửi đầu vào trở lại máy chủ không? Điều này sẽ đơn giản hơn nhiều để thực hiện so với sử dụng dự đoán phía khách hàng, nhưng tôi sẽ tưởng tượng nó sẽ quá chậm. Nó sẽ có thể?
1
Bạn nên gửi toàn bộ trạng thái thế giới cho mọi khung hình hơn là gửi các bộ đệm pixel khổng lồ cho mỗi khung hình. Nếu yêu cầu tốc độ khung hình rất thấp, bạn có thể thoát khỏi việc gửi bộ đệm pixel nhưng sẽ thật lãng phí.
—
Vaughan Hilts
Có một dịch vụ gọi là OnLive thực hiện chính xác điều đó, cho các trò chơi hiện có. Nhưng họ có phần cứng máy chủ mạnh mẽ, khả năng kết nối cực nhanh và có thể là thuật toán nén video độc quyền để làm cho điều này khả thi. Vì vậy, nó không đơn giản và chắc chắn không rẻ hơn. Quan niệm rằng một cái gì đó như thế này sẽ dễ thực hiện hơn xuất phát từ quan niệm sai lầm của nhiều người, rằng viết mã mạng là một thứ cực kỳ khó làm, khó hơn nhiều so với mã hóa phần còn lại của trò chơi. Không phải vậy.
—
TC
Dự đoán phía khách hàng không trở nên cần thiết do kết xuất phía máy khách. Dự đoán phía khách hàng là cần thiết vì một số trò chơi được thiết kế để chơi trò chơi trên toàn thế giới và do tốc độ ánh sáng, độ trễ tối thiểu tuyệt đối giữa hai điểm ở phía đối diện trái đất là khoảng 133ms, chậm hơn khoảng 8 lần so với những gì cần thiết cho Trò chơi 60fps. Kết xuất phía máy chủ sẽ không giải quyết được vấn đề độ trễ, máy khách câm của bạn sẽ vẫn phải gửi đầu vào và đợi ít nhất 8 khung hình trước khi có thể kết xuất đầu ra.
—
Nói dối Ryan
Độ trễ không phải là vấn đề trong tất cả các trò chơi. Hầu hết mọi người có thể sẽ không chơi trò chơi Scrabble trực tuyến với độ trễ một giây.
—
dùng253751
Ví dụ, Ultima Online rất gần với điều đó - máy chủ gửi vị trí và loại đối tượng có thể nhìn thấy (mặc dù không phải đồ họa và đạo cụ tĩnh), máy khách chỉ gửi đầu vào dài 2-3 byte (di chuyển / tấn công / chính tả + hướng / mục tiêu / loại v.v.)
—
Tomáš Kafka