# How display path ball will bounce?

I'm trying to figure out a way to show the path a ball will travel, so that the player can line up a shot before they fire the ball.

I can't think of a way to calculate this path in advance and show it to the player, especially if it involves collision detection. At first I thought I would run the game at a super high speed for one update, plot the path with some dotted lines where the ball bounced, and then in the next frame hide the 'tracer' ball. This seems to have two issues - Calculating collision detection without actually updating the frames and collision detection getting less reliable at high speeds.

If they were straight lines I think I could figure this out in a while loop, but trying to take into account the speed of the ball, the curve of the path, the reflecting from other objects..it all seems a bit much.

I'm not looking for any code and this isn't a platform specific question, more just help trying to figure out conceptually how this would work. Can this be done? Are there techniques to achieve this?

-
While I agree the accepted answer is a good one, it's typically a good idea to wait at least a day on questions like this before accepting an answer. You might get better answers and people are less likely to answer if there's already an accepted answer. Welcome to the site boolean. – Byte56 Dec 6 '12 at 2:38
Isn't path-finding related to the concept of an AI searching for a path to go throught instead to calculating an already known path a body will take? – Gustavo Maciel Dec 6 '12 at 4:05
Sorry about marking the answer too fast - I'll know for next time! @Gustavo: I had to pick at least one tag to post, and path-finding was the closest one I could think of. In retrospect it probably wasn't the best choice. – boolean Dec 6 '12 at 16:12
I went ahead and changed the tag to physics since the question is mostly about projecting the physics of the ball forward in time. You can edit and retag your questions however, should you decide something else is more fitting. You were right about it being an awkward question to tag though, I tried to think of a good second tag for it but didn't have much luck. :) – Lunin Dec 6 '12 at 18:13

You have a couple options depending on how complicated your situation is, but for the things you are mentioning I would say your first instinct is pretty close to what you want to do.

When you wish to display the path, go ahead and make a copy of your ball launched at the appropriate angle and run it forward without regard to framerate or drawing. You'll still step it forward in the same increments you normally would (to avoid high speed issues), you'll just start the next step immediately rather than wait for next frame as normal. You'll also want to keep track of the simulated time passed, as it's unlikely you'll want to trace out forever. You'll also need it for applying correct amounts of force as all physics will use the simulated timestep rather than the actual one.

Now, if your ball is going to affect the things it collides with, you'll have to include them in the simulation (and anything they hit) past that point, in which case you'll likely want to show a tracer "ghost" version of those objects as well. Obviously if this isn't an issue (or you can make it not an issue through design choices) it makes your problem quite a bit easier to manage. I'd make a copy of anything involved in the simulation for purposes of said simulation as that way you can affect them with your normal physics calculations without worrying about actually moving anything.

Every time you collide, figure out the new effects to the ball (primarily velocity) and continue running your simulation in a loop until either you stop (velocity under threshold) or you hit the end of your tracer (say, 5 seconds of simulated time, much less than that actually) For ease of calculation I'd set it up so you only trace the ball as things are right now, if that bounce will effect other obstacles and you want to stay accurate you'll have to update all of them as well should they be affected by anything moving in the simulation.

Once you have that data display just depends on how you want to handle it. You could have the simulated ball drop visible spheres at a regular rate during it's path, or you could play it in sections and let the tracer ball itself be seen. I would recommend that you only run the long calculation of what happens when the input factors change (direction/power difference) in order to cover up the extra time it takes to process.

-
Wow, really good info, thanks mate! – boolean Dec 6 '12 at 0:45
Glad I could be of assistance, and welcome to the site! Just as a note, on more open questions like this you generally want to give some more time for people to see the question before accepting an answer, as someone else might have an even better answer in mind for your situation. – Lunin Dec 6 '12 at 1:12