Resource and game state management for multiplayer game server

Question

I'm building a virtual world kind of engine. It's mostly for fun and learning. But I would like to get it right from the very beginning, so it is stable and can be scaled relatively easily.

I've been reading a lot lately about architecture of multiplayer real-time games (and real-time 3D games in general) but still there are some questions unanswered.

For now, I know the following:

• the server will be the authority, and clients will be "slaves";
• the game engine core will be based on subsystems (like physics subsystem, game logic subsystem etc.) and all the communications between those subsystems will be implemented using pub/sub approach;
• I'll use enet for networking, and my network layer will be as a separate subsystem, which will just plug into the pub/sub system (so other game server components don't have to know anything about the network layer);
• physics engine - some free library, haven't decided yet. I guess, I'll use the same physics engine on the server and on the clients, and implement client-side prediction;
• I would like my server to be cross-platform (Windows and Unix/Linux) so I'm thinking about using new C++11 features (like cross-platform threading support etc.). I know, C++11 is not stable yet, but I guess, it will be stable at the time when I have something working (Visual Studio 11 Beta and the latest GCC already support many C++11 features, so I guess, it's good to go). Using C++11 I could avoid some other 3rd party libraries, like Boost;
• game state storage - MySQL. I'm not yet sure, what strategy I'll use to flush the game state from memory to the database, but I think, it'll be mixed - more important state changes will be stored immediately, and less important ones will be stored in batches in some background process.

I guess, this information should be enough to see where I'm going to. And now the questions.

There are going to be lots of various resource files - textures, audio, meshes etc. Do I need a resource manager also on the game server or it will be enough to have a good resource manager on the clients only? As the game world gets bigger and the number of clients grow, the resource manager needs lots of careful planing to avoid loading all the resources in memory and thus possibly causing low-memory issues. What is the best practice - do game servers load and keep the resources cached in RAM (and also unload them as necessary to avoid low memory issues) or this task is relayed completely to clients?

I've heard a lot about memory managers/heap allocators and how the game engine might benefit from a custom memory manager to track memory allocations, collect statistics, debug etc. Will a custom memory manager give something valuable to the multiplayer server or it is enough to use custom macros around new/delete to track standard C++ memory allocations?

Could I use some NoSQL RAM database engine which periodically (or when there are enough dirty objects, or when system goes out of free physical RAM) flushes its state to some persistent database? Will the game server benefit from such approach? I don't want to use something just because it's modern and cool, I prefer simple (but still scalable) solutions.

Answer 1

Servers don't use "resources," they're completely headless and never touch memory heavy things like textures, audio or full resolution meshes, those are the client's job. A server will send the client the recipe and the client will bake the cake, a server will send the client a match and the client sets itself on fire.

The thing to keep in mind is that a server runs a numerical simulation while the client visualizes what is going on.

As for memory mostly you're concerned about leaks and any solution that lets you track who allocated a block will only help.

"don't want to use something just because it's modern and cool" != "thinking about using new C++11" I'm just sayin' =) And especially cross platform, you're going to have a bad time.

Databases are used for persistence, sometimes internal info transfer, and what you want a server to store is not transient object state but what's needed to restore the world.

Example: You have an "enemy camp" object that spawns 3 enemies and repopulates them on a timer if any are killed. You never persist the enemies, just the spawn object. When your world restarts it rebuilds the spawn object and it goes about business of recreating the enemy camp. Everything else is kept in RAM, there's no need to keep a permanent copy of temporary objects.

The point is that if your server crashes or is taken down for any reason you do not need to position every single enemy and put them at exactly the right animation and AI state, what you do need is enough to kick start their appearance in the world and then let the simulation take over.

Of special note for databases is that players get special attention. Any item/money/whatever that a player owns must be handled with ACID transactions and changes stored as soon as possible. There is nothing that can stand up against a wolverine except a pissed off customer who just lost his Sword of 1000 Truths because your server screwed up the transaction =)