It's a little rude to just to entirely ignore suggestions given to you just because they're not the "exact perfect solution" that you're looking for. It's your project and all, yes, but please keep in mind that: people are taking time out of their day to attempt to help you.
People may not have "exact" solutions but there are, more than often, solutions you can easily tweak to get working as desired.
Also, your project is 1 GB in filesize. Let me be frank here: Your +30 layouts open is not efficient in terms of memory. Memory warnings from Construct 2 generally should not be ignored, so keep that in mind. The "Construct 2 has estimated that this project will take X gigabytes of memory" are actually the ones you should look out for, in terms of severity. "8.58993e+009 gigabytes" is pretty serious, as: "e" at the end of said number represents far more than an average 'large' number. That's 8796093022.208 MB. Yes. That translates to 9 Petabytes. That's not a good sign.
It's not just with designing the game in the editor and testing it as I'm going to explain below.
That much memory usage will severely limit the number of devices capable of running your game. If your intention is to eventually make your project commercial or even port it to mobile or certain platforms (online such as Kongregate or desktop with Steam), you need to get that in check. The specs of everyone's computers varies vastly, and a general rule of thumb is to make the assumption that more than half of your userbase will not have top of the line rigs. It's even more so for mobile, since while mobile is vastly growing, mobile's capabilities in terms of raw power still pales in comparison to even a three year old PC.
Also, the memory usage may have to do with the too many sprite objects, other than if you have a handful of objects (say, 15?) will many animations each, such as 20 differently named animations. It's just a hunch though, I might need this project at least somewhat optimized so it won't run so slowly.
If it's that large, people are going to be hesitant in downloading your capx and looking at your code. There's some unwritten etiquette in the "How do I" forum with sharing capxs. Don't give out us a capx over 10 MB in size and try not to give us a cluttered project with unrelated code, just a capx with the isolated problem nearly by itself and anything barebones enough at the core of your system to make things work.
One last thing.
I've been using Construct 2 for four years, so you need to learn how important effective debugging is. It's far better to split your event sheets into different components such as enemy AI, animations, interactive world objects, main core barebone events, etc, so that is far easier to debug what is causing a problem, since you can disable entire event sheets in one go if you keep nearly everything in groups. That's a major key about successfully debugging, pick apart and pull your own code and disable medium or small chunks of it one by one, so you can narrow down your problem and what exact condition block or event is causing it so you can disable/remove it accordingly or attempt to figure out a solution on your own, once you know what it is directly causing it.