Since most player data is stored (somewhere) on the server, how is this accomplished? I mean I guess you could use mysql and store it in a table, or do you just write up some kinda of database system that goes specifically with your game?

I guess it depends, as always...

This sounds like you''re thinking of an MMO game, or at least a game with some kind of persistence, otherwise a database would be kind of pointless.
It depends on the kind of data you''re dealing with, really. For example, I''d store login data and general data in an external database. This has the advantage that I don''t need to worry about all the data management, and it is possible to write additional front-ends, such as a website that accesses the same database.
OTOH, "live" data (such as what items are currently in the game and where) should always be kept in the server''s own memory because of access time. Of course it would be possible to backup this data using a database, too.

cu,
Prefect

I have found www.mysql.com is a very easy database system to set up and use. It has a nice API to use in C++ and has many nice GUI's to maintain and organize your
data. Some comercial MMORPG's use it so it cannot be all bad


---------
Andrew

[edited by - acraig on November 28, 2002 9:22:23 PM]

Okay, i bet *this* sounds stupid.

When you say store it in the memory, you mean, the server-side app, would manage the storing of that information right? (like, what items exsist and where) it would store this information in the RAM until called by the server app for some purpose...

If we are talking about store''ing ALL of this "live" information in the RAM, how much should a server system have?



( I bet I sound dumb, but you can bite my butt if you dont ike it (jk) )

Depends on the game.

One of my MMO servers takes 1GB of ram to run. I have 512MB physical it uses virtual for the rest just fine. EQ probably takes significantly more than that.

The one I''m currently working on uses purely dynamic memory and takes around 1.3MB to run initially with one player logged in. It''s something like 100KB per player.

Ben


IcarusIndie.com [ The Labyrinth | DevZone | The Wall | Hosting | Tiberian Merchandise | GameShot | Fun With Cutouts ]

Waht kind of game? can i have a link??


Anyhoo...

I was thinking somewhere along the lines of a MMORPG/FPS with a 150 players per server, with one server running....

We already have a working GPL, design docs, etc etc...

What are your thoughts on the RAM requirements for somthing like that? (see screeny below)

heres a screeny of what the engine is capable of (and no, this is not rendered)

Clicky!

The one that''s 1GB of ram to run is Tombstone: Vendetta. It has a relatively large persistant world with the ability to hold 12,200 characters at once. The map takes around 300MB alone.

http://www.icarusindie.com/outworld

I have no idea how much Gang Wars (http://www.icarusindie.com/Gang Wars/)takes but it''s significantly less. Both are MMORPGs. How much memory it takes isn''t really dependent on the graphics. It''s more dependent on the number of players, the amount of information needed to store a character, items, missions, NPCs, ect. If your game with 150 characters takes more than a couple hundred megs of ram you''re probably doing something wrong unless you have a gigantic map with lots and lots of information.

The one that takes 1.3MB is still under wraps for the time being. It''s a small RPG type game though.

The only place you really need to worry about ram is on the client side.

Ben


IcarusIndie.com [ The Labyrinth | DevZone | The Wall | Hosting | Tiberian Merchandise | GameShot | Fun With Cutouts ]

So as far as keeping track of items and stuff, would my SQL my a good place to start?

And how does MYSQL integrate with the entire client and server system? IE: Where does it go?,how is it used in basic terms...etc etc.

(The MYSQL site says its a server, but thats not much to go on)

My other question is (Man I have a lot to learn ) what about player locations on the map, and projectiles. How are those handled by the client and the server, and what normally manages this? ( in a little bit of detail if you dont mind, unless of course you can give me a good web addy)






[edited by - raymondo on November 29, 2002 3:55:42 AM]

have a look in the article section of this site there are a couple good ones on gamasutra(is that how you spell it..)

cheers

First things you should know, and probably already figured out by now, is that there are volatile data and persistent data.

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.

Unless you plan to distribute the server with the client, it is always better to use a DBMS for persitent data, because it''s very efficient. However, while they do a great job of keeping generic long term data, 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.

I heard MySQL is good if you aim for non-Windows server platform. However, for Windows, a very good DBMS system is MSDE. It''s a light version of MSSQL that''s limited to 2G per database and only one concurrent user. It can be freely distributed as long as you own a legal copy of Microsoft Office or Visual Studio. The one user limitation applies only to the database system itself, not to the end user system. That is, your server is itself the only user accessing the database. If you need multiservers access, you may think about buying an -- unfortunatly -- very expensive license or use a proxy between the servers and the multiple servers. The only culprit, there are no entreprise tools with it -- you have to know SQL (especially DDL) real good.

______________________________
Oooh, you found the horadric cube!