Ragnarok Online has a big bytefield for each player''s inventory and storage in the SQL database.

quote:

---

Original post by TSwitch
Ragnarok Online has a big bytefield for each player''s inventory and storage in the SQL database.

---

Yup... that would be how I would design an object storage system - using Oracle or SQL Server (I don''t know about MySQL, someone else have an idea?) you can chunk that data to the DB and then later run an external process that pulls the data out and places it into another table in which you can "read" the data...

In fact, since I''m serializing all objects and messages and compressing them I''d probably store all data using that method.

Dave "Dak Lozar" Loeser

I think cache would be very efficient for this. You can run thousands of processes on a modest server.

It''s really good for transaction processing and has had success in the banking industry, although its roots are in the medical industry where it is most heavily used.


-solo (my site)

Lol, can anyone tell me how to program a java server? I have a bunch of java server files for an online multiplayer grapihcal isometric java-based rpg, but no server. Please e-mail me at neo_matrix110@hotmail.com If ou can tell me how to program a server, or would like to utilize the .java client codes in an attempt to make us both an online game.

A good commercial database would be the only way to go, imho. MySql, last I checked, did not offer such things as row-level locking, which would be critical for a large online game.

Besides, when you use a commerical db such as orcale, you get all sorts of performance gains over trying to manage storage yourself (through files, etc) for "free" (no programming effort). You also get all the normal stuff associated with dbs -- backup utilities, restore utilities, performance tools, caching tools, etc. That crap would be a real pain to have to code from scratch.

But at the cost of what 800K as quoted by the DAoC team, using MySQL becomes very nice indeed.
I don''t think I''ll be using Oracle.

Webby

Is there any real reason to run more than one process querying the server at a time?

Wouldn't it be better if the game had one thread that pop'd requests from a queue and issued them one by one to the db?

As for Nathan's original question I know that I would have used the same db structure, but instead of attaching all info to one object in that table I would use another table for all objects.

i.e:
PLAYER_TABLE:
player_id (PRIMARY KEY)
armor: 32612, 2382193, 2321
weapon: 9043, 3923, 2423
(etc)

ITEM_TABLE:
item_id (PRIMARY_KEY)
type: steel_hammer
condition: 37%
weight: 1kg
(etc)

It can contain very detailed info about every object but I guess it could be slow. Am I totally off the track on this idea?

[edited by - usser on July 24, 2003 8:20:20 AM]

I do something pretty similar to this, except I use three tables. I''ll put it in your format, Usser, although it''s not actually the exact format I use

PLAYER_TABLE:
player_id (PRIMARY KEY)
inventory_slot1: 32612, 2382193 //indeces into the specific and generic item table
inventory_slot2: 9043, 3923
inventory_slot3: 2013, 183
(etc)

GENERIC_ITEM_TABLE:
item_id (PRIMARY_KEY)
name: steel_hammer
weight: 1kg
characeristic: weapon
// and other data that pertains to the item type as a whole

SPECIFIC_ITEM_TABLE:
specific_id (PRIMARY KEY)
generic_id_index: 3612
condition: 37%
min_damage: 3 //in my game, each item can have different
max_damage: 12 //damage ranges, depending on it''s quality
// and other item specific data

This keeps the specific item tables from holding a bunch of information that just gets repeated over and over again (i.e. all steel hammers will have the same name, so we put that into the generic item table, while each steel hammer will have different condition level and damage range, so that goes into the specific item table).

I actually use an index into *both* tables in the player table (i.e. the player inventory list), just for speed purposes, so I can go directly to either table (otherwise, to get generic item information, you''d have to first access the specific item table).

That''s what I do. Dunno if it''s the best way or not

-Ron

quote:

---

Original post by usser
Is there any real reason to run more than one process querying the server at a time?

Wouldn''t it be better if the game had one thread that pop''d requests from a queue and issued them one by one to the db?

---

Well, that would certainly be very possible, but also extremelly limiting.

You''ve just placed a bottleneck on your db access when that''s the last place you want something like this.

If you are only expecting 100 or so users at any time, then perhaps a database like MySQL is useful. Large online games that expect to support multi-thousand concurrent users would be foolish to use a single database reader/writer or rely on a non-commercial db.

Hmm for our project we use SQL Server, with few hundreds tables, and more stored procedures/triggers...