Good practices to hold terrain data in a 2D networked game

Question

I am working on a client-server architecture game, its a 2D top view adventure.

My main focus for the map system right now is to have editable terrain, that will actually change in realtime to other players!

So, i've divided the map into equally sized chunks, that coupled together form the whole map. As the client camera moves, the server will be sending updates for the neighbour chunk, allowing the client to show the map up to date, without having it locally, and seamless.

And this is what brings the problem, if a whole chunk is going through the network, the data for its terrain must be clever built.

Making this edition and storing like traditional Tilemaps would seem a little overhead for a online game.. I tought of representing terrain as shapes of a certain texture, with certain parameters. All textures would be in client, with a id associated to each one. The server would send something like "AddShape [dirttextureid] [point1] [point2]" and the client would convert that into a dirt road between point1 and point2, but that seems to take a lot of freedom of the map creation process as there would be no freehand painting at all, causing the person to overdraw with shapes.

The rendering itself should be painless anyway, as i intend to draw all terrain in a few textures, only rebuilding those textures when something changed in the terrain, allowing the onscreen terrain to render with 3-4 sprites, leaving the rest of the cpu to draw other objects.

So, any toughts on how i can allow map editing and storing in a clever way, giving a good freedom/performance tradeoff?

Answer 1

Obviously, the server will know when a client needs to request the current condition of a terrain chunk. If the server is also told when a client unloads a chunk, it can use the knowledge of loads/unloads to maintain a list of which chunks each connected client is currently tracking.

When a terrain tile is changed on the server, it can inform all clients that are tracking the accompanied chunk that the tile has changed. From your description it sounds like the only change is what tile texture to use so the message could be as simple as "TerrainUpdate [Chunk ID] [Tile position] [New Texture ID]" (or whatever actually fits your architecture). If you can change more than the texture, similar messages can be sent for various changes. If a series of tiles are changed, like in your example, just send one message for each tile.

Unless you have a whole lot of network traffic and/or chunks are enormous, I don't think you need to worry too much about performance with this method.