hello All
I am working on a 2D helicopter side scrolling(left to right) game where it moves up and down, dodging and firing at the enemy copters...i would like to get some advice on the physics part of the helicopter which could make the up/down and dodging movement smooth...
please advice...
2D Helicopter Motion
How much 'physics' is used by the implementation currently? Do you move things in terms of forces, accelerations and velocities or just move them an arbitrary distance each timestep?
You can create a nice smooth movement by applying a force to the helicopter which increases (up to a limit) as the player holds the movement key down, and decreases when the player lets go of the key. The limits of this force, and the rate at which it increases/decreases can be tweaked until it feels right.
You can create a nice smooth movement by applying a force to the helicopter which increases (up to a limit) as the player holds the movement key down, and decreases when the player lets go of the key. The limits of this force, and the rate at which it increases/decreases can be tweaked until it feels right.
Author
currently i am moving the helicopter up and down at a constant value..which is very boring...what i am looking is to move it up and dowm(accelerate it up and down) in a smooth fashion when i hold the key down...can anyone let me know the ideas for it to do so...
This tutorial might help you out: http://www.rodedev.com/tutorials/gamephysics/
It's very simple to understand and interactive.
HTH,
Feen
It's very simple to understand and interactive.
HTH,
Feen
pseudocode:
[Edited by - Esys on July 19, 2010 8:28:14 PM]
if KEYDOWN == RIGHT: heli_velocity_x += 3 if heli_velocity_x > max_speed: heli_velocity_x = max_speed elif KEYDOWN == LEFT: heli_velocity_x -= 3 if heli_velocity_x < -max_speed: heli_velocity_x = 0 else: ## There's got to be a better way if heli_velocity_x > 0: heli_velocity_x -= 1 if heli_velocity_x < 0: heli_velocity_x = 0 elif heli_velocity_x < 0: heli_velocity_x += 1 if heli_velocity_x > 0: heli_velocity_x = 0 heli_pos_x += heli_velocity_x[Edited by - Esys on July 19, 2010 8:28:14 PM]
If you want a smooth motion you should probably incorporate time into your movements (unless you can guarantee a perfect framerate, which most OSes won't even allow you to do).
For example (this is only pseudocode):
For a very simple 2D movement this might suffice. For a more realistic movement you would want to allow the helicopter to rotate a bit. At this point I would combine your x and y into a Vector2, and store the helicopter's rotation. Then 'up' movement would need to be relative to the helicopter's rotation rather than the world rotation.
For example (this is only pseudocode):
float x = y = 0.0f; // Positionfloat Gravity = -9.8f; // Default gravity (in y direction)// Function called every frame// 'timeDelta' is elapsed time, in seconds (e.g. 0.05f would be 1/20th of a second)void FunctionBasedOnTime( float timeDelta ){ switch ( keyPressed ) { case KEY_ARROW_UP: // Move helicopter up y += (moveSpeed * timeDelta); // 'moveSpeed' would be in units/second break; // Handle other keys... } ApplyGravity( timeDelta, y );}// Pass your 'y' coordinate to have gravity take effect on itvoid ApplyGravity( float timeDelta, float& y ){ y += (Gravity * timeDelta);}For a very simple 2D movement this might suffice. For a more realistic movement you would want to allow the helicopter to rotate a bit. At this point I would combine your x and y into a Vector2, and store the helicopter's rotation. Then 'up' movement would need to be relative to the helicopter's rotation rather than the world rotation.
Quote:Original post by SneftelQuote:There's got to be a better wayheli_velocity_x *= 0.9
I was thinking of that, but I didn't know how to take into account a negative velocity when trying to clamp it to 0 when it reached a certain threshold.
Edit: n/m
Why would you need to make it exactly 0?
So what if your fixed time step isn't exactly every (say 20ms)? Any decent implementation would make up for it and might run at say: 20, 18, 23, 19, 19, 19, 22, ms intervals, which is perfectly correct and doesnt loose or gain time overall.
Using a fixed time step for logic (and a variable timestep for rendering with say interpolation) is far better than a variable one. As I found in another project even simple things don't always work the same with a variable step eg:
As I found at 20fps and 50fps, the position will get a different result over time (In a test I did it was nearly 2.5% after one second). There are some equations that will give the same results for constant acceleration, but AFAIK there is no general solution to this divergence. Far better to use a fixed time step in the first place.
Quote:Original post by lordikon
If you want a smooth motion you should probably incorporate time into your movements (unless you can guarantee a perfect framerate, which most OSes won't even allow you to do).
So what if your fixed time step isn't exactly every (say 20ms)? Any decent implementation would make up for it and might run at say: 20, 18, 23, 19, 19, 19, 22, ms intervals, which is perfectly correct and doesnt loose or gain time overall.
Using a fixed time step for logic (and a variable timestep for rendering with say interpolation) is far better than a variable one. As I found in another project even simple things don't always work the same with a variable step eg:
velocity += acceleration * deltaTime;position += velocity * deltaTime;As I found at 20fps and 50fps, the position will get a different result over time (In a test I did it was nearly 2.5% after one second). There are some equations that will give the same results for constant acceleration, but AFAIK there is no general solution to this divergence. Far better to use a fixed time step in the first place.
Quote:Original post by Fire Lancer
Why would you need to make it exactly 0?Quote:Original post by lordikon
If you want a smooth motion you should probably incorporate time into your movements (unless you can guarantee a perfect framerate, which most OSes won't even allow you to do).
So what if your fixed time step isn't exactly every (say 20ms)? Any decent implementation would make up for it and might run at say: 20, 18, 23, 19, 19, 19, 22, ms intervals, which is perfectly correct and doesnt loose or gain time overall.
Using a fixed time step for logic (and a variable timestep for rendering with say interpolation) is far better than a variable one. As I found in another project even simple things don't always work the same with a variable step eg:
*** Source Snippet Removed ***
As I found at 20fps and 50fps, the position will get a different result over time (In a test I did it was nearly 2.5% after one second). There are some equations that will give the same results for constant acceleration, but AFAIK there is no general solution to this divergence. Far better to use a fixed time step in the first place.
If you use fixed time step, you don't have to factor in timedelta into each movement. However, if you ever decide to change the time step length, it affects all of your movements, and you must go an adjust all movement speeds accordingly, which can be a maintenance nightmare. Additionally, if you do fixed time step for movement, you often need to have the same time step for rendering, or you will see jittery movement of objects, where you render on frames where the object doesn't move.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement