If got an Entity Component System based game-project (like classic zelda).

  • The Player as well as Enemys are Entities with sprite- and tranform-components.
  • The Weapons are also Entities with sprite- and tranform-components.
  • The player and the Enemies can pickup weapons.
  • Weapons got an ParentComponent so they will be rendered realtive to the Carrier-Entity.
  • There is a script/system for that.
  • No everytime an player/enemy walks upwards, the weapon must rendered BEHIND/under the carrier for the illution, that the player walks to the top of the screen.
  • I will do this by switching the Z-Index of the transform-component of the carrier with the one of the weapon.
  • Unfortunately, the rendering system is a Sorted-Iterating-System which holds a sorted list of all entities with Sprite-Components so everytime Im changing the Z-Index of an Entity, I have to force the re-sortening of the list.
  • This works but sorting an entire list in java almost every gamellop-update sounds very bad.

Is this really a good idea or should I try something else? BTW: In practice, Im using libGdx with Ashley as the ECS.

  • 1
    \$\begingroup\$ What about having 2 render systems, one which cares about the DrawOnTop component and another one which will render the non matching entities. Adding or removing this component will just unregister the entity from the system list and vice versa. \$\endgroup\$ Commented Jul 12, 2017 at 22:56
  • 1
    \$\begingroup\$ You're implying that sorting might cause issues, does it? If you dont want to sort every update then only sort when it should ( when the weapon received a new z value ). cpu's can easily sort thousands of objects. \$\endgroup\$
    – Sidar
    Commented Jul 13, 2017 at 0:50

1 Answer 1


I'm going to agree with @Sidar in the comments- this probably isn't an issue, and I don't see a better implementation given the libraries you're using.

If you look at the Ashley/libGDX implementation, the SortedIteratingSystem ultimately uses TimSort each time you resort it. While TimSort has a big-O of O(n log n), when working on a nearly-sorted array it typically does even better than that.

The only other way to handle this would be to create your own equivalent to SpriteBatch that allows you to pass an actual z coordinate when you render the plane your sprite is painted on. If you want to stay true to the spirit of ECS systems, you should keep your current system, and then if you find that this z-index sorting causes a noticeable issue in your game, create a separate replacement system with your custom spritebatch.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .