I haven't actually checked the cap - not installed Construct on this new machine yet - but I can offer a few tips. It is best to try and start organizing your code as soon as possible, because it is only going to get much messier
What I generally do is create external event sheets for each feature - one for game menus, one for actor movement, one for AI, one for sound&music etc., you get the idea, just include them when needed.
Also, it is an idea to reuse an implementation as much as possible, make everything modular so that you can reuse them again. For example, instead of using different and complex sprites for actors, have a basic actor (sprite) that has all the basics, then base player and NPC on it. That way you have more control over them; moreover, you can hijack the control from player and manipulate the player character around, like in cutscenes! All you have to do is change a variable. You can even make enemies playable, too!
Don't be shy of event groups, either. When you have a feeling that the chunk of code you are making won't be used much, consider putting it into an event group. That way you can enable/disable it as needed, thus lowering the overhead (the runtime skips over disabled groups). Moreover, they make it easier to make sense out of the whole sheet! (Try saying that quickly. Heh.)
Use placeholders ('dolls') for everything until you have basic functionality, then polish it up! It's fine to keep things really simple at the start, first you want to make it actually work!
Split your project into different sub-projects - graphical interface, gameplay, story etc. and work on one at a time. Try not to mix them too much, or it will be difficult fixing a thing or couple.
Don't lose your sleep and time on the look and feel - placeholder graphics (programmer's art) are fine. Braid started that way, it looked butt ugly until its developer felt it was done and hired a pro artist. Look where Braid is at now! Basically, you want functionality first, art last! You can replace those colored boxes with state-of-the-art sprites later. Just remember any limitations (size, length of animations etc.).
Try to use finite state machine, too. Each object in the game should have a state, which says what the object is doing, like if "Player" is "Walking", "Walking and shooting" etc. - you can then have a separate event sheet pick those states up and play appropriate animations/sounds. Easier than throwing a bunch of events together and bloating the sheet up!
And, most importantly, don't give up. Even failures are good, because you always leave with experience! Your next project will be all the more smooth.