Kiến trúc máy chủ cho trò chơi nhiều người chơi?

Question

Tôi đang lên kế hoạch xây dựng một trò chơi nhiều người chơi nhỏ có thể chạy dưới dạng applet java hoặc tệp flash trong trình duyệt web. Tôi đã không thực hiện bất kỳ lập trình máy chủ trước, vì vậy tôi tự hỏi những gì sắp xếp của kiến ​​trúc máy chủ tôi cần phải có. Nó sẽ dễ dàng cho tôi để tạo tập tin perl/php trên máy chủ, mà các liên hệ mã java/flash để cập nhật vị trí/hành động của người chơi, v.v. Nhưng tôi đang xem xét liệu tôi có nên có một trang web chuyên dụng hay không máy chủ, mà hệ điều hành để sử dụng, cơ sở dữ liệu, vv Ngoài ra, số lượng băng thông được sử dụng và khả năng mở rộng là một xem xét.

Một tùy chọn khác có thể sử dụng hệ thống lưu trữ đám mây (trái ngược với máy chủ chuyên dụng), vì vậy họ sẽ quan tâm đến việc bổ sung thêm máy khi trò chơi phát triển. Miễn là mỗi máy chủ chạy các tập tin perl/php lõi để cập nhật cơ sở dữ liệu, nó sẽ hoạt động tốt.

Một tùy chọn khác có thể là sử dụng công cụ ứng dụng của Google.

Bất kỳ suy nghĩ nào về kiến ​​trúc máy chủ, lựa chọn hệ điều hành/cơ sở dữ liệu và liệu phương pháp sử dụng script perl/php/python của tôi cho lập trình phía máy chủ có tốt hay không!

Answer 1

Bạn cần làm rõ thêm về trò chơi và suy nghĩ thêm về kiến ​​trúc hơn là chi tiết triển khai cụ thể.

Câu hỏi chính là liệu trò chơi của bạn có theo thời gian thực, dựa trên cơ sở hoặc trì hoãn lâu dài (ví dụ: cờ điện tử). Một câu hỏi khác là liệu bạn có đang đóng băng trạng thái cho các lần tải lại tiếp theo hay không.

Tôi đặc biệt khuyên bạn nên tìm hiểu xem liệu tất cả người chơi trong cùng một trò chơi có được lưu trữ trên cùng một máy chủ hay không (ví dụ: 1000 trong số 4 người chơi so với 4 trận đấu của 1000 người chơi). Nếu có thể, đi với người đầu tiên và gắn bó tất cả mọi người trong cùng một trò chơi dưới cùng một máy chủ. Bạn sẽ có đủ thời gian đồng bộ hóa nhiều máy khách với một máy chủ, thay vì có nhiều máy chủ để người chơi được đồng bộ hóa. Nếu không, định nghĩa về tính nhất quán là vấn đề.

Nếu có thể, yêu cầu mỗi khách hàng liên lạc với máy chủ và sau đó máy chủ phân phối các bản cập nhật cho khách hàng. Bằng cách này, bạn có một "trạng thái chính thức" và có thể thực hiện nhiều giải pháp xung đột, ngữ nghĩa khác nhau, ... Đồng đẳng để mang lại hiệu suất tốt hơn trong các trò chơi nhanh hơn (ví dụ: FPS) nhưng giới thiệu rất nhiều vấn đề.

Tôi không thể cho cuộc sống của tôi thấy bất kỳ lý do thuyết phục nào để làm điều này và perl hoặc PHP. Trò chơi của bạn không dựa trên web, tại sao bạn nên viết nó bằng ngôn ngữ theo định hướng web? Sử dụng J2EE cũ tốt cho máy chủ và trao đổi dữ liệu với khách hàng của bạn thông qua XML và AJAX. Nếu có thể, hãy chạy một ứng dụng Java thực trên các máy khách thay vì các servlet. Sau đó, bạn có thể hưởng lợi từ việc sử dụng JMS sẽ giảm tải rất nhiều cho bạn bằng cách tóm tắt rất nhiều chi tiết liên lạc cho bạn.

Answer 2

Đối với kiến ​​trúc máy chủ của bạn, bạn có thể xem Three Rings' code. Họ đã viết một số trò chơi rất khả năng mở rộng trong Java (cả phía máy khách và phía máy chủ).

Answer 3

Tôi cũng sẽ không khuyến khích sử dụng PHP, HTTP cũng không phải là ý tưởng tốt nhất vì nó là không trạng thái và nói nhiều. Tôi đã làm việc một thời gian trong công ty hiện đang phát triển trò chơi nhiều người chơi thực sự lớn. Back-end là đồng bằng JVM (được kết nối qua tomcat bởi nhiều khách hàng và từ điện thoại di động một cho mỗi khách hàng). Vì vậy, tôi biết ít dữ liệu bạn chuyển các bộ đệm nhỏ hơn bạn cần trên máy chủ -> nhiều khách hàng hơn trên một máy và cũng có một phản ứng nhanh hơn một chút. Cũng xem xét bảo mật, https là khá tốn kém, đặc biệt là nếu bạn cần phải chuyển đồ họa và âm thanh.Giao thức Binnary của riêng bạn với thùng chứa khách không phải trình duyệt sẽ làm tốt nhất (lựa chọn tốt là giao thức có thể chuyển đổi cho thời gian phát triển-gỡ lỗi). Có lẽ âm thanh phức tạp nhưng không phải vậy. @ Sarah gợi ý tốt đẹp, cảm ơn quá;)