Since datastream management is critical to ANY MM gaming project I was wondering if anyone had any good discussion forums or sites they could share with me that would be great. I could discuss things here but havent had a lot of success in teh past. Mostly because the feedback tends to be theory and not practical knowledge. One thing that almost 3 years of game development has taught me is that there is a HUGE diff between theory and practice Cheers guys, and thanks in advance. Mark Aakrana: The Forgotten Lands If you have C++ experience and wish to assist in the alpha development of our network transport using very easy middleware, please contact me.

Aww cummon guys You all know you wanna have a discussion on this. Tell you what. Let me see what kind of feedback I get on this design.

The database structure is to a MMRPG as gasoline is to a car. You use crappy gasoline your car runs crappy and dies. You use high octane gas with cleaning components and your car runs like a finely tuned forumla one champion. (Unless it''s like my car. Then even the good fuel doesnt help.) With that in mind I designed my entire datastream around optimizing the bandwith where I couldnt control it, and saturating the bandwidth where I can control it. This is what I came up with:

The gaming client is nothing more than a glorified rendering screen. It takes the datastream from the server and turns it into pretty pictures, ugly monsters and silly animations. In order to reduce potential hacking issues the only information sent to the client is entity update info. The client can not directly interact with ANY of the backend databases thus providing as much rock solid protection as possible.

The reward of that concept, aside from the obvious security ramifications, is that all of the time-consuming and bursting required to support frantic database parsing is done at a LAN level and not through the horrid latency of the Internet beast. My client communicates to the zone server through the net and the zone server does all filtering and database requests through a direct connection over a multi GiG backbone LAN connecting the database servers.

Now as a network analyst, I think I''ve done a fairly thorough job on the actual technical optimization of the datastream structure but here I get out of my element. Yes I have a multi gig backbone connecting several physical server entities which are load-balancing an array of mySQL databases but improper table design (I am told, and it makes sense really.) can slaughter that infrastructure very quickly. Concider this:

A player opens inventory, Identifies an item in the inventory, attempts to equip that item and attacks a target. All this happens in less than 3 seconds.. Yeah right Although it should. What I need now is some database discussion on optimizing the way to structure the different databases and tables so that the initial datarequest and subsequent parses and filtering happen with the fastest results and full optimization.

I guess specifically I''m thinking how do you break down the different fields that should go in the diff tables and how should they be linked. Things like player identifiers, names, stats, inventory, spells, augmentations, quests, factions etc.

Anyone been down this road before?

Cheers.

Mark

Aakrana: The Forgotten Lands
If you have C++ experience and wish to
assist in the alpha development of our network
transport using very easy middleware, please contact me.

That''s how all MMO systems do it (that I know about, which is about three and a half). There are reverse-engineered protocol descriptions available for UO and AC, for example.

Typically, when you log in, the server will load everything that''s related to your character into memory, and then dump it all to your client computer, in addition to the information about your surroundings (what monsters and other players are where, etc). This happens during the "logging in" screen.

Once this data is transmitted, you can send the client deltas only, assuming you have a recovery mechanism for lost packets.

If the user picks up something from the ground, it''s a delta of adding one item to the inventory. Typically, an item will be very small; a few bytes for an index into a (pre-loaded) item table, and maybe a few bytes of instance-specific variation data. This takes no time even on a modem.

The database on the back-end should provide reliable, transactional, write-behind persistent store for the world, and otherwise get the h3ll out of the way! You don''t want to be querying SQL to figure out whether the player hit that Greater Ooze with his Arrow Of Slaughter or not.

If the item table changes (because you add new kinds of items to the world, not handled through item variation data) then you patch the client data files before log-in. This is why most games (except ours) patch very frequently before you log in. We chose to put a more rich description in the item information packets, such that a hard-coded item table isn''t needed, at the expense of higher latency in loading inventory (and higher bandwidth used).

I''ve been down a similar road. Some thoughts, would include.

From a structural design standpoint, the player object is a container for an invenotry object. Which in turn is a container for items objects. Which in turn can be a container for item traits.

When a player joins the game the the inventory is loaded from an inventory table. This table contains a mapping of player ID to a binary data object composed of item IDs, listing all the items in the players possesion. The reason for this level of indirection is because you would proablly cache this table in memory if possible, so the smaller the better. Also using the binary object allows you to quickly utilize the object without too much parsing.

The item ids have 2 components. They point to the item type table and the items unique id(64 bits should be adequate to prevent item id collision for a MMORPG). The item type table serves as a convient demercration for the various items your game will support. Also item types can be mapped to default properties which allows you to deduce attributes of the items without having to load it up from the item type table. This would be useful for runtime performance. Its possible for items to posses more than one type, thus possing a superset of those properties.

The properites for items which are stored within the tables should just be the uniqueness of the item vs its base type properites. Since its base type properites are kept in memory and can be deduced, you dont need to store them explicitly. Things which make an item unique can include curses, damage, blessings, modifers, or even unique logical scripts.

For instance the player can possses a :

PoleArm of +5 dmg to small rodents and +5% chance of spontanously catching on fire per hit.

You would store the item within the PoleArm table :

Item #1213121 , with the modifer string "MDmg(+5,TYPE_rndt),SPCPHit(5%)"

Note the string is parsed by the game to produce the desired effect when it is used. SPCPHit is a mapping to a function whcih accetps a precentage range. And MDmg maps to another function which accpets the damage modifer and the conditionals.

The reason for using the string form is for maximum flexiblity. So the program parses the string into the numerous unique properites of the polearm. Also the hidden attributes for polearm can include (long pole weapon, and double handed, which are dedecued from the polearm class). The parsing can be done once and converted into a binary form which is very fast to execute.

Anyways this should get you started, Good Luck!

-ddn

Great stuff guys, thank you for the input. Thats the level of detail I was looking for. Some nice points there.

I will pitter-patter off to my design pages and see if I can make a bit more sense out of it.

Mark

Aakrana: The Forgotten Lands
If you have C++ experience and wish to
assist in the alpha development of our network
transport using very easy middleware, please contact me.