ID:260725
 
I know this isn't the best time for large suggestions, and I realize that if I want to make use of this I'll probably have to wait until at least fall 2010 to be lucky, but I got a design so here goes...

Maps currently work with X,Y,Z coordinates. The X and Y coordinates are points on the map, while the Z coordinate refers to the map you want to use.

The suggestion is to radically alter this. However, older versions should naturally remain backwards compatible.

An additional coordinate would be handy: the "map" coordinate. It can be used in locate() and accepts two possible values:
  • A reference to a resource file.
  • A reference to an external file.
  • Both files must be map files (.dmm) in order to work.

    Now this solves one issue that I've read about countless times: being able to separate z-levels from multiple map files.

    But this is not all that I'm requesting. Nay, the real request is about layers.

    Z-levels should be seen as layers. If you're on z-level 3, and there's a floor tile "missing" (a turf with no icon / (partially) transparent icon), it should be see-through to z-level 2. With this design in mind, it's actually possible to do this.

    That's basically my suggestion. To separate multiple map files and z-levels from each other, and to then use the z-levels as layers which are stacked on top of each other in relation to what the player sees. Perhaps there could even be a set src argument of some sort that can be used to access verbs of objects on different layers. I dunno.

    Any thoughts on this idea though? I bet it'll take 5.0 to finally have this implemented, but I just wanted to throw this idea out there in case nobody else thought of it this way yet.
Android Data wrote:
(...) use the z-levels as layers which are stacked on top of each other in relation to what the player sees.

I would certainly love to see this implemented, but why would that require a new way to sort/store/reference map levels?
You could do the very same with the current set up as well, "all" you'd have to do is to alter the client (and maybe parts of the client server communication).
Android Data wrote:
[i]> Z-levels should be seen as layers. If you're on z-level 3, and there's a floor tile "missing" (a turf with no icon / (partially) transparent icon), it should be see-through to z-level 2. With this design in mind, it's actually possible to do this.
That's basically my suggestion. To separate multiple map files and z-levels from each other, and to then use the z-levels as layers which are stacked on top of each other in relation to what the player sees. Perhaps there could even be a set src argument of some sort that can be used to access verbs of objects on different layers. I dunno.[/i]


That how games named Tibia engine works. As for BYOND, it probably would need too much engine edits (nearly remaking drawing) also that would increase bandwidth if networking would work as it is.
On the other hand, it already been made using on BYOND, as demo if I remember right
You can already stack atoms on top of each other to build such an effect, I see no reason to completely redesign the map editor to do what it already can o.O

And you can already include multiple maps files as well, though they just turn into a single map with multiple z layers.
Something like what was requested here ([link]) would probably more effective and much easier to implement.
In response to Falacy
You don't seem to really understand his suggestion.
In response to Kaioken
Kaioken wrote:
You don't seem to really understand his suggestion.

"Z-levels should be seen as layers. If you're on z-level 3, and there's a floor tile "missing" (a turf with no icon / (partially) transparent icon), it should be see-through to z-level 2. With this design in mind, it's actually possible to do this."

You can already do exactly that by sticking stuff on top of each other. Granted going back and editing lower levels isn't exactly easy, but completely revamping the mapping system to do something like this would be a gigantic waste of their time. If for some reason you want to design multi layered maps like this (with more flexibility), then just make your own little BYOND program to do it in, it wouldn't be all that hard considering it can already handle what hes asking.
In response to Falacy
Falacy wrote:
You can already do exactly that by sticking stuff on top of each other.

If you can find me a way to draw 100x100x3 turfs on top of each other, be my guest. =)

Oh, and by the way, I don't want the object count being drastically affected by the procedure, either.
In response to Android Data
You can probably do it with no extra objects at all by simply using underlays, can't you? Not that it means it'd be good/efficient/worthwhile, but it's most probably possible.
In response to Android Data
Android Data wrote:
If you can find me a way to draw 100x100x3 turfs on top of each other, be my guest. =)

You can stack turfs just like anything else, as long as they're transparent or not filling the entire icon space. Of course, they all turn into whatever the top layer one is at run-time.
Hmm... This is actually a really interesting suggestion. Hopefully there will be something like this added. I would be interested in seeing it in action. Sounds like a great idea.
In response to Kaioken
Kaioken wrote:
You can probably do it with no extra objects at all by simply using underlays, can't you? Not that it means it'd be good/efficient/worthwhile, but it's most probably possible.

Except every turf has a variable I need to access, since there's a gas system running. Every turf makes any "gas" that's on it spread.

It's possible to replicate the behavior with objects, but turfs "stacked on top of each other" (which just turns out as a single turf with multiple underlays) isn't the answer here since it needs access to that variable.

And even if you go "hey, but surely you can stop being lazy and do something about it, like making a single turf account for multiple layers", there's still the issue of getting this all to work: how am I supposed to map the multiple floors out?

The logical way would be to use z-levels. Since I don't use them much for anything else, I suppose this is doable. Except then you have the issue that the entire game is going to freeze up for five minutes whenever it starts up because it needs to be merge the maps automatically.


But okay. You make it work properly w/o having to re-merge the map every time I make a change. Even cached it'd cause significant problems, and this suggestion puts these problems away, at least for future generations.
In response to Android Data
Just like 90% of your suggestion posts, this would benefit nobody but you. Your description of use doesn't even make any sense anymore. You have multiple floors, with multiple gas leaks, that can all be seen/accessed at the same time? And yes, you could very easily track whatever this gas leak thing you're talking about is; if you have 3 floors, just add a variable on the turf that contains an array with 3 entries.
In response to Falacy
You don't see the point. This is a pretty cool suggestion, and pretty much emulates a top down 3D environment (3D in the sense that you actually have three dimensions). This is useful to many people, despite what you think.
In response to Jeff8500
Maybe I just can't picture what it is you want to do. Somebody make a diagram or something.
In response to Falacy
A good example would be games with roofs that disappear when you walk into a building. Instead of CPU/RAM-heavy image manipulation, you can simply change someone's Z-level (not as good example). A better example would be a game with flying. Increase someone's Z-level one, and all the sudden, they're flying with everything below them. The only this is that people can't see them, unless their eye is set to a Z level higher than their current Z level. There's infinite use for this, and were it implemented, you would definitely end up using it in one of your games (most likely your DBZ one).
In response to Jeff8500
You really did use a bad example, no offense ;p You can do that (that particular thing) by utilizing the layer variable ^-^

What I think Android is getting at, is if you have some null area at coordinate 1,1 on z-layer 1, whatever is on coordinate 1,1 on z-layer 2 will show up on that spot on z-layer 1.
In response to Spunky_Girl
Not really. Looks like I'm having a hard time explaining the idea, too.
I don't understand the point of this...

If you could clarify:

You're basically requesting that multiple height levels be implemented naturally into BYOND. I.E: If you are on Z-3 and there is turf, then its just like normal, but if there is a spot where there isn't turf, you can fall through to Z level 2, and interact with objects/etc from Z-level 2?
In response to AJX
AJX wrote:
You're basically requesting that multiple height levels be implemented naturally into BYOND.

He is, somewhat. But not like what you're saying.

I.E: If you are on Z-3 and there is turf, then its just like normal, but if there is a spot where there isn't turf,

There's no such thing as a spot on the map where there isn't a turf, by the way.

you can fall through to Z level 2, and interact with objects/etc from Z-level 2?

No. Unless a programmer specifically implements that into his game, anyway.

What 'Data is suggesting is that when a turf has no icon, or has transparent parts in its icon (and you can assume the same for the turf's area as well), then you'll be able to see through the transparent part to the lower z level(s). i.e., have it built like floors in a house. If a floor tile is missing or is transparent, you can see into the the previous floor/level below it. Additionally, it may "nest"; i.e., if both turfs 1,1,3 and 1,1,2 are transparent, then if you're on z level 3 you can see through the turf 1,1,3 into the turf 1,1,1. The suggestion is in the basic sense visual-only. Also, this should have been obvious but people (Falacy) seem to miss it, but seeing into lower levels should be integrated into BYOND the same way as seeing your current z-level. This means seeing a turf includes everything that should be in sight, e.g. objs or mobs on that turf would also be visible, and you can do with those whatever you can with usual objects that are in your current z-level, like mouseover them to see their name, use the mouse procs on them (like Click()), etc. Procs like view() and viewers() should also be modified to indicate the new atoms in sight that are in different z-levels, but that should probably only be limited to when a specific argument is specified to turn that on. Actually if this is implemented, one should be able to turn on/off the entire feature with a world var.
Possible usage which is not related to me: You can walk up the inn of "Ye Olde Generic RPG". You can then walk up the stairs.

And when you look outside a window, you actually see players down below who are about to enter the inn.
  • In RPG games, it adds to the atmosphere.
  • In adventure games, it can be used to show alternative routes or give clues.
  • In horror games, it can be used as suspense (you can see the zombies entering the inn rather than just hearing them).
  • In Anime/RPG games you can create a bench at a higher z-level from which players can see a big arena on the lower level. The players in the arena can't see who is spectating them, and can focus on their fight. The spectators remain unaffected by whatever the fighters do. (Hey, I'm talking Anime here. Nobody expects these guys to program well. =P)

  • There's a lot of other reasons why this would be an awesome feature. Unfortunately, we likely won't see this anytime soon...
Page: 1 2