2 favourites

Working around a workaround



Get emailed when there are new posts!


  • 840 words
  • ~3-6 mins read time
  • Published
  • 1,440 visits
  • 6.2 visits per week
  • 1,919 page views


This blog post is licensed Creative Common Attribution Required v4.0.


Enjoy this blog? Share with your contacts!

Share now

This a follow up to my last blog post 'Creating layers out of laziness' https://www.construct.net/blogs/skymen-13/creating-layers-out-of-laziness-1027 so you might want to read that first.

A bit of context

And so, I decided to try and create the layers at runtime. While I managed to do it, it still came with a lot of problems, and maybe even more that hadn't seen yet. So I decided to discuss the possibilities of doing this on a forum topic where I tagged Ashley for additionnal info. After a while, this is what he said:

And after me saying "But if I somehow manage to manually trigger everything, will it work?"

After laughing pretty hard for a few minutes, I finally accepted that trying to break the engine was probably not gonna work in my favor in the long run. So I kept looking for a way to solve my issue


That way I wouldn't have to add the menu's layers on every layout, making sure I'm not gonna mess up by forgetting or misordering a layer somewhere in the project, and I could 100% be sure that the player code isn't still running in the background.

That would mean less night wasting bugs on the long run, tidier code, and better organisation overall. That would also mean less breaking the engine.

You're right. If most people usually don't do this, there is a reason. It's because it's annoying to pull off. I tried anyway.

As I said:

Now some of you may already have an idea of how this would be done.

Using C2's Save and Load system

You're just gonna revert back your changes.

That would work but that would be extremely inefficient.

Save Data

Change Data

Save Changes to Data

Load Data

Load Changes to Data

Change Data

Do you realise the amount of required steps in order to change something in the option menu? That's not a good idea

Using the persist behavior

Using the persist behavior is a terrible idea and here's why

  1. If you do that, then everything will persist even when you just change levels, and might break a lot of your systems.
  2. If you want to be able to differentiate switching level layouts and going to a menu and coming back, you'll need to reset every persist behavior each time you go to another level layout. Which might be an issue if you want to use persist for anything else.
  3. You'll need to add persist to every single object in every single layout, adding unnecessary behavior ticks and impacting performance.
  4. You're a human, you're gonna miss ONE object, and that ONE object is gonna give you nightmares when it's gonna cause the wildest bugs for no reason.

I hope I was clear enough. This is not a good idea.

So what?

Yes you can. Using the amazing world of 3rd party addons. Let me introduce you somone.


He was a really great member of the Construct community and created a LOT of addons. More than 220 of them. And every single one of them is free.

In those 220 plugins there are some that are so great that you might not even comprehend their use the first 20 times you see them. But when you finally do, you start to understand how powerful these plugins are.

One of these plugins is named Layout Freezer. You can take a look at this plugin here


And get its doc here


What this plugin allows you to do is save the state of a layout into a JSON string, and load it later. A simple exemple comes with the plugin to showcase its one action and one expression.

And just like that you can now save a layout and load it later.

No C2 Save and Load. No persist behavior.

And thanks to that I was able to get my menus to be on totally different layouts and seamlessly transition to them whenever I need to.

That's it

It's that simple. Use 3rd party stuff. Especially rex's plugins they're amazing.


  • Order by
Want to leave a comment? Login or Register an account!