Game Server Structure

[Gambit]

Things like weapons and items are a tad different, they are usually hard coded or created at run time with a script language. They are nor persistent or temporary (unless of course thats how you want them).

Also be careful about using strings in persistent data if you are using a database as you are prone to injections (especially if you are persisting strings that the user can change like names).

[StDH]

i dont use strings anywhere (except player name or some text in game) even npc name is an enum in server.
About changing string-names in client, first way to "protect" it, is using char[] but still... not enough.

EDIT:

so i assume theese are the most suitable containers for my needs.

std::vector<std::unique_ptr<entity::Actor>> m_npcs;
std::deque<std::unique_ptr<entity::Actor>> m_players;

std::vector = there is only static amount of npcs that respawns on death
std::deque = because player can change his/her map, so i need to delete in middle

[Gambit]

I havent used queues in C++ at all but as far as char[] being secure? I'm not sure where you got that from.

[StDH]

i meant to not let them make the string longer.

[Nexus]

i meant to not let them make the string longer.

Against who are you trying to protect exactly?

What Gambit meant are SQL injections. But at the moment, you definitely have more important things to care about

[Gambit]

Yes I meant SQL injections, thank you for clarifying that Nexus. "Protecting" a string length against users using a char array is old and C. I hope you are checking for overflows.

[StDH]

i'm still at beginning, have to make fully working BOT system then add players, so protecting/securing code phase will be at the end.

EDIT:

ToDo List:
let npc be aware of map.
AI + they should attack each other (not in real game)
data echange between maps (for players)

[Nexus]

"Protecting" a string length against users using a char array is old and C.

It makes no sense whatsoever. How can a user (not a developer) simply resize a std::string but not a dynamic char array (it must be dynamic if it should be able to store variable length names)?

i'm still at beginning, have to make fully working BOT system then add players, so protecting/securing code phase will be at the end.

Exactly. Before worrying about crazy scenarios, you should get your basic mechanics working... With questionable protection mechanisms you're just wasting your time.

[Xornand]

so i assume theese are the most suitable containers for my needs.

std::vector<std::unique_ptr<entity::Actor>> m_npcs;
std::deque<std::unique_ptr<entity::Actor>> m_players;

std::vector = there is only static amount of npcs that respawns on death
std::deque = because player can change his/her map, so i need to delete in middle

If you're deleting stuff in the middle of a container, you'd be better off using std::list - after all, that's what it's for.

[Nexus]

Not necessarily. std::vector is in most cases considerably more efficient than std::list. It also uses far less memory, especially when elements are so tiny (sizeof(std::unique_ptr) is 4-8 bytes).

In std::vector containers, algorithms like std::remove_if() can remove elements in a relatively efficient way, and the swap()-and-pop_back()-idiom even allows to remove a middle element in constant time, as long as the element order can be changed.

I have used std::list mainly when indirections (pointers, references, iterators) to elements must remain valid. std::deque for queue-like structures where elements are often inserted and removed at both ends, or if I want containers to grow without invalidating existing pointers. Otherwise always std::vector for sequential containers, it should be the default choice.

[Xornand]

Yes, std::vector might prove to be cheaper if you're only copying objects of the size of integers and are not storing tens of thousand of elements. That's a special case though.

Generally, using a linked list is preferred if you're removing very often from the middle - and especially if you're also storing a large amount of elements.

That being said, I think it's best to measure it yourself. It may very well turn out that in this specific case using std::vector will be cheaper - if not, then using std::list should be your next choice - but then again, it all boils down to how you're planning to be using the data after you store it (i.e. how often you will iterate, perform random accesses and removals in the middle).

[Gambit]

"Protecting" a string length against users using a char array is old and C.

It makes no sense whatsoever. How can a user (not a developer) simply resize a std::string but not a dynamic char array (it must be dynamic if it should be able to store variable length names)?

Huh? What do you mean? I was simply saying that explicitly declaring char[] to hold a string is old and C-style and that std::string should be preferred since it is dynamically allocated and you dont have to worry about buffer overflows.

[MorleyDev]

Generally, using a linked list is preferred if you're removing very often from the middle - and especially if you're also storing a large amount of elements.

Actually you'd be surprised. Whilst theoretically list does do the removal quicker, the search for what to remove is still O(N) for both vector and list, and vector has better cache coherence so performs this search significantly faster due to less cache misses. Fast enough that vector can outperform list overall, simply because all those cache misses add up.

It's this reason that even himself advocates viewing vector as the default container, and only using a specialisation like list or set when needed (i.e you need iterates to remain valid after a remove) or when profiling shows you that the removal is costing performance and that the specialisation does indeed overall out-perform a vector.

[Xornand]

Generally, using a linked list is preferred if you're removing very often from the middle - and especially if you're also storing a large amount of elements.

Actually you'd be surprised. Whilst theoretically list does do the removal quicker, the search for what to remove is still O(N) for both vector and list, and vector has better cache coherence so performs this search significantly faster due to less cache misses. Fast enough that vector can outperform list overall, simply because all those cache misses add up.

It's this reason that even himself advocates viewing vector as the default container, and only using a specialisation like list or set when needed (i.e you need iterates to remain valid after a remove) or when profiling shows you that the removal is costing performance and that the specialisation does indeed overall out-perform a vector.

I'm not entirely sure what's your point because I've already said that using std::vector for storing integer-sized objects will likely be cheaper than using an std::list. I read Bjarne's article about std::list in which he was basically encouraging people to think twice before using it because of the very same reason mentioned in the posts above - and I totally agree with him.

Besides, I know that the time complexity for finding the element is the same for both a linked list and an array - and that's why I said that it's always best to measure. Because the thing is, that adding an element in the middle of std::vector is another O(N) in the worst case - and if you're storing a lot of large objects, then copying/moving them will likely diminish any benefit of having the L1/L2 cache-friendliness of an array - and in fact would make linked list a much better solution.

That's also the reason I said that a lot depends on what you'll be doing with the data because if you only add/remove from the middle occasionally, then you probably won't gain much from using std::list - but if it's something that is done every game frame and especially on a container that is supposed to be storing large objects, then that's a different story.

[MorleyDev]

Wasn't a critique, more meant as an additional bit of info The you was meant to be a general you, not you you. Kinda confusing, I could of worded it better. As in "Actually this can be surprising, I find it rather interesting". Sorry that intent wasn't clear ^^