How do I create a physics trajectory?

0 favourites
  • 12 posts
From the Asset Store
Fully commented source code/event sheet & sprites to create a space shooter game
  • I'm making a turn based game. I have a physics object which is moving. When the game is essentially paused, I want the player to be able to move a sprite which acts as a target for the physics object.

    I want to be able to display a predicted line, or series of dots that will show where the object will move to based on its current velocity, force and angle.

    I've found many threads on the forum with people talking about this, but every link is broken, and half the pages are gone.

    Here's what I have so far:

    At the moment, this just creates the dots in a straight line, and doesn't follow the physics path at all.

    I have the physics Linear Damping set to 1, and gravity set to 0.

    If someone has a simple example, I'm sure I can use it to get what I'm aiming for.

  • This old one still works, although it could be cleaned up more.

    construct.net/en/forum/construct-2/how-do-i-18/parabolatracjectory-tracing-55313

    Here's a cleaned up version. The y acceleration is the gravity*50. Why? because the units with the physics behavior are wonky aka scaled. It will still be off slightly from the physics behavior's path and I figure the only way to make match perfectly would be to use js to load box2d, set it up identical to how the physics behavior uses box2d, run n amount of simulation steps.

    dropbox.com/scl/fi/htkostz6pa29v65ytxzh6/perdicted_path.capx

    Here's a test to figure out the differences of the physics behavior units.

    dropbox.com/scl/fi/f8pecd2r8hrltfh2z3zhn/physics_units_compare.capx

    Finally if you want to set the acceleration from a force you'd do it like this:

    mass = density*area /50

    acceleration = force*50*50/mass

    The density is the mass property in the editor.

  • This old one still works, although it could be cleaned up more.

    https://www.construct.net/en/forum/construct-2/how-do-i-18/parabolatracjectory-tracing-55313#forumPost493367

    Here's a cleaned up version. The y acceleration is the gravity*50. Why? because the units with the physics behavior are wonky aka scaled. It will still be off slightly from the physics behavior's path and I figure the only way to make match perfectly would be to use js to load box2d, set it up identical to how the physics behavior uses box2d, run n amount of simulation steps.

    https://www.dropbox.com/scl/fi/htkostz6pa29v65ytxzh6/perdicted_path.capx?rlkey=abgmmli99t6y2izahqwt47fkd&dl=1

    Here's a test to figure out the differences of the physics behavior units.

    https://www.dropbox.com/scl/fi/f8pecd2r8hrltfh2z3zhn/physics_units_compare.capx?rlkey=qx9mgkfesim7w6zufvecgi13m&dl=1

    Finally if you want to set the acceleration from a force you'd do it like this:

    mass = density*area /50

    acceleration = force*50*50/mass

    The density is the mass property in the editor.

    The first example is closest to what I'm looking for, but none of the examples are quite right. The second just seems to be based on a rotating 'cannon' with no change to strength.

    The first is great, but I can't quite figure out why the angle is clamped, and applying any additional force breaks everything entirely. However, I love the fact that it pretty much always collides with the mouse. That's smart.

    The closest I've come is an Angry Birds clone "tutorial" I found... but I feel like the creator simply brute forced things into working, rather than coming up a good method.

    No idea why it's listed as a tutorial, let alone a beginner tutorial, seeing as I've been unable to figure out a lot of things, there are no steps and no comments. I mean, that 7.1 scale just appears to be a random number that luckily fixes things.

    https://www.construct.net/en/tutorials/angry-birds-clone-2615?highlight=62670#comments

    In the game I'm working on, the Ship has momentum, and is turn based. So rather than gravity, it's 'flying' toward a marker. When you end your turn after repositioning the marker, the ship restores its velocity, but if you've moved the marker, it will start applying a force toward that. Essentially, gravity is a point in space, rather than a constant direction.

  • I think I read what you wanted wrong. It sounds like its mostly a matter of calculating the force so that the object lands on the target after a duration.

    dropbox.com/scl/fi/bikvo6eg66yyzf4p18o2v/physics_force_calc_and-trajectory_plot.capx

    I skipped the physics behavior entirely so I wouldn't have to deal with the units.

  • I think I read what you wanted wrong. It sounds like its mostly a matter of calculating the force so that the object lands on the target after a duration.

    https://www.dropbox.com/scl/fi/bikvo6eg66yyzf4p18o2v/physics_force_calc_and-trajectory_plot.capx?rlkey=f9iz261uogmqcn12d1x5xc8ra&dl=1

    I skipped the physics behavior entirely so I wouldn't have to deal with the units.

    What you've produced is pretty amazing, but sadly, although 'cool' looking, I don't want it to land on the target.

    I want the ship to always have a physics force applied toward the target, allowing the player to only shape the ship's path.

    I have provided an example, but I'm working in Construct 3, and seem to recall you only working with Construct 2, which seems likely as you're sending me CAPX solutions. However, I note you have a C3 badge on your profile, so I may be wrong.

    In any case, here's the example:

    https://1drv.ms/u/s!AlZkRk7KfdFFjdpKzutJyXpnXPE8ow?e=t782T4

    This is as close as I'm able to get. I basically want the dots to always show where the ship will go.

  • Ah gotcha. I get what you’re after now I think. The examples at this point are predicting the path as of the acceleration remains constant. But with what you’re after the force will vary based on the objects position.

    Glancing at your file the force you apply with physics is different that the force variables. But that’s as far as I got.

    If the fps is 60 and the physics is set to fixed timestep (which is 60 i think no matter what) then it’s just the process of simulating a frame at a time to get the path. Unfortunately the predicted path will vary if the the frame times vary. It’s trickier to make it frame rate independent since the force varies by position.

    Anyways, just some thoughts. I’ll be away for the computer for a while so there won’t be any soon solutions from me.

    I use the free version of c3 sparingly. I typically am not connected to the internet so I prefer c2. Someone gifted me c3, hence the icon I guess. It was nice of them, but I really don’t use use c3 to need it. I’m not even logged in. The free version is fine for my purposes.

  • Ah gotcha. I get what you’re after now I think. The examples at this point are predicting the path as of the acceleration remains constant. But with what you’re after the force will vary based on the objects position.

    Glancing at your file the force you apply with physics is different that the force variables. But that’s as far as I got.

    If the fps is 60 and the physics is set to fixed timestep (which is 60 i think no matter what) then it’s just the process of simulating a frame at a time to get the path. Unfortunately the predicted path will vary if the the frame times vary. It’s trickier to make it frame rate independent since the force varies by position.

    Anyways, just some thoughts. I’ll be away for the computer for a while so there won’t be any soon solutions from me.

    I use the free version of c3 sparingly. I typically am not connected to the internet so I prefer c2. Someone gifted me c3, hence the icon I guess. It was nice of them, but I really don’t use use c3 to need it. I’m not even logged in. The free version is fine for my purposes.

    Not to worry. I'm struggling to understand how mass, etc play into things. The manual says mass is determined by multiplying the Density by the area of the object's collision polygon. So if my sprite is 30x30, and my density is 1, then why does my mass show as 18 in debug???

    Very frustrating :)

  • It’s 30*30*1/50 = 18. Notice the /50 is needed. That’s what I mean by the units of the physics behavior being off. That second capx figures out the conversions between units in the behavior and what it should be. 50 comes up a lot. I think it was mainly due to an oversight when the behavior was made. Position and speed are spot on but most other values are off by some factor. This really only becomes an issue when trying to apply physics based calculations.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • It’s 30*30*1/50 = 18. Notice the /50 is needed. That’s what I mean by the units of the physics behavior being off. That second capx figures out the conversions between units in the behavior and what it should be. 50 comes up a lot. I think it was mainly due to an oversight when the behavior was made. Position and speed are spot on but most other values are off by some factor. This really only becomes an issue when trying to apply physics based calculations.

    50??? 60 I'd understand, but 50? I don't get it.

    Do you know how velocity is calculated? I imagine it has that 50 in there again. If I apply an impulse of 1 again on an object with 0 density, I end up with 50. Strangely, I thought that force was essentially a constant impulse being applied, so if I apply a single frame of force, I'd get the same result.

    If I could figure out how much velocity the force would generate on a stationary object based on it's current position toward a certain angle, I could add those numbers to the predicted velocities in the loop, and get a more accurate line.

    I note that force actually appears to be based on time, so if I apply a single force of 60, I end up with 49.79... so let's say 50.

    However, that all becomes a lot harder when you have mass and damping included.

    Additionally, while if I give the sprite a density of 0, I get 49.79 after that burst of force, if I instead give it a density of 1 I get 139.16. No idea why an object with more mass would move faster. However, saying that, a density of 2 gives me 69.58.

    So that makes no sense. I think you're right. It just seems like someone made a mistake in coding the physics engine...

    Update - Just realised, with a density of 0, we get a mass of 50, rather than 0: 30*30*0/50 = 50, which is wrong.

  • When you use a density of 0 it probably just sets it to 1. Otherwise there would be divides by 0.

    Anyways look at the 2nd capx to see the conversion factors between what the behavior uses and calculating it manually.

    You asked about velocity? It’s the same either way. Pixels per second.

    Box2d uses meters for the distance unit internally not pixels so it’s typically scaled. So likely they picked 50 pixels = 1 meter in the behavior. The behavior tries to convert the values to be in pixel units but misses the mark with the conversion for anything but velocity. A fix would be simple but would break all existing projects with physics.

    Anyways units aside I’ll mess with it later.

  • I'm probably missing the mark about what you're after again. But this has an object move with a force applied to an object (I went with a gravity based force). The predicted path is found by just doing multiple steps.

    This just does the physics manually so we don't have to simulate what the physics behavior does and deal with the value differences. It uses a fixed timestep to avoid the inconsistencies of a variable timestep since the acceleration is continuously changing.

    dropbox.com/scl/fi/3zw8r9yo86oh0xpef5akl/perdict_path.capx

    Maybe it could be useful for some ideas.

  • Thanks, but I think I managed to brute force it.

    I applied the same force to multiple objects of various sizes and mass to figure out if there was a number that seemed to be in common with all of them, allowing me to predict the velocity based on the mass and the force. I eventually came to:

    V= M/(F×41.73)

    41.73 seemed to be a common number. Although not 100% perfect, seeing as I only need to predict about 1 second into the future, it works fine. Also, with this, I'm able to predict 10 seconds into the future with general accuracy. I haven't tried further than that, but I imagine it's capable for some time.

    In addition, this allows me to continue to work with the physics engine, dealing with collisions, etc.

    Thank you for your help! The above method could be improved on, for sure, but it should work for all games that need to predict physics.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)