Kiến trúc phía máy chủ cho trò chơi trực tuyến


7

về cơ bản, tôi có một ứng dụng khách trò chơi đã giao tiếp với máy chủ cho hầu hết mọi hành động, trò chơi này là Java (sử dụng LWJGL) và ngay bây giờ tôi sẽ bắt đầu tạo máy chủ.

Cơ sở của trò chơi thường là một khách hàng giao tiếp với máy chủ, nhưng tôi sẽ yêu cầu sau này để một số khách hàng làm việc cùng nhau cho một số chức năng.

Tôi đã đọc cách phân tách máy chủ xác thực và tôi dự định thực hiện nó. Vấn đề là tôi hoàn toàn thiếu kinh nghiệm trong loại lập trình phía máy chủ này, tất cả những gì tôi từng lập trình là các ứng dụng web của JSF.

Tôi tưởng tượng rằng tôi sẽ thực hiện các kết nối ổ cắm cho hầu hết mọi giao tiếp trò chơi vì HTML rất chậm, nhưng tôi vẫn không thực sự biết bắt đầu từ đâu trên máy chủ của mình.

Tôi sẽ đánh giá cao việc đọc tài liệu hoặc hướng dẫn về nơi bắt đầu, máy chủ trò chơi nên có kiến ​​trúc gì và có thể một số đề xuất về các khung có thể giúp tôi có được giao tiếp giữa máy khách và máy chủ.

Tôi đã xem xét JNAG nhưng tôi không có kinh nghiệm với loại điều này, vì vậy tôi thực sự không thể biết liệu đây có phải là một lớp nhắn tin tốt và tốt hay không.

Bất kỳ trợ giúp đều được đánh giá cao ... Cảm ơn!

BIÊN TẬP:

Chỉ cần thêm một chút thông tin về trò chơi. Nó được dự định là một trò chơi rất phức tạp với một số chức năng, làm cho một số chức năng trở thành một "chương trình" bên trong chương trình. Nó không phải là một trò chơi thông thường, như FPS hay RPG nhưng tôi dự định sẽ có nhiều người dùng sử dụng nhiều "chương trình" khác nhau này trong trò chơi.

Nếu tôi không đủ rõ ràng, tôi thực sự đánh giá cao những người đã phát triển trò chơi với kiến ​​trúc máy khách / máy chủ java, cách họ giao tiếp, bất kỳ khung, apis, hệ thống nhắn tin, v.v.

Đó không phải là một câu hỏi thiếu kiến ​​thức về ngôn ngữ, hơn nữa là một câu hỏi cho lời khuyên, vì vậy tôi không kết thúc việc tạo ra một cái gì đó hoạt động, nhưng trong các giai đoạn sau sẽ phải viết lại cho bất kỳ lý do hạn chế nào. PS: xin lỗi nếu tiếng anh của tôi không hoàn hảo ...


1
Các máy chủ Multiverse được viết bằng Java theo như ghi nhớ, nhưng có vẻ như bạn đã có một trò chơi. Tuy nhiên, có một tổng quan cấp cao đẹp mà bạn có thể xem tại đây: update.multiverse.net/wiki/index.php/ mẹo
DrDeth

Trong khi kiến ​​trúc máy chủ trò chơi của bạn sẽ được xác định bởi trò chơi nói chung. Nó là rất nhiều nền tảng và thể loại phụ thuộc. Nếu bạn đang lập kế hoạch cho nhiều người dùng, Java là một cơ hội tốt để sử dụng [Bean Beanalk] của Amazon [1]. Đây là một cách tuyệt vời để mở rộng quy mô máy chủ của bạn theo yêu cầu. Có lẽ bạn nên cho chúng tôi biết thêm về trò chơi - JNAG có thể nhiều hơn những gì bạn cần tức là. trong một trò chơi dựa trên tối đa 4 người chơi. [1]: aws.amazon.com/elasticbeanstalk
Konrad K.

Câu trả lời:


12

Thật không may, tôi không biết về bất kỳ tài nguyên hoặc sách trực tuyến (tốt) nào về chủ đề này. Và tôi không biết Java. Tuy nhiên, thấy rằng chưa có câu trả lời nào, tôi sẽ chia sẻ một vài lời khuyên từ kinh nghiệm cá nhân.

Trước hết, bạn cần một RPC nhanh và đáng tin cậy , hoặc ít nhất là cơ chế xếp hàng tin nhắn. Đây là những gì sẽ được sử dụng cho cả giao tiếp máy khách-máy chủ và máy chủ-máy chủ. Tôi không biết nếu có bất kỳ giải pháp làm sẵn nào cho Java. Với .NET, chúng tôi luôn tạo ra một tùy chỉnh của riêng mình, vì cơ chế này thực sự quan trọng. Thông thường nhất là một giao thức tin nhắn nhị phân nhẹ qua TCP được sử dụng, nhưng các tùy chọn khác có thể tốt hơn tùy thuộc vào loại trò chơi. Chiến lược theo lượt có thể tốt hơn với XML hoặc SOAP và một game bắn súng có nhịp độ nhanh có thể đảm bảo UDP.

Tối thiểu tuyệt đối cho hệ thống nhắn tin là khả năng gọi các hành động từ xa một cách đáng tin cậy, trong khi vẫn đảm bảo trật tự của chúng . Một bổ sung thực sự hữu ích là hỗ trợ cho mẫu câu trả lời yêu cầu, trong đó một hành động từ xa có thể trả về một số loại kết quả cho người khởi tạo nó. Điều này là không bắt buộc, nhưng có thể làm cho cuộc sống của bạn dễ dàng hơn nhiều.

Khi bạn có tin nhắn của mình, hãy nghĩ về việc phân vùng máy chủ của bạn. Rất có thể, một máy chủ duy nhất sẽ không đủ để lưu trữ trò chơi cho tất cả người chơi. Bạn cần xem xét cẩn thận những nhiệm vụ nào có thể độc lập với nhau và do đó có thể được ủy quyền cho các máy chủ khác nhau. Xác thực và đăng nhập là ứng cử viên rõ ràng nhất cho phân vùng này. Trong số những người khác là tính toán thống kê và xếp hạng, giao tiếp cơ sở dữ liệu (một máy chủ để thực hiện bộ đệm DB chuyên dụng). Vấn đề với các trò chơi MMO, trái ngược với các ứng dụng web, là chúng có xu hướng rất cao, với nhiều dữ liệu cần thiết cho mỗi người chơi. Và hầu hết các hoạt động yêu cầu quyền truy cập vào tất cả hoặc gần như tất cả các dữ liệu này.

Ngay cả khi bạn sử dụng một máy chủ, bạn cũng phải tận dụng nhiều bộ xử lý. Bất kỳ máy chủ MMO nào cũng là một chương trình đồng thời cao (máy chủ hiện tại của chúng tôi có khoảng 30 luồng đồng thời). Để có bất kỳ hy vọng giải quyết vấn đề đồng bộ hóa, bạn phải cách ly các luồng khác nhau. Giống như các máy chủ khác nhau, họ sẽ có dữ liệu của riêng mình và sẽ giao tiếp bằng một số loại giao diện truyền tin nhắn. Thậm chí có thể cùng một RPC mà mạng của bạn sử dụng, nếu nó đủ nhanh.

Sau đó, bạn có cơ sở dữ liệu của bạn. Người chơi MMO thường làm rất nhiều thứ và tạo ra rất nhiều trò chuyện trong thế giới trò chơi, phải được lưu trong cơ sở dữ liệu. Tất cả các máy chủ tôi làm việc cùng không lưu chúng ngay lập tức - thay vào đó, các thay đổi được tích lũy trong bộ nhớ và sau đó được lưu hàng loạt sau mỗi 5 phút hoặc lâu hơn. Điều này cho phép trò chơi tiến triển thuận lợi hơn, với chi phí chậm trễ có thể xảy ra khi viết. Sự chậm trễ này là lý do chính để có một máy riêng để liên lạc cơ sở dữ liệu.

Thông thường các trò chơi MMO sử dụng cơ sở dữ liệu quan hệ làm phụ trợ dữ liệu của họ, nhưng tôi tin rằng cơ sở dữ liệu NoQuery có thể tốt hơn. Thông thường, bạn có một loạt dữ liệu trong DB cho mỗi ký tự, tải tất cả dữ liệu khi ký tự được đăng nhập và rất hiếm khi, nếu có, thực hiện bất kỳ truy vấn phức tạp nào. Chế độ hoạt động này dường như là sở trường của NoQuery. Điều đó nói rằng, tôi chưa sử dụng NoQuery DB với máy chủ MMO thực tế, vì vậy tôi có thể sai ở đây.

Một điều khác liên quan đến cơ sở dữ liệu tôi muốn cảnh báo bạn là điều này. Nhiều nhà phát triển, đặc biệt là sớm trong chu kỳ sản xuất, sẵn sàng lưu trữ dữ liệu "thiết kế trò chơi" trong DB. Tôi đang nói về những thứ như các thông số, khả năng, vật phẩm và các thứ khác như thế. Đừng làm vậy. Những thứ này thực sự là dữ liệu tĩnh không thay đổi trừ khi có bản cập nhật máy chủ; và dữ liệu này luôn luôn cần thiết bởi máy chủ. Thông thường, bạn sẽ không thực hiện bất kỳ truy vấn nào ngoại trừ SELECT * ...khi máy chủ khởi động. Do đó, bạn không thực sự cần một cơ sở dữ liệu và việc có những thứ này trong DB có rất nhiều nhược điểm. Đối với một, bạn không thể đặt cơ sở dữ liệu dưới sự kiểm soát nguồn.

Đây là ba thành phần chính cho kiến ​​trúc máy chủ MMO: giao tiếp mạng, phân vùng logic và truy cập cơ sở dữ liệu. Tất cả logic sử dụng ba có lẽ là rất phụ thuộc vào trò chơi. Tôi có thể có thêm một số lời khuyên nếu bạn hỏi những câu hỏi cụ thể hơn và cho chúng tôi biết thêm về trò chơi.


Tôi rất muốn nhận được nhiều lời khuyên từ bạn nhưng tôi không thể tìm cách liên lạc trực tiếp với bạn (một PM hoặc đại loại như thế). Chỉ không muốn tiết lộ bên trong trò chơi của tôi công khai.
Draiken

Bạn có thể liên hệ với tôi qua email và / hoặc googletalk tại cthulhu dot trong tại gmail dot com.
Nevermind

4
Mặc dù tôi thực sự khuyên bạn nên hỏi càng nhiều càng tốt ở đây, và không riêng tư. Bằng cách đó, nó mang lại lợi ích cho nhiều người hơn và bạn sẽ nhận được câu trả lời tốt hơn.
Nevermind

0

Bạn có thể muốn xem xét lập trình ổ cắm. Đây là một giới thiệu cơ bản sẽ giúp bạn bắt đầu.

Hoặc chỉ cần thực hiện tìm kiếm Google cho các ổ cắm java và bạn sẽ tìm thấy nhiều tài liệu.


1
Tôi đã sử dụng ổ cắm trước đây, đã sử dụng RMI, EJB và các cách giao tiếp khác, nhưng vấn đề không phải là cơ bản của việc sử dụng nó, đó là cách nó NÊN sử dụng hoặc tại sao nên sử dụng cách này hay cách đó.
Draiken

Ồ được thôi. Tôi đọc sai câu hỏi của bạn rồi. Lấy làm tiếc.
bummzack
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.