3
\$\begingroup\$

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?

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

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.

\$\endgroup\$
3
  • \$\begingroup\$ So, you think tiles will be fast enough? A chunk could be a whole city, thats a lot of tiles to inform the client about. It makes me doubt tilemap solutions a little, should i go with it anyway? :) \$\endgroup\$
    – Grimshaw
    Sep 2, 2011 at 21:21
  • \$\begingroup\$ I don't know the scale/scope of your game to say anything for sure. But if your chunks are of a manageable size (you'll need to determine what size that is) and you're only sending the whole chunk when necessary, sending changes as they're made seems like a viable solution to me. \$\endgroup\$ Sep 2, 2011 at 21:45
  • \$\begingroup\$ Thanks for the answer, i will start implementing this! Anyway, if someone else has something to say, its welcome ! :) \$\endgroup\$
    – Grimshaw
    Sep 2, 2011 at 21:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .