I made few edits to Zatykas approach, mainly I condensed all ball objects into single object which shrinks the whole event sheet down to 6 events. Heres the link:Catch-a-ball

Also removed the second bucket object and few other things I felt were not necessary :)

You still need to add the fix I posted in earlier post, add for each enemy before fire condition.

Add targetx and targety variables which you set at coin creation to point to desired target coordinate. Then each tick set position lerp(coin.x, coin.targetx, dt) . Same for y coordinate.

Look at manual entries for containers and pin behavior :)

vee41 I was thinking of using bullet behavior but it still needs to slow down.

Something like this?

Bouncy enemies example

EDIT: Took a second look at that game, you can probably remove the whole 'phase' thinking and just give them high acceleration.

EDIT2: EncryptedCow Redid it with custom movement, fits a lot better. Collision rebounds have to be done manually but that's quite simple. :)

What is the size of the sprites? Any effects? Behaviors, like physics maybe?

Here is an demo with that sort of thing:

Evil Sprites Demo

Check out the events at the start.

EDIT: Fixed

Do you mean that collisions should act 'real' as is case with default bullet collisions, or that ball should move in relation where it hits the pad, as in awesome balls (link in my signature)?

Option one doesn't really need anything done, option two (line from awesome balls):

<img src="https://dl.dropbox.com/u/19921470/awesomeballs_collisions.PNG" border="0" />

Add 180 to action where you set the ball direction on collision.

In the capx I was looking at it was done correctly:

<img src="https://dl.dropbox.com/u/19921470/firerate_fix.PNG" border="0" />

It works, because the just created enemy is picked and any actions done to enemy objects are thus only applied to that particular enemy.

vee, I should just hire you to be my personal Construct 2 teacher.

This still bugs me, because I really shouldn't have to change it to LayoutWidth. WindowWidth should be working, and I'm not sure why it's buggy.

Heh :)

This is my assumption, haven't seen any official on this: LayoutWidth is the width you define in the game, it does not change with scaling or other properties. WindowWidth on other hand can change depending on monitor, your layout is scaled to fit windowWidth. But layout with width of 1000 is still 1000 pixels wide, no matter what your indowWidth is.

Thanks for the quick comment. I'm assuming this is a yes. I just starting using Construct so I have not seen how to interface with it yet. As long as I can automatically generate a layer with the players, that will work.

You can communicate with external database via AJAX/PHP, check the AJAX manual entry for more detailed info on how to proceed :)