Three more test ideas:

What happens if you try making a whole bunch more event sheets that aren't included/attached to anything, and copying and pasting code from other event sheets into them?

What happens if you make a new layout, and add a whole bunch of new unique objects to it?

And what happens if you add lots more layouts?

I assume this is the iconoclasts that we're talking about (and therefore you can't post the .cap), and that game should definitely be possible with construct. More code elsewhere in the .cap really shouldn't affect other layouts than the ones the code is in.

About how many layouts, events, objects and event sheets does your .cap have?

Hmm... did you try after disabling/deleting the code, keeping the objects in the project, but not having any instances in the layout, then trying again after deleting the actual objects from the .cap? Those two should be about the same.

If there isn't anything there of note either, then my best guess would be to incrementally disable parts of the code to discover what's taking up the most cpu time and to try to find ways of optimizing it. It may be 10 fps here and there, but then if you make 10 optimizations that's 100 fps.

Do you have copies of the older versions where the frame rate was higher?

You might want to try some experiments. First, after making a backup, I would try first disabling, then deleting all code and see if it makes a difference on the frame rate if its been disabled or deleted. Then I would also try deleting everything from the .cap while incrementally checking the frame rate to try to find if there's anything in particular that deleting helps the frame rate a lot. Then when you finish deleting everything, compare it to the FPS of a fresh .cap.

If you can get the frame rate hit to be there even in a .cap with nothing else in it, maybe someone can help fix it if it's a bug in construct.

Welcome to scirra! Topic moved to help/support.

If you're starting out, yes, that's a good way to do it. Make sure to learn about event sheet includes!

When you get more advanced with the program, making an in-game level editor is another option.

Moved to the your creations section.

I also think you should leave the movement of the object to the person making the game.

That's been solved in C2. The only way around that problem in CC that I know of is to make your own level editor, which at least when I tried it making a basic one wasn't as hard as I thought it would be. I have been using construct a while, though.

Basically all you need to do is make some controls to create/place sprites and tiled backgrounds, then save the locations and properties of each to an array. Then when loading a level at runtime, load the array and create the parts of the level from it.

You can even build those controls into the game itself so you can edit levels while playing them!

This is where you discover the awesomeness of inheritance layers. From the wiki:

Every layer has a property titled 'Inheritance Layer'. Using this property, it is possible to display the content's of another layer - even from a different layouts! Just specify the (unique!) name of the layer you would like to 'inherit', and Construct will search for that layer in the entire application. This is very practical to make things like HUDs appear in multiple layouts without having to copy their containing objects.

Instead of having a comment action, I think comments should simply be able to be put anywhere - as events, conditions or actions. I also think it would be helpful to have 'post-it' comments for the layout editor as well.

C2 is.