new map_format: PILE_MAP

Page: 1 2 3 4
ID:104732
 
Nov 18 2010, 2:44 pm
Redundant
Applies to:DM Language
Status: Redundant
This feature has already been implemented, or is already achievable with existing methods.
Native support for this type of map:

All I did was add on to the classic roof system, with certain invisibility/see_invisibility and layer modifications. That is only a poor illusion, however.
With this mode's support, collisions and other interactions between floors can more easily be handled.

In my project, I was able to simulate these features myself:
-I use multiple Z levels that at runtime all pile onto the ground level(grass; the brown area is a big ditch). This only practically allows for one usable Z level, with all the rest being completely empty.
-Stepping onto a tile with a floor one level above you will disable your ability to see all higher floors. In the image below, I stand in the northeast tower.

This is mainly to avoid not being able to see yourself. I also have verbs(look up, look straight). Looking Up allows for you to see the sides of buildings, while Looking Straight removes the tall buildings that block your view of what's directly north of them.
-Modified Move() to ignore collisions on separate floors.
-Icons are lighter at higher floors. This isn't absolutely necessary, but in my opinion it adds depth. It's not relative to your floor in my project, but it probably should be. (Floors higher than you will look ligher, floors lower will look darker)
-A set floor height: the distance in height between one floor and the next. The pixel_y of the floors are currently calculated floor * LEVEL_HEIGHT
-The floors themselves are all under /obj. This makes checking for stairs a bit tedious.

What I can see in the future with this map mode:
-Opacity relative only to the same floor(currently, the only way to do this would be to use black images)
-Multiple Z levels, if a "floor" variable other than "z" itself can be separately added. For travel between... planets or mystical dimensions.
-In Dream Maker's map editor, another set of arrows to edit separate floors. I see it being like in The Sims, where you can see lower floors in the map editor but only modify tiles on the current floor.
-Interactions between floors can still be considered, using procs similar in essence to block() (maybe interfloor_view_crazy_proc_name()?) instead of view(). The view() proc in this mode would only return tiles on the one floor, as if you were on separate z levels.
-The floors would all be under /turf.

Another thing that came to mind is the isometric view that was added. This PILE_MAP format could simply be ORed together like so:
world/map_format = TOPDOWN_MAP | PILE_MAP
//or
world/map_format = ISOMETRIC_MAP | PILE_MAP

I'm sure it would make better use of isometric mapping if BYOND handled multiple floors.

Basically, this feature only really asks for being able to view multiple Z levels (in this case, those less than or equal to the current Z level, unless you're not under a building), along with better interaction between those visible.
Nov 18 2010, 7:14 pm
I really support this, too. It would be absolutely amazing for my project (as it ideally incorporates underground aspects, as well as above-ground aspects), and they could be more easily dealt with this way.
Nov 19 2010, 4:17 am
I would absolutely love this to be implemented, and I'm certain SuperAntx would too considering his Decadence game utilizes a form of viewing Underground/Above-Ground features.

I could use this in my current project when dealing with buildings and having the player be able to jump on-top of the top of a building to view players on a lower-ground level, instead of coming up with my own system.
Nov 20 2010, 4:47 am
As much as I would love to see this (I really do, I even asked for it in a thread when there was no feature tracker yet ;)), the response was rather negative, mainly regarding issues with view based procedures and how hard-wired the client's functionality is, as far as I recall.
Nov 20 2010, 2:17 pm (Edited on Nov 21 2010, 3:36 am)
This can also work with my/Falacy(He created the name) (draw_dist) proc. (http://www.byond.com/members/ DreamMakers?command=view_tracker_issue&tracker_issue=2322)

Nov 21 2010, 3:33 am
Schnitzelnagler wrote:
mainly regarding issues with view based procedures and how hard-wired the client's functionality is, as far as I recall.

lol if we can manage it ourselves through just a few modifications, how hard could it be for them? Maybe somebody should just build a library for it
Nov 21 2010, 4:49 am
I wouldn't consider it that easy, given that the solution has to be modular and expansible enough to fit more games and the mess that the BYOND client obviously calls a source code ;)
Two problems a BYOND developer wouldn't have to deal with.
Nov 21 2010, 4:56 am
The only complication I can think of would be setting src in o/view(), though that proc could be augmented with something like layer() from their end
Nov 22 2010, 6:39 am
It sounds like this is better handled as a library than as a built-in feature. Having this be a built-in feature would save you a lot of time but it doesn't sound like there are any benefits that are feasible for a built-in implementation that you cannot already achieve now.
Nov 22 2010, 8:31 am
Forum_account wrote:
(...) any benefits that are feasible for a built-in implementation (...)

You mean like saving on a lot of overhead, objects and general server resources, allowing for this map type to be used in real multi player games (talking 200 players on a server MORPG) while looking somewhat professional?
Nov 22 2010, 11:50 am
Schnitzelnagler wrote:
You mean like saving on a lot of overhead, objects and general server resources

Any feature that you can soft-code in DM has a potential built-in implementation that would save overhead and resources. These aren't valid reasons to include the feature because these are benefits of all features.

allowing for this map type to be used in real multi player games (talking 200 players on a server MORPG) while looking somewhat professional?

I don't see any technical limitation that prevents this from being accomplished already. There's no reason why Kaiochao's work can't lead to a quality library.
Jan 10 2011, 12:10 pm
When I get a single core supercomputer to host all my BYOND projects, I'll stop complaining about how slow BYOND is in general. I'd still really like to see something like this happen.
Jan 14 2011, 1:01 pm
I agree this would be nice to see implemented, I can already do this currently using the same kind of tricks but it's not like we can change the map editor so it handles how we need to more easily edit the map in this way, you can't code the map editor.

As far as things goes you'd need something in-game or from a whole other program, etc... made for editing maps of these types because how BYOND's map editor works can't be changed in any way by us.
Feb 5 2011, 3:00 pm
As far as putting multiple floors in the same view(), that's highly difficult and is unlikely to be done.

If this is just a visual effect, I'm generally okay with the concept (although I don't think it needs to be done with map_format)--the problem is it'd be necessary to specify which z levels were truly "above" which others, since obviously if z 1-3 is a certain zone and 4-5 are another, you don't want level 4 overlaying level 3. It seems to me this suggestion is missing the critical matter of how this would be implemented on the DM language side of things, since just setting PILE_MAP would definitely be inadequate to handle those cases.
Feb 5 2011, 7:00 pm
I think the critical matter is how BYOND handles Z levels in general. My theory is that BYOND's concept of Z levels came from the days of DUNG, where they were designed for multiple floors in a dungeon, reached through ladders or completing the level by finding the lost treasure. I'm sorry if I'm coming off as wanting to change BYOND for my specific reasons, and I'm sure that's how BYOND started, with a certain goal in mind: let people make their own graphical, multi-user dungeons.
Other more successful programming languages focused on efficiency and flexibility(the languages used to make BYOND have nearly infinite other uses), while DM seems to be focused on simplicity of syntax(the easier it is for the user, the more complex it is behind the scenes) and... whatever popped up as suggestions in earlier development.
I understand that this request was poorly written, and I apologize for wanting to change the way BYOND works as a game development tool. I can't help but want changes that make BYOND easier for me to use, yet I also can't help but think that it may be too late.
Can't help but wonder how different the amount of influence I would have had before 2000 is than that of today.

At any rate, this request is probably hopeless. Optimistically speaking however, someone may bring up an idea that would make this work. Maybe, a W coordinate to go along with XYZ? Haha.
Feb 5 2011, 7:35 pm
I don't think there's really anything to apologize for here. The general concept sounds good, it's just that there's no implementation plan to go with it.
Feb 5 2011, 8:22 pm (Edited on Feb 6 2011, 12:40 am)
I think it'd be interesting to have an equivalent of a 3D "z" coordinate for atoms(maybe "w" to go along with xyz, but please feel free to name it anything else), rather than the "zone/level" z coordinate that exists. This way, atoms may be on the same z level. Clients would have a w_range variable that specified what w levels are visible.

I was thinking that the map editor would have another set of buttons near the [<] and [>] buttons for changing Z level: [^] and [v] for changing W level. I'm not how much sense it would make to include a w_range setting for the map editor, which would act the same was as client.w_range would at runtime. Like for different Z levels, you'd only be able to edit the tiles on that W level.

The "w_range" variable would be in the format "[low] to [high]" or the default, null.
low:
-a number less than 0. -1, for example, would give the client "visual access" to the floor directly beneath its mob's current floor.
-"BELOW" for all floors below the current floor.
-"CURRENT" or 0 for the current floor.

high:
-a number greater than 0. 1 = floor directly above, 2 = see floors 1 and 2 above current floor.
-"ABOVE" for all floors above the current floor.
-"CURRENT" or 0 for the current floor.

Example would be client/w_range = "BELOW to CURRENT". This would allow the client to see all floors below the current floor, including the current floor.
Like the isometric mode, atoms on a higher floor will always appear over lower-floor atoms. (I would love for an easy way to modify an icon's alpha value with a simple variable, so that you might be able to see higher floors completely transparent o:)

This is different than magically associating the Z levels to other Z levels. This is pretty much a request to make another couple variables that work how you'd expect a Z-coordinate to. As for view()-based functions, I'd say do as much as possible to relate them somehow, if possible. If not, then they would only return objects on the same W level.

If there's a lot missing, I'd love to try and think up more stuff. If it's complete crap, feel free to say so.

Also, I like how this has only 1 vote(mine) and is still being paid attention to :)

(Can I say that this would be awesome, though completely unrelated?)
Feb 6 2011, 7:53 am (Edited on Feb 6 2011, 7:58 am)
Why would you implement an imaginary 4th dimension instead of just calling it z_range? Would your suggested w even do anything by itself? I think something like "floors" (above and below), associated with a z layer on the map, would be effective. Though, you would probably want some way to change it at runtime, per client. Also, wouldn't you need to be able to leave turfs blank where you want to see above/below? Currently not possible.
Feb 6 2011, 8:23 am
As I said, please feel free to name it anything else. I know that W doesn't make sense, and I'm asking for discussion to come up with a better name.
Maybe other floors would ignore world.turf/turfs with icons so that they would appear blank.
I'm already asking for a lot here, and I appreciate any discussion to help clarify it. :)
Jun 2 2011, 1:05 pm (Edited on Jun 2 2011, 1:38 pm)
Lummox JR wrote:
I don't think there's really anything to apologize for here. The general concept sounds good, it's just that there's no implementation plan to go with it.

I see this written on a lot of feature requests. It was made much more annoying when "Needs Discussion" was applied. What needs to be discussed here?

Not to be rude but if you aren't going to plan it then we have to, right? What do we need to plan out for an implementation? What needs to be taken into account?

I see a few things mentioned by you and a few ideas for responses but like always, that's where the conversation dies. There needs to be more communication if anything is to get done, if any help is to come from us.

As for this request, I would love to see this implemented. I would assume it to be a purely visual effect and that the effect would only apply to single maps with multiple z layers. I can see an issue with isometric display (which is what I want it for) with how "high" up the map is displayed. This could easily be handled with a pixel_z equivalent for maps. It could be a global variable, a variable for the map itself (set in the map editor), or even a variable for each individual layer.

The second issue I perceive is with buildings, as shown in the pictures above. I think a variable could be defined for areas that will allow or disallow the showing of higher layers in that area.

Just my two cents. If I missed anything, I'll be glad to throw in more ideas (as I really, really, really want this feature for a new project).

EDIT: As for view(), range(), et cetera, they would function as normal but could have third argument for vertical distance. For example, range(5,usr,2) could return everything in a 5x5x2 area. Though this is not entirely even necessary considering the existence of block().

EDIT 2: Though it seems there are some speed issues concerning block().
Page: 1 2 3 4