quote:Original post by Coincoin Volatile data are data that are temporary, like a missile beeing shot or a user current position. These should be stored in server 's system memory. The same piece of data is accessed very often (probably once every game cycle).
Persistent data are data that are kept from game to game. These should be stored in any DBMS (MySQL, MSSQL, ORACLE). The same piece of data should not be acessed as often as volatile data because there is some significant overhead.
...they are a poor choice for frame by frame access because 'you have' to call a SQL script everytime. There are some optimizations available, but still, accessing the data directly from local process memory is way faster than making a call to DBMS everytime...
...It's a light version of MSSQL that's limited to 2G per database and only one concurrent user...
...you have to know SQL (especially DDL) real good...
I think I'm getting the drift of this, but lets keep this going for learnings sake.
What do you mean by "every game cycle"? Every CPU cycle on the clients machine, or something else? (explain )
When we talk frame-by-frame, are we talking every MS? Every second, or every 30 seconds?
And how do you classify the difference between something that should be stored in memory (volatile data) and something that should be stored in a DB (persistent data). It's not just common sense is it? It sounds to me like interpreting the difference wrong could cost you valuable latency.
Would I be correct in suggesting that you would store the existence of items in the db, and the location of the items in memory?
That way, if a player is in a tile where an item is located, and for arguments sake, the item location needs to be transmitted to the player (its in view of the player perhaps) it could be accessed quickly VIA the memory, and then when the item is sold at the store, the existence of the item would be erased from the DB and hence also erased from the memory?
[edited by - raymondo on November 30, 2002 2:27:03 AM]
A game cycle lenght depends on the servers speed and load. It''s every loop on the server. In the context of my post, frame by frame was a poorly chosen word because we are talking exclusively server side here. However, it could mean the same as game cycle.
Volatile data are data stored on the server that don''t need to be saved. Position of a missile or a magic cast for instance. To prevent cheating, you should store as much data on the server as possible. Persistent data is data that needs to be saved for some amount of time.
An item creation should in fact be reflected in a database and also all user information. However, the position of each object don''t need to be written to database every game cycle. Only when the user exits, the position should be saved IF you need it the next time she respawn.
In a perfect world, we would keep everything in a persistent fashion, however, there is way too much overhead. So everything that do not need to be persisted is kept in system memory and we call that volatile data. Everything that needs to be persisted and is rarely accessed is kept in the DB and called persisted data.
However, there is a ''middle ground'', cached data. You can take some data from persisted data and cache them into memory for repeated access then save them back to DB as soon as you no longer need them. However, don''t go too far or you may end up doing the job of the DBMS.
To determine if an object is persistent or volatile, use common sense. Is it temporary or does it need to be SAVED as you would save a game in single player.
For more information on DBMS read a book or read about SQL. Knowing the overhead behind a call to a database will give you a very good idea of what should be persisted and what shouldn''t.
______________________________ Oooh, you found the horadric cube!
However, depening on how you set your server up(I am guessing), The DBM needs to be acessable by the server app only and not all the clients since all the clients data is passing thru the server app.
In my current configuration I have a server cluster (due to throughput on the network and CPU requirements on the server). One server has the login information such as player name, billing information etc.... It also contains a reference ID to be used throughout the rest of the cluster.
Once the user logs in, the reference ID is associated with them and they can access the pertinent information about themselves on all the other servers.
I also have a ''World Server'' that contains the overall data for an entire game universe instance. For example, if a player was to transition from one server to the next, the World Server contains the player during that transition period. Furthermore, the server is also responsible for terrain/map validation.
Finally, I have ''Sub Servers'' that contain all the environmental data for the particular area in that universe instance.
I divide this information because of the scope of my project, you can divide it anyway that you want.
The reason I went into a little more depth of my architecture is to explain how I utilize the resources on each server.
For the Login Server, I have a database (M$ Access actually, but I will probably make it an encrypted flat file) that contains UserID, Password, and all the other information. On the Login Server Shutdown, the application dumps all its information into that database. (persists the data). On startup, it loads it back into memory. Everything is done from memory.
For the World Server, all terrain/map information is stored directly in memory. It takes about 100 MB of data (I deal with ID''s that references the correct tile/picture to use, etc...). It also contains all the information about player whereabouts, stats, etc... Finally, it stores all this information in the exact same manner as the Login Server into encrypted flat files.
For the Sub Servers, this is the real enchilada. It contains all the vendor, NPC, Faction, etc... all that data is stored in memory. When the server goes down, it knows what kind of information to persist and stores that information into flat files.
In all cases where I say Memory I am referring to the RAM of the machine.
When I mention Flat File, I refer to specially formatted text files (openable by Notepad).
There are a few things to know about this system: 1) Your server applications have to be ROCK solid. If your app blows up (GPF or otherwise), then you can lose a substantial amount of data that needs to persist. I would reference a game called Mankind by Cryo. They had a similar problem and I would venture to say that this was their problem (I believe it was resolved already). Basically, they would take their servers down to patch and when they brought them up, players lost weeks worth of work.
2) Flat files are sometimes easily hackable. (hence the encryptions).
3) Memory management on the server becomes critical especially in multi-threaded instances.
Overall, my system works very well. But, there are TONS of ways to do this.
Finally, yes, Database systems are good. But you have to be one heck of an architect. My only advice is to make your schema as flat as possible or you may end up with a performance nightmare. MySQL is good. SQL Server is ok (not geared towards games). Overall, MySQL is a good bet.
Now, if I was to use a database system for my engine, I would probably use MySQL (because it is optimized for speed) and then create an app on the server that acts as your connection to the database. Then, your clients make requests to the server application which in turn requests information from the database, parses it the EXACT way you want it and passes it to the client.
This makes your system efficient and removes some of the unnecessary additives that standard database communication impose.
Keeping things in memory is OK, but what about hardware failure? What happens if the power goes out? You''ll lose everything that hasn''t been saved to disk. That''s one of the reasons DBMS software, like Oracle, exist. Oracle can gaurantee zero data loss under any circumstance, as long as you''ve got a media backup taken at some point in time, and all the redo logs since then (which is why you usually have multiple redo logs on multiple physical disks).
