Imagine a game with lots of tiles. So many tiles that is is practicaly impossible to keep them all in the RAM of the server. How to solve this: Maybe I could only load the areas that are currently visible a client? NPCs in areas that are not visible should not be updated only in a very simple way. Someone told me to write my own file system, optimized to read the map from the hard disk as quickly as possible, and use that as alternative RAM. (To me, this doesn't sound like a very good idea) What is the best sollution? Are there better solutions than those mentionned above? Are there games that have problems like this?

You are going to need to be a little bit more specific in your post for anyone to give you any good advice, but my first guess would be trying to shorten the memory footprint of your tiles so that they would fit. What must you store that will exceed memory limitations?

Yes, generally anything that doesn't fit into ram goes onto disk.

If I had too many tiles, I would write the maps to disk and load them into memory like how maps are held in memory and moved onto video memory.

But then again I am curious as to how you have "too many". My current project test has somewhere akin to 30000 objects [tiles and paths between the tiles mostly] and is humming along around 6 meg resident.

Perhaps you're using strings to store the tile type by name rather than storing the tile type as an int [or better yet as an enum]?

I would spend a little time thinking about your design. I am guessing by the size of your map, it isn't for 3 or 4 players. Or even if it was, you might want to avoid using geometry as your game boundries. This is the approach that logically comes to mind, and what was used early on for MUDs, and games like UO and EQ. However, for the most efficient use your server resources, I would look to defining something else as your boundries. One common approach is the use the user. A bit harder to conceptualize, but if done correctly, greatly increases your game scalability.

Good Luck!

Thanks for all the replies.
Obviousely I don't have a map so big that it doesn't fit in the RAM, but what if I need to add more areas later? Even if I just use 32 bits per tile, the map doesn't need to be incredibly big before I get problems.

Maybe you could go streaming the map in the direction the user moves the view. I mean, you have a static chunk of memory in which you load a certain area of the map, and as the user moves the view, you load more map (and unload the bit left behind).

Like fowarding/rewinding a very big avi/mpg.

It would never be super-smooth, but it could work.

Wouldn't a PC write the chunks that don't fit in the ram in the virtual memory anyway?