I'm working on an RPG, and in most RPGs, your average map is pretty small. (Perhaps 20x20 to 50x50) Yet, many RPGs have a world map which is significantly larger. (I'd estimate somewhere around 300x300 on average) Now, the problem with doing this on BYOND would be that all maps (or map layers) be the same size, so if you have a 20x20 map and a 100x100 map, you end up with two 100x100 maps when you run the world. (Most people reading this know this stuff already, I'm just being thorough) Now, this is a huge waste of 9600 unused tiles/turfs. And this is a fairly conservative number. In reality hundreds of thousands of tiles are wasted, even only using a maximum size map of 100. Once you go up from there, it gets ridiculous, and literally millions of tiles can be wasted.
Now, my first question is: should I care? How significant are these blank turfs? Assuming very little is defined under /turf itself, are potentially millions of turfs even an issue?
Other than that, I'm looking for ways to deal with large maps, even if its not on the scale of a world map. Is it even possible to put something on the scale of a world map in the game?
I've already considered ways to avoid using a single large world map, I'll probably try to divide up the world into sections naturally, but I'm trying to see what the options are.
ID:265892
 Jan 18 2009, 2:44 pm
|
|
The obvious answer is to not waste the rest of those blank tiles.
If you have a 100x100 map, you can fit a maximum of 25 20x20 areas in it. Rather than having a z level for each 20x20 map, put them all on the same z level. (You might not fit 25 on a single z level, but you can easily fit a lot more than 1 on). Here is an example of what I mean. http://www.byond.com/members/TheMagicMan/files/insidemap.png I could have used a single z layer for each of those buildings, but even though half of the area is not even used, it wastes a lot less space than having 14 individual z layers. | |
From what I understand, turf objects are special in that unique instances of them aren't really created unless they differ in some way from their default values. So a lot of unused/identical turfs shouldn't really use up that much extra memory.
To be extra sure of this, I'd keep your "blank" turfs as just /turf, and avoid defining any variables or functionality under the base /turf path (instead putting them in a subtype). That includes things like not overriding the base /turf/New() proc, since that will be called for every turf during map load. | |
The turfs themselves have little impact. Several years ago I generated a detailed map of the earth that was near BYOND's limit of 16 million turfs and it loaded and ran fine on my old computer. The real problem comes when you have a whole lot of stuff executing code.
So if your map doesn't change or need dynamically allocated areas it's perfectly reasonable to have a gigantic map so long as you don't have too many things that need to run code. If you do then it'd be best to have the base map of turfs static and just load in and out mobs and objs in sections of the map as players near them and clean them up when no one is around. However this isn't the real problem of a big map. The problem with big maps is they take forever to design and fill up with stuff. A vast empty world with much repetition is very boring whereas a tiny highly detailed interesting world can be lots of fun even if it isn't massive. | |
You can deal with large maps in a few ways:
1) Run different servers for different map areas.
2) Waste as little as possible. Don't make Z levels just for one purpose, like for 1 small building. If you do this, you should be wasting millions of tiles.
3) Dynamically save and load your maps as needed, this probably isn't a very good alternative to the above two options because it can use a good bit of CPU.