Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A lot of the online games out there have this concept of "User" or "Profile", and the concept of "Player". The "User" has username, password, lifetime stats, ... etc. The player concept is per game basis, and holds volatile information around the currently played match. That's how I picture it, at least.

I am puzzled about how is that usually implemented? Does the player class hold a pointer to the User object, or does it inherit from user? or maybe something else?

I can't completely decouple the two, since during the match, I need to send messages back and forth between "user" and "player" (e.g. update achievements)

share|improve this question
up vote 13 down vote accepted

They're typically not even handled by the same machine, much less the same codebase. The user profile is handing by a service that deals only with users. The simulation server deals with in-game things. There may even be another session server that ties the two together.

The simulation server has an ID that corresponds to each user, so its Player class might look something like:

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

For anything that affects the user account, the server sends a message to the user service telling it what happened, e.g.

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

So if the user gets an achievement for something happening in game, the simulation server just lets the user service know (usually via some kind of messaging service, e.g. RabbitMQ or the like) and then forgets about it (since it's not the simulation server's job to care about users).

If the user service has to notify any in-game matches, it can again use a messaging service (or proxy through a match service) to notify any player instances of that user that something changed. For instance, the match service knows about all matches running, who's in those matches, etc., so a user service can just ask the match service to notify all simulation servers that have an instance of that user (a player) about whatever it was that changed. Clever use of RabbitMQ or the like can remove the need for a proxy service, too.

Samller/simpler games often just have one or two servers and overlap a lot of functionality, but this is due to a lack of time/budget and not because of good engineering.

In any case, User and Player (or whatever terms you use) are two entirely separate things. The coupling, if any, should be as light as possible. Unique IDs are typically the way to go. Each user could have a UUID, for instance, and any Player instance just contains that UUID. If something that happens to a Player affects a User, call a method or send a message to the UserManager with the affected UUID and other details. The UserManager can then update internal data structures, send network messages, or do whatever other implementation details it needs to do.

share|improve this answer
Mindblown.. I wasn't even thinking about it at the scale you're describing, more like a local game with mini games. Nevertheless, the concept holds true. – Mazyod Jul 18 '14 at 2:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.