"For each layer" event type

[Elairyx7301]

Short description

A "for each layer" event type that iterates through all layers, saving the current layer name in a scene variable (like the "for each child variable" event type does it) for users to easily get all layers automatically.

Description

With the GDevelop "code blocks" it's possible to iterate through all instances, array/structure children etc. but to get all existing layers requires a JS block which I believe many users aren't familiar with (especially with the PixiJS- and GDevelop syntax and -specific actions) and would be opposite to the "with no programming language to learn" slogan.

While making a camera zoom extension where this event type would have saved me some time, I see other applications for this event as well. For example showing all layers, rotate (angle) camera on all layers (to create a rotation effect for an upside-down game etc.) and enable/disable layer effects for all layers.

Current method

Note that even though this isn't much code, I find it difficult to build working logic on top of it.

const allLayerNames = new Array(); //Create array for all layers
runtimeScene.getAllLayerNames(allLayerNames); //Add all layers to the array

allLayerNames.forEach(layerName => //Iterate through all layers
{ //...
})

Solution suggested

A "for each layer" event type that iterates through all layers, saving the current layer name in a scene variable to access all layers / iterate through them. (from a code perspective, this event might be similar to the "for each child variable" event type)

[4ian]

I'm a bit sceptical about making this easier to do.
Layers are usually not present in a large number in games - a few for the UI, for the game, for the background. So iterating on them is an unusual operation. I can see the need for sometimes doing a lot of similar operation on a multiple layers (like change the zoom/angle of 4 or 5 layers). But in this case, I would recommend to pack these actions into an extension dedicated to your game, in a custom action :) Because it's quite possible that some games have layers that they don't want an extension to touch.

The "for each layer" solution here would also mean exposing a very specific concept (layers) to a very generic place (the events, which are supposed to define the structure to create the logic of your game) - so it feels a bit out of place.

An alternative could be to expose a way to 1) get the total number of layers and 2) an action to get the name of the layer at a given index. So you could iterate on them using a For Each event - it would be the equivalent of the JS code you exposed.
Not as easy - but again this is not necessarily something that we want to make easy.

Sometimes less is more, and in the case of layer I'm hesitant to give more power through events because iterating is something you want to avoid in most cases. Let me know if you have more specific use cases in mind though! :)

[Elairyx7301]

You mentioned a few points I haven't thought about and I totally see and understand the reasons for those arguments you made.

In the back of my head I was - maybe only subconsciously - planning a huge debug "kit" or tools (mainly for personal use) that allows to hide and zoom all layers so with those tools I could easily navigate through a big platformer level etc. or maybe for a flickering effect on all layers but those and even though it would be nice to not be required to use JS for it, those are actions that are far from impossible with the currently available tools so I'm not saying something against your understandable decision

[Silver-Streak]

I'll refer back to my GUI Layer proposal from a while back: https://forum.gdevelop-app.com/t/implement-gui-layer-based-scaling-options-to-better-scale-text-and-other-objects/27705

If there was a "For Each Layer" event type, the amount of math and events required for this becomes substantially simpler. As you can see in the example, handling "for each layer" via just events becomes substantially more difficult the more layers you have, as you'd start needing to have repeats/variables/etc which becomes more complicated for new users.

While obviously a perfect world solution (for me) would be implementation of a full GUI layer and associated scaling methods for non-GUI layers (to allow for better scaling/resolution options for users and eliminating the need of "For each layer" for this purpose), because "For each layer" has multiple uses beyond just my GUI layer proposal I can still see value to non-JS users on a pretty regular basis.

I'd also say just having GUI + Base + One Background isn't quite true to most games newer than NES.

To give an example: Checking some games from the SNES area, such as Mega Man X, there are 4 layers not including the base layer for the parallax and animations they're doing in background layers, not just a single background layer. On top of that they also have their GUI.

No super strong feelings on this, while it'd be helpful for some of my dream-scenarios in regards to scaling/resolutions/GUI/etc, it's still not a perfect use case, but I can definitely see folks getting use out of them, so I wanted to bring in some added context.