Any ideas how Mysql vs. Postgresql do in comparison when it comes to stored procedures and views?

stored procedure? how do i do that?

Assuming you would use SQL...

How far can you go? Using SQL for an account-table will probably work. But accounts would only be the beginning.
But what about storing multiple levels, and enemies in a database? You will need to save this data somewhere when your server crashes or needs a reboot.
I guess storing and loading the coords of every object - every frame - will be too slow.


And now for something completely different:
I guess when the amount of users grows - you will need a second server. Your game will probably be very big and professional by then, but hey - we're still allowed to dream - right?
I personally think the real power of SQL starts here...



Edited by - baskuenen on February 27, 2001 10:26:12 PM

The least of your worries is a crash. Write good code and build a good PC and you''ll little if anything to worry about. I have yet to see my server crash. The program or the computer.

Worry about lag issues and how to program the server to handle all the data you''ll need then worry about how to improve your storage methods.

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

Now this is mainly a discussion about MMORPGs, but I think I should throw in my 0.02 RTS-Euro anyway

I''m currently writing a realtime strategy game (I''m at really early stages but oh well) which will be playable over the internet. I had to choose between plain files and a database (mySQL in my case) to store player accounts and more info for my master server. Basically I want to have a list of players (name, password, score, etc...) and a log of all games that have been played to get some fancy stats. I opted for mySQL - why? First of all, I think that using plain files is easier for the simple things, but when I start with game logs etc... things will get complicated pretty quickly with plain files - not so with SQL. The real argument for SQL was something different though: I want the player stats to be accessible (some day) via the website and more (e.g. why not link the forums to the in-game player data in some way?). I can do this with PHP & SQL in a matter of a few lines. With plain files I''d have to implement the file parser in the server scripts, I''d have to address locking issues etc... SQL just makes life so much easier.

Of course this doesn''t mean you should use databases for everything - storing every single item in a database is overkill. It''s interesting for some critical things though. Let''s say you have unique items in your MMORPG. Once you distribute the game over several servers, keeping track of these items is an issue, you have to make sure they aren''t completely lost or duplicated. As a safety net against these problems you could create a table that lists all unique items and who owns them. With some sanity checks this is an almost dead-safe cure against all those unique item troubles.

cu,
Prefect

---
Sanity is the trademark of a weak mind.

Well with the items we''re going to have a limit on the amount of items you can have in your backpack and bank. so say there''s 20 slots in your pack (just an example) i would have a separate table or something for his backpack inventory and in that table something like "packslot1, packslot2," etc.... and below that have the item ID number that is in that slot! So if the character has say a battle axe in his bank slot#3 and the item ID# is 948039 then it would be set up like this:

bankslot1 bankslot2 bankslot3 bankslot 4
whatever# whatever# 94809 whatever #

also if the slot isn''t filled i''ll have the number = to zero. That should work shouldn''t it?

Alos i need advice for x,y,z,dir, positions and keeping them stored. I''ll use SQL for when the log off/on but what should i do with the data whihle the player is online and the information is constanly being updated. The player position will be the only thing really that''s being constantly updated everything else (stats,skills,item placement) won''t be constant unless the user is acting like an ass so iwas thinking to use SQL for those. should i store the position inside the actual game and in a structure while it''s being updated or what?

kalldrex, your item storage system should work. What I mentioned was a system to store really unique items that MUST NOT appear twice in the game. It''s really just a secondary safety measure though in case everything else fails.

Don''t use SQL too often, as it is slower than simple memory reads/writes (of course it is). So while the game is running you''re better off using in-game structures (a mmaped file could be interesting too).

cu,
Prefect


Sanity is the trademark of a weak mind.

ohh i may do it both ways so this way it shows in his bank plus it confirms that he''s supposed to have it. thanks for the idea.

also what''s mmaped?

btw what''s your sig pic mean?

MMapped files are files that are directly accessible via memory, so instead of using fread/fwrite or the OS level functions read/write or ReadFile/WriteFile you create a memory mapping. You will then get a pointer to the beginning of the file, and you will be able to access the file through that pointer.

Now first of all, I have to mention that this method has a huge limitation: if you create a memory mapping for write access, you have to know the final file size beforehand because you can''t change the mmapping size on-the-fly - well, maybe you can on some OSs, but it''s very limited and won''t work all the time even if it''s supported.

A general advantage of mmapped files is that you have less calls to OS functions (everything is done transparently), and seeking the file is no hassle (you just change your pointer).

There are two main places where I can imagine mmapped files:
- Read-open files that you''ll seek a lot in. So instead of seeking the file position all the time, you''ll just use a different pointer...
- I have never tried this one, but: why not use a flat, fixed-size mmapped file to store your game data, especially on a server? There won''t be additional HD accesses (or are there? I''m not sure on this) because the OS postpones synchronizing writes, and if everything fails and the program crashes the OS will still safely synchronize the latest state of the file to disk.

Oh, another problem with mmapped files: Only use them if you''re really sure nothing can go wrong with your files, because the file itself isn''t read into memory at once; instead, the OS will page them in when they''re needed, i.e. accessed (there''s probably some read-ahead though). Now if an I/O-error occurs in the paging routines, you''ll get a segfault or GPF...

Check out the Lounge thread "Windows XP" to learn more about my signature (and the picture isn''t by me, but we''re all free to use it ). Basically it''s about resisting Windows XP, the next-generation Windows. And please, don''t start an XP discussion in this thread here. If you want to complain about my attitude, please use the "Windows XP" thread, thank you

cu,
Prefect


Sanity is the trademark of a weak mind.