2D Helicopter Motion

This topic is 3016 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

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...

Share on other sites
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.

Share on other sites
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...

Share on other sites

It's very simple to understand and interactive.

HTH,
Feen

Share on other sites
pseudocode:
    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]

Share on other sites
Quote:
 There's got to be a better way
heli_velocity_x *= 0.9

Share on other sites
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):

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.

Share on other sites
Quote:
Original post by Sneftel
Quote:
 There's got to be a better way
heli_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

Share on other sites
Why would you need to make it exactly 0?

Quote:
 Original post by lordikonIf 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.

Share on other sites
Quote:
Original post by Fire Lancer
Why would you need to make it exactly 0?

Quote:
 Original post by lordikonIf 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.

1. 1
Rutin
46
2. 2
3. 3
4. 4
5. 5
JoeJ
19

• 11
• 15
• 9
• 10
• 13
• Forum Statistics

• Total Topics
633004
• Total Posts
3009837
• Who's Online (See full list)

There are no registered users currently online

×