Mô hình người dùng và người chơi


7

Rất nhiều trò chơi trực tuyến ngoài kia có khái niệm "Người dùng" hoặc "Hồ sơ" và khái niệm "Người chơi". "Người dùng" có tên người dùng, mật khẩu, số liệu thống kê trọn đời, ... vv Khái niệm người chơi là trên cơ sở trò chơi và chứa thông tin dễ bay hơi xung quanh trận đấu hiện đang chơi. Đó là cách tôi hình dung nó, ít nhất.

Tôi hoang mang về việc đó thường được thực hiện như thế nào? Lớp người chơi có giữ một con trỏ tới đối tượng Người dùng hay nó kế thừa từ người dùng? hoặc có thể một cái gì đó khác?

Tôi không thể tách rời hoàn toàn hai người, vì trong suốt trận đấu, tôi cần gửi tin nhắn qua lại giữa "người dùng" và "người chơi" (ví dụ: cập nhật thành tích)

Câu trả lời:


13

Chúng thường không được xử lý bởi cùng một máy, ít hơn cùng một cơ sở mã. Hồ sơ người dùng được bàn giao bởi một dịch vụ chỉ giao dịch với người dùng. Các máy chủ mô phỏng liên quan đến những thứ trong trò chơi. Thậm chí có thể có một máy chủ phiên khác liên kết cả hai với nhau.

Máy chủ mô phỏng có ID tương ứng với mỗi người dùng, vì vậy Playerlớp của nó có thể trông giống như:

struct Player {
  UserId _user;
  PlayerId _player;
  int _health;
  // etc.
};

Đối với bất kỳ điều gì ảnh hưởng đến tài khoản người dùng, máy chủ sẽ gửi tin nhắn đến dịch vụ người dùng cho biết điều gì đã xảy ra, ví dụ:

struct UserAchievementMessage : public UserMessage {
  UserId _user;
  AchievementId _achievement;
  uint64 _timestamp;
  // etc.
};

Vì vậy, nếu người dùng đạt được thành tích cho một điều gì đó xảy ra trong trò chơi, máy chủ mô phỏng chỉ cho phép dịch vụ người dùng biết (thường thông qua một số loại dịch vụ nhắn tin, ví dụ RabbitMQ hoặc tương tự) và sau đó quên nó (vì đó không phải là công việc của máy chủ mô phỏng quan tâm đến người dùng).

Nếu dịch vụ người dùng phải thông báo cho bất kỳ trận đấu trong trò chơi nào, thì dịch vụ đó lại có thể sử dụng dịch vụ nhắn tin (hoặc proxy thông qua dịch vụ đối sánh) để thông báo cho bất kỳ trường hợp người chơi nào của người dùng đó biết có gì đó đã thay đổi. Chẳng hạn, dịch vụ đối sánh biết về tất cả các trận đấu đang chạy, ai trong các trận đấu đó, v.v., vì vậy dịch vụ người dùng chỉ có thể yêu cầu dịch vụ đối sánh thông báo cho tất cả các máy chủ mô phỏng có phiên bản của người dùng đó (người chơi) về bất cứ điều gì điều đó đã thay đổi. Việc sử dụng khéo léo RabbitMQ hoặc tương tự cũng có thể loại bỏ nhu cầu về dịch vụ proxy.

Các trò chơi Samller / đơn giản hơn thường chỉ có một hoặc hai máy chủ và chồng chéo rất nhiều chức năng, nhưng điều này là do thiếu thời gian / ngân sách chứ không phải do kỹ thuật tốt.

Trong mọi trường hợp, UserPlayer(hoặc bất kỳ thuật ngữ nào bạn sử dụng) là hai điều hoàn toàn riêng biệt. Các khớp nối, nếu có, nên càng nhẹ càng tốt. ID duy nhất thường là cách để đi. Mỗi người dùng có thể có một UUID, ví dụ, và bất kỳ Playertrường hợp nào chỉ chứa UUID đó. Nếu điều gì đó xảy ra với Playerảnh hưởng đến a User, hãy gọi một phương thức hoặc gửi tin nhắn đến UserManagervới UUID bị ảnh hưởng và các chi tiết khác. Sau UserManagerđó, có thể cập nhật cấu trúc dữ liệu nội bộ, gửi tin nhắn mạng hoặc làm bất kỳ chi tiết triển khai nào khác cần thực hiện.


Mindblown .. Tôi thậm chí không nghĩ về nó ở quy mô mà bạn mô tả, giống như một trò chơi địa phương với các trò chơi nhỏ. Tuy nhiên, khái niệm này đúng.
Mazyod
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.