I want my server to send only certian regions of the map that was just explored. My reason for this is... 1. To avoid players from hacking into the map data saved on their harddrive. 2. I want Gamemaster characters to edit the map while its being played on. A bit of background about my game... Its a 2D tile based MMORPG; very simple one (More/less just a giant linear array [1500 width, 1500*7 height]. I'm not sure what is the most bandwidth/simple way todo this... =/ Any ideas? .. my first idea was just to send a 40byte packet everytime the user moved (eg.. it sends the bits of the map that the client needs to view the scene properly). However, with the expected 1000 players, this resolves down to too much bandwidth. >.<

Yes yes, of course, but how?!

With gamemasters editing the map on a regular basis the update list would be HUGE. Inaddition, there would be no way to know whether the player has all the updated tiles before hand.

My hunch is that I add a property to the tiles called "isActive", where active tiles are tiles that have been edited prior to each "Minor Update" patch for the client.

Walking in places that are composed entirey of "isActive" tiles would trigger to the server to send you all the tiles for which you are about to walk on; and send them for each movement.

This way, the game is only inefficent when fresh hunting grounds are being tested out before a "Minor Update".

Quote:

Original post by Anonymous Poster Worth noting is that you can forge packets to make the map look however you want, so doing it like this for security reasons is stupid.

The client does not have the server program; even if they forge their own packets to send to themselves, they won't be revealing hidden dungeons since they don't have these dungeons saved to their computer.

Doing it like this for security reasons is most certainly not stupid.

Quote:

Original post by Anonymous Poster If the server keeps an update map for each player, containing the copy of the map in the player's local store (on the client), then determining if a tile has to be sent is easy. On the start the player map is empty, comparing it to the master copy will result in updates. If someone changes the map, then the player copies won't be updated, so when the player moves around the changed tiles, it's copy will differ from the master map, and the updates will be sent. This algorithm covers both the unexplored map case and the updated map case, and only requires a per player copy of the master map. The server doesn't have to trust the client, since it has a copy of the client's map, stored on the server.

This doesn't work if the player logs on from a different computer, since the server thinks that the client has already seen half the map, and thus, the client just sees blank black tiles.

I would slice the world into smaller chunks, say 20x20 tiles. For each chunk, I would have a generation count (the edit operation when they were last edited). When the player comes close to a chunk (just outside visibility), he sends the generation count he has stored on the hard disk for that chunk; if the server has a later generation chunk, it sends an update for that chunk. The actual size of a chunk should be such that you can send a single chunk in a sub-second amount of time -- 20x20 works well for 1- or 2-byte tiles.

When the map is edited, the chunk(s) affected are stored to the database with a new generation count -- there only needs to be one generation count for the entire database, and you can make it monotonically increasing. 32-bit counters means you'll never run out (unless you make two edits per second for the next 100 years :-) but you can probably actually get away with 16-bit counters. Editing is usually slow and ponderous, so getting to 60,000 edits will take a long time. Smaller generation counts save bandwidth.