Working on the world map

[Karl G.]

I'm trying to get the mapping stuff done this week for Volucris. It's taking a while because I'm thinking really hard about how best to do this. I want to support a very large (and expandable) terrain, but I don't want the download to be huge. Also, it needs to fit on your computer! As such I don't think it's a great idea just to store data for every single point on the map--there has to be some sort of optimization involved.

[Ratiotile]

How big do you want the world map to be?
I estimate that the biggest map that could be made without significant optimization is on the order of 10,000 by 10,000. As the world map can be represented by a bitmap, you would need more than 100,000,000 bits to represent it uncompressed. If we assume that each square can be represented with a byte of data, we have the 10,000^2 map occupying 100MB of disk space.

Further using the bitmap analogy, top lossless image compression standards can reduce filesize by up to 80%. If we were to use some sort of compression algorithm to reduce the size of the world map, the 10,000^2 map can be reduced to 20MB of disk space.

Just how big is the Xen map? Correct me if I'm wrong, but off top of my head, I'd estimate that you can fit the Xenimus old world onto a 2000^2 map.

Is a 10,000^2 square world map large enough, or do you envision something larger?

[Karl G.]

A 10000 square map is certainly big enough, and using the PNG compression algorithm can significantly reduce the size, but the problem is the number of layers that need to be represented:

Ground texture (at least 256 of these)
Navigability (solid/transportable wall/swim/fly-over wall, trigger wall)
Spawn points
Scenery elements
Map triggers
Tile height (short/medium/high wall, no wall, pit)
Special effects (poison cloud)
Status effects (slide, poison, etc.)

[mongatard]

Are you trying to fit all of that information, such as object location, spawn points, textures, into one file? Wouldn't it simplify it to have the ground textures/types in one image file, and have the software add properties to the ground type such as poison or slow. Then also have a seperate file containing the coordinates of objects in the game?

[Ratiotile]

You could have two separate files, and on a map of this size you could save some space in exchange for more processing required.

Have all the per-tile properties in one "terrain" file.
8 bits for texture,
4 bits for navigability+tile height

And then put the sparse elements in another file.
a pair of 16-bit integers for location,
and say 8 bits to determine what special effects are active,
32 bits for properties of each effect.
Space is not critical in this file, as it does not cover every tile.

Using this outline there will be a terrain file that is 50% larger than the previous estimate, putting it at about 150MB, 30MB with compression. There is also a relatively small "doodad" file describing all sparse map elements( trigger points, scenery, special effects) that I expect won't exceed 15MB uncompressed.

The two file system will save 1 bit per tile verses having everything in a single file, so thats about 100,000,000 bits...
However, the advantage of 1 file is that you won't have to read the "doodad" file then lookup where to place the elements, or calculate position again when players move, so I think it'd be faster.

[ziggman]

are we still using my 5000 x 5000 map or no?

i would like to know if Ratiotile is taking this over?? If i should continue to work on my map?

[Ratiotile]

No, keep working on your map. I was just discussing ways to store the map within a file and our maximum map size. If the world map is 5000 x 5000 then there won't be any problems with storage.

[ziggman]

saved as PNG format the map is only 542k im not sure if all the textures will be saved as PNG as well but it would save alot of space if they were

[thadiusofx3]

yes the textures are png as well

[Ratiotile]

I've thought of a way to save a lot of space on map representation. Instead of representing every square on the map, you can have a default terrain type that is automatically assumed. Then you only have to specify the spaces that are different. Since you won't have one type of terrain dominate the entire map (even xenimus isn't grasslands everywhere), you can break up the map into separate regions and specify the base terrain for each region. This would help reduce client software requirements as well, because they wouldn't need to load the entire world into memory, just their region and any adjacent ones.

To illustrate this, I've drawn a picture of a map:


Areas A,B, and C are "grasslands" dominated.
For areas D and E, you could specify a forest base terrain, perhaps pine needles.
Areas G, F, and H would be dirt in Xenimus, however we could have separate desert, rocky, and lava tilesets.
The inside of the castle in area H would be defined with an interior "stone corridor" tile.

[Karl G.]

Even with a default terrain type, you still have to specify something (even if its a zero) in the map, unless you're doing a sparse representation. In any case, to make the ground look interesting at all you have to randomize the ground texture a bit so a sparse representation wouldn't save all that much information--in fact, it might inflate the data slightly.

Anyway, I'm just going to do this the old-fashioned way and store each spot of information individually in the editor, then do some sort of interesting compression on it when it's saved. I'll just make the terrain code modular enough that I can gut it and rewrite the internals later. Too much time is being spent on this and I think PV needs to work at all before we plan on it getting that big.