# 'Thrust' Physics

This forum is currently in read-only mode.
0 Favourites
• 22 posts
• Hey everyone. I've been looking everywhere for tutorials and they seem rare, even for code, never mind construct!

I'm looking to prototype a simple space shooter type movement, something like Asteroids, Thrust etc. I've gotten a basic setup done with custom movement, and I think I understand how that particular object works... but I'm trying to implement the correct physics, using events and avoiding using many of the built in behaviours. This is only because I prefer to know what's going on and don't like the idea of something changing in another version and breaking everything

So I suppose what I'm stuck on is how to implement the movement of a single sprite... I want to use vectors maths but I'm unsure what the correct way to implement them would be. I assume you should set up separate private variables like XPostion, YPosition, Angle... is there any advantage to making a few vector functions (dot product, cross product etc) or can Construct do all this anyway? (I've not been through every single event yet so I might be mistaken)...

Also I'm a bit confused about the way angles are implemented, with 0 being right rather than up like I was used to. Will this cause problems when calculating rotations and inertia and all that? Furthermore it all has to work with delta time, have acceleration/deceleration for rotation as well as the same for movement itself.

Any ideas would be helpful, it's been a while since I've looked at any maths in detail

Cheers

• For that type of movement only addition and subtraction of vectors are needed. No need for dot or cross product although those are easily implementable.

Here's an example for you viewing pleasure:

http://dl.dropbox.com/u/5426011/examples/asteroidsMovementEx.cap

• Absolute genius, thanks mr. hound

I love it, it's got a great feel to it, I've just added some additional private variables 'ThrustSpeed' and 'RotationSpeed' and adjusted the events so that the numbers 100 and 200 should be easier to play around with. Any idea how I could get the rotation to decelerate when the left/right arrow isn't being pressed? It'd be good to be able to prevent the ship spinning out of control so easily

• I was looking for a way to implement this explanation but I never could get my head round C++ code examples having really understood OO programming :S

http://www.gamedev.net/community/forums/topic.asp?topic_id=183827

• Actually the 200 and 100 are linear and angular acceleration, not speeds.

For angular deceleration:

``````+ MouseKeyboard: [negated] Key Left arrow is down
+ MouseKeyboard: [negated] Key Right arrow is down
-> Sprite: Subtract 2*'AngularVelocity'*TimeDelta from 'AngularVelocity'
[/code:3q26kvpc]
2 is the deceleration amount .

On a side note the physics behavior is way better suited for this type of movement, as it takes very little to set up.``````
• Actually the 200 and 100 are linear and angular acceleration, not speeds.

Yup haha I figured it out after I'd made the post, sorry for that

Thanks for the additional help, it works quite nicely

• ## Try Construct 3

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

Construct 3 users don't see these ads
• I managed to piece something together using some things I learned browsing the forum, seems the physics behaviour route might be more ideal anyways since the collisions are already handled much better that I could probably implement them

http://www.mediafire.com/file/o1zvm0muyjb/Ast_Physics_1.cap

Any ways to improve this? The torque/rotation doesn't use DeltaTime, I'm not sure about that :S

I don't know, something feels a tad bit jagged and unnatural about the thrust, what do people think?

• The nice thing about using behaviors is you don't need to worry about TimeDelta, because it's handled within the behavior.

You can simplify your events and it will behave exactly the same and be more readable:

``````+ MouseKeyboard: Key Up arrow is down
-> Sprite: Set force Sprite.value('Thrust') towards (Sprite.X + cos(Sprite.Angle), Sprite.Y + sin(Sprite.Angle))
+ MouseKeyboard: Key Left arrow is down
-> Sprite: Set torque 0-Sprite.value('Rotation')
+ MouseKeyboard: Key Right arrow is down
-> Sprite: Set torque Sprite.value('Rotation')[/code:1fvwdf3w]``````
• Ah I wasn't aware of that, that's made things a lot easier

It looks much more readable now, cheers again for the help

• One more little addition here... I've been trying to figure out a method of having a mouselook/turret type of behaviour using physics, where the 'ship' rotates to look at the mouse pointer. I've managed to implement this, using the Angle command to find the correct angle to turn towards, by applying torque... however, the torque overshoots and then constantly 'bobs' the ship back and forth in a swinging motion, never settling on the point it should be aiming at. This obviously makes the control a bit unpredictable.

What I need is a way to slow the rotation down as it approaches the correct angle, so that it stabilises on the angle that points to the mouse pointer. I've looked everywhere all night and everything I have tried to implement has failed... there are some helpful things on the net but they all revolve around normalizing angles using pi - I'm not sure if Construct has defined constants, or the ability to define them? Or if a global float would have sufficient accuracy, etc etc...

This was the most useful reference I found http://stackoverflow.com/questions/2617476/physics-game-programming-box2d-orientating-a-turret-like-object-using-torques

I'm off to London til Thursday so I can't carry on working on this, but any ideas would be appreciated so I can get cracking when I return

• weird, I was just doing this today for my own project

set torque towards object

at a force of anglediff(.angle,angle(ship.x,ship.y,mousex,mousey))

multiply that whole thing by something or divide it by something until it's at a good looking amount

• Very cool lucid, it seems to work pretty well if the changes in angle are small, but if you make anything bigger, lets say a 90 degree swing, you still get a pretty big overshoot of the intended target - maybe some of the physics settings need to be different in order to have a more responsive torque behaviour? Or is it just unavoidable when using the physics behaviour to have objects swing all over the place when torque is applied?

• Would clamp help here? Or perhaps lerp?

• Finally got an example for a physics turret working:

http://dl.dropbox.com/u/5426011/examples/PhysicsTurret.cap

and tweaked so it works with multiple turrets:

http://dl.dropbox.com/u/5426011/examples/multiPhysicsTurret.cap

The only drawback is the turret's inertia needs to be calculated (which I do in the first second). Also the calculated inertia is not 100% accurate so the turrets jitter a bit when pointing at the target.

-enjoy

• That's a really cool example, the maths are getting more and more complex eh It's a shame about the jitter, I've been pondering how exactly to remove that. I'm still not sure about the whole radians/angles thing... since all of Box2d's calculations are implemented using radians (which is the proper way to go in a mathematical sense) yet everything in the physics behaviour and construct in general uses degrees...

I'll just have to keep trying stuff and see what comes of it Maybe there's a way of implementing it by setting the angular velocity as opposed to using torque