Map Storage Optimization

[Nemerle]

The premise of this idea is that map data occupies a significant amount of time loading, unloading, and processing both on the server and on the client. A simpler solution would be to use a seed number to a pseudo random-number generator to generate the map. This seed number would then be shared with the clients so that the clients would no longer have to download the map to view it.

Of course there are a few issues with this idea, which I will enumerate and then address. The first issue is that it will be difficult (when generating the map) to control any of the parameters except for the seed key, resulting in many useless or ugly maps before a usable one is arrived at. Second, some objects on the map change frequently, and those changes must be propagated to the client, which may not seem possible with a map generated from a shared seed number.

The first issue
The first issue is not hard to address. Two seed numbers are used instead of one. The first seed number (lets call it J) is the same for the server, and all clients. The map is divided into 100x100 chunks, and seed numbers "J" and "K" are combine to produce a unique map chunk, without rivers or forests. If the map chunk is ugly or does not fit well with the other chunks then it is tossed away and the "K" value is adjusted. The process is repeated until a usable map chunk is generated from the constant seed "J" and the variable seed "K". Once a usable chunk is found, the "K" value for that chunk is stored for later use.

This is repeated for the rivers, which are merged with the terrain chunks. Likewise the process is repeated for forests and other resources, however when the merging stage is reached any forest chunks that overlap rivers are tossed out and generated again with a different "K" value.

Finally, the "J" values for the different layers of the map are stored both on the server and the client. When a user wanders into a particular chunk, it's respective "K" values for each layer are sent to the client to be generated.

The Second Issue
The second issue was a little more difficult to figure out than the last. Basically any time a change is made to an object that is part of one of the pre-generated map chunks (and not, for example, an object created by the user), the tile coordinates (relative to the map chunk and not the entire world map) and the object ID are stored away as "marked" in a database. Now any time a user walks through that particular map chunk, the client uses the "J" value it has stored, combine with the "K" value for that chunk from the server, generates the map, requests any marked tiles/objects on the chunk, and merges those changes with the chunk before actually displaying the chunk.
While the upfront work necessary to get a working map up and running is much larger, it also means a significant savings on server ram, hard-disk space, and bandwidth. Objects that change frequently (such as items created by users) are stored as per-usual and not generated in any sort of way.

The benefit
This would result in needing less time to load the map, as well as less bandwidth to transfer tiles. Also, because clients rely on the "K" values and not just the "J" value to generate a map chunk, a user wanting to map the entire game by altering the client would still have to visit every map chunk in order to do so.
On the user side, this would allow the client to perform off-screen rendering quicker, because the client application would only need to request the "K" values for the chunks adjacent to the chunk the user's avatar is in. Dynamic objects (user created) and NPCs (animals) would only be sent when the user's avatar actually approaches the adjacent map chunks.

Edit: When I refer to the "map" I'm referring to the tiles that characters walk on, not the minimap (edited for clarification).

[sabinati]

i don't think that would work

[Moogie]

i don't think that would work

What a brilliant and well-thought critique, going into incredible detail. I have simply no choice but to agree with all the points you've raised!

(Wow. Can't believe I actually got a warning for this. Sense of humour = broken? )

[sabinati]

i apologize for not going into great detail on why an idea is flawed. perhaps you have some insight into why it would work better than the current method? if so, please enlighten me, if not, kindly fuck off.

[Sarge]

I understood the principals of the OP, which is fucking amazing since I am pretty tech clueless. I may not understand why it would or would not work better than the way it works atm, and I don't know how it works atm either. I would however, probably to a lesser extent than those that actually understand this better, like the OP, like to hear why it may or may not work better. At the very least, the goal of the OP warrents that imo.

[flaw]

i don't think that would work

What a brilliant and well-thought critique, going into incredible detail. I have simply no choice but to agree with all the points you've raised!

(Wow. Can't believe I actually got a warning for this. Sense of humour = broken? )

Remember, don't sass the mods, even when they aren't being mods.

[Potjeh]

I reckon it'd be simpler to just cache maps client-side. Client sends timestamp of his map to server, and if there's any changes since the map date the server sends changes alone (like tile x,y got paved) which are used by the client to update it's copy of the map.

[Haba]

There is absolutely no need to create the maps on the server side. But this is just one of the many small optimizations that have been waiting for a fix for a long long time. Just learn to enjoy the uncompressed PNG's, I guess?

[Thurrok]

What a brilliant and well-thought critique, going into incredible detail. I have simply no choice but to agree with all the points you've raised!

(Wow. Can't believe I actually got a warning for this. Sense of humour = broken? )

So sarcasm has become the privilege of solely the mods now, huh?

Son, I am disappoint.

Besides, it would be interesting to hear why such a system would NOT work, maybe from a techie POV, maybe even from loftar himself. Ingame maps have always been utterly useless. I would love to see that change in the future.

[Potjeh]

I just think the OP's method is a bit too heavy (randomly generating a bunch of maps, and then discarding most of them). Memory is cheaper than CPU cycles, so I think caching is the way to go.