Có cách nào để tạo ra một thế giới năng động như MMORPG có thể mở rộng theo chiều ngang không?

Hãy tưởng tượng một thế giới mở gồm hơn 500 người chơi với dữ liệu thay đổi nhanh như 20 cập nhật / người chơi / giây. Lần trước tôi đã làm việc trong một MMORPG tương tự, nó đã sử dụng SQL, vì vậy, nó không thể truy vấn DB mọi lúc. Thay vào đó, nó tải tất cả người chơi từ DB vào bộ nhớ dưới dạng đối tượng C ++ và sử dụng chúng. Đó là, nó được thu nhỏ theo chiều dọc. Thay vào đó, có thể làm cho máy chủ đó có thể mở rộng theo chiều ngang không? Có một cơ sở dữ liệu được thiết kế để hỗ trợ số lượng cập nhật đồng thời không?

Trường hợp thử nghiệm gồm 500 người chơi đang liên lạc, đó là luồng thông tin 250K bay xung quanh ở tần số 20Hz. Băng thông nội bộ cho điều đó sẽ là, giả sử 100 byte mỗi tin nhắn, khoảng 500MB / giây. Âm thanh đầy tham vọng. Đặc biệt là giữa các quá trình.

Nếu bạn tách người chơi thành các nhóm 100 người, điều đó sẽ giảm xuống còn 20MB / giây, v.v. Đó là lý do tại sao các MMO có các vùng và trong các vùng đó ít bong bóng ảnh hưởng, và cứ thế giảm dần cho đến khi băng thông trở nên hợp lý.

Vấn đề ban đầu có thể được nói rằng nếu bạn có 10 người chia sẻ thông tin theo thời gian thực, nhưng bạn muốn có tất cả 500 chia sẻ , đó là sự tăng trưởng theo cấp số nhân của các liên kết truyền thông và làm thế nào chúng ta có thể khắc phục điều đó . Tôi sợ rằng không có viên đạn ma thuật nào mà tôi từng nghe nói có thể làm cho tiến trình hình học biến mất một cách kỳ diệu.

Không sử dụng cơ sở dữ liệu để liên lạc, đó là những gì nhắn tin dành cho. Sử dụng cơ sở dữ liệu để thực thi các giao dịch và lưu trữ thông tin mà bạn không muốn người chơi bị mất. Hầu hết các MMO mà tôi quen thuộc chỉ cập nhật cơ sở dữ liệu với thông tin người chơi động cứ sau 1-10 phút hoặc tại các điểm tiện dụng như chuyển vùng hoặc vào vùng "an toàn" trong thiết kế.

Bạn có thể phải thiết kế lại nhu cầu của trò chơi cho mọi người chơi, bất kể ở xa, để có các cập nhật theo thời gian thực của mọi nội dung ba lô của người chơi khác.

Đồng thời thay đổi mẫu cập nhật từ 20Hz thành tốc độ dựa trên khoảng cách, một người nào đó cách xa 1 dặm không cần biết rằng bạn đã di chuyển 1 feet trong đúng 230,6 giây, sau đó một chân khác ở mức 231,4 giây, họ có thể đối phó với bạn di chuyển 15 feet cứ sau 10 phút giây

Sử dụng diện tích lọc quan tâm. Nếu một thế giới được chia thành 3 máy chủ và khu vực trên máy chủ 1 không ở gần khu vực của máy chủ 3, không có lý do gì để họ chia sẻ thông tin về các thực thể cả.

Tương tự, trên một máy chủ, chỉ gửi thông tin liên quan đến khách hàng. Nếu người chơi A ở phía đối diện hoàn toàn trên bản đồ từ người chơi B, không có lý do gì để gửi thông tin cập nhật về B đến A hoặc ngược lại.

Khi bạn có nhiều máy chủ trong một thế giới liên tục, bạn sẽ có các thực thể gần một cạnh trên máy chủ 2 gần với các thực thể trên máy chủ 1. Bạn có thể gửi các bản cập nhật từ máy chủ "có thẩm quyền" cho một thực thể đến máy chủ khác (khi thích hợp) và tương tự chuyển tiếp bất kỳ tin nhắn nào đến máy chủ có thẩm quyền nếu thích hợp.

Có, trong trường hợp này, một máy chủ sẽ hơi lỗi thời đối với các thực thể cụ thể. Đừng cố gắng giải quyết điều đó. Chỉ cần đối phó với nó. Giả sử rằng các thực thể có thể là một chút lỗi thời. Thực hiện bất kỳ logic nào cần thông tin cập nhật chỉ trên máy chủ sở hữu chính thức các thực thể. Khi một thực thể ảnh hưởng đến một thực thể khác, hãy gửi một tin nhắn và cho rằng nó có thể mất nhiều dấu logic logic trò chơi trước khi nó được xử lý và chế độ xem của bạn cập nhật.

Thiết kế này cũng làm cho nó dễ dàng hơn nhiều để xâu chuỗi một máy chủ. Không có thực thể nào nên trực tiếp sửa đổi một cái khác, chỉ gửi tin nhắn và bộ đệm proxy cho mỗi máy chủ / mỗi luồng cục bộ nên được coi là hơi lỗi thời.

Ví dụ: nếu thực thể A tấn công thực thể B, đừng kiểm tra tuổi thọ của B và sau đó gửi tin nhắn tử vong nếu nó chạm 0. Chỉ cần gửi tin nhắn "bị hỏng", hãy để máy chủ có thẩm quyền cho B xử lý, sau đó xử lý bất kỳ Thông báo "thực thể đã chết" được gửi bởi máy chủ B sau đó nếu thực thể A quan tâm đến điều đó.

Điều tương tự cũng áp dụng cho bất kỳ ứng dụng phi trò chơi lớn, có thể mở rộng. Một cơ sở dữ liệu trung tâm không phải là một công nghệ chia sẻ tức thì kỳ diệu. Hai máy chủ phải liên lạc với các tin nhắn, không đồng bộ, theo đợt, để duy trì thông lượng cao. Do đó, sự phổ biến của các công nghệ như AMPQ và tương tự. Cơ sở dữ liệu là để lưu trữ và hỗ trợ đồng bộ hóa ngoài sự cần thiết cho phép chúng được sử dụng để liên lạc, không phải vì bản thân chúng có nghĩa là để đồng bộ hóa hoặc liên lạc.

Bạn có thể sẽ quan tâm đến bài viết này trên Gamasutra , nơi các nhà phát triển của Eve Online thảo luận về cách có thể thành công khi chạy một trò chơi với 400 000 người chơi đang hoạt động ... trong một cơ sở dữ liệu SQL.

Đừng nghĩ về cơ sở dữ liệu như một mô hình thế giới chia sẻ thời gian thực nào đó lưu trữ mọi thứ về mọi thứ mọi lúc - như bạn đã nhận thấy, điều đó không thể thực hiện được.

Thay vào đó, hãy coi cơ sở dữ liệu giống như một tệp lưu được cập nhật tự động: thỉnh thoảng bạn chỉ cập nhật cơ sở dữ liệu, chẳng hạn như khi người chơi đăng nhập hoặc đăng xuất hoặc di chuyển từ vùng này sang vùng khác hoặc bất cứ khi nào điều gì quan trọng xảy ra mà bạn không muốn mất trong trường hợp máy chủ gặp sự cố.

Trạng thái thế giới thời gian thực thực tế phải được giữ bởi các máy chủ trò chơi, trong bộ nhớ, giống như trong ví dụ ban đầu của bạn. Bây giờ, mẹo cho quy mô ngang là không phải mọi máy chủ đều cần biết mọi thứ ở mọi thời điểm . Ví dụ, nếu người chơi A đang chơi ở khu A trên máy chủ A, B máy chủ chạy Khu B thường không cần phải biết những gì người chơi A có trong ba lô của họ - và, nếu nó không cần phải biết rằng đối với một số lý do (nói, bởi vì người chơi B trong khu vực B đưa ra một loại phép thuật gián điệp từ xa trên A), nó chỉ có thể yêu cầu máy chủ khác cung cấp thông tin đó .

Điều này đòi hỏi bạn phải phân công trách nhiệm rõ ràng cho các máy chủ, để khi máy chủ B muốn biết về ba lô của người chơi A, nó sẽ biết máy chủ nào có thông tin chính thức về điều đó. Bạn cũng có thể muốn bao gồm một số loại cơ chế đăng ký cập nhật, do đó, ví dụ: máy chủ B chỉ có thể nói với máy chủ A " Tôi có ai đó theo dõi người chơi A, hãy cập nhật cho tôi mọi thứ họ làm cho đến khi tôi nói với bạn. " cũng muốn bao gồm một số loại hệ thống phát sóng toàn cầu cho các sự kiện toàn cầu quan trọng mà người chơi có thể cần biết về bất kể họ ở đâu; tất nhiên, những sự kiện như vậy cũng nên được ghi lại trong cơ sở dữ liệu, nhưng việc chúng chủ động phát đến tất cả các máy chủ có nghĩa là các máy chủ sẽ không phải tiếp tục thăm dò cơ sở dữ liệu để cập nhật.

Các phản hồi khác đã thực hiện tốt việc chỉ ra cách sử dụng cơ sở dữ liệu và không sử dụng cơ sở dữ liệu để liên lạc. Một khía cạnh khác mà bạn có thể xem xét là phân loại các cập nhật của bạn dựa trên cách thông tin cần được truyền đạt tới các thực thể khác. Thay vì giao tiếp phạm vi đến các máy chủ, bạn có thể phân phối tin nhắn của mình và sử dụng các cơ chế pubsub để liên lạc cập nhật giữa các thực thể. Chẳng hạn, bạn có thể đối xử với vị trí khác nhau dựa trên những người gần gũi với bạn:

• Vị trí chính xác, thời gian thực có thể hữu ích trong bán kính R
• Cập nhật vị trí ít chính xác hơn, ít thường xuyên hơn có thể hữu ích trong bán kính 2 * R
• Không có thông tin vị trí có thể cần thiết ngoài bán kính 2 * R

Bạn có thể truyền đạt thông tin vị trí cho một thực thể bằng cách quét định kỳ các thực thể trong bán kính 2 * R (hoặc một số bội số dựa trên tốc độ cập nhật và vận tốc tối đa của thực thể) và đăng ký thực thể vào nguồn cấp dữ liệu vị trí chính xác hoặc không chính xác của thực thể khác.

Bạn có thể có các chiến lược khác nhau cho các loại thông tin khác nhau, nhóm các thứ chung vào cùng một hàng đợi tin nhắn hoặc có các hàng đợi khác nhau cho các thư cần đến các thực thể khác nhau (hoặc chỉ gửi chúng đến nhóm thực thể rộng nhất và loại bỏ các tin nhắn nếu chúng 'không hữu ích).