I have got a ball which bounces of walls. This bounce is simple, i just do this, ( code snippet )
if ( x - moveSpeed < 0 ) // Ball hit left wall
xVel *= -1;
However i also got a rectangle which the player moves. The bounce on this practically works as the bounce on walls.
But i figured out that when a ball got similar movement as the picture, its impossible for me to make it go straight up again. I therefore need some kind of calculation regarding the rectangles movement to influence the outcoming angle of the ball. The rectangle always got a constant movement speed when moving. This picture shows a rectangle moving to the left and the ball hitting it during its movement, which results in a 90 degree angle.
( Which shouldn't always be 90 ).
Sorry about my crappy pictures i hope they make sense. My math is rusty thats why i really could need a push in the right direction.
Here is a tutorial on some physics (which is what you need to know) and you need to learn about vectors. The tutorial doesn't go over exactly what you are looking for (the reflection of the bounce and angles) but this is a GREAT start for beginning, because you'll need to know all this to finish your project.Game Physics 101
If you want to do it the easy way, here is code in c++ that describes exactly how to do what your looking for.
Edit
You should actually check out the second link first, its a tutorial on exactly what you need to know. But if you are looking to do more than just make the ball bounce around, say include other moving objects or something like that, check out the first link.
No need for any fancy math here. My understanding of these types of games is that the angle the ball comes off of the paddle is determined by where on the paddle it bounces. If it bounces in the middle, then the current angle is preserved. As it bounces closer to the edge of the paddle, the angle is adjusted in the direction of that side of the paddle. Think of the paddle as a rounded surface.
Going the route of simulating actual physics (as opposed to #Treebranche's answer, which is how I think those sort of games really work) can get very complicated. You can consider friction, spin, duration of contact, etc. Here are a couple links that discuss this.
https://physics.stackexchange.com/questions/11686/finding-angular-velocity-and-regular-velocity-when-bouncing-off-a-surface-with-f
https://physics.stackexchange.com/questions/1142/is-there-a-2d-generalization-of-the-coefficient-of-restitution/
This code demonstrates how to bounce the ball back or in another direction by reversing the ball's X or Y heading with ball.headingX=-ball.headingX and ball.headingY=-ball.headingY .
Putting theory to practice :
/* update ball's x heading */
ball.x+=ball.headingX;
/* update ball's y heading */
ball.y+=ball.headingY;
/* if ball at most right of screen then reverse ball's x heading */
if( (ball.x>PONG_SCREEN_RIGHT) )
{
ball.headingX=-ball.headingX;
}
/* check if ball's location at top or bottom of screen,if true reverse ball's y heading */
if( (ball.y<PONG_SCREEN_TOP) || (ball.y>PONG_SCREEN_BOTTOM-2) )
{
ball.headingY=-ball.headingY;
}
/* check if ball lands on pad, if true bounce back */
if ( (ball.y>= PlayersPad.LEFT) && (ball.y<= PlayersPad.RIGHT) && (ball.x==PlayersPad.x))
{
ball.headingX=-ball.headingX;
playersScore+=10;
}
/* let computer track ball's movement */
if (ball.x>PONG_SCREEN_RIGHT-18) computersPad.y=ball.y;
/* check if ball misses pad, if true display you missed */
if (ball.x<PONG_SCREEN_LEFT)
{
displayYouMissed();
ball.x=ball_Default_X;
ball.y=ball_Default_Y;
}
Related
I have two rectangles, one of them stationary. Whenever I try to move one towards another I want it to 'slide' rather than getting stuck without being able to move. I use oriented bounding boxes and the code is fairly tested, but I don't know how to avoid them getting stuck.
Currently what I do is this:
o1 = o;
vector2df vxy = o.V;
o1.Pos += vxy;
if(o1.overlaps(o2)){
o1 = o;
o1 += vector2df(0.f, vxy.y);
if(o1.overlaps(o2)){
vxy.y = 0;
}
o1 = o;
o1 += vector2df(vxy.x, 0.f);
if(o1.overlaps(o2)){
vxy.x = 0;
}
}
o1.V = vxy
Which is quite 'dirty' as it just checks if the movement can be done in either X and Y, disabling it if it collides individually.
The velocity is a float, so later it will just add it.
I had thought doing a while loop until it doesn't collide, leaving the smaller value in which it won't collide, but it either doesn't work or is stuck in an infinite loop...
I'm guessing the first thing to do would be to rewind your moving box's movement so that it doesn't collide anymore with your fixed box. Right now your boxes are probably staying in a colliding state, hence the infinite loop.
Then as for determining the new velocity of your moving box, you probably want to get the direction of the edge from your fixed box your moving box is colliding with and set that as your new velocity.
You also might want at some point to multiply this new velocity by the dot product of your initial velocity and your new direction, so that when the moving box goes perpendicular to the fixed box's edge, it basically stops, but if it's going at a sharp angle it doesn't loose much speed.
All of this describes a vastly oversimplified approach, you might want to read more about basic game engines/physics/collision detection if you want a cleaner result.
Hope this helps.
I am editing the rollingball example map from Unreal (in Unreal Engine). I changed it so my ball you grow and melt (it's a snowball), gaining and losing size and mass.
My problem is the control of it. The example map moves the ball by adding torque. My problem is that my mass changes a lot, so I need a torque the changes depending on the size of my ball (not 1:1 as a bigger snowball should still moves slower).
My problem is that my ball seems to accumulate torque and spins a lot (I added a lot of friction to the ball, it did not helped, it just moved the problem a bit). As an example, if I press left for a while, it's gonna go left. Then if I press right, it goes right. But when I stop pressing right, it spins and goes left again.
This is my current code:
void ASnowballBall::MoveRight(float Val)
{
const FVector Torque = FVector(-1.f * getNewTorque(Val), 0.f, 0.f);
Ball->AddTorque(SpringArm->GetComponentRotation().RotateVector(Torque));
}
void ASnowballBall::MoveForward(float Val)
{
const FVector Torque = FVector(0.f, getNewTorque(Val), 0.f);
Ball->AddTorque(SpringArm->GetComponentRotation().RotateVector(Torque));
}
float ASnowballBall::getNewTorque(float Val)
{
return (Val * RollTorque * (log2(Ball->GetMass()))) / 10000;
}
Note: The log was a test to increase the torque slowly with the mass. It's not working well at all. Right now I am using return Val * RollTorque instead, but it's almost as bad.
The control is horrible and I would like to get an idea on how to fix it. If removing the torque would be better, I will change it. I simply want a responsive control that is fun, and where the player still have a sense of the size of the ball (slower when big compared to small).
PS: My original mass is about 500 kg and can go up to 20 000 kg (it's a puzzle game). I did not set the original mass, it's set by Unreal relative to it's size. I could change the mass scale though.
You could try using AddForce instead of AddTorque.
So the speed of the ball is modified every tick like this:
void APlayerBallBearing::Tick(float deltaSeconds)
{
Super::Tick(deltaSeconds);
BallMesh->AddForce(FVector(InputLongitude, InputLatitude, 0.0f) * ControllerForce * BallMesh->GetMass());
}
InputLongitude and InputLatitude are the values that are put in by the user in the current frame for movement in cardinal directions, they correspond to your MoveForward and MoveRight values I reckon.
The controller force is something you need to tweak in order to find the right value for your ball movement. With a value of at least 600.0f I started getting "decent" behaviour.
I cannot help you with the mass though you would need to try that out yourself, the default mass of the ball mesh I used was ~110.
I'm having difficulty getting the Chipmunk physics engine to do what I want. The only solution that appears to work requires some heavy vector math. Before diving into that rabbit hole for the other components of my game, I was hoping someone could fill me in on a better way to go about this. The desired gameplay is as follows:
A character moves around a finite space in a top-down view
Movement is always a constant velocity in whatever direction the character faces
The player taps on the screen, which causes the character to 'turn' towards the touched location
The basic idea is like driving a car. You cannot immediately turn around, but instead must first perform a u-turn. That car must also maintain a constant speed. How might I do this? Bonus question: how can you override whatever method chipmunk calls to update a body's position, and is this a good idea?
There is this tutorial on how to do top down controls using specially configure joints:
http://chipmunk-physics.net/tutorials/ChipmunkTileDemo/
It's based on Chipmunk Pro, but the stuff about controlling the character is easily adapted to vanilla Chipmunk. The "Tank" demo that comes with the non-Pro Chipmunk source implements pretty much the same thing if you want to see some C code for it.
You basically want to rotate the orientation of the player more gradual. You could do this at a constant rate, so when you tap the screen it will start rotating at a constant rate until it has reached the right orientation. This would give a circular turn circle. This will however affect your position, so you would have to keep turning until you would be on a collision course with the position you tapped.
The path you would travel would be similar to that of the game Achtung die kurve.
So you would have to save the location and orientation of the player (x, y and phi coordinates). And to determine whether to stop turning you could do something like this:
dx = playerx - tapx;
dy = playery - tapy;
targetAngle = atan2(dy,dx);
if (phi > targetAngle)
{
if (phi - targetAngle > PI) omega = rotate;
else omega = -rotate;
}
else if (phi < targetAngle)
{
if (targetAngle - phi > PI) omega = -rotate;
else omega = rotate;
}
else omega = 0;
For the past days, I've been trying to make a ping pong like game. I have 2 paddles and a ball. All dynamic sprites. Everything's been working well except for one issue I'm having. The ball tends to bounce on the same angle at some point. So there would be times when the player can simply move the paddle on a specific part and the game can go on for a while or might be forever, since the ball doesn't change its angular velocity regardless of which part of the paddle it hits. I'm using a combination of linear and angular velocity to keep the ball moving like so:
if(_isPaused == FALSE)
{
_world->Step(dt, 10, 10);
for(b2Body *b = _world->GetBodyList(); b; b=b->GetNext()) {
if (b->GetUserData() != NULL) {
CCSprite *sprite = (CCSprite *)b->GetUserData();
if(sprite.tag == 2)
{
b2Vec2 dir = b->GetLinearVelocity();
dir.Normalize();
float currentSpeed = dir.Length();
int maxSpeed = 60;
float accelerate = vel;
if(currentSpeed <= maxSpeed)
{
b->SetLinearVelocity(accelerate * dir);
}
sprite.position = ccp(b->GetPosition().x * PTM_RATIO,
b->GetPosition().y * PTM_RATIO);
sprite.rotation = -1 * CC_RADIANS_TO_DEGREES(b->GetAngle());
//Keep sprite from bouncing in a straight angle
b->SetAngularVelocity(_body->GetAngle());
}}}
So my question is, how can I manipulate the angular velocity to keep the ball bouncing on different angles everytime it collides with my paddle? I'm thinking something like getting the current angular velocity then multiplying it with some value but I'm not sure if that's the right way to approach the issue I'm having. Any suggestions or ideas would be greatly appreciated. Thanks in advanced.
The way I see it, you have two options:
Check the location of a collision. If it's close to the top/bottom edge of the paddle, deflect the outgoing velocity by an angular amount proportional to the surface "curvature" at that point. Of course, this is cheating, but if the artwork and code are in agreement, it looks correct. And graphics is "the art of cheating without getting caught".
You could take into account the current velocity of the paddle as well as that of the ball. Eg: if the ball is moving downwards and to the right, and the paddle is moving down, then you can compute the outgoing direction using conservation of linear momentum. Just make sure you restrict the paddle's change in momentum along the horizontal axis to be zero.
Finally, you could combine the above techniques, but now you'd have to use accurate collision detection (not the hack I described in (1) above).
Hope that helps!
A few pointers, you should use SetLinearVelocity() and SetAngularVelocity() rarely. Each alters a property of the body definition, which could make you run into problems later on when things get more complex. It would be better to use ApplyForceToCenter() or ApplyLinearImpulse() in the place of SetLinearVelocity() as these two are much more versatile functions and are a bit more coder-friendly. In my opinion, I don't think you should use b->SetAngularVelocity(_body->GetAngle()); If you wanted to change the angular velocity each time it collided, you could, in your beginContact method, write that every time the body collides with the paddle body, a random angular impulse is applied to the ball, using ApplyAngularImpulse().Hope that helps.
I am using OpenGL to create the 3D space.
I have a spaceship which can fire lasers.
Up until now I have had it so that the lasers will simply to deeper into the Z-axis once fired.
But I am attempting to make a proper aiming system with crosshairs so that you can aim and shoot in any direction, but I have not been successfull in trying to update the laser's path.
I have a directional vector based off the lasers end tip and start tip, which is gotten from the aiming.
How should I update the laser's X,Y,Z values (or vectors) properly so that it looks natural?
I think I see.
Let's say you start with the aiming direction as a 3D vector, call it "aimDir". Then in your update loop add all 3 (x, y and z) to the projectile "position". (OK, at the speed of light you wouldn't actually see any movement, but I think I see what you're going for here).
void OnUpdate( float deltaT )
{
// "move" the laser in the aiming direction, scaled by the amount of time elapsed
// since our last update (you probably want another scale factor here to control
// how "fast" the laser appears to move)
Vector3 deltaLaser = deltaT * aimDir; // calc 3d offset for this frame
laserEndpoint += deltaLaser; // add it to the end of the laser
}
then in the render routine draw the laser from the firing point to the new endpoint:
void OnRender()
{
glBegin(GL_LINES);
glVertex3f( gunPos.x, gunPos.Y, gunPos.z );
glVertex3f( laserEndPoint.x, laserEndPoint.y, laserEndPoint.z );
glEnd();
}
I'm taking some liberties because I don't know if you're using glut, sdl or what. But I'm sure you have at least an update function and a render function.
Warning, just drawing a line from the gun to the end of the laser might be disappointing visually, but it will be a critical reference for adding better effects (particle systems, bloom filter, etc.). A quick improvement might be to make the front of the laser (line) a bright color and the back black. And/or make multiple lines like a machine gun. Feel free to experiment ;-)
Also, if the source of the laser is directly in front of the viewer you will just see a dot! So you may want to cheat a bit and fire from just below or to the right of the viewer and then have in fire slightly up or in. Especially if you have one one each side (wing?) that appear to converge as in conventional machine guns.
Hope that's helpful.