0
\$\begingroup\$

I am writing a multiplayer game that has account system and character creation system like standart MMORPGs. I have a question about name creating issue. I think that I can create a static variable on Player class that keeps created player names but it confused me. It will tell me name is valid or unvalid depends on the other players has this name.

Questions;

  • Does implementation does make sense ?

  • If i have 1000 players, is it means it consumes 1000 times of memory of this list? Or it just consume as like there is one?

  • What is your suggestion for place that I can keep player name list? A new class?

\$\endgroup\$
5
  • 1
    \$\begingroup\$ This doesn't make sense. You want a static variable in the player class to contain a list of all the player names? How does this variable get updated when new players are created? Why would you need to store it all in one variable in your class? If you're making an MMO, this list would be stored in a database, not in the game client. \$\endgroup\$
    – House
    Commented May 2, 2014 at 1:27
  • \$\begingroup\$ I can update the new names with constructer of player by .add function of listing. But yeah you must be correct, thanks man! \$\endgroup\$ Commented May 2, 2014 at 1:43
  • \$\begingroup\$ I strongly suggest you look at getting a simple game working before starting on an MMO. \$\endgroup\$
    – House
    Commented May 2, 2014 at 1:44
  • \$\begingroup\$ yeah i am working for it , actually i won't create a MMO, it is just a RPG for now , as you told :)) thanks again \$\endgroup\$ Commented May 2, 2014 at 1:52
  • 1
    \$\begingroup\$ When you create an MMO you will have far too many registred characters to keep them all in memory. You will need to use a database. A database should be able to tell you if a name is already used. In SQL it would be something like SELECT count(*) FROM characters WHERE name="WhatPlayerEntered". Many databases also allow you to define a UNIQUE-constraint on certain fields, so you can just try to insert the new character and you will receive an error message when it already exists. \$\endgroup\$
    – Philipp
    Commented May 2, 2014 at 12:54

2 Answers 2

2
\$\begingroup\$

This is not a good idea.

The player class should be concerned with an individual player; the actions you will want to do with the set of all player names in the system exist at a much broader level than what the player class should be concerned with.

Further, a single static list in code means:

  • It is difficult to segregate the names by region, so you could not neccessarily easily have a seperate pool of names for players in Asian countries versus those in European countries, if your game worlds were so divided.

  • It is difficult to access that name list in a distributed fashion, since it exists in only one process's address space on one machine, which means that one process becomes a bottleneck for every other distributed process that would need to check, remove from, or insert into that list.

  • It is difficult to access that list from a service that isn't an .exe compiled against the code library containing the player class (for example, a web service like a forum that wants to display player names).

    Your Player class is a runtime representation of a single player for use in the simulation of your game. The list of currently-used names is data -- related, true, but not data that should be owned by Player. Store it in a database.

\$\endgroup\$
0
\$\begingroup\$

1) At the level you're working, yes. In the future you definitely want a database, but I think there's a lot of things you can do before needing one.

2) No. A static class variable is a single variable shared by all the instances of the class. You can access it as player1->list, player2->list or Player::list, and it's always the same variable.

3) A list is OK, but you may want to use a set<string> (or unordered_set<string> in C++11) for faster lookups.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .