Là một trò chơi nhiều người chơi trong JavaScript là một ý tưởng tồi? [đóng cửa]

8

Những nhược điểm có thể có khi sử dụng JavaScript (phía máy khách) khi tạo trò chơi nhiều người chơi là gì?

Mô tả trò chơi: Đó là một MMORPG / RTS. Điều đó có nghĩa là người chơi đóng góp tích cực vào các cấu trúc trên thế giới và tự tạo ra nhiều nội dung.

2d multiplayer javascript

— jcora
nguồn

Tôi tò mò: bạn sử dụng cơ chế nào để máy khách nói chuyện với máy chủ và độ trễ như thế nào? Bạn đang sử dụng nền tảng nào cho máy chủ?

— Sẽ

Máy chủ đang chạy trên netbook của tôi chạy Ubuntu Linux và nó được viết bằng JavaScript phía máy chủ, chạy bằng node.js.

— jcora

Tôi không biết tại sao ban đầu tôi nêu lên câu hỏi này. Thay đổi thành một downvote và xem xét bỏ phiếu gần, bởi vì "có phải là một ý tưởng tốt?" không bao giờ thực sự là một câu hỏi có thể trả lời. Thật vậy, trong câu trả lời của tôi, tôi thậm chí còn chỉ ra rằng câu hỏi không thể trả lời chính xác.

— jhocking

Ngoài ra, tôi cảm thấy muốn thay đổi tiêu đề thành "Trò chơi nhiều người chơi trong JavaScript có phải là ý tưởng tồi không?" sẽ cải thiện câu hỏi. Lúc đầu có vẻ như là một thay đổi nhỏ, nhưng việc đặt lại câu hỏi như tìm kiếm nhược điểm khiến nó trở nên dễ trả lời hơn là "tôi nên sử dụng công nghệ nào?" loại câu hỏi. Hỏi "công nghệ này có tốt không?" chỉ mời mài rìu.

— jhocking

1

Tôi không biết mod nghĩ gì nhưng tôi thích nó hơn bây giờ rất nhiều. quay lại upvote

— jhocking

9

Sẽ ổn thôi nếu:

Máy chủ không gửi bất kỳ thông tin nào về người chơi phía sau trường quan sát của người chơi cục bộ (phải được tính toán bên máy chủ) cho người chơi cục bộ (để ngăn chặn hành vi treo tường).
Tất cả các hành động được kiểm tra tính khả dụng trên máy chủ khi người chơi nhấn nút hành động.
Bạn chỉ kết xuất trên máy khách - tất cả các hành động được thực hiện trên máy chủ và chỉ dự đoán trên máy khách.
Tất cả các hành động hẹn giờ là máy chủ.

— Tam giác3l
nguồn

Vâng, tôi đang làm những điều này.

— jcora

10

Xin lưu ý rằng các hướng dẫn này có giá trị cho mọi trò chơi nhiều người chơi, bất kể ngôn ngữ, nền tảng hay bất cứ điều gì.

— o0 '.

10

Trò chơi của bạn có phù hợp để phát triển JavaScript hay không tùy thuộc vào trò chơi. Bạn đã không mô tả trò chơi của mình, vì vậy không có cách nào để chúng tôi trả lời câu hỏi trong tiêu đề.

Tuy nhiên tôi có thể nói rằng mối quan tâm hack của bạn không phải là một vấn đề ở đây. Không phải vì JavaScript không thể bị hack (có thể và dễ dàng) mà mọi công nghệ phía máy khách khác cũng vậy.Một trong những nguyên lý cơ bản của phát triển trò chơi nhiều người chơi là "không bao giờ tin tưởng khách hàng". Thiết kế trò chơi của bạn theo cách mà bất cứ thứ gì bạn cần để bảo vệ khỏi hack đều chạy trên máy chủ, bởi vì máy khách sẽ bị hack. Điều này có nghĩa là chỉ gửi các lệnh UI từ máy khách (ví dụ: "người chơi đã nhấp vào nút Bomb") và tính toán kết quả của các hành động của người chơi trên máy chủ. Sau đó, máy chủ gửi lại cho khách hàng kết quả của những hành động đó.

Vì dù bạn dựa vào công nghệ nào, bạn cũng nên thiết kế trò chơi của mình với giả định rằng thành phần phía máy khách sẽ bị hack, tính hack của JavaScript không phải là điều cần cân nhắc khi quyết định có sử dụng JavaScript hay không.

— jhocking
nguồn

Cảm ơn rất nhiều. Tôi sẽ chỉnh sửa bài viết của tôi và mô tả trò chơi bây giờ.

— jcora

3

không bao giờ không bao giờ không bao giờ không bao giờ tin tưởng khách hàng, cho dù javascript của nó hoặc cái gì khác!

— the_e

1

Trong khi tất cả các máy khách trò chơi thực sự có thể hack, một số có thể hack nhiều hơn những cái khác.

— Jonathan Connell

2

Đó là sự thật, nhưng sự khác biệt là không liên quan. Khi thiết kế bảo mật cho trò chơi của bạn, có vấn đề gì nếu tùy chọn A khó hack hơn tùy chọn B nếu cả hai sẽ bị hack?

— jhocking

2

Mọi người có thể thay đổi mã máy khách để gian lận, đó là một vấn đề đối với bất kỳ trò chơi nhiều người chơi nào. Nếu tốc độ phản ứng hoặc giải quyết nhanh chóng các nhiệm vụ toán học là một phần của trò chơi, bạn hoàn toàn không thể ngăn chặn gian lận.

Đối với bất kỳ yếu tố trò chơi nào khác, bạn phải đảm bảo rằng khách hàng sẽ không và không thể lấy thông tin được cho là ẩn cho người chơi. Và tất nhiên, máy chủ phải xác nhận rằng mọi hành động của người chơi là hợp pháp.

Vấn đề lớn nhất tôi thấy trong các trò chơi JavaScript là rất nhiều trình duyệt có xu hướng nói lắp, đặc biệt là Firefox khá tệ trong lần kiểm tra trước. Vì lý do này, JavaScript không phải là một lựa chọn tốt cho trò chơi nhạy cảm với thời gian. Nhưng đối với các trò chơi theo lượt hoặc ít nhất là trò chơi có nhịp độ chậm, JavaScript có thể hoạt động khá tốt.

— aaaaaaaaaaaa
nguồn

2

Việc thay đổi các biến Javascript khá dễ thực hiện với các công cụ như Fireorms (cho firefox) hoặc công cụ xây dựng trong dev / Safari. Bạn có thể chỉ cần gõ javascript trong bảng điều khiển và nó sẽ được thực thi. Như một quy tắc đơn giản, không dựa vào phía khách hàng để bảo mật. Ngoài ra, với việc giới thiệu yếu tố canvas HTML5, javascript cung cấp cho bạn một số khả năng thực sự cho các trò chơi đơn giản (ví dụ, có một phiên bản javascript / html5 đầy đủ của Angry Birds).

— Pjotterke
nguồn