I''ve been addicted to databases since I graduated college, so I''m normally the first to say "use a database." But unless you *really* need the features a full-blown database represents, the overhead that comes with it is probably not worth the trouble.

As developers, we get so used to finding the "best" solution that we often overlook the simplest. And perhaps the simplest solution for storing player information for a multi-player game is: 1 file per player, stored in a standard directory.

Kind of an off-the-wall approach, neh?

But think about it...are you *really* going to be doing relational/SQL searches on your player information? Or are you taking their name and password when they log in, and then pulling their information into memory, where it stays for the entire time they''re logged in, with periodic updates as things change?

Worried about disk accesses slowing down the process? Don''t, or at least, don''t much. After all, unless you''re saving their family portrait in their information, chances are it''s a few K bytes, total. Hard drives these days have caches that range to the Truly Huge. Chance of your server even noticing that the file wasn''t already in RAM? Minor. And if you insist on worrying about it anyway, setup a simple "file server process" that you query via sockets. That server hits the disks, pulls in the file and sends it back, and the main process never even glanced at the hard drive. And that works for just about any file size.

Database servers like SQL Server are designed for applications where you must rapidly search a diverse collection of data, pulling back a potentially large number of records. Using SQL Server or MySQL for grabbing a single, specific record is very much akin to using a hammer to drive in screws. You can, and they''ll stay, but there''s a better way...


DavidRM
Samu Games

I use the file on disk approach and have had no problems. 0Msec loads really can''t be beat. Excell is used to create most of the game information and then is converted with a specialized app. That way I don''t have to use plain text which is slow when loading.

Just out of curiosity, what does Artifact use?

Ben
http://therabbithole.redback.inficad.com

If you think about it it''s really better to use MySQL David. Think about this if we have one player file per account per char each storing all the items the char has in the bank, in his pack, on him, all his skills, etc... the server would have to searche through the whole file to find one skill to determine the char''s skill gain if he uses it! And especially when a user gets a lot of money what''s he going to want to do? spend it! He''s going to get lots and lots of items and that just makes the item file bigger which means it gets slower and slower as he gets more items. I''ve seen how SQL works and it''s really fast and efficient. There''s a lot of data that''s stored on the server since everything happens server side so SQL is the best option. Also everything is going to be streaming in SQL except for the char''s position. Why you may ask? Because how many times is an itme going to go in and out of the bank or off his body etc.. Once someone moves an item he usually keeps it there not moving it till he gets to his destination and does whatever with it! If you loot a corpse and put his items in your pack well your going to run to the bank to bank the items but untill you get to the bank the place that the item''s in won''t change at all (unless you die trying to get to the bank)and so that item''s data won''t be changing very often! Same with skills, you use the skill, it raises, and the data won''t change untill the skill raises again! the position will most likely always change so that''s why I''ll have periodic saves for basically a backup of the database and to save the char''s position this way if a time warp occurs they didn''t loose skill or items they just went back to the position they were at on the last save, and you can easily live with that!

Kalldrex, you''re not understanding the whole concept.

It takes about 3k of memory per character to do everything you''re talking about and more. I know because I''m doing it. I have many many tricks up my sleeve.

You don''t search the file. You put it all in memory at once. I think this is what you''re not quite understanding. SQL may seem efficient compared to what you assume we mean by file i/o but you''re wrong.

Once the file is in memory you read and write directly to memory. You can''t beat that with any database program. When a player exits all the memory pertaining to that character is dumped back into a file until they log on again.

Basically you want to use SQL like memory. Which is slower because you''re writing and reading the disk. You have to account for seek time of the drive and network quality if it''s a remote computer. It will never be faster than memory. You''ll also be replacing your HD rather often unless you use SCSI drives which are really expensive.

You really need to look into fstream and ofstream and how games use them before you make any judgements on whether SQL or normal files are faster.

Ben
http://therabbithole.redback.inficad.com

quote: Original post by kalldrex
yeah don''t worry we''ll back up every couple of days or so. Also I think i have a way to make it so if we have a time warp you still have the same skills,stats,items, etc.. and only your position is reset to the last save spot!

Backing up every three days or so may be ok for a free ware game or a non-commercial online game... but, for a commercial online game - you better have a back up of no later than 30 minutes IMO.

I don''t think you are thinking out side of the box here. Let''s assume that playerX logs in and starts out on his nightly 6 hour playing spree... the last time you backed up the database was 2 days ago. When playerX logs in you read the database and pull his info into memory - all is well at this point.

PlayerX is racking up experience tonight - he''s made 2 levels and has picked up a Kryss of Mighty Sticking(TM). Right after he gets the KoMS the game server crashes and you haven''t saved any of his achievments of the evening. Ok, lets be nice... the last time you saved was when he made the first level...

PlayerX is cursing... he furious... he wonders if any of his progress was saved... He logs in the next day only to find he is level 19 instead of 20 and he can''t find his KoMS... he''s upset (as anyone who devotes som much time into something would be) and fires an email off to the customer support. Customer support can do nothing but try to calm playerX down.

Now. Reading this post... I am on KalvinB''s side... his ideal is actually very good! I might even adopt it into my server design... I still prefer to pick up this data and stuff it into a database for safe keeping. Another reason for using a database is that we are going to provide a very high level of information from website that will be closely integrated with the game.

One of the nice things about KalvinB''s design is that when you load the player (assuming your using C++) the players class can be _IN CHARGE_ of writing/saving to disk. Another thing about his design is that you don''t have to parse the data... you save the data in a binary format and you read it in a binary format right into your class!!! Nothing could be quicker than that...


Game On,

Dave "Dak Lozar" Loeser

LOL Dak I thought you meant backing up the SQL file (which i''ll do more frequently anyway)! For backing up stats and stuff that''s what i''m going to use SQL FOR!!!

Also kalvin Please report back when you do a stress test on the server and it keeps on opening and closing people''s files! And if you keep files in memory and it crashes the file''s gone because that''s how fstream works and yes i''ve read about it! yes SQL''s loaded into memory BUT not by the game which means the actual SQL server needs to crash and even then i don''t think the database is gone! Plus i''ll have frequent backups of it. So your going to keep on opening and closing files which (once you get near your max amount of players) will start affecting performance!

If the server crashes during play then yeah, anyone on-line at that time would lose however much they did since their last logoff or the last autosave. They wouldn''t lose everything. The server can''t crash during the file write unless the file write routine is bad. In which case I''d already know about it and it''d be fixed.

I''ve got it covered.

Ben
http://therabbithole.redback.inficad.com
http://www.vendettaonline.net

No they would loose everything from their last BACKUP! cause the file would be totally gone if you kept it in memory so it would have to load the last backup!

I don''t think you understand what is meant by loading a file to memory. If you open a document in Word and save it. Then you make some changes and your computer crashes, you don''t lose everything. Just the changes you made between your save and the crash. Maybe it''s better to say the file is COPIED to memory. It''s never actually taken off the drive.

At most, those on-line will lose an hour of play. I don''t know of any ways to crash the server program. As long as it''s running no information can be lost. If a client crashes they can relog on and resume play where they left off.

Ben
http://therabbithole.redback.inficad.com

The book i have on c++ begs the differ so whatever!