ID:151266
 
Alright, I was wondering, other than for the purpose of organization, what are benefits of having more than one map file? I know that having a large world map cut up into z-levels can reduce lag for the player, but what about having different Map Files? I was just wondering on the different uses of doing so.
When you have more than one map file it simply compiles them into a single map file when you run your game. The various maps will be added to their own z-level(s) in alphabetical order.
the benefits of multiple map files is that it saves disk space when u use different sized maps, for instance map a is 10x10 and map b is 5x10 u will save the disk space of 5x10 turfs. Im not sure if this also translates to memory saved when the game is compiled and run.
In response to SamuraiJei (#2)
SamuraiJei wrote:
Im not sure if this also translates to memory saved when the game is compiled and run.

It does not. In fact, it often leads to the opposite, because the developer doesn't realize how much padding is added to each map (they're all resized to the largest width/height of all the included maps)

However, now that I think about it, any padding that is added to the smaller maps would have minimal impact on the game, as I believe identical turfs actually share the same instance in memory.
In response to DarkCampainger (#3)
DarkCampainger wrote:
SamuraiJei wrote:
Im not sure if this also translates to memory saved when the game is compiled and run.

It does not. In fact, it often leads to the opposite, because the developer doesn't realize how much padding is added to each map (they're all resized to the largest width/height of all the included maps)

However, now that I think about it, any padding that is added to the smaller maps would have minimal impact on the game, as I believe identical turfs actually share the same instance in memory.

I would assume this true. The smaller maps will re-size to the maps with the large dimensions, meaning that if you have a 5x10 map, and a 10x5 map, they'll compile as a 10x10 map with padding. The null spaces however will simply be overlooked, and use only a microscopic amount of RAM since there's nothing there except for information about the coordinates. The only real benefit with multiple maps of different sizes would be downloading resources, since the padding is generated at run-time. It won't decrease it by much however, unless you have a lot of very large map files. Though the main reason for multiple map files is indeed organization, and this liberty should be used to any and every degree possible. It will surely save you a lot of headache in the future.
In response to Solomn Architect (#4)
You sure it fills it with null space?
I think it might fill it with the default map turf and area.
Darker Emerald and I use dynamic map loading with Feed for sole purpose of organization and that with wave-based gameplay it makes everything a helluva lot easier to clean up between matches.
In response to Complex Robot (#5)
I wouldn't think so. The coordinates are preserved as to keep sudden "loc=null" arguments from parsing accidentally, I think, take that with a huge grain of salt. I wouldn't think that it would be so wasteful as to fill void space generated at run-time with more useless objects. Though I have not tested this, so this is merely speculation.
In response to Solomn Architect (#7)
The space created when smaller maps get their size increased is filled with the default world/turf and world/area values, it does take up memory, the same amount as having empty maps of that size.
In response to Nadrew (#8)
A map takes up ~1 byte per tile, it seems.

Somewhere below 50 different tiles(any difference between the tiles causes it to require a different reference area) seems to cause each tile's size in memory to almost triple, though.

Size of tiles in memory doesn't appear to go up at all after that. Well, unless its at an absurdly high number(I tested 500 different tiles).
In response to Medicator (#9)
Medicator wrote:
A map takes up ~1 byte per tile, it seems.

No. The amount-per-tile is actually a logarithmic function of the size of a map.
In response to Popisfizzy (#10)
Popisfizzy wrote:
No. The amount-per-tile is actually a logarithmic function of the size of a map.

Wouldn't that make the number of unique tiles completely irrelevant, though? Considering that the map-size in memory seems to change depending on the number of unique tiles, that seems... odd.
If it is a log, the base would also be extremely odd. Above 100. Depending on how much more space I'm counting that I can't attribute to other things, it's somewhere below 109.

The main problem with this is that it's unlikely the size of any tile is a partial-byte. But a logarithm would make it necessarily so at these sizes.
In response to Medicator (#11)
My mistake. The bytes-per-tile is actually a logarithmic function of the complexity of a map, not the size. Complexity here is defined as "unique tile combinations", and the base is 52. (26 lowercase letters + 26 uppercase letters).
In response to Popisfizzy (#12)
Oh. That.. makes a lot more sense... It also makes it more difficult to figure out when map instancing would really become necessary, much less useful.

Dungeon Master's 1000x1000 map comes out to being 1.9731278536(complexity 94), and has a size of 2`013`635.

(1`000*1`000)*1.9731278536=1`973`127.85 - not exact, but.. Eh. Around 45`000 bytes missing. Reference data and format information could fill that, I suppose...
In response to Kumorii (#6)
Do you use a library for this? I've been thinking about switching over to map instances for a while, but I'm not sure the best way to do it.
In response to KetchupKid (#14)
In response to Medicator (#15)
Thanks =). I've seen this before(even a fan of it), but forgot to download it lol.

[Edit]
Been playing around with it, but I'm having trouble fitting into a game.
I find the benefit of it most is the ability to have player-made maps without needing to re-compile. You just need to have them added to a folder and load them at runtime.