I'm not going to make this a feature request because I'd need to make 8 different topics and I'd get a bunch of nos due to technical reasons.
BYOND can barely handle a 1000x1000 map. 1000x1000 is tiny. You might try to argue that it is a million tiles and this is huge, but lets to an accurate size comparison.
If you make a 1000x1000 map, use pixel movement and move at a speed of 1, this will take you 31 minutes to walk across the entire map. This means the map is just over 1.5 miles wide, and has an area of 2.25 square miles.
Skyrim, a modern game with a relatively small map for an open world game has a map that is just under 15 square miles. It is about 3.7 miles across and walking across it would take you 65-70 minutes.
http://i.imgur.com/SlbMch0.jpg
Take a look at this image. You see the tiny red square in the top left corner of the map? That is a 1000x1000 map in BYOND assuming you have a step_size of 1. BYONDs maps suddenly don't look so big anymore, do they?
The reason BYOND sucks at large maps is pretty obvious. When BYOND creates a 1000x1000 map, it loads it all into memory. You cannot prevent this, even if you try to delete every mob, obj, turf and whatever else in the map, the 1000x1000 area physically exists even if at the current moment in time players are accessing 1% of it.
What most games will do is slice a map into small areas, a 1000x1000 map might be made into 400 50x50 areas. Then only load the areas the player is on, or next to. Everything else simply does not exist. If a player leaves an area, it gets unloaded and when a player is next to an area it is loaded.
Even multiplayer games do this (MMOs might not, but lets be fair, these games run on server farms and potentially have hundreds of machines running a single server).
Obviously it's not an easy feature to implement, which is why I'm not requesting it, but it'd be nice to see something like this in the future.
And now onto the next problem I find with BYOND, and this one I find really strange.
Dream Maker can save and load maps. Quickly. I can create a 1000x1000 map, it takes me 2-3 seconds to open it, and 2-3 seconds to save or compile it.
Dream Seeker/Daemon (and the BYOND language) lacks such a feature. You can manually do this, and libraries exist for this, and they work in small scale. But in SwapMaps, to save a 1000x1000 map, it takes about 20 minutes on my computer, other libraries take 5-20 minutes too. Even a 100x100 map can take a while to save using these libraries, and can result in huge file sizes.
Is there any reason players couldn't be given control of saving/loading maps like dream maker does?
Like I said, I'm not going to request these features. I don't know if there are technical reasons they don't exist and they wouldn't find a lot of use for most people. But it seems rather strange to me that they don't exist already.
Discuss.
ID:1301510
 Jun 24 2013, 4:19 am
|
|
|
Jun 24 2013, 4:38 am
|
|
Kaiochao
  |
Lummox JR has mentioned wanting to implement map instancing and mobius strips, so that's... possibly possible.
|
On the mobius strips... Troll?
| |
No, he actually said he liked the idea of seamless maps wrapping around, in a topic called "Mobius strip maps."
I don't think it'd actually be a mobius strip. | |
Oh I was confused!
| |
Here's the concept I had in mind:
First, we might want to build in a new format for easily loading and saving maps sections, not .dmm because it's not capable of representing full map complexity, but something else. SwapMaps and other libraries can do this, but a native method would be a great thing to have. Tom has talked about this before. For connections, a var called world.maps could hold a built-in list of datums or special arrays that store info about the connections between maps, so for example world.maps[1][EAST] could tell you which map is connected to z=1 on the east. Making connections could be as easy as setting this var. All connections would be symmetrical. The engine would assume diagonals would be kept consistent; there's no way to enforce consistency otherwise. A map could be able to connect to itself. Functions like block() and view() would be fundamentally altered. locate(0,0,z) would also not necessarily be meaningless, as connections could be followed to reach a new, valid location, within reason. (Example of what I mean by "within reason": If you have connections to the west and south, but the maps each side is joined to have no connections that would give you a valid southwest, then -100,-100,z would become meaningless even if there's an indirect path that will get there. The engine would try to follow west or south if southwest was unavailable, but it wouldn't backtrack.) The goal here is just that you might have coordinates relative to the current map that could make sense via connections, but ambiguous cases would be treated as failures to prevent loss of performance. Walking/stepping and get_dir() would obviously be altered as well. It might be reasonable to keep a list of ways to reach one z level from another, as there are graph algorithms that cover that sort of thing. The number of z levels should never get so big that an N^2 list of small data would be difficult to manage. | |
That was a lot of information about the wrapping of the map and not a lot about actual maps.
Any more info about the actual map themselves, like if they'll be dynamic and more useful at run time? I haven't seen a non-native solution really pull it off. Nothing is fast. | |
FIREking wrote:
Any more info about the actual map themselves, like if they'll be dynamic and more useful at run time? I haven't seen a non-native solution really pull it off. Nothing is fast. I did mention Tom and I have talked about native map loading and saving. I think it would be good to have map saving that could leverage our existing savefile code, though it'd end up being very similar to SwapMaps in that sense, just more streamlined. Loading maps could be done by parsing .dmm files (SwapMaps can do this) or reading the same format we use to save. As with any saving option there would be some caveats. We'd want to avoid saving mobs that are attached to keys, for instance. We'd also want to avoid saving references to any turfs not on the map, and probably also any objs and mobs not on the map, unless they're built into the compile. | |
Why don't you just cut the map into sections? 1 million tiles is a lot in one map @_@! I mean if you turned 1000x1000 into 4 500x500 I think it would cut down a lot and you can have a lot of those!
| |
We're talking about loading and unloading maps at runtime, not about having more maps. The only way to have more maps at once is to reduce the size of the turf itself. Each turf has a finite number of bits or bytes in memory that it takes. Unfortunately, in 32 bit land, you only have a finite amount of memory, hence you can't just have as many turfs as you want.
The games mentioned by the OP use complex mathematical algorithms to describe the landscape, instead of just "holding" the data or memory of the landscape. You can describe a hill side or a collection of valleys with an algorithm in less space than it actually takes to hold the landscape on a hard drive. At any rate, we're simply concerned with having the ability to better handle maps during run time so that we can "seemingly" have large worlds. There's no point in loading your entire world map if only 20 players are online and they're in the same town. The only way to have a big world is to load things as you need them. | |
Man, if we could easily and quickly load and unload maps there would be so many more possibilities, and even things that are possible now could be made waaaay more efficient. Imagine a side-scroller that doesn't have all of the levels loaded at the same time, that can easily load new levels from files; I'd have a blast with that.
| |
Spirit Age's engine is built to have maps created,and rendered at runtime. a map/zone is only loaded for a player once they've entered it. so it frees up a lot of memory for us.
the way we've worked around it is not to use DMM at all. Maps are saved via save files. http://puu.sh/3nK0J.png http://puu.sh/3nJML.png Some native support would be nice indeed but, i just wanted to show people that there are possible work arounds :/ | |
Zane444 wrote:
Spirit Age's engine is built to have maps created,and rendered at runtime. a map/zone is only loaded for a player once they've entered it. so it frees up a lot of memory for us. Yeah, that method is pretty slow from my experience. | |
Its actually quite fast. rendering an entire map almost instantly.
| |
Zane444 wrote:
Its actually quite fast. rendering an entire map almost instantly. That sounds good, but their dev team will probably never share it with the community so who cares, this is why we have to request the features because we're trying to make games, not map loaders. | |
FIREking wrote:
Zane444 wrote: Actually i'll just explain now how I did it for Spirit Age, to share the current system would require sharing the source so here is the next best option; Step #1 - Create a .dmm with the number of zones you want, I have a 5x5-100x100 grid for our main map, and an additional 5 for interiors, so I have 30 100x100 zones. Step #2 - A library has to be defined to house the list of objects (smart objects) that are available to be placed on the map. The names of these objects act as a unique ID to be used as reference by their sub-objects. These "smart" objects hold data such as bounds, icon and more. Step #3 - For each zone, I have lists such as; names (ID), x, y, z, step_x, step_y, etc. These lists are read upon map loading (prompted by player entry), sub-objects are created based on the data in the lists which gives them position & ID, they then call on their parent smart object for their other characteristics. (using their unique name/ID as a reference to find their parent.) This takes less than 1 second to completely load each zone. It becomes trickier when you get to writing the map editor ontop to achieve this type of functionality but your editor really would have to be tailored to your purpose, but it gives you a lot more power in the long run. I do intend to create a demo to display the system, but I have a few things I have to get done first. | |
I feel like some of your terms are being used loosely, for example you said "a library has to be defined"... What exactly do you mean by "library"... and "to house the list of smart objects"... What are smart objects?
Based on what you said, it doesn't seem much different than just saving everything as a buntch of text and just being choosey with which variables you care about to decrease the amount of data to parse. | |
FIREking wrote:
I feel like some of your terms are being used loosely, for example you said "a library has to be defined"... What exactly do you mean by "library"... and "to house the list of smart objects"... What are smart objects? When I say "define library" I mean you will need to create a system for keeping records of the smart objects, "smart object" is a term I have used to define a set of data that represents something like a tree or NPC in an world. It is saving everything basically as a bunch of text/characters, that is what the .sav is afterall. The point is that the data is saved in packets as savefiles and loaded when requested, instead of loading the entire map when some will not be needed. | |
Maybe you're misunderstanding what I was trying to say.
http://i.imgur.com/MNPlMcg.jpg Imagine this represents a 1000x1000 map. Each square on it is a 100x100 area on this map. The red dots represent players. When BYOND loads this game, the entire 1000x1000 map is loaded into memory. Even if you make the majority of it blank and fill it when needed, that area of the map still exists and still takes up resources. You cannot make parts of a BYOND map not exist. If you have a single 100x100 z layer, but then in game set world.maxz to 100, another 99 maps are made. They are empty, but they take up RAM. The same applies here, but on a single z layer. This is a waste, a huge waste. What makes more sense is to do something like in this picture. http://i.imgur.com/mKDnzpJ.jpg This is the same 1000x1000 map, divided into 100x100 areas. Only the green areas exist and are loaded. As a player moves, areas that have no players in, or next to them are unloaded (possibly saved if that is what the developer wants), and any areas next to an area a player enters are loaded. At any one time, there will never be more than 9 out of 100 areas loaded for a single player. Obviously, these numbers are just examples, but in games with large, open worlds, this is usually how such a large world is managed. What BYOND does however is load the entire world, even if only 9% (or less) of it is needed, all of it is loaded. Such a feature would probably be complex to add, and complex for people to make use of, but currently such a feature is impossible to replicate in BYOND and would be immensely useful for a lot of games. PS. While we're on the subject, is there any reason the map editor limits map size to 1000x1000 while you can set world.maxx/maxy to any number you want (I'd had it to 5000 before). | |
