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.