How do I, if there is a way to, keep my layers' settings consistent thru layouts?

Post reply
Not favoritedFavorited Favorited 0 favourites
From the Asset Store
Massive Tilemap Z-Indexing
$19.90 USD
Create large maps with dynamic depth and precise sprite layering control in top-down games.
marcelokohl's avatar
marcelokohl

  • So I'm making a game where each layout is a different level. Obviously, as the game logic is the same for any level and so is the artstyle, all levels have the exact same layer structure. But then, whenever I want to change anything about these layers or add a new one, I have to do that to all my level layouts, which are ever increasing in number.

    It goes without saying that this is very error prone. Is there a way to have something kind of like in between regular layers and global layers where settings, effects and whatnot are the same but objects aren't, or really anything else that would fulfill that need of mine?

    Thanks.

    Tagged:

  • Yeah this is one of those grand architectural quandaries when it comes to Construct. Either you put up with it, jump through lots of hoops to use an external editor (thereby radically changing your entire workflow in Construct) or find a different game engine.

    I've been requesting some solution to this for years and have been met with little more than "Eh, that sounds like a lot of work." without even exploring solutions or acknowledging the critical need for such a thing.

    You can maybe tell I'm a little bitter over it by now.

  • Pretty frustrating, but if I had to tackle it I would probably do some combination of organizing layers functionally to those that will be the same on all layouts and those that will not, to take advantage of global layers. Then I'd aim to set as much of the variable layer properties and do as much of the object arrangement and placement by events to use an event sheet include, which can be edited once project wide, and also overridden by local events when necessary.

  • Global layers are intended to solve this problem. Using a global layer covers all content and properties of a layer and allows propagating those changes to other layouts automatically.

    Global layers do not themselves cover adding and removing layers, as if you add a new global layer, you need to go and add new override layers in all the layouts that use it. But there is another approach using sub-layers: if you have something like a set of global UI layers, you can make one global UI layer and add all your other UI layers as sub-layers of that. Then if you make any change to the sub-layers, such as adding a new layer, those changes are automatically propagated to all other layouts.

    Here's a project demonstrating that approach: global-layers.c3p

    If on SourceLayout you add a new sub-layer UISub3 and place a Text object on to it, then switch to InheritingLayout, it has automatically updated with the new layer and content. So perhaps that's a decent workaround.

    FWIW, the design of global layers looks straightforward and seems obvious, but in the end it wasn't actually a great design. It has ended up extremely complicated internally and is an endless source of difficult bugs. Touching that code in any way is very difficult and feels dangerous, which makes us wary of further modifications. Then any further requests to change it have to be balanced with the constant 5+ years of work of other suggestions. So if you can get by using sub-layers of a global layer, that would be the best approach for now.

  • The problem is that the layers content needs to be different, it cannot be shared:

    i.e. on level 1 there are mountains on the background layer and on level 2 there are clouds.

    But you still want a shared layer setup that is consisten across levels, like [postProcessing, foreground1, foreground 2, world, player, enemies, background1, background 2]. Now after creating 100 levels and noticing you need to make some change to that layer set-up you need to repeat it 100 times.

  • Right, we're not talking about shared layer contents like for UI which is what the current global layer system solves.

    Ashley Please refer to my thread The Case For a Proper Layer Template System where I elaborate on this and provide real world examples.

  • The problem is that the layers content needs to be different, it cannot be shared:

    i.e. on level 1 there are mountains on the background layer and on level 2 there are clouds.

    But you still want a shared layer setup that is consisten across levels, like [postProcessing, foreground1, foreground 2, world, player, enemies, background1, background 2]. Now after creating 100 levels and noticing you need to make some change to that layer set-up you need to repeat it 100 times.

    Exactly. That is what I meant, Ashley. Global layers are great but what we want here is global layer structure and settings, not global layers.

    Edit: Another way to say it is: We want global layers but that don't share object instances. Can you "just" make it an option to have global layers do exactly all they already do but share objects?

  • Another way to say it is: We want global layers but that don't share object instances. Can you "just" make it an option to have global layers do exactly all they already do but share objects?

    I'm afraid as I said the existing global layers system is extremely complicated and very difficult to change, and as the design proved highly problematic, I would not want to add a second separate system that uses the same design. So anything along the lines of global layers would be a major project with many difficult complications and a high chance of accidentally breaking other things.

    I think the easiest way to solve this problem might be some way to make batch changes across layouts - for example if you add a layer "Background2" above "Background1", have the option to repeat that change for every layout in the project that has a layer named "Background1". There would need to be something similar for renaming, moving, and deleting layers, and perhaps also an option to copy a layer's properties over all the other ones in the project with the same name. However it would be a tiny fraction of the work and complexity of anything involving global or "template" layers. Would that do?

  • In general, yes. But can we, instead of going only by names, have an option to select to which layouts we want that to apply? Cause like, we may want to change the "Background" layer of all game level layouts but not of a menu layout that may also have a layer named the same.

    Also, please note that a very important part of this is that we want them to share properties (inspector properties and effects), so please do include that.

    And please, with all due respect, and I do respect you a lot, try acknowledging that this is very very very needed and not just some niche thing we are requesting.

    Thanks as always Ashley.

    Edit: just realized there is no good way to figure out where a new layer should go in the layer order of all layouts it was also created in, as they may even have a different number of layers. Can we maybe just make a family or something of layouts and we get all the layer structure and settings to sync from a template layout to all replicas?

  • It would be great to copy and paste an entire layer from one layout to another. Or when copying a bunch of sprites on one layout, being able to paste them on another layout and have them keep the same layer.

  • It would be great to copy and paste an entire layer from one layout to another. Or when copying a bunch of sprites on one layout, being able to paste them on another layout and have them keep the same layer.

    I assume you mean copying a layer without its object instances?

    Yes to both, which also reminds me about the issue where creating objects with a hierarchy from templates does not create all children in the correct layers, which was said not to have been solved before because there was no guarantee two layouts would have the same layer structure. So maybe if Ashley actually adds what we are talking about here and depending on how he does so, we could also have that.

    But also, you and I are now a bit off topic and this should probably be a different discussion.

  • Can we get an update on this? Is this feature coming or not? I know it may take a while but I'd just like to know if it is at all coming. Thanks.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I'd love to do every single feature request that is asked of us, but we have to deal with the real-world constraints of available time and resources. I also prefer not to make specific promises about features and schedules - there is just too much uncertainty, and I prefer not to promise things we may not deliver on (under-promising and over-delivering is better than over-promising and under-delivering). Having said that, I do appreciate the need for this and I'd like to see if something can be prototyped soon.

    If project-wide changes based solely on the layer name with no ability to select specific layouts was acceptable, that would be a quicker and easier update and therefore more likely and possible to come sooner. If you don't think it would be useful unless there was some UI to choose which layouts to update, then as anything involving UI - even a small amount of UI - is a great deal of work, that would make it a bigger update and less likely to come sooner. Uncertainty about which we really need also makes it harder to justify scheduling sooner rather than later, as it is a real pain if we think we can do a small simple thing, but then after it comes out, everyone decides it's not actually sufficient and we have to do the bigger thing.

    This is a small window in to the decision making for every feature request. The art of the realistic feature request is to work out the bare minimum you can live with, ask for that, and then once that is implemented, move on to your next bare minimum improvement, and so on. That also mitigates the risk that we end up doing a great deal of work that turns out to have been the wrong approach once it makes a beta release.

  • Well, first of, thank you once again.

    Second of, the version without the specific UI is already much better than what we have. If you think it would come much sooner, I'd rather have that and work around the limitations myself by renaming layers.

    If that is the case, just please do consider adding the ability to select layouts later on.

  • Imo the most robust and flexible way would be fairly similar to how objectType templates work: you can set something as a template layer and you can set another layer as a replica of it (could just be that any aditional layer with the same name is a replica), then on that replica you can disable copying of specific properties, effects and for a more completete case we could even choose if sub-layers and content should be copied (in that case it could supersede global layers).

    The initial implementation could forgo that disabling of replication functionallity, so the replica layer would basically behave like a global layers without copying what's on the layer itself.

Post reply
Index icon Return to board index
Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)