How display path ball will bounce?

Question

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?

Answer 1

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.