Greeting, all. This is my first post (yeah, yeah, we get that all the time...) and so I''ll spare you the gory details. I have several questions regarding MMORPG development as I am writing one. To give you some background, I am a Java software engineer with about eight years in the middle-ware space. So threading, communication, and databases are not new to me. What IS new is the whole concept of tile engines, sprites (though I do remember sprites from my Commodore 64 days) and what not.... and then there''s the new problem I''m working through. Your help is appreciated. Here''s the problem. I have a game based off of a table-top RPG. The game map is approximately 40 miles by 30 miles, and since the game is usually played with a Gamemaster, only the gross details, like "there is a town here somewhere in this 25 square mile area" is given; the rest is up to the GM. So now here''s the problem. In calculating memory requirements for the server, I can''t see how I can have a data structure in memory, be it a Vector, LinkedList or whatever (still not decided till I figure this out) less than half a GIG of memory. The reason is that I figured out to have any reasonable level of detail I would need to divide each 25 square mile area into 1000 "tiles" by 1000 "tiles". This gives the resolution, if we fudge a mile into 5000 feet, of about 1 "tile" being about 25 feet in each dimension. I''m a bit worried, as the initial projects are about 48 MILLION tiles. How on earth do I store that? Or should I just give up now and start dusting off the SQL books again? Also, while the server has to manage that, does this make sense (25 foot tile) for the client? Oh BOY do I see a long road ahead. Regards and advance thanks, GergisKhan

It could depend partly on how many clients you have viewing it simultaneously -- or how clustered they are. You could have a rotating structure, that only loads (from disk) the relevant parts of the map, hopefully cutting down from 25sq miles to a 1 sq mile chunk -- whatever your horizon maxes out at, anyway. It could make for a lot of disk-thrashing tho, and you''d need some intelligent pre-loading algorithms.

Well, I had been thinking.

I don''t think a server should be responsible in any way for rendering or display of a map tile. I was only thinking that a client would follow the following idea:


Client: character moving off of display on screen to tile XY.
Server: receives message
Server: lookup tile XY and discover what type of terrain and/or items are here (this is the part where I''m lost... what am I looking at, a database? Memory?)
Server: send to client details on terrain
Client: based on server reply, render terrain from locally stored map tiles, etc.

What do you think, all?

Thanks for replys.

Shouldn''t the client just have a local copy of the map? If the terrain isn''t changing all the time, there''s no reason to send that info back and forth across the net all the time.

4.8 x 10^7 tiles * 2 bytes / tile ~= 91 megs of map data. Not that large on todays modern computers. Using memory map files or some custom caching scheme you can dynamically load parts of the map into memory which you need, and write out changes if needed too, on a 91 meg file. You can keep it all in memory if you have enough memory, which is not inconviable in todays world of 256 meg machines. Now if you had 4.8 x 10^9 tiles, that might be a problem

Good Luck

-ddn

4.8 x 10^7 tiles * 2 bytes / tile ~= 91 megs of map data. Not that large on todays modern computers. Using memory map files or some custom caching scheme you can dynamically load parts of the map into memory which you need, and write out changes if needed too, on a 91 meg file. You can keep it all in memory if you have enough memory, which is not inconviable in todays world of 256 meg machines. Now if you had 4.8 x 10^9 tiles, that might be a problem

Good Luck

-ddn

4.8 x 10^7 tiles * 2 bytes / tile ~= 91 megs of map data. Not that large on todays modern computers. Using memory map files or some custom caching scheme you can dynamically load parts of the map into memory which you need, and write out changes if needed too, on a 91 meg file. You can keep it all in memory if you have enough memory, which is not inconviable in todays world of 256 meg machines. Now if you had 4.8 x 10^9 tiles, that might be a problem

Good Luck

-ddn

Keeping it in memory is fine... until you need to take down the server for maintenance, or the unthinkable happens and you have a crash.

In that case, one must take care to persist the world into some sort of hard disk storage.

My question: SQL database? Flat file?

Any thoughts here?

GergisKhan

I agree with one of the anon posters saying to have the basic map locally on the client. The server has in addition all the dynamic items.. like goodies and the location of NPCs or other stuff. Then I''d separate the landscape in logical tiles and swap them in and out of memory (like mem pages) when they are needed. This doesn''t work very well of course when your clients are evenly spaced on the map. I can''t see the advantage of a SQL database here. If you would have some sort of frontend for the game admin where you could place goodies or quests /whatever then a database might make sense but only to regenerate the map file. How do you keep your game in sync ?