I was thinking too, but don''t pay too much attention to me as I am new as well.
Having done much in webdesign, I thought a XML approach might be good. As I see it, you only have to relay information as in where what is, not specific pictures. Pictures might be referenced and downloaded as needed (chaching?). As you will definetly have lots of repeats of tiles (there will be lots of grass on a 25 squaremile area, even though there is a town), this might be worth thinking of... I hope...

bye
max

Hi there!

Im also working on a MMORPG, but in 3D. We are going to use threads for each client, and since both the server and the client has the map, and no major changes are going to happen on the terrain, there is no need to send info. Of course at start, the server as to check if the map is ok, so there will be no cheating. We only load into memory no more than necessary, stuff like the players stats and is current frustrum.

Hi there!

Im also working on a MMORPG, but in 3D. We are going to use threads for each client, and since both the server and the client has the map, and no major changes are going to happen on the terrain, there is no need to send info. Of course at start, the server as to check if the map is ok, so there will be no cheating. We only load into memory no more than necessary, stuff like the players stats and his current frustrum.

GergisKhan:
To your original question - you''re solution is correct.. Only the client needs to load the graphical information up - the server just passes on and stores information. It needs to have a form of the map in memory, to check for such things as collision detection etc to make sure clients are not cheating - with a tile engine this can be done as simply as storing a byte for each tile, or whatever you need. Servers these days are not unlikely to contain 512mb - 1gb ram, so there should be no problems there.

To your second question on storage:
Data needs to be preserved in case of a crash. If you use databases or files - it''s up to you, each person users their own system (just look around these boards). In my view, you want to be accessing the hdd as little as possible due to how slow it is. Therefore constantly saving information on the hard disk is not practical. Instead I would suggest storing everything in memory, then periodically saving it to a disk in a seperate low priority thread (yeah, most likely causing a little slow down for a small amount of time). This way, if you crash you can load from the most recent backup which wont be TOO far behind. You might also try saving the file on the applications closing functoion, as even with some crashes, the app can manage to perform a few closing ops.
Unfortunately I don''t have enough information on databases to discuss those. From the sounds of things you have that covered.

In the end it''s all your call

Hope that helps,

Dachande

WHUT THE F**K ARE YOU ALL DOING?????????

Just store all the data in seperate map files (on the client) that are each like 100 MB, don''l load all the data into the ram, say 100MB holds 25sq m, then load _only_ enuf for gameplay to continue w/out too many read/writes, not memory stuff invloved

create an intelegent loading algorithm, hav any of you played Half-Life or Quake2, it loads after youve finnished a level but the load is seemless except the few seconds its flashing the "loading..." text.

even diablo II uses this method. the only informatin the client would have to receive from the server is where the badies are, and what entities are hanging round eg. daggers, swords, guns, armour, money etc.

you do realise though, your talking about a MUMA size server!
the server applications are basicaly __VERY__ efficient database applications - 30+ HDDs all RAID and REALLY FAST supplying the information to the RAM which is feed of throught the 12 OC3 Internet BackBone Lines =)

That''s, in fact, if you are lucky enough to have such a mondo server, which I won''t when this starts online.

To all: you have been VERY helpful. It seems I''m on the right track instinctively, but not in practice and that is what you have provided.

Looks like a 100 MB memory database with a low-priority database writer thread, and the clients handle all the image graphics.

Thanks, everyone!

Joe

I've thought about this problem before, and this is how I think MMORPGs handle it, but I'm not sure. If I understand you correctly, the question you are asking is how to handle memory requirements for an extremely large world on the server - memory requirements so large that you can't fit the world onto a single server??

I think the way most MMORPGs handle this problem is split the world up into geographical zones, called, well.. zones. Each zone is handled by a different a different thread or process, I'm not exactly sure how this works - but I'm 95% sure its different processes. Each process may or may not be running on the same server. (This is the way EQ handles things.) Each zone can be on a different server.

When a player moves between one zone(process) and another zone(process), you would have to do things like:



The tricky part is handling the load and distributing the processes among the zone servers. Depending on the number of players in each zone and the size (memory requirements) of the zone, you need to distribute the processes among the available servers. There are lots algorithms for this I'm sure. I know that AO uses a system where the load is dynamically balanced among the servers depending on past statistics. During the beta, each time the servers were restarted, it would take a few days for the servers to accumulate statistics and figure out how to rebalance the load, and the GMs would tell us not to play for a while if we didn't like the lag. There are also third party programs out there for redistributing the load from serveral processes among many servers. These programs are typically used at various academic institutions and research facilities to make sure their processing tasks are distributed among all the PCs.

There's still the client side of things. There is the problem of transitions between zones. You want the player to be able to see into the other zone if they are close to the zone boundary. If zones are in different processes, how can one zone get access to the world geometry from the other process?

MMORPGs typically handle this by duplicating part of the terrain of the second zone on the boundaries of the first. Perhaps sometimes you've been playing a MMORPG and you've run through a zone and you didn't zone and found yourself in this area? I know AO had a big problem when you were zoning out of Rome Blue, you'd sometimes not zone and you'd get stuck in this area.

Another trick is to use the terrain to naturally separate the zones. Usually they will have one zone connected to another by a long twisty passage, or a corridor with sharp turns (you'll see this alot in EQ). This way you don't have to duplicate much of the zone geometry.

There is one more client-side issue. The issue of load times. I'm not sure how AO reduces their load times so low compared to EQ. I know they store their world geometry data on the HDD in a read-straight-into-memory format with very little or no compression. I think the solution that most MMORPGs use is that they anticipate the loading and preload the zone when they think the player is going to be zoning soon. You'll notice in most MMORPGs that zoning by running through a zone is a lot faster than zoning if you gate/teleport (this is not true in EQ). When you run, the client has a much larger time to anticipate and start preloading the zone.

If anyone has any comments or things to add, I'd be much interested.

EDIT - I reread your post and I had some more thoughts. I'm not sure how EQ/AO handle the world geometery. If I were a MMORPG designer I would think seriously about not loading the world geometry in the server at all. I could then make the clients responsible for collision detection and such, so that the world geometry only be needed to be loaded on the client. I would still maintain a quad-tree or sphere-tree of mobile objects and their positions on the server for proximity testing. But the big problem with this is security and hacking - I'm not sure what to do, I can think of some pretty big (hacks) abuses here.

[edited by - Z01 on March 30, 2002 1:22:08 PM]