Hiệu suất phía máy chủ FPS nhiều người chơi


12

Điều này có liên quan đến Hiệu suất MMO ngoại trừ câu hỏi đó là về băng thông. Đây là về tải cpu.

Tôi kết hợp một FPS đơn giản bằng cách sử dụng node.js và webGL. Nó cực kỳ đơn giản, giống như bản sao BuddyMaze của Mê cung MIDI. Có rất ít điều xảy ra, mọi người đều di chuyển theo hai chiều (không có chiều cao), bắn những viên đạn đơn giản và chạy vào tường.

Ngay bây giờ, nếu tôi thực hiện nhiều kết nối đến máy chủ nơi mọi người chơi bắn nhanh trong khi quay vòng tròn, tôi có thể nhận được khoảng 15 - 20 người chơi trong trò chơi trước khi máy chủ rút hết lõi và chậm lại. Và đây là khi chạy ở tốc độ 30 khung hình / giây trên máy chủ. Ở tốc độ 10 khung hình / giây, tôi nhận được khoảng 25 - 30 kết nối. Điều này khá tệ, vì trò chơi sẽ còn nhiều việc phải làm sớm và tôi sẽ cần phải phù hợp với nhiều người chơi hơn để đây là một nỗ lực khả thi.

Anh tôi chỉ ra một số thống kê về máy chủ TF2 của đồng nghiệp. Máy chủ của anh ta có thông số kỹ thuật thấp hơn so với chúng tôi, nhưng nó chạy TF2, rõ ràng là một trò chơi phức tạp hơn nhiều, với con số khổng lồ 500 tick mỗi giây, với 36 người dùng mỗi lõi. Ngoài ra, chúng tôi hiện tiêu thụ nhiều băng thông hơn so với chúng, nhưng chúng tôi vẫn chưa cố gắng hạ thấp mức đó.

Sao có thể như thế được? Có những loại thủ thuật nào để tăng hiệu suất máy chủ đến mức độ này? Một số điều mà tôi biết bao gồm:

  • Giảm tốc độ khung hình trên máy chủ và nội suy các vị trí trên máy khách. Tôi đã nhận được một số lợi ích, nhưng rõ ràng máy chủ TF2 thậm chí không bận tâm đến điều này.
  • Làm những việc đắt tiền như phát hiện va chạm trên máy khách và xác minh nó không thường xuyên trên máy chủ. Tôi chưa chuyển cái này đến bây giờ, tôi sẽ tối nay. Mặc dù vậy tôi không mong đợi một lợi ích to lớn như vậy.
  • Chia sân chơi thành các khu vực (cây bốn phương) để giảm thiểu tính toán. Chưa có cơ hội cho việc này.
  • Tôi đã xem xét khả năng đáng tiếc rằng node.js chỉ chậm hơn bất cứ thứ gì TF2 đang sử dụng và có thể không phù hợp với loại tác vụ cường độ cao này.
  • Có phải tất cả trong ma thuật cấu hình máy chủ?

Vì vậy, các thủ thuật khác của ngành chỉ làm tối thiểu trên máy chủ nhưng vẫn có trải nghiệm trò chơi hoàn hảo là gì? Có một cuộc xung đột lớn giữa "trì hoãn khách hàng để tiết kiệm thời gian cpu" và "không tin tưởng khách hàng", vì vậy có thể giúp biết được đường kẻ được vẽ ở đâu trong các tình huống khác nhau?

Cập nhật

Profiling thực sự là câu thần chú duy nhất tôi từng thấy đó là hoàn toàn không thể sai lầm. Tôi nhanh chóng bọc một số hàm thời gian xung quanh mã của mình (cảm ơn, FP!) Và phát hiện ra điều tôi không bao giờ mong đợi: hành động truyền phát dữ liệu tới các máy khách chiếm gần như toàn bộ thời gian thực hiện. Cụ thể, khoảng 90% của nó. Thử nghiệm thêm cho thấy thời gian này phụ thuộc vào cả số lượng khách hàng và kích thước của dữ liệu, nhưng nhiều hơn sau đó. Khi tải 20 người dùng, tôi đã giảm 90% thời lượng phát sóng, từ 24ms xuống chỉ còn hơn 2ms bằng cách chỉ gửi "{}" thay vì dữ liệu đầy đủ. Nhưng chỉ với 5 người dùng, phát sóng mất khoảng 0,5 ms. Vì vậy, tôi rõ ràng cần phải làm một số tối ưu hóa ở đây.

Cải tiến rõ ràng nhất đầu tiên là dòng kiểm tra thị lực. Điều này sẽ làm giảm cả số lượng người quan tâm đến dữ liệu và cả lượng dữ liệu được gửi cho các bên quan tâm. Có những thủ thuật nào khác trong lĩnh vực này mà tôi có thể thử, trong đó tập trung vào việc giảm thiểu chi phí cho hoạt động phát sóng của tôi?


5
Hồ sơ mã thực sự là tất cả tôi có thể đề nghị. Tôi đoán là nó không tinh chỉnh như bạn nghĩ và đó là lý do tại sao TF2 đang chạy tốc độ đánh dấu cao hơn trên phần cứng ít hơn. Tôi cũng nghĩ rằng TF2 có thể đang làm tất cả những điều bạn đề nghị làm và kết quả là góp phần giải thích tại sao hiệu suất của chúng cao hơn.
Nate

1
Tôi rất thích nghe kết quả mới nhất của bạn, bạn có thể có được hiệu suất tốt hơn từ node.js không?
iddqd

Câu trả lời:


5

Máy chủ của bạn không nên gửi trạng thái của tất cả người chơi cho tất cả người chơi ở mỗi tích tắc. Thay vào đó, nó sẽ gửi một thông điệp được chế tạo đặc biệt tới mỗi khách hàng nói rằng cứ sau 500 ms nói rằng "những người chơi x này trong cổng xem của bạn nên ở các tọa độ này trong 500 ms." Hầu hết thời gian điều này sẽ hoạt động tốt, nhưng nếu máy chủ nhận ra nó đã cung cấp thông tin sai, nó chỉ gửi một thông báo thêm.

Điều này sẽ làm giảm lưu lượng mạng đáng kể.

Một điều khác cần xem xét là không có dấu kiểm trò chơi trên máy chủ mà thay vào đó, khách hàng chỉ gửi tin nhắn khi có hành động xảy ra (đổi hướng, bắn bị bắn) và sau đó tính toán trước trên máy chủ khi nhận được hành động.


Vâng, tôi đang thêm dòng kiểm tra tầm nhìn ngay bây giờ. Trên thực tế mức tăng là tối thiểu, từ 45 ms cho 25 người chơi, xuống còn 35 ms. Nhưng có thể có một số chi phí phụ để sử dụng các lệnh gửi riêng lẻ thay vì phát sóng. Và tôi chỉ gửi tin nhắn trên đầu vào. Nhưng bạn đã đúng, có thể có một cách để không phải đánh dấu vào tất cả, chỉ khi nhận được đầu vào.
Tesserex

1

Tôi đã xem xét khả năng đáng tiếc rằng node.js chỉ chậm hơn bất cứ thứ gì TF2 đang sử dụng và có thể không phù hợp với loại tác vụ cường độ cao này.

Có lẽ đây là. Máy chủ của TF2 được viết bằng C / C ++ và do đó, sẽ nhanh hơn node.js (nếu tôi nhớ chính xác, sử dụng Javascript được diễn giải trong Java)

Quake dựa trên WebGL của Google sử dụng java cho máy chủ và mã nguồn được tìm thấy tại đây: http://code.google.com.vn/p/quake2-gwt-port/ . Có thể đáng để xem qua điều đó để xem nó đã được thực hiện như thế nào. Tôi cũng tự hỏi ý của bạn là gì khi bạn nói về việc có tốc độ khung hình trên máy chủ. Không có lý do để kết xuất bất cứ thứ gì trên máy chủ, nó chỉ nên ở đó để xử lý các lệnh được gửi bởi máy khách.

Cuối cùng, quy tắc "không tin tưởng khách hàng" quan trọng hơn việc giảm tải các tính toán đắt tiền cho khách hàng với hy vọng cải thiện hiệu suất. Đặc biệt là một cái gì đó quan trọng như phát hiện va chạm. Chắc chắn là như vậy khi trò chơi của bạn dựa trên Javascript, và do đó khá dễ bị hack (so với một cái gì đó như TF2 được biên dịch).

Tôi biết đây không phải là một câu trả lời, nhưng hy vọng nó sẽ chỉ cho bạn một vài hướng có thể giúp cải thiện hiệu suất.


7
Tôi nên nói tỷ lệ đánh dấu thay vì tốc độ khung hình. Tất nhiên không có gì ám chỉ trên máy chủ. Tôi có nghĩa là khoảng thời gian mà nó xử lý các lệnh trong vòng lặp trò chơi. Ngoài ra một vài câu trả lời gợi ý rằng bạn có thể đưa ra những thứ như phát hiện va chạm cho khách hàng, miễn là bạn thực hiện xác minh ngẫu nhiên cứ sau vài giây. Có người nói rằng nó loại bỏ những kẻ gian lận khá nhanh.
Tesserex
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.