[JAVA]Problem with game(simple block breaker game)

[Graimer]

Hey. I have a problem with my simple java game. It's a block breaking game and it's almost done. The last thing to do is make some of the detection methods perfect. The methods should detect if the ball hits one of the blocks in the air. My current code does it well if the ball hits one of the longer sides of the blocks(north and south), but if the ball hits the west or east side of the block, it starts bugging. The ball will move into the block, until one of the current if-tests detects it, and reacts by changing the y-axis direction. When it first reacts like this it may also bring some other blocks with it. This will all be fixed if I can get some rules/if-tests to detect when the ball hits the shorter sides of the block and then changes the x-axis direction. Could anyone help me, please? :)

The block to test is called b, and has the getX/Y/Width/Height methods to call. The ball has the ints ballX, ballY and ballSize. dy and dx are the directions the ball moves. So changing the direction on x-axis is of course dx = -dx;

Picture of the situations I need code to detect

Detection code

I really hope some of you guys could help me fix this. Been struggeling all day to get it right. The y-axis test might also need to be fixed for this to work, I actually don't know anymore :s Thanks

[Andre S. Veteran]

I always cringe at this sort of style:

boolean predicate() {
    if (condition) {
         return true;
    }
    else {
         return false;
    }
}

Could be written in one line and much more legibly:

boolean predicate() {
    return (condition);
}

Also your:

if(checkHitY(b)) {
    if(checkHitX(b)) {
        addToScore(b.getValue());
        model.hitBlock(i);
        dy = -dy;
        i = model.getSize() - 1;
    }
}

Could be rewritten, more logically, as

if(checkHitY(b) && checkHitX(b)) {
    addToScore(b.getValue());
    model.hitBlock(i);
    dy = -dy;
    i = model.getSize() - 1;
}

Stylistic issues aside, I see a dy = -dy, but not a dx = -dx in your code. No wonder then, that side collisions are not handled correctly. You need not only to determine if the ball hits, but whether it's a side (dx = -dx) or frontal (dy = -dy) collision, before applying the right velocity adjustement.

[Graimer]

Dr_Asik:

Stylistic issues aside, I see a dy = -dy, but not a dx = -dx in your code. No wonder then, that side collisions are not handled correctly. You need not only to determine if the ball hits, but whether it's a side (dx = -dx) or frontal (dy = -dy) collision, before applying the right velocity adjustement.

Thank you for your answer, thought it didn't help. I'm aware of the kinda messy if-test structure at the moment, but they won't be like that. I change specifically to this style to try out new methods of detection. Siince I might need a seperate checkHitXdx() method to detect the sides, I found it would be better to seperate the if-test for checkHitY() and checkHitX() while testing.

When it comes to the dx = -dx; it's not written there because that's what I need help with. I need help finding a similar method as checkHitX and checkHitY that detects the side, because I'm struggelin to make the formulas/if-tests myself. So there's not dx = -dx; at the moment, since hitting the sides is atm not beeing looked for by the methods. I've tried multiple methods to detect just the sides, but the game just got lots of bugs when trying them out. The ball would hit the corner of a block, and always change direction in x-axis, even though it hit on the left end of the south wall, which should make it just change the y-axis direction.

[Andre S. Veteran]

You could simply test for the ball being below or above a block. If yes, reflect on y, if no, reflect on x. This will break if the ball speed is too high, but that's a problem with all simplistic collision schemes. If you want perfect collision you need to take into account before and after points, trace a vector and find the intersections with the segments defining the blocks, so there's some linear algebra involved.

[Graimer]

  On 06/04/2011 at 18:46, Dr_Asik said:

You could simply test for the ball being below or above a block. If yes, reflect on y, if no, reflect on x. This will break if the ball speed is too high, but that's a problem with all simplistic collision schemes. If you want perfect collision you need to take into account before and after points, trace a vector and find the intersections with the segments defining the blocks, so there's some linear algebra involved.

Yeah, but then I'd be checking the y-axis for hit 5 times(the dy value) for each block on each frameupdate, which would be lots of work for this. I tried to fix this by adding a area it could hit on both sides. Checking if it hit on the border, or at least before (border +/- dy pixels). The problem with this is as since I'm not detecting the sides now, it may slide into the middle of a block, and both upper test(with +/-dy) and lower test would be true and the ball starts bouncing up and down inside :p

To check the movement pixel for pixel for each frameupdate, would you simply check every object dy times, with lastX + (dx/dy) and lastY + (dy/dy) to check for hit? Is that a better solution then the "overflow" tactic (or whatever you could call my current method), or would that be too heavy on resources, with lets say 5 tests just for the y-test, for 100blocks on every frameupdate ?

[Andre S. Veteran]

  On 06/04/2011 at 19:45, Graimer said:

Yeah, but then I'd be checking the y-axis for hit 5 times(the dy value) for each block on each frameupdate, which would be lots of work for this.

No, you start by detecting if there is a collision, and only if there is a collision you check on which side it is. So this usually adds 0 test per update, and at most 2 (when there is a collision). Unless you're running a 386 this should not present any performance problems.

[Graimer]

  On 06/04/2011 at 21:43, Dr_Asik said:

No, you start by detecting if there is a collision, and only if there is a collision you check on which side it is. So this usually adds 0 test per update, and at most 2 (when there is a collision). Unless you're running a 386 this should not present any performance problems.

Okey, I understand how you think. But would you mind actually making the tests for me, if it isn't too much to ask for? I've tried so many methods the last days I'm actually getting dizzy :p

I know it's asking a lot, but it seems like you got both the experience and a clear vision of how to solve this puzzle :)

[Andre S. Veteran]

I'm sorry but I don't have time for this atm.

[Graimer]

  On 06/04/2011 at 23:18, Dr_Asik said:

I'm sorry but I don't have time for this atm.

Well anyways, thank you very much =) Now I'll just need to get my sketchboard and start drawing/making test-conditions.

[Graimer]

  On 07/04/2011 at 21:02, Graimer said:

Well anyways, thank you very much =) Now I'll just need to get my sketchboard and start drawing/making test-conditions.

Last update: Made it work now. My tries with vectors(or one pixelmovement at a time) didn't work to well. But I found another solution and thought I'd share some hints of how I did it in case someone else is wondering about the same thing.

I found out that the Rectangle class had a bool intersect(rectangle r)-method and a rectangle intersection(rectangle r)-method. So I made a rectangle out of the block to check and one for the ball, checked it ball.intersect(block), if so , found the hitZone/intersected area with ball.intersection(block) and made tests on this very small rectangle to check if the ball hit on top, left, right or bottom side and the correct action for each side. Ex. if the ball hit the left side, the ball would now change to move to the left.