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.

Have you thought about looking into tilemaps and then just using objects only for interactive objects and ones that need precise collision? Such as involving layering moving if the player is behind or in front of an object.

You need to give public access if you want others to access your file from google drive

https://dl.dropboxusercontent.com/u/589 ... alker.capx

For the first one, are you using bounding boxes to cover collision detection? The issue there is that bounding boxes (or known as AABB) only covers detection on the frame of collision, and not a frame before or after, unlike raycasting.

You could utilize rough makeshift raycasting (set a line to the ball, and do collision based if the line is overlapping with other objects) which I have an example for you to figure out from. Raycasting has the advantage of being very precise (find the distance between an object and the edge of another) and thus say, know exactly how far the character is from the ground in pixels, such as when they fall or jump.

For two, try maybe?:

angle(Paddle.X, Paddle.Y, Ball.X, Ball.Y)

I'm guessing the ball isn't directly player controlled, so you may have to use "move at angle" instead with the same line I provided.

Not sure on three, I'll read over it again soon and try to think of something.

I know of a few examples you could look at, if you'd like.

One is general eight direction movement behavior (with proper animations) intended for topdown games like Zelda and another is probably what you're looking for, a capx I know of that mixes eight direction with platform behavior (some sort of generic superman, press a key to fly and descent)

Have you thought about using bullet behavior to cover the rising uppercut and diving kick moves? You can set the bullet speed to 0 and have it disabled by default and I might have a rough example (although for a similar concept, narrowly) for you to screw around with and engineer it to get working the way you need it.

Textspeed is a lot faster, it's just a gif framerate limit (the actual milliseconds between letters is 50)

Try this:

For a different thing but the logic should apply here.

Solved the combat issues just now!

Can we see a capx, please?

For the first, also try adding a "For Each" loop.