Layer Functions in ZC 3.0

[CJC]

This isn't so much a feature request as an idea on how to handle Layers after the tear-down. Since the tear-down won't be beginning for quite a while, this won't be important until later. It is, however, a core mechanic of ZQuest, which is why I felt it best to bring it up now before the tear-down begins.


I think it would be beneficial to redesign the way layers handle information.

Currently, the zero, one, and two layers are hard-coded to be the only ones that transmit their combo data to the engine, while layers three, four, five, and six strictly display their tiles. Also, 'overhead' positioning is also hard-coded into layers three and four for Link and ground enemies, and five and six for flying enemies.

I believe these things should be handled globally instead of being locked features.


Here's my thought:

Each layer would acquire identical function, and could be 'radio button' flagged as a combo layer or a tile layer. Combo layers transmit their combo information to the engine, meaning they can affect the player's screen. Tile layers simply display their image. Each layer would also have a 'minimum z-height' that decides when a L-Object or E-Object should be placed on that layer.


In addition, this menu would allow the player to set Link's Z-Height. His Z-Height is used in conjunction with the minimum layer heights to determine which combos affect him, and which layer he is drawn on. The default Link Z-Height is the same as the minimum Z-Height for layer 2.
The enemy editor would also require a similar addition, allowing the quest maker to specify just which layers should influence the enemies.


I also suppose scripting changes to these settings would be possible, although it would be along the same lines as 'snatching combos' from other screens: make sure you know what you're doing.

EDIT EDIT: Strike that, this would spew glitches throughout old quests. Instead, being able to set a 'Link Combo Layer' range, with a low and high value that determines which combo layers affect him (Default 0-6), and a 'Link Draw Layer' which dictates which layer Link is drawn on would maintain backwards functionality.



ORIGINAL EDIT: OH! Related tangently, the ability to set the amount of increase on the z-axis necessary to display a y-shift. This is hard-coded too and would be the primary impediment of using these layer adjustments to make a game-boy style game.

[CJC]

@Majora
had a brilliant idea (that I wish he would have posted in here) with regard to this suggestion.
He proposed that the combo options menu could dictate which layers it affects, allowing for a much greater control of layer influences. Coupled with the option to script which layer Link or an enemy functions on, this would serve an identical function to my suggestion with a lot less work.

[Majora]

[17:47:50] <%CJC> My original idea was to have each layer be able to function as either a combo layer or a display layer, unlike the hard-coded system it currently uses
[17:48:13] <+Majora> see things like that ... I dunno
[17:48:15] <%CJC> Each layer would have a 'z-position' height, that, if exceeded by another resource on the screen, would force it to draw beneath and ignore its combo properties
[17:48:26] <+Majora> I much prefer every aspect be applied to the pieces of the puzzle themselves
[17:48:34] <+Majora> in this case, a setting on individual combos for that
[17:48:49] <%CJC> ...That's...
[17:48:50] <%CJC> Brilliant
[17:48:53] <+Majora> "attributes active on Layer (checkboxes)"
[17:48:56] <+Majora> it allows for much more flexibility
[17:49:16] <%CJC> What about forcing Link to change layers?
[17:49:36] <%CJC> Like when he jumps, or goes up a ramp?
[17:50:13] <+Marisa> Actually I lied, 3.0 will be a Zelda minecraft mod lel
[17:50:35] <+Majora> unless you get a whole team of codemonkeys on this, making layers interact with link might be a suicide mission
[17:51:03] <+Majora> I mean truly interact beyond damage combos on layers 1/2 or tiles being drawn over/under him.
[17:51:11] <+Majora> pushblocks on layer five!
[17:51:26] <+Majora> because the room has non-warp stairs/different levels!
[17:51:40] <%CJC> Yeah, that's what I was going for
[17:51:53] <+Majora> no more using duplicate screens to simulate over/under bridges!
[17:52:06] <+Majora> because link is literall walking on layer 3!
[17:52:18] <+Marisa> Dunno about you guys, but I'd like to see true multi layer rooms like in LttP...
[17:52:40] <+Majora> layer transition horizontal/vertical/4-way combos!
[17:52:50] <+Marisa> Like where Link could be walking under a bridge and an enemy could be walking over it at the same time
[17:52:50] <+Majora> if link is walking from left to right/right to left, he either goes up or down a layer
[17:53:00] <+Majora> and not hit link when their XY coincide
[17:53:05] <+Majora> because their Zs are different
[17:53:07] <+Marisa> yeh
[17:53:22] <%CJC> My idea was that Link would have a set 'z-height', making him approximately as tall as Layer 2, and that if his minimum z-height was greater than the layer's minimum z-height, he would be considered 'on that layer' for the purpose of combo function
[17:53:51] <%CJC> Each combo would be considered 'one layer' tall, meaning you'd have to 'cake' mountains with multiple layers to make them have a higher physical position on the screen.
[17:53:58] <+Majora> it would probably be easier to just use a pseudo-3D engine
[17:54:15] <+Majora> instead of half-assing 3D with a 2D engine
[17:54:40] <%CJC> I suppose trying to make it work with the current assumptions of ZC is moot, since it's a tear-down anyway.
[17:54:42] <%CJC> You're right, Majora
[17:56:00] <%CJC> Though technically... you COULD achieve this if you wrote a script that caused automatic tile-warps to another screen when Link reaches certain z-heights. ...Wow, that is insanely complicated!
[17:56:52] * CJC is now known as CJC|BRB

[DarkDragon]

LttP-style multiple walkable layers are a good idea. It will take quite a bit of thought figuring out how to make them work, though.

[aaa2]

What is so difficult about that. You just tag a layers as walk layer background layer(where combos dont work) and as foreground layers. Then you put an invisible line at say steps and check if that line gets crossed from where depending on that you toggle between foreground background and walk layer status.
I dont see whats even to think about here its just assigning some extra properties and then checking those properties first when looping through the layers.

Probably when programming all that you will need to create a class layer anyways that holds a number (layer num) combo list and some extra properties where those can be included anyways. Then you can have an interact function for that layer that depends on those properties. In a class screen then you can call those layer functions. It seems pretty easy to me(at least if you code object oriented and in a constructive way slowly building your way up from primitive data types).

Oftentimes when seeing all those seemingly hardcoded arrays in zelda classic i wonder why no std::vectors were used seeing how standard and fast they actually are.

[SUCCESSOR]

I would see layers working something like this:

You have the normal 8 display layers(DL0 - DL7) and then say 3 walkable layers(WL0 - WL2). The walkable layers are simply a way to tell the game where to draw the display layers. You simply set where the walkable layers align with the display layers. WL0 -> DL0, WL1->DL3, WL3 -> DL5 So when Link enters the screen he goes to the default Walkable Layer(Let's say WL0) and the game draws him over DL0 and every other layer over him(Let's say he is on the floor of a forest) and only combo flags on DL0 are active/triggerable. There are stairs leading up to rails built in the trees so you put a flag on these stairs that tells the game to move Link to WL1 and he is now drawn over DL0, 1, 2, and 3 and only combo flags on DL3 affect him. We move Link to WL2 so now link appears over the treetops(walking or flying) and only combo flags on DL5 affect him.

Enemies would be placed on Walkable Layers as well and wouldn't affect Link if he was on another layer unless programmed to somehow do so.

Also setting height values for Walkable Layers would be necessary. So if Link jumps higher than WL1 set height (with nothing in the way)then he would be able to walk onto that layer or be hit by enemies on that layer. Or say you have a Boss that is on WL0 but has a hitbox set high on the Z-axis so Link has to be on WL1or 2 to be able to hit it's head and damage it.

I am not experienced with game programming so I can't tell you how it would be coded. Just scraping ideas off the top of my brain.