I am making a breakout game for a school project. The only problem I am running into is the Ball Bouncing when the Ball and Bricks collide. I used ball1.getEllipse().intersects(b.getRectangle()) allowing me to figure out when it is colliding and delete the brick. The bouncing chances depending on the side it collided with. This is the main problem. The .intersect piece does not show me which side the brick gets hit by. I need this to know whether to change the x or y speed. If anyone has any idea on how to figure this out, please leave your input (I have been trying to think of a solution for 5 hours, I gave up)
public void collision(int i) {
for (Block b : blocks) {
if (ball1.getEllipse().intersects(b.getRectangle())) {
if (!b.isDestroyed()) {
b.destroy();
blockCount-=1;
ball1.brickBounce();`public void collision(int i) {
From what I understand from your question, you want to know which side of the rectangle the ball is hitting. A simple way of doing this would be to take the position of the ball and the position of the rectangle and compare the two. If the ball's x position is less than the rectangles x position - half its width(to get the x position of the bound), then the ball hit on the left side. You can then do the opposite for the right side. Checking if it hit on top or bottom is similar just with the y positions and the rectangle's height. Do note that I'm assuming the x and y position of each shape is the center, if not only minor adjustments should have to be made to get the same result as if it were the center.
Related
I'm working on a brick breaker game in JavaFX (FXGL). The collision detecting is working like this:
Bricks and players have a x, y position in the game world (placed in LEFT, TOP).
When a collision is detected (this is done by the engine) I use the x, y position to detect where the ball is colliding with the brick to calculate the next direction. The ball direction is created by a velocity vector with (x, y) speed. The collisionLogicSecurityPadding is a small padding which is added since the collision is only detected inside the box. (It's not possible to get the ball and brick exactly at the same x, y coordinates)
if (ball.getX() > levelBrick.getX() - ball.getWidth() + collisionLogicSecurityPadding &&
ball.getX() < levelBrick.getX() + levelBrick.getWidth() - collisionLogicSecurityPadding) {
//velocity.getX(), -velocity.getY()
} else {
//-velocity.getX(), velocity.getY()
}
So I measure if the ball is inside the brick with it x position. If this is the case the collision is TOP or BOTTOM. If not RIGHT or LEFT.
However this is causing the issue when the ball is hitting near the edge it detects wrong. Here a short clip: https://i.imgur.com/U8ybhRl.mp4
The issue is that the x is smaller than the area where it thinks it's TOP or BOTTOM so it's switching the X direction which is causing an issue.
My question here is how to avoid this? Is there any way I can solve the collision that it's working correctly? When I'm looking online the most tutorials are only checking top or bottom collision.
I think you could change the detection of TOP, BOTTOM, LEFT, RIGHT collisions to where the collision happened relative to the ball. Assuming the preservation of momentum you just need to negate the X- or Y-velocity.
In the example above the ball clearly generates a collision TOP and LEFT to his center of mass. Therefore it is impossible to generate a RIGHT collision which would generate the behavior you described. This leaves the Problem, that you do not know yet whether it was a collision on the LEFT or TOP. But since the Vector was pointing to the RIGHT (positive X-Movement), it is impossible to generate a collision on the LEFT. The collision must have happened at the TOP and therefore the Y-velocity needs to be multiplied by -1.
As long as the ball is the only moving object this method cannot generate weird behavior. As soon as you have an Object moving faster then the ball, you need additional checks: An Object hitting the ball on its left, while it is already in a general movement towards right will increase the X-velocity.
As I understood your question it seems to me like your issue is that the red box goes in an incorrect direction after bouncing on an edge.
I think you need to detect collision in three instances.
Top/Bottom
Left/Right
An Edge
If the collision occurs at an edge you need to send it in the same x direction as before with reducing the speed it goes in the direction y. y speed should always be less than initial speed and in the same direction as before.
I think above would solve your issue.
Hiho. On a below image we have three situations. Black arrow shows the path before collision, green one - after the collision.
I. Ball 1 hits ball 2 when their are floating on themselves. After the collision, they should both reverse their directions from up to down and from down to up.
II. Ball 1 hits ball 2 and ball 1 reverses it's direction, ball 2 still floats to it's old dir.
III. Here we have a problem. Ball one has lower x position, they collide with just a piece and they should float to some direction that I don't know.
I know some vectors, linear algebra etc. but I just need a point where to start. Is there anyone who know how to solve an issue like this? With vectors? Trig/Cycl functions?
Thanks !
I'm creating a Breakout game to familiarize myself with Java.
Currently I've got everything working but I've noticed that the ball seems to take off in the same direction.
I've programmed it so when the ball hits the paddle the Y velocity is reversed. This works, but the ball seems to follow the same route...
How would a make the collision seem more realistic?
When the ball hits the left side of the paddle, I want to redirect it back to the left but I'm not sure at which angle to reflect it. Can anyone provide a formula to help me work out the angle at which I need to direct the ball upon contact with either the left or right side of the paddle?
If the ball hits the paddle from the top, negate Y velocity.
If the ball hits the paddle from the side, negate X velocity.
Reversing the vertical velocity is the correct thing to do for a perfectly elastic collision, which is what you want in a breakout game (the ball keeps it's total velocity after the collision).
The problem of following the same route can be avoided either by randomizing the initial ball position and velocity, or by changing the collision dynamics to be unrealistic. You could either add a small random component to both coordinates (taking care to keep the total velocity the same), or send the ball at a different angle, depending on where it hits the pad (which is what many games of this type do).
To do the later, you need to calculate the absolute position where the ball hits the pad, normalize it (by subtracting the pad position and dividing by the pad length), and map it into a angle range (maybe -80 to 80 degrees). You can then calculate the desired horizontal and vertical velocities using trigonometric functions.
One idea might be to use motion of the paddle to vary the direction a bit. Say, if the paddle is moving to the right when hitting the ball, change the X velocity of the ball to the right a little in addition to reversing the Y direction. That provides a way for the user to actually use some skill to put the right "English" on the ball.
There are two separate problems involved, a design problem and the physics problem. In the end, the physics problem might have the easier solution:
Compute the collision point on the paddle
Compute the instantaneous horizontal velocity pvx of the paddle
Compute the normed outward surface normal (nx,ny) at the impact point. This is the design decision, in the middle part of the paddle one probably wants (nx,ny)=(0,1), while on the left side (nx,ny)=(-1,0) or generally in WNW direction, on the right side correspondingly (nx,ny)=(1,0) or in the general ENE position.
Use the physics formula for a collision with a moving infinitely massive object to compute the new velocity vector (vx,vy):
dot = nx*(vx-pvx)+ny*vy
vx = vx - 2*dot*nx
vy = vy - 2*dot*ny
One may check if the dot product dot is positive to avoid spurious collision computations if paddle and ball do not separate fast enough after collision.
I have a mouse event handler and under mouseMoved I have this:
public void mouseMoved(MouseEvent e)
{
if((e.getX()>=0 && e.getX()<=100) && (e.getY()>=0 && e.getY()<=100))
{
robot.mouseMove(mainOutput.getX()+200,mainOutput.getY()+200);
}
}
What this does is that if the user tries to move towards the first 100x100 pixels of the frame, the pointer will translated. What I want to do however is recreate an "impassable wall".
Basically when the user attempts to go in the region it cannot pass the end points of the region. What I want to know is how would I go about doing this?
Unfortunately, this is a bit more difficult than it seems. Let me first illustrate the problems with a simple move-to-outside-of-boundary approach.
As you can see, in this case the boundary approach will detect the mouse inside the boundary, and move it to the blue point in the corner. Let me emphasize this, it detects the location of the mouse. What we want is to capture the movement of the cursor, and have it end at the red point. There are also other problems with this method that may not be immediately apparent.
So how do we capture the movement of the mouse? We need to capture the mouse displacement (black arrow) as a vector by keeping track of the previous location as well. I assume you can do this. So how do we calculate the new location? Well, we can perform line intersection of the displacement vector with the lines that make up the edges of the box. As you're only dealing with horizontal and vertical lines, it is greatly simplified and can be done with just a bit of thinking. If you're lazy, copy a generalized line intersection algorithm.
You may think that this approach is too rigorous, but it is the most robust way. I can already think of two additional issues with the simpler approach. Also, you're actually doing 2D hitbox detection. This is quite a useful thing to know.
Assuming the impassable area is a JPanel, you can add a mouse listener to it that will respond whenever the mouse enters the area, and then do the relocation stuff that you already have.
JPanel pnlArea = new JPanel();
pnlArea .addMouseListener(new MouseAdapter() {
#Override public void mouseEntered(MouseEvent arg0) {
//execute some codes if the mouse pointer has enterd the area.
}
});
I think you just need to clarify to yourself what the behaviour of a mouse hitting a wall would be, in terms of coordinates.
Hopefully this terrible image helps;
Whenever the mouse moves, you want to check if it's in the forbidden region (the region beyond the wall; the no man's land). To do this, just check if the x coordinate (assuming a horizontal wall in this example) of the mouse is beyond its limit (the x coordinate of the wall).
If it is, move the mouse back to the wall, preserving its y value (set its x coordinate to that of the wall)
FOR A CAGE:
The case of having a surrounding, square wall is a little bit more complicated, in terms of where to place the mouse when breaching the wall.
Observe that there are 8 different regions to consider where the mouse could enter the 'forbidden zone', and each boundary should translate the mouse differently.
The coordinate of the boundary corners are in red (and consist of 4 values; xL, xR, yT, yB for left, right, top, bottom respectively)).
The green text in each region describes the conditions that must all be true for the mouse to lie in that region (they're how you detect the mouse must be in that region) where x and y are the mouse coordinates.
You can see that the four 'side' regions involve a simple translation; just altering one of the coordinates of the mouse (the x coordinate for a vertical wall, y for a horizontal wall) to match that of the wall.
The four 'corner' regions can entirely change the mouse coordinate (to their corner coordinate!)
I'm working on a Java Bomberman clone, using a grid system, and I'm not really satisfied with the movement right now. When the player presses a movement key, the character starts to move (with 0.25 speed). The player loses the control, and the character keeps moving until it has moved a full tile. The player only regains control when the character gets to the center of the next tile.
This makes it's too "laggy". If I want to change direction now, I can't.
Maybe I could make the base of the character smaller than the size of the sprite, meaning I would have to check ahead of the corners to check if it was a valid move. Any thoughts?
Thanks!
I just played Bomberman a few minutes ago :)
You can move pretty smooth, there no grid calculations.
I haven't used Java that much. I use Flash a lot. Is the Grid for checking collisions ?
What is it for exactly ?
Would it make sense to have something like(I'll try to sketch it):
float vx,vy = 0;//velocity on x and y
Character bomberman
void keyDownHandler(KeyboardEventSomething event){
if(key is Left && ! Right ) vx -= .5;
else if(key is Right && !Left ) vx += .5;
//idem for Y axis
}
void keyUpHandler(KeyboardEventSomething event){
vx = vy = 0;
}
void updateLoop(){
bomberman.x += vx;
bomberman.y += vy;
}
I might be a bit off, because I'm not sure how much you want to clone Bomberman or not. What you're describing with the grid movement seems closer to hopmon
Don't disable user input. Ever. Constantly poll for it.
Have a Tick() or OnFrameEnter() function that does the following:
Poll the keyboard/joystick/whatever, and cache the last direction entered by the user.
Check the position of the character.
If the character is idle in the center of a grid square, set it's velocity in the proper direction and upate the movement one step, unless there's a wall/collision object in the way. Also clear out the last key press to some invalid value.
Else if the character is already moving, update the position of the character, checking for collision with a wall, or proximity to a direction changing node (intersection). If it collides with a wall, stop the character. If it's close to a direction changing node and can travel in the cached direction, change the direction and clear the cached direction. Else if the input direction is opposite the current direction (it's in a hallway and the player wants to reverse), reverse the direction and then clear the key press. This all assumes that the character should continue moving, always, until it hits a wall and stops. If you want the character to stop anywhere, a reverse direction key should simply stop it in place.
Caching the key press allows the player to preemptively change directions as the character approaches an intersection. This way the character doesn't have to wait to stop before moving on, and the player doesn't feel the game is unresponsive. Polling constantly lets the player reverse directions at any time, and makes direction changes at intersections seem faster.
You should be able to get rid of current sprite and load the new one exactly when you need it - i.e. if the character moved half way to the next tile and the player presses a key to return, cancel the sprite and load the new one starting at 0.5.
I guess it depends on how you want it to behave.
Say you are moving up, and you click right.. do you want it to stop moving up and go right?
I would store the previous grid location when you make a movement. that way if you click to move elsewhere you can hop backwards and change the movement direction..
Or if you are moving up and you click down... you could set the movement speed to be the opposite of what it is...
It is hard to answer with out knowing what you want it to behave like.
It sounds like you update the players position (start of the animation) by changing the grid cell in which its contained.
To be able to achieve the desired effect, the sprites render position should be independent of where the entity represented by that sprite is located on the grid. And allow the user to move inside that grid within a range of the cell's center without changing cells. If this range is not chosen correctly you may en up with the "doh! im in this (visually) cell but it says im in the future cell" problem, or the "my avatar is overlapping a wall".
Dont change the players cell until he is within a range (lets say 1/3 of the bounding sphere of the sprite) from the limits/borders of the cell that contains him. You would also have to modify the animation process for it to be interruptible.
This is independent of the degrees of liberty you give the player (like, it could only move up, down, left, right, and diagonals vs 360 degrees)
Another thing you should watch out for is, if the sprite is larger than the cell size. For instance, a Fat monster, or a Snake boss which spans across X cells but not necessarily in rectangular form.