Yes I figured that players are basically the only persistent data, or data that dynamically changes as far as the database goes. Monsters are obviously going to spawn at runtime. And I know that we're talking more like 100K+ objects not 10K+, as far as an MMO goes. I've actually operated and worked as a dev for private mmo servers for more than 5 years, so I have a pretty substantial understanding of how they operate. It's simply the actual code and how the application itself operates that I'm a little hazy on....
The way I see it there are 3 options:
1. The server creates a list/array of every game object that is necessary at runtime (Mobs, Porps, etc...) and assigns each entity a unique ID, then when some form of interaction is initiated (AI Movement, Combat, etc...) the server simply acts as a medium and may do calculations within the query to the database, or something.... Problem: How would each unique ID understand what it represents, not to mention you would have to store even temporary values within the database. The server would be making a ton of connections to the database over and over so long as the server is running. For every little detail the client would make a connection to the server then the server would make a connection to the database. Obviously this would be a hug resource hog and WAY too many connection states. You'd need like 3-4 times as many connections as the number of players logged in.
In this case I would say the database is authoritative over the server, and the server is authoritative over the client.
2. The server has various classes that store both data and methods. When the server is launched it creates every game object, calls the database to set the values of each piece of data within each object then adds the object to a list/array. In this case, most interactions happen between the client and the server, very little interaction would be needed with the database, aside from saving the player's current state every now and again. Basically the database is used as nothing more than a reference for the server's assets. Problem: Runtime would suck! The server would be making a crap ton of queries to set each and every object, not to mention that the server would then be "beefed up" with a ton of data. Obviously you could minimize this by only updating objects that are within a players view, but it would still be a memory hog. In which case you would do just fine using a SQL CE Compact database file to store your actual game data, and then could minimize the player states to it's own higher end database. I believe Perfect World uses this type of design, both their client and server use a simple database file similar to a SQL CE file to store and load their game data, but have a MySQL database that stores both account and player data.
Here the server is authoritative over both the client and the database.
3. A Hybrid System: This of course would blend both options 1 & 2 into a more complex operating system. But seeing as I've never really seen one in action I couldn't say for certain how it would work unless I designed one myself.
Obviously I've thought a lot about this but ultimately haven't come to a concrete conclusion as to what the best design would be. I would say 2 sounds great, but I'm not so sure if the resource hogging is really the best thing.
Then of course I was talking about how the server actually stores this data... is it a list, an array, some sort of custom container? And would there be a single container to hold all of the game objects, players included? Or would I create multiple containers and simply access the one that I need when necessary. I would think the later option, but I've been wrong before which is why I'm asking.
Also, there was one other thing I was curious about... I assume that the server is nothing more than an application that responds to events triggered by a client connection. The client however is a game application that is running a tick rate and updating itself every tick. From what I understand a client is getting updated from the server somewhere around 20 times per second, although it would be more in line with ticks.... so if 60 ticks = 1 second then the client would be updated once every 3 ticks??? Would a connection be sent and response received in that amount of time? I doubt it....
But anyway, so what if say... an admin sends out a message to the entire server? Obviously the admin's client would take the message send it to the server for processing but then how would it be distributed to the clients? Wouldn't the server require the network information for each client currently connected in order to send something to it? In which case when a client logs into the server, is it also sending it's local network information to the server for temporary storage and then the server is iterating through every connected client and using it's connection information to distribute a mass text message?
In which case, when a client logs in is it creating a new client/player object and assigning it values like say the client's network information, it's unique key, the characters current hp value, etc... then acting upon that object when new actions are called, like distributing a message or when a monster attacks, etc? Or is all player related information only stored and accessed through the database, and only non-player data is stored within the server temporarily during it's active state?
In which case, is the client sending a request to the server for an update of the current state within the player's surroundings 20 times per second and then receiving that data and updating the client, or is the server sending data 20 times every second for the client to update itself?
