There are a couple of options for storing MP player data... one (I think which was mentioned on this forum) was to store information in one folder/directory per account or character. My plan is to create one directory per account, and create one sub-directory per character in a person''s account. This way, backups may be made easily, and files can be edited a lot easier and more quickly than storing everything in one file. Ideas? MatrixCubed
http://MatrixCubed.org

Are you developing a storage method for a persistent world game (ie Everquest)? Or are you talking about storing data for a game like Diablo?

For my own MMORPG I just drop all the files in the main directory. I doubt that does anything for load time but it simplifies things code wise. The naming convention I use keeps them sorted. The files are binary also so they can''t be edited by hand anyway.

If I need to edit a character file I use Excell and a conversion program I wrote for now. I''ll probably write a Visual Basic app one of these days to make it easier.

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

If you are talking about MMORPGs....

I use SQLServer to store world and character data. It gives you the power of the SQL language and the stability of a transactional database.

Edited by - LostLogic on June 9, 2001 11:46:24 PM

Good idea for a dir per account/character, is that under a unix sys or a win32 env? I am relatively new to win32 coding, so I know not how this would be done.

NuKeS

I like ur directory idea, which is what I will prolly use but it is less efficient. On a large scale all that directory switching will add up quickly. I personally don''t care for databases too much because if 1 part is corrupted, the entire file of users is screwed, plus most file formats are extremely large for the amount of data stored. ie, a phonebook database I did for a web site once was about 10X bigger as a database than the original data. What I would do, for a final product, would be store all the files in a subdirectory of the server, each file being the userID#.charID#.extension so each char has its own file, but could easily be sorted.

Pinch me... See if I''''m still asleep... *pinch* Owe! Mother f*****... Yep, you were still asleep.

The main reason I mentioned using SQL based databases before is that you can query/insert/update your entire user base without having to open/close/edit hundreds or thousands of files.

For example: Imagine that you just released a patch to your game and found that a new "dupe" bug is present that lets people duplicate gold. You want to go through your player accounts and search out people who have more gold than normally possible (~600,000.)

#1 SQL Database solution
You use your query editor and run the following:
select username from player_resource_info where gold > 600000;
The query engine returns a list of user names that have over 600,000 gold. The entire query should take no more than a few seconds for a database of less than 1 million users (say, 1024 bytes worth of data for each.)

#2 Flat file/director solution
You write a program that loads each account file, parses through it to the gold section, and then checks the value. If the person has over 600,000 you write it out to your list. Now imagine that you are trying to do this in "real-time."

As you can see, the SQL database makes this very easy to check. Not only can you perform selects, but you can also perform inserts, deletes, or updates based on criteria. I did not even talk about how you could use the transaction log capability to "go back in time" to find players who had a sudden jump in gold.

As for stability, I wouldnt worry about losing the whole player database. You should always have a safe backup system in place before ever going to production. I recommend that you plan your backup system from day one. You can also use the transaction log system to roll back the user info is something bad happens. And there is always SQL clustering and/or replication software. If you plan on load-balancing, you will definitely want to use a database oriented system with replication.

If cost is a concern then I suggest you look into MySQL or any other capable free database system. You can even use Access for prototyping. Once your game is ODBC ready, you can really use any database that can handle it when production time comes.





LostLogic
www.lostlogic.com
Author, Multiplayer Game Programming