Game Server Structure

[StDH]

Hello, after long time  .

I want help because i've got problem with my game-server code structure (c++) VS2013.

#I'm getting quite pissed off when:
 - i want to let ent/npc get some data from map,
 - exchanging data between two maps

@ because the structure looks like this:

Main - calls funtion Server::run() to prepare an initialize enviroment.
   |
Server - everything what this does is controling FPS and calls MapMgr::update()
   |
MapMgr - there is std::map<enum, std::unique_ptr<Map>> to store maps & updates them.
   |
Map - std::deque<std::unique_ptr<EntActor>> storing npcs & in update() calling ptr -> update();
   |
EntActor - whole interface, move, goto, health, shield, speed .....

EntActor::update()
moves/rotates entity to specified location, or try attack any near player by data from Map.

and this whole system is one-way, should i make some sort of a global-message-bus ?
Please tell me if you have better idea .

# Problem begins when i want to port/move EntActor from map1 to map2.

[eXpl0it3r]

So you really think these few keywords will explain everything to us?

[StDH]

okay, i'll try to "explain" more

EDIT: i hope it's better now .

[Xornand]

A simple solution could be to access the map directly - for example, by creating a Service Locator as a singleton, which would hold a pointer to the map (or an array of maps).

Also, I have two questions after looking at how you store your maps and entities.

• Why are you using std::map for storing maps? Your keys are enum values, which can be directly casted to integers - you could just use std::vector, resized for the total amount of enum values and then just access the maps directly with the access operator. This way you could get rid of the overhead of using the hashing algorithm every time you access the element in the map (although, in case of integers it's negligible... but still).
• Is there a particular reason to store entities in std::deque? Are you adding or removing the entities from the front? If not, then using std::vector instead would have less overhead too, and would be more efficient for CPU cache.

[StDH]

Xornand: thanks it helped a lot.

And that std::vector, well i never used it because it reallocate everything when added something new but when i read your post then i reallized this in my mind : (f**k, i use only static amount of maps and npcs....., he's right) 

[Nexus]

You should always use std::vector unless you have a reason for a different data structure. It performs well in a wide variety of scenarios.

std::array is a possibility if the number of elements is known at compile time, such as the number of enumerators in an enum. You can then use the idiom of a separate Count enumerator to avoid magic constants:

namespace Scope
{
    enum MyEnum
    {
        Enumerator1,
        Enumerator2,
        ...
        Count // <- always last one
    };
}

std::array<MyElem, Scope::Count> array;

Alternatively, you can use C++11 scoped enums (enum struct or enum class), but then you need an explicit type cast to integers.

[StDH]

I've already done this couple of minutes ago before i read your post :

managerMaps.cpp

Maps::Maps()
{
        m_maps.reserve(global::MAP::MapsAmount);
}

m_maps is a std::vector

but thanks .

[Gambit]

You need a form of persistance to keep data from the server stored between sessions. When you change map, generally you will be starting a new local server which (obviously) will not have the same variables and stuff as the previous one. This is easily solved by writing the relevant persistant data (health, armour, weapons, etc) to a file before the map changes, then reading it when the next map is loaded.

[StDH]

It's not "local" game, it's multiplayer, so maps are paused except map/s where is/are player/s.

[Gambit]

Its still the same thing. You save persistent data, close the server, open a new one, load the new map, load the persistent data. This is how most games do it like Half Life and Counter Strike (even Quake did it this way).

[StDH]

i'm not quite sure what do you want to tell me with that

[Gambit]

I'm simply pointing out that its a common method and it works. You could even use a database depending on which way you want to go but a file is probably safer and maybe faster in the long run.

Simply put, persistent data is data that will not change between sessions. If you have 10 health and leave the game, restart the server or change the map, when you come back to that game you will still have 10 health.

I'm suggesting that you do it the way that Quake and Valve's games do it which works and its a simple approach.

[StDH]

i dont use any DB/File, intead i use computer memory:

databaseNPC, databaseMap: (example)

enum iType
{
        A = 0,
        B,
        C
}

struct iStruct
{
        int a;
        int b;
        int c;
}

static std::map<enum, const iStruct> m_db;

funcs:
static void initialize(); // to add all npcs .or. maps to db
static const iStruct get(const enum);
 

i use this for npcs & maps that's the reason of std::map

[Xornand]

I think you didn't understand what Gambit was talking about. Storing everything in RAM doesn't make your data persistent - it'll be gone the moment your std::map is destroyed (either by going out of scope or by closing your application, for example due to a server reboot).

Now, depending on your game, this may be or not a desired behavior. If your game is like an MMO or needs to keep players' stats, then you'll want state persistence, so saving the game state to a file or a database is the way to do it. However, if each multiplayer session is unique and you don't care about tracking any information about the players (and thus everyone always starts from the beginning and the entire map is reloaded every time a new game is hosted), then I guess you could get away without the database.

From your vague description, it seems like you're making a persistent world (at least that's the impression I got), so if that's the case, you'll need some persistent storage for storing your persistent data and storing it in RAM doesn't solve the problem.

[StDH]

now i understand.

Well, static things like Hitpoints,Shield,Wapons are in application/ram, and (as you said) stats will be in database (persistent)