Giải pháp tốt nhất cho trò chơi Android thời gian thực nhiều người chơi [đã đóng]

Tôi dự định tạo trò chơi nhiều người chơi cho Android (2-8 người chơi) và tôi xem xét, giải pháp nào cho tổ chức nhiều người chơi là tốt nhất:

1. Tạo máy chủ trên PC và máy khách trên thiết bị di động, tất cả các cộng đồng đều đi qua máy chủ (ClientA -> PC SERVER -> Tất cả khách hàng)

2. Sử dụng bluetooth, tôi chưa sử dụng và tôi không biết có khó để tạo nhiều người chơi trên bluetooth không

3. Tạo máy chủ trên một trong các thiết bị và các thiết bị khác kết nối (thông qua mạng, nhưng tôi không biết có khó giải quyết vấn đề với các thiết bị qua NAT không?)

4. Giải pháp nào khác?

Tuyên bố miễn trừ trách nhiệm; Tôi chưa làm được gì nhiều với java và nền tảng Android.

Tuy nhiên, trải nghiệm sâu rộng hơn của tôi với các ngôn ngữ '.net' trên nền tảng di động windows, cùng với nền tảng windows, là 75-90% tất cả các mã cần thiết để tạo và duy trì kết nối Bluetooth hoặc dữ liệu mạng được duy trì / được hỗ trợ với HĐH hoặc các thư viện sẽ cần truy cập vào phần cứng.

Cho đến nay điều này cũng có vẻ đúng với Android, với hệ điều hành phơi bày hệ điều hành để tạo kết nối dữ liệu qua Bluetooth hoặc internet, cùng với việc bật / tắt phần cứng tương ứng.

Tôi sẽ tưởng tượng rằng Bluetooth sẽ là phương thức kết nối ưa thích, vì đây sẽ là phương thức ít tốn kém nhất để thực hiện (Không có máy chủ). Và cho phép thu thập / trò chơi địa phương nhiều hơn. Bluetooth khá dễ sử dụng. nó hoạt động tương tự như các ổ cắm mạng thông thường khi bạn biết bạn muốn kết nối với thiết bị nào.

Những cái khác là chính xác ở chỗ Bluetooth v2.0 / v2.1 hiện không có khả năng hỗ trợ tải dữ liệu lớn. Điều này sẽ thay đổi với sự lây lan cuối cùng của v3.0 và cao hơn. và có nhiều cách để vượt qua giới hạn này.

Bây giờ mặc dù có một khái niệm đơn giản, nhưng giải pháp phức tạp, mà bạn có thể muốn thử. Tôi đã sử dụng nó một lúc, Nó tương tự như ngang hàng, nhưng nó liên quan đến việc trò chơi được lưu trữ trên tất cả các thiết bị cùng một lúc. Theo cách đó, nếu một kết nối tạm thời bị mất, bị chậm hoặc người chơi bị hủy vì bất kỳ lý do gì, những người chơi khác sẽ không bị ảnh hưởng. Điều này cho phép người dùng đã bị loại bỏ để tham gia lại trò chơi đang diễn ra với rất ít hoặc không có sự gián đoạn nào đối với người chơi khác hoặc trò chơi của riêng họ.

CON: Mỗi người chơi thực sự sẽ chơi một phiên bản trò chơi hơi độc đáo của riêng họ, điều đó sẽ được liên kết với những người chơi khác để giữ cho các trò chơi không đi lạc quá xa với nhau.

CON: Mã hỗ trợ có thể mở rộng / phức tạp và khó khăn để quấn đầu bạn tùy thuộc vào những gì bạn muốn đạt được.

PRO: Không yêu cầu máy chủ trung tâm hoặc thiết bị! Không cần bảo trì $$$.

PRO: Việc trao đổi dữ liệu nặng nề sẽ chỉ xảy ra khi người chơi (tái) tham gia hoặc trò chơi được khởi tạo. - Ngay cả điều này có thể được giảm bằng cách đảm bảo rằng tất cả các trò chơi sẽ được tạo ra và tiến triển theo cùng một cách bởi tất cả người chơi. TIỀM NĂNG làm giảm mức tiêu thụ năng lượng xảy ra do sử dụng mạng nặng.

CHUYÊN NGHIỆP: Dữ liệu trở nên ít nhạy cảm về thời gian hơn, vì các thiết bị sẽ có tất cả dữ liệu họ cần để duy trì trò chơi mà không cần người chơi khác. Cho phép bạn tập trung nhiều hơn vào trải nghiệm trò chơi thực tế cho từng người dùng, thay vì một nhóm người chơi.

Tôi đã thiếu thời gian để thực hiện một công cụ trò chơi chuyên sâu đầy đủ sử dụng điều này. Các trò chơi tôi đã thực hiện bị giới hạn trong việc tạo lại các trò chơi tương tự như Monopoly và Uno, có vẻ như hoạt động rất tốt.

Đơn giản nhất là cái mô phỏng Uno. Về cơ bản, tôi xếp chồng những người thua cuộc sau khi một người chơi giành chiến thắng để đảm bảo rằng người chơi đó thắng tất cả các trò chơi. 95% + thời gian tôi không thể nói rằng tôi đã không chơi chính xác trò chơi như mọi người khác.

Tôi bắt đầu xây dựng một trò chơi tương tự như Master of Orion II, nhưng bản thân trò chơi này hơi nhiều để tôi tự thực hiện.

Nó phụ thuộc rất nhiều vào trò chơi, nhưng một số bạn bè và tôi đã suy nghĩ về những vấn đề tương tự chỉ một vài tháng trước, và đây là những gì chúng tôi xác định. Tôi đang ở trong một tâm trạng thuận và nhược điểm một lần nữa.

Máy chủ dựa trên máy tính

Ưu

• Đã thử và đúng
• Có thể mở rộng

Nhược điểm

• Cần phải viết một "nhiều máy chủ" có thể lưu trữ nhiều trò chơi cùng một lúc. Điều này có thể sẽ sử dụng công nghệ hơi khác so với điện thoại Android của bạn. Bạn vẫn có thể sử dụng java, nhưng bạn vẫn có thể sử dụng các gói Android?
• Có thể tốn kém để chạy, và duy trì
• Bạn có khả năng có thể kéo nó xuống một ngày vì lý do chính đáng. Người hâm mộ có thể không vui nếu máy chủ ngừng hoạt động chỉ một vài tháng sau khi mua trò chơi.

Peer To ngang hàng với một trong số họ kiểm soát

Ưu

• Máy chủ đặc biệt nơi bạn bè có thể tham gia cùng những người bạn khác khi họ muốn
• Ít đến không có chi phí hoạt động từ phía bạn
• Mã máy chủ sẽ được trộn lẫn với mã máy khách, không cần phải viết một ứng dụng máy chủ riêng.

Nhược điểm

• Cần phải viết một công cụ tìm ngang hàng tập trung đơn giản. (Tôi đã khai thác php + mysql trong vài trăm dòng dễ dàng)
• Các máy chủ đang chạy trên điện thoại. Điện thoại có thể bị chậm. Tất cả các điện thoại mục tiêu sẽ có thể lưu trữ một trò chơi?
• Điều gì xảy ra nếu điện thoại máy chủ bị ngắt kết nối?
• Dễ dàng hơn máy khách-máy chủ để tin tặc xâm nhập

Đối với bluetooth, tôi hy vọng rằng nó tương tự như phương pháp ngang hàng ở trên. Tôi cũng không nghĩ rằng bạn nên có bất kỳ vấn đề nào với NAT.

EDIT : Nó cũng phụ thuộc nhiều vào kinh nghiệm của bạn. Tôi sẽ bắt đầu bằng cách viết một số trò chơi máy khách / máy chủ tương đối nhỏ để có được kết nối mạng trước tiên. Đây là một chủ đề khó mà dễ bị sai ngay lần đầu tiên. Tôi đã nhận của tôi ngay lần thử thứ ba. Thực hiện theo các mô hình đã biết và đừng cố gắng tự tạo ra thứ gì đó.

Một trong những cân nhắc lớn nhất bạn cần thực hiện là độ tin cậy. Điện thoại không đáng tin cậy lắm; thực tế, có lẽ bạn nên cho rằng trong một trò chơi 8 người, một người nào đó có khả năng ngắt kết nối (cuộc gọi đến, tiếp nhận không tốt, người chơi bỏ cuộc ...)

Với suy nghĩ này, hãy hiểu rằng bạn nên giảm thiểu tác động của người dùng bị ngắt kết nối. Trong tùy chọn thứ hai của bạn, về cơ bản, bạn đã tạo một điện thoại cho máy chủ. Nếu điện thoại đó đi MIA, trò chơi sẽ kết thúc hiệu quả với tất cả người chơi.

John đã đề cập đến những ưu và nhược điểm của kiến ​​trúc máy khách <-> truyền thống. Đây có lẽ là cách kiên cường nhất để cung cấp trải nghiệm nhiều người chơi đáng tin cậy cho mọi người.

Bạn cũng có thể xem xét một kỹ thuật dọc theo dòng mô phỏng bước khóa. Điều này có thể được thực hiện theo cách hoàn toàn ngang hàng. Ý tưởng chung là mọi khách hàng đều được yêu cầu gửi bản cập nhật (chuỗi lệnh hoặc thiếu) mỗi bước mô phỏng. Trong bước mô phỏng tiếp theo, các lệnh của mỗi người chơi được áp dụng cho logic trò chơi. Nhiều trò chơi RTS sử dụng loại chương trình mạng này.

Kỹ thuật này có thể khó thực hiện và có thể rất khó gỡ lỗi. Nó chắc chắn là khó khăn hơn so với việc có một kiến ​​trúc máy khách-máy chủ truyền thống hơn. Nó cũng bao hàm độ trễ giữa đầu vào của người chơi và khi trò chơi phản hồi lại đầu vào. Tuy nhiên, nếu một người chơi thả ra, những người chơi còn lại chỉ có thể loại anh ta khỏi trò chơi và tiếp tục. Nó cũng có khả năng làm giảm lưu lượng mạng so với các chương trình khác.

Nếu bạn muốn tìm hiểu thêm về kỹ thuật này, bắt đầu với này bài báo xuất sắc về đề tài này. Mặt khác, tôi sẽ không khuyến khích mạnh mẽ sơ đồ mạng trong đó một điện thoại duy nhất chịu trách nhiệm cho phiên nhiều người chơi và đề xuất kiến ​​trúc máy khách <-> đơn giản hơn.