Skip to Main Content
Construct 3 suggestions 21H2 - ARCHIVED

This suggestions platform is now closed and will no longer be monitored.

Please refer to this forum post for details on the latest suggestion platform.

Status Shipped
Categories Runtime
Created by dop2000
Created on Apr 29, 2022

Hierarchy support for tilemaps

Tilemap is the only basic object type which doesn't support hierarchy.

I assume the reason why it was omitted was, that syncing properties like angle/width/height may not be possible for tilemaps. If this is the case, these checkboxes may be permanently deactivated in hierarchy settings for tilemaps.

Why we need it:

1. Multiple instances of tilemap are often used in random map generation. I'm currently working on a project where a dungeon is created from rooms (as in Binding of Issac) and not being able to add tilemaps into a hierarchy is a massive drawback. I ended up using GameObject addon from the ProUI collection which offers similar functionality as hierarchies, although there is a big risk that it may stop working with any new Construct update.

Template feature is not a valid substitute for hierarchy here. It will take a lot of effort to configure template names on tilemaps and parent room sprites. And templates can only be used for creation, picking and pinning tilemaps will still need to be done by other means, different from other objects in room hierarchy.

2. I'm often using hierarchies not just to sync physical properties like size or position, but to logically connect objects. It's a powerful feature allowing to create complex tree structures of instances and pick them in event sheets. Sometimes I need to include tilemaps into these structures, which is not possible.

More discussion on why we need hierarchy support for tilemaps in these posts:

  • Attach files
  • dop2000
    Dec 5, 2022

    @Ashley, Could you tell us if this will ever be implemented? I'm so tired of inventing complex and ineffective workarounds for this issue. I really don't understand why Tilemap is not supported.

  • Scoremonger
    Sep 30, 2022

    Fwiw, random map generation is why I cast my vote here too.

  • Matt Gruber
    Jul 23, 2022

    Agreed. Most object types, including data, should be compatible with the hierarchy system. Just deactivate the incompatible parameters. I've got plenty of cases where linking tilemaps to other objects would save me a lot of trouble of UID/variable picking & comparisons.

  • tarek2
    Jul 10, 2022

    Sorry by 100+ I mean that all plugins should be compatible with the Hierarchy feature not just the TileMap

  • tarek2
    Jul 10, 2022

    +100 for me even I don't have any more votes to vote for this indeed one of most needed

    Right now we have to mix up things (Containers, Pins, etc...) as

    Overboy mentioned just to (Pin & Link) objects which becomes quite messy.

    For example:

    Just recently I was working on an editor that you can (Show & Hide) Panels and on this panels has to have some objects pinned like (TxtBoxes, Buttons, List, CheckBoxes, etc...) and because the Hierarchy does not support the form objects I had to mix (Containers + Pins) etc... When you could just including them in the Hierarchy and Grey out the settings that are not supported as Doop & Oberboy explained, this will make so much easier to work on UI or Games as I needed this in almost every project I worked.

    Also, you will fix another annoying problem when you pin by Pin behaviour they follow the panel one tick behind which makes it look like the pinned objects stuttering so by adding to the hierarchy they will mow smoothly as the other objects. Plus the easy Picking.

    And as Doop explains "Template feature is not a valid substitute" as this is a complex editor in which the Panels have to be created at Run Time as there are so many form buttons, Padding, etc.... that it makes it impossible to do it in the editor using Temples.

    Also if you fix that then you could use the same system of greying out the settings that are incompatible and do the same with the Families so we can add any type of object in one single Family so we can use one family for basic settings as (X, Y, Opacity, Width, Height) and any other settings that they all can share so we can have one universal object for basic things as this has been a huge problem for me since I started to Construct as if you need to check basic things and you have many different objects you have to create one family for each object unnecessary and many events for a simple task.

    So you could fix 3 Huge Problems at once ))

  • Overboy
    May 3, 2022

    +1 regarding the 2nd reason of why we need this, I always felt almost all plugins should be compatible with the Hierarchy feature, because of this amazing way to pick instances in Event Sheet. Even Plugins that aren't World Objects need it.

    For example it is very common that we need an Array or a Dictionary as an Object's properties.
    So far the 2 only way to do it is :
    - either use the container trick to link it to an object (but it doesn't work with Families so in most of use cases it can't be used)
    - either add a variable number to the Object with a Array_UID variable to pick the correct Array : the big issue with this is that we need to add a new variable for each data object we want to link to it, we can't pick several instance of Data Objects this way and so on (on top of the tedious worflow)

    If we add a Data Object as parent/child to an Object, all the optional boolean of the corresponding Action Event (Z Elevation, X, Y) could be grayed out except the "Destroy with Parent" (or instead of graying out them, the unwanted boolean just disappear)

    TLDR : Hierarchies should be compatible with all Plugins : even Data Objects such as Array and Dictionaries (except single Global such as Mouse/Keyboard)

    no matter if C3 handles it differently behind the hood for those objects, it would be a pleasant workflow for the C3 user and an amazing unified system that work with all plugins

    Bonus : If someday a hierarchy view is added, Data Plugins could be there as World Object to easily create hierarchies relationship by drag and dropping them/ or to easily select instances of thoses Objects even if they aren't in the Layout view

  • +17