bevyengine / bevyengine/bevy

Ergonomic z-order layers for 2D graphics (and UI?)

Open
#1,275 36 comments 34 reactions 0 assignees View on GitHub
A-Rendering C-Feature S-Needs-Design-Doc
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 22h
Merged PRs (30d)
161

Description

**What problem does this solve or what need does it fill?**

Currently, we can control the relative position of 2D sprites by manually setting their z-value. This technically works, but requires setting and updating magic numbers scattered throughout the codebase.

When creating a game, you'll often want to specify things like "all in-game UI elements occur on top" or "units are drawn above terrain". Layers provide a sensible, comprehensible way to think about this in a single place.

**What solution would you like?**

To me, a good solution to this has the following properties:
1. A single, central source of truth which controls the relative positions of different varieties of sprites.
2. Easy initialization of freshly created sprites on a specific layer.
3. Ability to move sprites between layers. You should be able to move sprites to a specific layer, up / down one layer, and to the top or bottom-most layer.
4. Support for nested sublayers.
5. Changing the position of one layer doesn't require changes to any other layer.
6. Layer names must be unique.

I'm not exactly sure what such a solution would look like in practice; I plan to explore it in the comments below. Others are very welcome to comment with proposed solutions as well.

In addition, we need explicit, well-documented rules for what happens to sibling sprites that overlap and share a z-value.

**What alternative(s) have you considered?**

If a good-enough solution can be created without touching engine code, adding an example to the examples folder would likely be entirely sufficient to resolve this issue.

**Additional context**

This could be useful for customizing the ordering of various UI elements as well (see #254), depending on the exact pattern we use for constructing it. A builder pattern can obviate the need for this (especially if we have a single rooted tree), but 2D graphics can be used to create sprites in much more diverse fashions.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.