Please ensure any content you care about is backed up before that date.
Feature requests are now handled on GitHub here: https://github.com/Scirra/Construct-feature-requests
Add a new UI Mode for Object Part of Hierarchies.
Add a dropdown choice on top of Hierchies properties for all Objects.
- Regular Hierarchy (Hierarchy as they work right now)
- UI Hierarchy (new Hierarchy positionning system thought for UI, featuring AutoLayouting-related properties for both Parent and Children)
If an Object part of a Hierarchy is set to "UI Hierarchy", the properties would be different from the existing "Regular Hierarchy".
UI Hierarchy Parameters :
Autolayouting Children (dropdown)
No/Horizontal/Vertical/Grid
This UI Hierarchy Properties should allow to auto-layout any "UI Hierarchy" Children based on several parameters.
The existing Hierarchy related ACE (Pick Parent/Pick Children) would work both for "Hierarchy Regular" and "UI Hierarchy" Instances.
However the existing "Add Child" should be renamed as "Add Child as Regular Hiearchy", and a new condition "Add Child as UI Hierarchy" with parameters corresponding to this new "UI Hierarchy" Mode.
This UI Hierarchy suggestion is WIP - I will complete it with more details later
EDIT : Everything below is the old suggestion "Hierarchy Anchors" I made earlier, while i still believe UI features should be implemented on top of Hierarchies in Construct (especially some kind of Horizontal/Vertical/Grid Autolayouting for children of a Hierarchy UI element) as explained above, I don't believe anymore Hierarchy Anchor is the right way to go to build a UI System. I let this old suggestion for record purpose only.
HIERARCHY ANCHORS (old suggestion)
Regarding the recent discussion about UI in C3, I think one thing to add, that would solve many many issues in a elegant and relatively easy way to implement for Scirra is :
1. A new "Anchored Position" dropdown list option for Hierarchy feature (set to "No" by default)
It's basically the anchor behavior but using a parent's bbox as reference instead of the viewport, and using the Hierarchy features (no need to add behaviors on anchored objects and all handy existing and upcoming Hierarchy features included)
(see gif example)
From this dropdown list, the user can choose between "No" and the 9 posible "Anchor_Positions" : "TopLeft","Top","TopRight","Right","BottomRight"," etc...
It would make disappear (or gray out) the X and Y boolean fields
It would add 2 or 3 variables fields depending on the chosen Anchor_Position (so except if "No" is chosen)
1 or 2 "Offset to [Border]" numbers fields corrresponding to the chosen Anchor_Position
Example : if the Anchor_Position is set to "Bottom Left" then there would be 2 number fields "Left Offset" and "Bottom Offset",
but if the Anchor_Position is set to "Top", then there would be only one field "Top Offset"
Those fields would allow to specify precisely where the child is relatively to the anchor so it won't be a pain to setup exactly at the right position in editor, and they can be set using expressions through the "add child event"
A boolean "Anchor offsets based on current position"
If False : the 1 or 2 Offset number(s) are specified by the user when creating the child relationship, exactly as explained above
If True : the 1 or 2 Offset number(s) field are grayed out. As soon as an Object is anchored to its new parent Object, the 1 or 2 relative position (offsets) corresponding to the chosen Anchor_Position would be automatically set accordingly to the relative position between Parent and Child at that specific frame
(QOL Idea : at Editor time, in Property view, the two Offset Hierarchy fields could be grayed out but the values could still be updated to show the current offset of the child that would be its offset at runtime)
With this feature alone making UI in construct would be really easy for most standard use case, especially in combination with existing Height/width/angle boolean for Hierarchy. It would make it easy to create complex auto-layouting and animated menu supporting all aspect ratio !
We could just create invisible parent objects and set their size through events to handle complex cases auto-layouting
For example, if we need a 3 column layout, it would be 3 "invisible panel parent" object which width would be 1/3 width of their own "invisible main panel parent" object
This feature would also lessen a lot the need of instanciating layers at runtime (even if this would still be amazing) because a popup window with nice sliding animation could just be a parent object with childs Anchored to it. And this pop up window would support all aspect ratio.
2. Enhancement to this idea : Adding Anchored Dimensions support for Hierarchies
(in addition to Anchored Position).
So it's also possible to set width/height of an child object based on the dimensions of its parents with specified border offset.
This additional feature would add a bit more complexity to the first idea so i detail it in its own part. This could be added later on top of the first idea but would covers every case needed
See the screenshot of Unity's RectTranfrom for a better visualisation of the following explanations (important)
Right now in Construct, the Hierarchy System works as the white square (Center + Middle)
The first paragraph of this suggestion (the Anchored Position dropdown list) would add the situations depected by the 8 red squares ("TopLeft","Right","BottomRight"etc...)
So to add Anchored Dimension support to this first idea of Anchored Positon, we would need to add basically 7 options, corresponding to the 7 squares with blue arrow on the unity screenshot ("Stretch horizontal top", "Stretch vertical middle", "Stretch both vertical and horizontal" and so on)
So the best would be to replace the dropdown list by a pop up window inspired by this "Anchor Presets" Window from Unity. (Don't reinvent the wheel). It's really more user friendly than a dropdown list covering the 16 possible situations. (it could work exactly the same as a dropdown list under the hood, just the UX to select the option would be different for better UX/Visualisation)
Depending on the "Anchor Preset" the C3 user would select on this pop up window, it would add corresponding offset number settings fields to the Hierarchie settings and make disappear the boolean settings that are not needed anymore
(as always, I mean settings in the Hierarchy Section of Properties view for Layout, or in the "Add Child" action settings for Eventsheet) :
For the Standart Preset ("Center + Middle"), which corresponds to how hierarchy works right now, the options for Hierarchy settings are the same as they are right now (X, Y, Width, Height, Angle... boolean)
For the 8 "Anchored_Position presets", as explained in first part of suggestion :
it would disable X and Y boolean Hierarchy settings
replace them by "OffsetBottom" and "OffsetLeft" number fields if the selected preset is "Anchored position BottomLeft" for example
For the 7 "Anchored_Stretch presets" :
it would disable X, Y, Width and Height boolean fields
replace them by the 2 to 4 required offset settings (for "Stretch horizontal top", we need OffsetTop, OffsetRight and OffsetLeft but no OffsetBottom)
(in fact those 4 OffsetSide number fields could appear as soon as the option selected is one of the 15 that isn't "Center Middle Anchor", but only the 1 to 4 Offset number would be editable/the other would be grayed out)
Remark : For the 7 "Achored stretch" options, it would require for Construct Engine to take the child origin point into account (behind the hood) to update its position and dimensions. So the Stretch features would work whatever is the child's origin point.
Only Anchored Position (first part) is already great for a lot of use case and Anchored Dimension can already be achieved by combining Anchored Position + events
3. [Optional Other Feature] Option to update all children's position/angle/width/height/Zelevation when the C3 user change the parent properties in Layout view, exactly as it works at runtime.
Even without Hierarchy Anchor, this feature would be an amazing addition to the existing Hierarchy System. Right now, in the Layout, we need to select all parents and children to move the whole hierarchy (which is already painful) but it's even worse if we want to change the Angle of the hierarchy. We need to first, change the angle of the parent, then for each children, we need to move them one by one on the right relative position to the parent (and change the angle accordingly)
For UI creation, and the potential new Hierarchy Anchor system, updating childs properties depending on parents at editor time would be a truely amazing workflow.
4. Small additional QOL ideas regarding Hierarchy Anchors
Adding Action[A]/Conditions[C]/Expressions[E] for this new feature
[E] ChildObject.BottomOffsetToParentAnchor (same with Top/Right/Bottom)
While in the facts those variables are matching the value of the "Anchor offsets" number fields detailed above, they would actually be 4 common variables (for all Plugins supporting hierarchies features) accessible no matter if the Object is currently a child of an other object (then, they would be equal to 0) or whatever the Anchor_Position is if the Object is, indeed, anchored to a Parent Object.
So if ChildObject is anchored "TopLeft" to ParentObject, then ChildObject.BottomOffsetToParentAnchor = 0 but ChildObject.TopOffsetToParentAnchor would be in fact matching the Offset number.
This allow to avoid unexpected issues
Alternative, might be even better : instead of "OffsetToParentAnchor", it could just be "OffsetToParent", then, even if offset sides aren't corresponding to the Anchor_Position, the value would be the distance between the X,Y of this object and the BBoxSides of its parents. So in my previous example above BottomOffsetToParent would not be equal to zero. This expression would be useful even if for regular (existing) uses of Hierarchies, that's why it's probably better.
[C] Is Anchored ?
[C] Is Anchored to [choose Angle_Direction] ?
Those Hierarchies enhancement would work great in combination with a new Hierarchy View to make the worklow of Hierarchy relationship creation more user-friendly in the Layout, on top of other benefits such as a nice place to select any Instances in the current Layout and order them in a convenient way. I detailed it in this seperated suggestion : https://construct3-21h2.ideas.aha.io/ideas/C321H2-I-311
Screenshot wasn't attached, trying again to add.
Ashley, while the behavior described above is a little overwrought and maybe too perscriptive in its implementation, this is an increasingly common method of building hierarchies of objects across a wide range of software, including that intended for, UI/UX, graphic design, etc. In fact, I think you would be hard-pressed to find any gamedev-specific software that doesn't include positioning of objects in relation to their parent object when arranged in a hierarchy.
As an example, here's (attached) how Figma handles it (and also how every other piece of UI/UX software handles it, in addition to every single one of C3's competitors):
Button_Text is an object
Button_Shape is an object
Button is a hierarchy of both Button_Text and Button_Shape, in a hierarchy, with both parented to a null/empty object, that includes their positioning within that object:
Regarding the complex logic behind how hierarchy works, couldn't it just work as you were thinking at first (creating a "NewPin" behavior) under the hood but the UX/visual part of how to set it up would be through a the hierarchy settings for the user (and that """behavior""" won't show up at all) ?
I mean something such as creating an invisible behavior (that won't show up as the regular behaviors) with the right settings automatically depending one what the user choose in the hierarchy settings (hacky way), or more probably, just disabling totally the usual logic behind hierarchies positionning for elements having a Anchored Position or Anchored Dimension to their parent, using a logic specific for those cases. (if "no Anchored Position/Dimension", then [usual hierarchy positionning logic] else if "Anchored Position/Dimension", then [the logic you were thinking to implement as a behavior at first])
Because even if it would be a behavior instead of a hierarchy new option, it would still need to be compatible with hierarchies right ? the object with NewPin Behavior could still be part of a hierarchies (which could create really undesired results for the user btw) or at least being pinned to a parent which would be part of a hierarchy itself.
(i don't know how construct is working of course so pardon me if that specific post is not relevant at all)
Hi, yes sorry, i understand this is more difficult that it seems, so it might involve a lot of work but it seems it would be far better than a new behavior, and much less work rather than implementing a lot of already-asked new features towards better UI in C3 + more elegant as it's build on top of existing systems.
Regarding a new behavior instead (let's call it NewPin), most of the benefits of this suggestion would be falling appart, especially regarding the fact they come from existing Hierarchies features. The workflow to create UI with autolayout, supporting all aspect ratio and eveything i described in the suggestion would be extremeley painful using the NewPin behavior :
First you will need to add the Pin behavior on each object that need to be "Anchored on a gameobject". (No need for behavior with hierarchy)
Then you couldn't do any of the setup in Editor Layout, while this is the worflow you want to have in a Game Engine. Like you would need to create all "anchored relationship" in the eventsheet (while Hierarchies can be done in Editor Layout). That would mean picking the right pinned object and picking the right object to pin the first one on to it. Which is awfully difficult if you imagine doing it in a game involving more than 3 to 4 tiny UI elements.
Hierarchy comes with a lot more feature than Pin. Such as spawn with Hierarchy that would allow to easily spawn a pop up menu when needed for exemple or even better any kind of UI that would require to be properly duplicated. And soon we might have Hierarchy support for Template which would make it even better.
Hierarchies allow for nice picking between child and parents that can be really really useful : for exemple, i could use the same Close buttons Sprite for all my pop-up Window. On clicked it would select the parent window to close it.
Above all, it's not elegant at all to have a mix of hierarchies and some NewPins, it would be hard to remember how everything is settup. We already have several things that are doing similar things such as Anchor, Pin and Hierarchies and most users on Discord never use Pin since Hierarchies are a thing. NewPin won't be used because of that
(If someday a Hierarchy View is added, then it would be a mess because NewPin relationship won't appear there while it feels like it should)
This suggestion of Hierarchies enhancement is also a good way to lessen the needs of other features that would be great to have to solve the UI problem (and great to have anyway), but that looks really difficult to implement in the Engine (Flexbox system directly in C3 with nice UX and so on....)
I edited and added a new part in the suggestion (second part) to also support Anchored Dimension, so the Child's Width and Height are updated to match parent's dimension, with specified offsets value. It would be more complex so could be added in a second time but would cover all use cases we can expect.
I do not think this is a simple or small feature at all. The hierarchy geometry code is already very complicated, and adding extra positioning logic like this in to it will make it even more complicated. Seemingly minor features are often much more complicated than they first appear. I think it would actually be much easier to implement if it was not part of the hierarchy system. How about if it was a behavior, like a mix of Anchor and Pin?