Sorting layers

[pkulev]

Idea

Good combines with implementing some sort of projects.

• Project is configuration file that contains user overrides for engine settings.
• This file can be further created with an editor.
• Example is sorting layers:

Settings.project.sorting_layers = [
    "GUI",
    "Player",
    "Enemies",
    "Pick-ups",
    "Background"
]

# Somewhere in game classes
class Background(Renderable):
    sorting_layer = "Background"
    ...

"default" is initial value for every untagged object.

This is unity-like alternative to Renderable.render_priority with meaningfulness instead of strange integers.

Implementation

• add initial project config file with declarations for game and applying mechanism for it
• Use sorting layers instead of render_priority
• Implement sorting by defined priorities

Maybe a little difficult to implement sorting, need some kind of prototyping.

@taptap, let's discuss it.

[alex-eg]

I like the idea of project, but prefer to think about it as config overlay or override.

The idea of sorting layers are basically Z-level aka render order, or priority, but with meaningful names. It's ok, but integers are better suited for this task:

• one look at render priority and you can roughly estimate the position. With 0 being GUI and 1000 backgruond, you will understand that 10 is probably overlay message, 200 is explosion effect and 900 -- some bg animation. With a large number of different layers this could be hard.
• when you want to change priority, you just change the number in single place. No need to go to setting list and rearrange it, moving lines around.

Though names are good. I think we might try to consider it despite above points, but certainly {name : z-level} dictionary would do much better than just a list.

[pkulev]

{name : z-level} dictionary - maybe it would be difficult to sort. In list we know order, here we need to do something. Ok, need to check sortings in console.
For what we need so many layers?
Player and enemies have one layer because they are collidable and not intended to overlap each other for instance. Background animation I suppose is changing background state, in background object it belongs.

Will return to this after prototyping?

[alex-eg]

maybe it would be difficult to sort

Why? Just sort by value, and that's it.

For what we need so many layers?

Now we indeed don't need so many. Maybe it's a good idea after all.

Player and enemies have one layer because they are collidable

I don't think so. Colliding must not rely on rendering order. Rendering is for rendering.

Background animation I suppose is changing background state, in background object it belongs.

Imagine tunnels or hollow mountain passage, or hanging cliffs at sides of the main path. It still obeys background rules (scrolling), but must be rendered on top of crafts.

Will return to this after prototyping?

Yep, I think this might be the best way.