search

4ian / GDevelop

🎮 Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone.
https://gdevelop.io
Other
10.85k stars 852 forks source link

Give priority of selection to instances that are behind others #3680

Open AlexandreSi opened 2 years ago

AlexandreSi commented 2 years ago

Description

To echo https://forum.gdevelop.io/t/improve-usability-of-the-scene-editor/21515, first bullet point.

Example use-case: In some projects, we can have big objects in the foreground to give depth to a scene. They can completely cover part of the scene editor and make us unable to select instances that are hidden behind.

image

Here the wasp cannot be selected. There are workarounds for this particular example, but I think it can be inconvenient in lots of use cases

Solution suggested

By default, make it so that the instances that are completely hidden behind a bigger one, are the ones that can be selected.

It can be done by default, or this way of working could be enabled when a particular key is pressed (but I don't know which one, I think they are all taken: Alt, Ctrl, etc.).

⚠️ It should not be costly on a performance point of view, we don't want to slow very user's interface

Alternatives considered

I have not found alternatives. I checked on Figma: they don't have such a feature.

Work done so far

This issue is highly related to Pixi and they don't propose such a feature as a simple parameter.

Our Pixi renderer (defined here https://github.com/4ian/GDevelop/blob/916938b4a8df88a060da95019b4921d615f15205/newIDE/app/src/InstancesEditor/index.js#L131) creates an InteractionManager that itself uses a TreeSearch to know on which object (Sprite, Text, etc.) apply events (onPointerOver, onPointerUp, etc.).

As this search is applied on every frame, it should be very fast (efficient tree search).

To work on this issue, I would recommend:

D8H commented 2 years ago

Can this issue be solved by users with the layer management?

PascalLadalle commented 2 years ago

Before, we would simply lock the foreground object, but the new lock behavior (that nobody asked for 😛) changed that.

AlexandreSi commented 2 years ago

Can this issue be solved by users with the layer management?

  • Add foreground instances to a layer (it will also be useful for parallax)
  • Hide the layer
  • Edit the instances behind it

Well, in this case that uses parallax, it's feasible, with the inconvenient that you have to make the layer visible before previewing the game each time. But I don't think it's a good thing to tell users that they have to manage layers so that they can easily select hidden instances.

Before, we would simply lock the foreground object, but the new lock behavior (that nobody asked for 😛) changed that.

I didn't know it worked like that. Do you know when this new lock behavior was introduced? Or maybe the PR that introduced it?

Anyway, locking instances or managing layers feels like a hack for me, it should be made easy to select hidden instances by design.

PascalLadalle commented 2 years ago

The new lock was introduced in 5.0.122, it seems.

I don't think hiding the layer is a great workaround, but usually, large objects like that are locked anyway, so I didn't consider it much of a problem.

Not sure how to easily allow selection of hidden instances from a UX point of view... Detect multiple instances under the cursor and display a small hover button to cycle through the instances?

I think part of the issue is that the scene editor view is cluttered with big panels, so the Instances list is not easy to reach/use (which caused the change in the lock behavior too, because that's how we were supposed to select the locked instances).

D8H commented 2 years ago

Can this issue be solved by users with the layer management?

  • Add foreground instances to a layer (it will also be useful for parallax)
  • Hide the layer
  • Edit the instances behind it

Well, in this case that uses parallax, it's feasible, with the inconvenient that you have to make the layer visible before previewing the game each time. But I don't think it's a good thing to tell users that they have to manage layers so that they can easily select hidden instances.

Selecting something that doesn't appear on screen seems counterintuitive to me.

AlexandreSi commented 2 years ago

Selecting something that doesn't appear on screen seems counterintuitive to me.

  • What can users do with the selection?

Once it's selected, you can move it easily or right click on it.

  • How can they know they selected the right instance?

The border box should be enough to understand you selected something behind, with smaller dimensions. It could be ambiguous for hidden instances that are almost the same dimensions as the instance hiding them.

  • How can they move it to the right place if they don't see it?

In the case of the wasp above, when hovering the wasp, pixi detects that the cursor is above both trunk and wasp. A logic can see if the wasp is completely hidden behind trunk, if true, it would display:

image

In this case, it seems obvious, but for instances that you actually cannot see (not transparent), the bounding box could be a different color maybe?

AlexandreSi commented 2 years ago

Before, we would simply lock the foreground object, but the new lock behavior (that nobody asked for 😛) changed that.

It seems to have been changed in #3286 following discussion in #785. It sure has the side effect you mention.

Silver-Streak commented 2 years ago

This conversation seems to have veered slightly from Alexandre's original question, so I do want to reiterate: Regardless of the feasibility of locking (which could maybe help for large objects, but only if behaviors change), or the feasibility of layers (which isn't a realistic choice for games that need the objects on the same layer), there is still very much a need for a "select lower/higher" option in the scene editor.

I also think @AlexandreSi is correct in that all normal toggle keys are taken. But what about a not-normally taken key, like Tilde? (~) Alternatively, a key combination? (ctrl+shift+click to select beneath).

D8H commented 2 years ago

I wonder if it could break some other cases. For instance, what if there is a grid of small sprites in the background and the users want to move a big platform on the foreground. Will they have to find its exact center to move it? It might feel like a bug where the current behavior only feels suboptimal. But, using a key like you suggested should solve this issue.

PascalLadalle commented 2 years ago

I also think @AlexandreSi is correct in that all normal toggle keys are taken. But what about a not-normally taken key, like Tilde? (~) Alternatively, a key combination? (ctrl+shift+click to select beneath).

I think keyboard shortcuts should remain shortcuts and not be mandatory. I don't think I know any of the GDevelop-specific shortcuts. Also, IIRC, we want to enable, now or in the future, users with a tablet to use GDevelop, which would contraindicate this solution, I guess.

Anyway, to me, this is a non-issue due to the Instances tab, so I'll stop here. :)

AlexandreSi commented 2 years ago

Indeed, there could be such cases:

In this case, it would be not possible to select it directly on the scene, but with the instances tab.

But I would prefer to go to the instances tab to select a unique shown instance rather than multiple hidden instances.

Maybe I'm too zealous with this request. Let's wait and see if users vote for this feature.

AlexandreSi commented 2 years ago

Just adding the link to a related discussion about this: https://github.com/4ian/GDevelop/discussions/3334

Oxey405 commented 2 years ago

Can this issue be solved by users with the layer management? @D8H I had the same problem described in this issue and I use layers as a way to solve it but maybe a way to selected based upon the side of the sprite could be a better approach. BTW @AlexandreSi , I think that the sprite of the "Tronc" should be thinner. It can be cropped...