I want to create a simple BreakOut game, so I made a bat, some bricks and a ball. I made the bat and bricks solid, and set the behavior for the ball to 'Ball'. I want a brick to disappear when the ball hits it, but when I set up the event 'On collision between Ball and Brick -> Destroy Brick', it doesn't work properly. The chance a brick disappears is 1/10th or something, seems quite random. When I choose another action, like making the bat disappear, it also doesn't always happen, so the problem seems to be the condition.
So, what did I do wrong, and how to fix it? Thanks!
Have you tried changing the condition to "if Ball is overlapping brick" ?
Develop games in your browser. Powerful, performant & highly capable.
If the bricks and bat are set to Solid, then the ball won't be able to overlap them. They're solid, so it can't move into the same space as them to cause an overlap. That's just how the Ball behavior works... it's doing it's own collision routines before your events run.
"On collision" sounds like it should work, logically speaking, but actually a collision is basically the same as "Is overlapping + Trigger once." (Though I seem to recall something a while back about some behavior or another having a fix for that so "On collision" worked... I thought it was Ball, maybe it was something else)
You might want to check out Midnight's Busta Ball example on the wiki to see how he did it. I haven't looked at the .cap myself.
http://apps.sourceforge.net/mediawiki/c ... =Tutorials
It would simplify the situation, if at least the default behaviors would "toggle" a collision if one were to happen in the processing of the behavior's movement. Wasn't that kind of system added in the physics behavior?
Yes, I did try Midnight's game, but in his version, the ball doesn't bounce back when it hits a brick. "if Ball is overlapping" only works when I don't set the brick to solid, and the ball doesn't bounce back then.
The changelog for 0.97.4 says it should work: "- [FIX] Ball movement: registers 'On collision' when bouncing off solids", but it doesn't. So it's a bug?
Fred, you can chect this my old example:
You could also check out Deadeye's Platform School tutorials and see how he uses the offset command. I think it first appears in part 4 when he's dealing with the slopes.
So, I can't use the Ball behavior and destroy the brick on collision, but I have to set the ball manually to bounce off the paddle and the bricks? For me, it's not that much a problem, but I wanted to use this example to show my teacher we should use Construct instead of Game Maker 7, and he used the BreakOut game example in Game Maker, so wanted to do it in Construct. Too bad I can't do it in a logical manner, but have to resort to detour. Or is me it just me making a thinking error?
Like Stainsor said, you could use the "Is Overlapping at Offset" condition and set the Y offset there to -1. That would allow you to keep the ball movement.
But I agree, I think that all behaviors should register when there's a collision.
You could also give the ball an invisible hitbox that's slightly bigger than the ball itself. You'd have to set the position of the hitbox to the position of the ball in an always event. But then you could trigger on collisions between the hitbox and bricks. (Basically this would be like using a detector.) Maybe that's less of a detour or maybe it's more.
There are problems with both offset and invisible detectors in this case... using offset would require several conditions to check all sides of the ball, which means extra code.
And using an offset in that manner, as well as using a detector sprite, would mean that the detection area could overlap more than one brick at once, thus destroying two bricks with one hit, which would look strange.
I agree that each movement-type behavior that interacts with solids should have some sort of collision condition built into it that you could use instead of the regular "On collision" condition. Either that, or be able to utilize the regular "On collision" somehow.
I think you can destroy two bricks at once in the real breakout. Of course you have to hit right between them. So anyway I guess I'm saying I would go with a detector that extends on or two pixels beyond the ball in all directions.
Good point about the offset ... I guess I didn't really think that one through enough.