I have a story and something you should avoid.
When writing events in construct, you can refer to an object that has no instances. This is fine if you want to read some default instance variable or behavior value off it - such as max speed or gravity power. But what you can't do is change something that doesn't exist. For example:
On start of layout -> set playerObject physics stepping mode to framerate independent...
more events, more events, more events... blah blah blah...
Create playerObject at playerSpawnpoint.
The result of this is that you do not have framerate independent physics because you couldn't change the physics behavior from an object that doesn't exist. In a large project with thousands of events, errors such as these can be easy to create, nearly impossible to find and worse may remain hidden for weeks.
Don't spend hours of debug time trying to figure out why something doesn't work only to find a mistake like this. The worst part is construct is happy to go along with bad events like this... same thing for calling functions that don't exist. Its like if you told an employee to bring the client in the waiting room some coffee. The employee goes to the coffee room and finds no coffee. Instead of telling you, he just abandons all other subsequent instructions and asks for the next set of directives... Well, he thinks to himself, you are the boss and you must know there is no coffee. What a bizarre instruction. Oh well, best to carry on.