Hello I'm programming a fully seamless 3D online game, and I'm wondering if anyone here can give me any advice on that... On the client-side, 16x16 tiles are visible at once. But to shade the edge-tiles correctly I need data for 18x18 tiles. Also, the camera can be orbited freely around the player, and 16 tiles in any direction should be able to be seen. Which means that the client needs to be "aware" of a 33x33 tiles area. On the server-side, I'm storing all the tiles in a scalable list data structure. And each tile holds some static data, as well as some dynamic data like items lying on it, and it might hold a reference to a unit standing on it. Whenever the player moves, the "area of awareness" scrolls by 1 tile, which means the server needs to get 33 tiles from the map. And each tile is on average maybe ~16 bytes. A little more than half a KB needs to be sent around once every second when the player moves, which definitely would work. But accessing 33 objects from the scalable list data structure -map is slow... I was thinking of dividing the map into "super-tiles" consisting of maybe 32x32 tiles, and that the client is aware of 4 of these at once. The more I thought that through, the better it seemed, until I realized the big amount of data that needs to be sent to the client whenever he crosses the middle of a super-tile as 2 super-tiles need to be sent, and each tile is on average maybe 16 bytes. 32x32x2x~16=~32KB That sure is a lot of data, and that wouldn't work if I want the game to be seamless. So I was thinking of maybe letting the supertiles be 16x16 instead 16x16x3x~16=~12kb Still sounds like too much 8x8x5x~16=~5kb I don't really have a lot of server and internet-communication experience so I don't really know where the limit is... Any advice on these things would be really appreciated. Thanks in advance

What happens when the players moves diagonally? then you need (33 + 33 - 1) tiles?

32kB / second = 256 kbit/sec. That's roughly the minimum DSL connection instream bandwidth capacity. Of course, you can also compress your data using Huffman compression or some sort.

Quote:Original post by oliii
What happens when the players moves diagonally? then you need (33 + 33 - 1) tiles?

32kB / second = 256 kbit/sec. That's roughly the minimum DSL connection instream bandwidth capacity. Of course, you can also compress your data using Huffman compression or some sort.

It wont be 32kb per second, a little more than half a kb when scrolling is sending only the needed tiles without using super-tiles.
if having 32x32 super-tiles then the packet is around 32kb, but its only sent once like every ~30 seconds or something like that. and multiply that by 1.414 when moving diagonally, yes..

And if I only have a border in the middle of the SuperTile then a player can walk back and forth on those 2 tiles and make the server send ~32kb packets every second.
So in that case might have to make the super-tile a little bigger, and make it so that the player has to walk a few tiles back to get it to send the previous supertiles again.

oh, and when using supertiles, I could store units and items and such in a hashmap belonging to the supertile instead of having a storage in each and every tile.


I haven't looked into any compression-solutions at all.. I assumed compressing and uncompressing the data would take too long to be usable.
But maybe it's not?

Why don't you just use the tile hierarchy (like a quadtree) on the server side?
When the player moves you could use the new position to index into that hierarchy and quickly retrieve the new tiles which you then send to the client.