I wouldn't say easier, because you have extra objects to manage which causes more work when destroying etc.

Regardless for now I will give that a try, thanks. :)

I know it wouldn't be easy but there is great value in this for touch games.

When we put a collision box on a sprite, we typically make it as tight as possible so that when the sprite collides with other sprites it looks good (no massive gaps between the collided objects).

But with touch we want the opposite, we need exaggerated collision box to more easily pick up a touch otherwise the game isn't very playable.

So would it be possible to have more than one collision box?

Then instead of :

"on sprite touched/overlapped"

etc, we could check

"on sprite.collider("box1") overlapped"

"on sprite.collider("box2") touched"

And also

"on sprite touched/overlapped" would now mean any of the sprite's defined collision boxes.

I've used touch as an obvious reason why you'd want this but I imagine there could be many more. And lots of cool stuff to be gained from allowing it.

newgrounds.com audio section is good. Both for game loops and music. Usually you just contact the artist and ask permission then put them in credits or whatever.

Here are my tracks:

silkng.newgrounds.com/audio

I'm happy for them to be used, so long as you give me credit. :)

I had similar issue with touch affecting multiple objects.

Fixed it by:

On touch myObject

MyObject Pick top Instance

So I only touch one at a time.

Also you can probably get rid of the extra box - you could make a large sprite (e.g. 128x128), draw your ball in the middle, and make sure the collision bounds are set to the full sprite area.

Well guys, there's more than one way to skin a cat but a friendly tip: You shouldn't really ever use variables unless you have to.

I've already done it the same way I posted and works exactly as you'd expect (I'm making a gauntlet type game).

Holding fire spawns a bullet. If it hits an enemy or goes off screen the next bullet spawns. This of course means you get the "faster" fire rate the closer your target, and when it's right next to you, basically bullet spam.

silkc2 - Exactly right

However you could also:

Keyb key is down

(Sub) Cond: Bullet is NOT on screen: Spawn Bullet

That was first thing I tried, wouldn't work though (something to do with the event not firing if there are no instances of the sprite).

Cond: Bullet is on screen

ELSE

Keyb key is down: Spawn bullet

A very quick one - would it be possible allow us to set the back colour of our comment and "event group" boxes. I don't mean as an overall theme, rather per box.

Use "distance joints" to connect them. Also make sure they are set to disable collisions with one another.

Sorry for the late reply - yes, you can only access two different instances of the same sprite at the same time via families, i.e. paid c2.

The important thing to understand is a "game loop" - what happens & when per frame of the game running - usually broken down into "update" where you trap events such as key presses, and "draw" which is where you draw the next frame onto the screen with all your associated sprites.

Construct thankfully simplifies the concept for non-programmers, so in a nutshell you just have to know that the event sheet is looked at once per frame, events are read in order from top to bottom, and html5 games typically run at 40-60 frames per second.

If you want something to happen every frame, such as moving a sprite around, you'd use "every tick". If you only want something to run on a condition, then there's loads of different things you can do - me checking the sprite's frame is just one example of a condition.

Following the tutorial I linked should make you more than familiar with the above.

There isn't an opposing word for hard-coding, just know that it's frowned upon in the programming world.

In this case I could have hard-coded the number "2" on my max frame check, rather than "animationframecount-1". That would be typical hard-coding and would break if I added more frames to the animation.

As for what would happen if you try and set the animation to 3 and above.. try it yourself! Construct2 is a sandpit, grab your shovel. I suspect it would simply keep the previous/last known frame i.e. frame#2 as it doesn't understand the next instruction. In other programming languages which are more strict this would end up throwing an exception.

Alternatively have an invisible sprite "lead" as your projectile, attach the visible one to it via a physics joint, and set your angle to the invisible sprite.

Just a theory.