Tag Archives: 2d

Jetboard Joust Devlog #60 – Flamethrower Blues pt. 1

Been far too long since I updated the devlog, it’s not that I’ve been slacking but that there simply hasn’t been enough progress made to warrant writing anything. I’ve had my hands full with a big chunk of contract work and haven’t really been able to face yet more coding on my ‘off’ days, preferring to try and get the new Muleskinner Jones album finished instead. No luck with that yet either! Now I’m beginning to understand why so many #indiedev projects never reach completion, as well as feeling like I used to when I’d try and keep a diary and end up trying to write three month’s worth of entries in one go.

Anyway – there has been some progress. Now that the alpha’s done I’m starting to work on new weaponry and the first up is the flamethrower. I deliberately started with what I thought would (probably) be the hardest weapon to get right and it hasn’t disappointed on that score, hence splitting this entry into two parts. Firstly we’re going to deal with getting the flamethrower to look and feel right (which is as far as I’ve got at the moment), next up we’ll deal with collision detection and actually getting the thing to do damage to enemies.

My first attempts at generating a convincing ‘fire’ effect with particles were pretty ropey, at best they looked like one of those cannons that shoots streamers or confetti rather than flame, some kind of manic party popper. Eventually though, after going down far too many blind alleys, I realised I was superficially trying to recreate what a flamethrower looks like rather than how it actually works. A flamethrower, of course, doesn’t actually shoot flame – it shoots a highly flammable liquid which is ignited as it leaves the barrel.

So, instead of using a single particle emitter to despatch a bunch of particles from the barrel of the weapon, I worked on firing a bunch of imaginary blobs of liquid. Each of these act as individual particle emitters so they appear ‘on fire’.

You can see the first results of this approach on the right, alongside an approximation of the motion of the individual ‘flammable blobs’. At this stage things still looked nothing like a flamethrower but I could tell that I was at least on the right track (believe it or not this was a massive improvement upon my earlier efforts)!

The next step was to vary the intensity of the particles dependent on how long their parent ‘blob’ has been in the air. I imagined a very intense, focussed flame to start with that would gradually get weaker and less focussed as the ‘blob’ burnt out and dispersed. After some tweaking to this effect my flamethrower was actually starting to look pretty convincing!

Last tweak was to give the individual particles a small amount of vertical acceleration, as if the heat was making them rise, and I was now pretty happy with the way things looked. Unfortunately my job was far from done!

Up until this point I’d been testing the flamethrower whilst firing from a static position, of course as soon as I tried it whilst moving everything went horribly wrong! I had been applying ‘correct’ physics to the ‘blobs’ in that, when fired, they are given a horizontal force from the gun as well as a horizontal and vertical force based on the players movement. It just didn’t feel right in practice however and I could see I was going to have to apply some ‘fake’ physics in order to get things to play nice.

I couldn’t find anything much on the Internet to help me but I did find an interesting YouTube video on the physics of the flamethrower in Half-Life 2 which demonstrated that the flamethrower ‘blobs’ always move relative to the player rather than relative to the game world. I reworked my code to operate on this basis, it was a definite improvement but I felt things has now gone too far the other way and the flames felt too rigidly ‘stuck’ to the player, it looked particularly noticeable when the player switched direction.

So I applied a kind of ‘halfway house’ approach instead, keeping the blobs moving relative to the player as long as the player maintains the same direction and keeps ‘fire’ held. When the player changes direction or releases fire the blobs are ‘unstuck’ from the player, ie the force of the player’s currently horizontal and vertical motion is applied and they are left to move relative to the world.

This seemed to be a good compromise approach as it allows for strafing and general playability whilst also looking nice and ‘fluid’ as the player changes direction. Now I just need to figure out the collision detection…

Dev Time: 2 days
Total Dev Time: approx 117.5 days

previous|next


Deconstructing The Flamethrower – Flammable Blobs

mockup_3x
First Attempt With ‘Flammable Blobs’


Adding Particle Dispersion, Getting There…


Adding ‘Heat Rises’ Effect To Particles


Damn! It Looks Dreadful When You’re Moving!


Moving Relative To Player, Better But Too ‘Sticky’


The (Hopefully) Final ‘Halfway House’ Approach
Advertisements

Lerp Camera Motion Smoothing Tutorial and Example Code

Recently I’ve been revisiting at the way the camera works in Jetboard Joust – something that has been a continual thorn in my side throughout the project.

When researching how to make the camera movement better I came across many references to Lerp smoothing but I found few, if any, detailed explanations as to how this works in practice and (particularly) ways to get around its significant limitations. Cue this post, by the end of which we’ll have a class that’ll move an object smoothly towards a target point and ‘brake’ so it reaches it exactly no matter how often and by how much the target is changed.

I’m just concentrating on one axis of movement here for simplicity but this approach can easily be applied to 2D or 3D vectors. For those of you with short attention spans you can just download the final class here.

So… Lerp is a quasi-acronym for ‘linear interpolation’ and used to create smooth movement between two points. It’s often used to smooth out camera movement but can equally be applied to sprites or anything else in 2D or 3D space. The basic equation for Lerp is very simple, it takes a position and target, works out the difference between them and then returns a value a specified amount along that path. Only values >0 and <1 are generally meaningful.

public static float Lerp(float position, float target, float amount)
{
     float d = (value2 - value1) * amount;
     return value1 + d;
}

If you are using this equation to move an object and each frame call it with the object’s current position (keeping the other values the same) the object will move a smaller distance each frame which results in a ‘slowing down’ effect as the objects reaches its target. Here’s an example of this type of motion applied to a sprite. In this case the sprite is moving approx 480 pixels at a frame rate of 60fps with a Lerp value of 0.025.


Basic Lerp Smoothing

Now this looks pretty good already but, as you’ve probably figured out, there are issues. The first one is that using this approach the object will never actually reach its destination – this can result in a slightly jerky looking motion as it reaches the end of its trajectory as well as presenting potential issues if you want to do something when the destination is reached.

One way of resolving this is to implement a minimum amount of movement per frame. This can be anything you want but for many applications it makes sense for this to be one pixel.

Here’s a simple ‘Lerper’ class that implements this – each frame the amount of movement (LerpVelocity) is calculated and, if the absolute value of this is less the minimum velocity we clamp it at the minimum velocity. Of course this means that the object might now be in danger of moving beyond its target point so we check for this at well and make sure it doesn’t.

public static float Lerp(float position, float target, float amount)
public class Lerper
{
    public Lerper()
    {
        Amount = 0.025f;
    }

    // Returns the amount of movement at this stage of the lerp
    private float LerpVelocity(float position, float target)
    {
        return (target - position) * Amount;
    }

    public float Lerp(float position, float target)
    {
        float v = LerpVelocity(position, target);

	// If this is less than the minimum velocity then
        // clamp at minimum velocity
        if ( Math.Abs(v) 0) ? MinVelocity : 0 - MinVelocity;
        }

	position += v;
	// Now account for potential overshoot and clamp to target if necessary
        if ( (v= target))
        {
            position = target;
        }
        return position;
    }

    public float Amount
    {
        get;
        set;
    }

    public float MinVelocity
    {
	get;
	set;
    }
}

Here’s an example of this in action. As you can see it looks much better…


Lerp With Minimum Velocity Applied

Still we have limitations though if we’re looking for really smooth movement. The next glaringly obvious one is that Lerp is ‘ease out’ only, the object will be moving fastest at the start of the sequence which makes it look like it’s being fired from a slingshot rather than smoothly accelerating from rest.

To resolve this I’m going to apply an ‘Acceleration’ property to my Lerper class. This ensures that, if the object is increasing in speed, the increase doesn’t exceed a specified amount. This requires a variable to store the amount of movement each frame.

public class Lerper
{
    private float previous_velocity;

    public Lerper()
    {
        Amount = 0.025f;
        Acceleration = float.MaxValue;
    }

    // Returns the amount of movement at this staget of the lerp
    private float LerpVelocity(float position, float target)
    {
        return (target - position) * Amount;
    }

    // Returns the next position with lerp smoothing
    public float Lerp(float position, float target)
    {
        // get the amount to move
        float v = LerpVelocity(position, target);
        // don't allow increases in velocity beyond the specifed acceleration
        if ( v>0 && previous_velocity>=0 && v-previous_velocity>Acceleration )
        {
            v = previous_velocity + Acceleration;
        }
        else if (v < 0 && previous_velocity  Acceleration)
        {
            v = previous_velocity - Acceleration;
        }
        // If this is less than the minimum velocity then
        // clamp at minimum velocity
        if ( Math.Abs(v) 0) ? MinVelocity : 0 - MinVelocity;
        }
        // Remember the previous velocity
        previous_velocity = v;

        // Adjust the position based on the new velocity
        position += v;
        // Now account for potential overshoot
        if ( (v= target))
        {
            position = target;
        }
        return position;
    }

    public float Amount
    {
        get;
        set;
    }

    public float MinVelocity
    {
        get;
        set;
    }

    public float Acceleration
    {
        get;
        set;
    }
}

Here’s an example of this in action – now we have a nice ‘ease in’ to our Lerp motion. Here I’m using an acceleration value of 0.25f.


Lerp With Maximum Acceleration ‘Ease In’ Applied

There’s one other problem I’m going to address though. This ‘ease in’ effect works nicely if the object is initially at rest or moving in the same direction but if the object had previously been moving in the opposite direction we’re still going to get a nasty jolt. Here’s an example where I’m changing the destination to the opposite side before the previous Lerp has reached the end of its trajectory.


Sudden Changes In Direction Result in A Nasty Jolt

So we’re going to check for this in the code and again apply a maximum amount by which the velocity can change each frame. Remember that because we’re changing direction the absolute value of the current velocity at the point of change is the sum of the absolute value of both the current and previous velocities, ie a change in direction from 10 to -10 would result in a new velocity of -20.

A side-effect of this is that the object will probably end up moving away from the target until it’s gathered enough momentum to change direction. As the code that clamps to the target position assumes we are moving towards the target we have to max out the target value if this happens.

We also have a special case check for our minimum velocity here as we need to make sure that if the minimum velocity is applied its applied in the direction that moves towards the target (otherwise the object could get stuck moving in the wrong direction).

public class Lerper
{
    private float previous_velocity;

    public Lerper()
    {
        Amount = 0.025f;
        Acceleration = float.MaxValue;
        MinVelocity = 0;
    }

    // Returns the amount of movement at this staget of the lerp
    private float LerpVelocity(float position, float target)
    {
        return (target - position) * Amount;
    }

    // Returns the next position with lerp smoothing
    public float Lerp(float position, float target)
    {
        // get the amount to move
        float v = LerpVelocity(position, target);
        // don't allow increases in velocity beyond the specifed acceleration (ease in)
        if ( v>0 && previous_velocity>=0 && v-previous_velocity>Acceleration )
        {
            v = previous_velocity + Acceleration;
        }
        else if  (v  Acceleration )
        {
            v = previous_velocity - Acceleration;
            // we might actually end up moving away from the target
            // here in which case we adjust the target so we don't get
            // clamped to it later
            if (v  0 && previous_velocity  Acceleration )
        {
            v = previous_velocity + Acceleration;
            // we might actually end up moving away from the target
            // here in which case we adjust the target so we don't get
            // clamped to it later
            if (v > 0-MinVelocity)
                v = MinVelocity;
            else
                target = float.MinValue;
        }

        // If this is less than the minimum velocity then
        // clamp at minimum velocity
        if ( Math.Abs(v) 0) ? MinVelocity : 0 - MinVelocity;
        }
        // Remember the previous velocity
        previous_velocity = v;

        // Adjust the position based on the new velocity
        position += v;
        // Now account for potential overshoot and clamp to target if necessary
        if ( (v= target))
        {
            position = target;
        }
        return position;
    }

    public virtual void OnTarget(){}

    public float Amount
    {
        get;
        set;
    }

    public float MinVelocity
    {
        get;
        set;
    }

    public float Acceleration
    {
        get;
        set;
    }
}

Here’s what happens when you suddenly change the Lerp target with this code applied – as you can see we now have a nice smooth movement no matter how often we change the target value.


Lerp With Maximum Acceleration ‘Ease In’ Applied

And that’s pretty much it. You can download the final class file here – in the final version I’ve also added a MaxVelocity property, a delegate to be called when the object reaches its destination, and tidied up the code so its not quite so verbose.

If you are in the process of coding a camera for a 2D game I highly recommend you check out this excellent article.

If you are looking for something to move smoothly between two points over a specified number of frames then you’re probably better off using some kind of tweening rather than Lerp. Check out Robert Penner’s excellent tweening/easing functions or the ‘smoothstep’ algorithm approaches described here.

Hopefully this article is of use – if so please consider following me on Twitter.