You know that golf holes in any games that "attracts, or sucks, balls into/towards the hole" game mechanic?

I find games in space, such as Angry Birds Space on Android produces some zones in which objects spins around the planet when interacting with gravity, intriguing with gravity involved. Like how black holes interact with objects, how gravity distorts the original velocity vector of an object towards the center, etc.

I'm curious about:

What is the name for the "gravity hole" game mechanic? (Depicted as such in the picture.) I would like to know the most generic name, so I can find it easily on Google.

How it was done exactly? Does one rotate the dot product of (the normalized vector from center of hole to point of collision) and (speed vector of any object within range of the gravity hole) towards the center of the hole?

The effect? Nope, not rotating for the most part. It's more a build up of velocities based on the acceleration imparted by objects on objects. You're not really 'rotating' anything (Of course, due to the way that most objects function in these circumstances a rotation does occur, however that's a side-effect, not a cause).

Basically, you do something like: dv = g * mass / distance^2. Then you can figure out the 'components' of it by doing dx = sin(angle) * dv, dy = cos(angle) * dv. These are then added to the object's velocity vector. Rotation happens, to a small extent due to the fact that gravity doesn't affect the entire object at the same amount. This tends to be very negligible, instead more of it comes from the forces of drag/other atmospheric/friction based considerations.

In your image the 'Yellow' zone is really just the point at which the dv formula actually starts to apply a change in velocity that is noticeable (Due to the distance^2, far away objects are relatively unaffected), however the objects still feel them.

I thought the entire process can be done by vector calculations, instead of using sines, cosines, and angles.

It's trippy, but I guess my curiosity is fulfilled.

The only problem left is the search term that allows me to search around on Google. I see that, other than using physics to describe it, there aren't anything on Google that points me to a few Java examples.

What you are looking for can be done with springs. Google spring physics and Hooke's law and it should take you in the right direction. It shouldn't be too hard to inplement if you've got a good physics engine as a base.

What you are looking for can be done with springs. Google spring physics and Hooke's law and it should take you in the right direction. It shouldn't be too hard to inplement if you've got a good physics engine as a base.

Yes, but the example tom_mai78101 is using is a golf game, as he states is "´attracts, or sucks, balls into/towards the hole´ game mechanic". When an object is in the yellow zone you let a spring force work on the object. It the force of the object is weaker than the spring it will "magnetise" itself to the center, else it will just change the objects course as it enters and leaves the yellow zone. I might not be gravity, but I belive it´s an relatively easy solution to the problem. Why wouldn´t this work?

Note that it's not just any golf games. It could be any space themed games.

By continuing this discussion further, I would like to try taking such a challenge and be able to get this mock Java code up on here:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

publicvoidsuckIntoHole(Ballb, Holeh){//Note that (x,y) for Ball and Hole are given at the top left corner.floatballRadius = b.diameter /2;floatholeRadius = 16;//Give the correct difference of the two objects' position.floatdx = b.position[0] - h.x + (ballRadius + holeRadius);floatdy = b.position[1] - h.y + (ballRadius + holeRadius);//Find the angle of the line of collisiondoubleangle = Math.atan2(dx, dy);//Change the angle of the speed vector to the line of collision.doublelx = b.speed[0]*Math.cos(angle)-b.speed[1]*Math.sin(angle);doublely = b.speed[1]*Math.cos(angle)+b.speed[0]*Math.sin(angle);//Set the new speeds to the current speed.b.speed[0] = (float) lx;b.speed[1] = (float) ly;//And then set the new position on the line of collision to the object's position.b.position[0] = (float)(lx*Math.cos(-angle)-ly*Math.sin(-angle));b.position[1] = (float)(ly*Math.cos(-angle)+lx*Math.sin(-angle)); }

My hypothesis is like this:

But in practice, the ball went awkward... And didn't quite bend around the hole like I expected.

I made a little sample applet. All I do is add the speed vector to the position vector.

The "hard" part is figuring out the x and y components of the pull. Which you can do with sin and cos on the magnitude of the pull. You get the angle needed by the angle between the objects. I wasn't bothered I simply took the delta of the objects positions and added a fraction of that to the speed.

I made a little sample applet. All I do is add the speed vector to the position vector.

The "hard" part is figuring out the x and y components of the pull. Which you can do with sin and cos on the magnitude of the pull. You get the angle needed by the angle between the objects. I wasn't bothered I simply took the delta of the objects positions and added a fraction of that to the speed.

Very intresting applet.The problem with your implementation is (I fist didn't know you are able to right-click on it to make things appear), that if you create a lot of object on one position, then wait for it to drive off, the more far away you put new "particles" the faster they move to the gravitation center.

So to put it in an easier sentence: The farer away your particles are from each other, the stronger the gravity is between them.

That's totally logical. You used the fraction of the delta vector and added that one to the position. So when does this vector get larger? Of course when the total delta is getting bigger.

I noticed something as soon as I try the implementation. The balls will eventually go towards the hole, but very slowly, while it's bouncing around and around the hole.

I tried tweaking it, so that if the ball gets closer and closer to the hole, the speed increases. I realized that if I were to hit the balls affected by the gravity pull with my cue ball, the balls ignore their current position and continues to move around, despite my cue balls changing their positions directly.

This behavior isn't what I wanted, and they seemed to be off by many factors. I've been tweaking it until I fell asleep on the keyboard, so I must've been thinking too hard on this problem.

Actually, I'm adding buffers to this. If we look at this one-dimensionally, for example, on the X axis, we could see that the values tend to increase/decrease around the targeted X value (where the hole is located on the X axis). The values go up and down, as show here.

What I'm doing is to try to make it so that when the ball goes past the targeted X value, and slow down, just like the red graph shown above.

I thought that if I give the Dx and Dy values a bit more intensity, it will work. But that is not the case.

Sounds like you're wanting to simulate something like a gravity well, where an object is caught in the gravity field of a larger more massive object and is pulled inwards. Jonjava above does a good job of explaining the physics involved, i'd like to try and take it a tiny bit further.

Once you calculate the force due to gravity on the smaller object, F, i think its useful to use this to calculate the acceleration on the object, since F = mass x acceleration, and work with acceleration instead of F alone. This way you can just use the acceleration value to update the velocity, then use the new velocity value to update the x and y position co-ordinates of the object.

If you call m1 the mass of the larger more massive object, and m2 as the mass of the smaller orbiting object, then the acceleration of m2 is found by the following...

If m1 is much larger than m2, then the above shows that you can effectively drop the value of m2 from the calculation of acceleration due to gravity on m2.

Once you have the acceleration, you find it's horizontal and vertical components. You've already nailed that in your code above using trig and the angle.

In each frame just keep adding the horizontal and vertical components of the acceleration to the horizontal and vertical components of the object's velocity, and in turn add these velocity components to the x and y position co-ordinates of the object to simulate the effect of gravity, though rather roughly. A more accurate simulation would include higher order integration factors to accommodate the effects of a variable acceleration rate.

If you're having bother splitting a vector into its horizontal and vertical components, check out the applet I knocked up to help visualise this at the link below. Click the mouse left button and drag it around the screen to see a vector and its horizontal and vertical components.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org