Jetboard Joust Devlog #70 – Shred-ache

At last – a weapon where I can write about something else other than endless tweaking of shader and particle effects (though there was still plenty of that involved)!

The Shredder is another weapon inspired by many wasted hours playing Turok 2 on the N64 back in the day. In Turok it’s a weapon that fires a laser that bounces off anything it hits, you can it in action here.

I knew that to get this mechanic to work I was going to need a method of collision detection that was more robust than the current system I’m using due to the speed the shredder’s ‘beam’ would be travelling. My current system relies on objects actually colliding at the point at which the collision checking is done, this is fine for the most part but will fail when very fast objects more ‘through’ smaller objects (the so-called ‘bullet through paper’ syndrome).

So I started looking at how to implement a basic raycasting algorithm to check for collisions instead. I am not great at Math(s) so was slightly dreading this, but thankfully I found a YouTube video that was able to explain to explain the calculations involved in simple raycasting here. There’s some very clear code linked to from that same video.

I was able to implement a decent enough raycasting algorithm fairly painlessly, so the next step was to work on the visuals. I didn’t really like a plain ‘laser beam’ type effect as is used in Turok, so began working with smaller particles instead. I felt a weapon called the ‘shredder’ should look at least vaguely like it’s tearing things to pieces!

After several hours of tweaking particle parameters (a process I am now getting a bit tired of) I managed to settle on an effect I was pretty happy with and seemed to fit with the name ‘shredder’. There’s two sets of particles here, one which stays aligned with the ‘beam’ and one which drifts away from it. Also particles are added when the ‘beam’ reflects off a surface.

I uploaded this to Twitter thinking I was done, but after coming back to it felt the trail of the ‘beam’ was too dispersed. It needed some kind of central ‘pulse’ or something. I also had some feedback, again via Twitter, to this effect so I wrote a simple shader that allowed me to taper a beam out to a point and used this. I also focussed the distribution of the particles a bit more.

Now I think I am done!

Dev Time: 2 days
Total Dev Time: approx 138.5 days

previous

mockup_3x
First Steps Testing The Raycasting Algorithm

mockup_3x
Adding Reflection And Testing A rough ‘Laser Beam’ Effect

mockup_3x
The Point At Which I Thought I Was Done

mockup_3x
The Final Weapon In Action
Advertisements

Jetboard Joust Devlog #69 – Boom Boom, Shake The Room!

This latest weapon is called the ‘Sonic Boom’ and I had a fairly good idea of what I wanted it to look like visually before I started. Something akin to radiating circles but not so regular in feel.

I remember seeing something as a kid in a book about optical illusions (we had no Internet then, kids) that always stuck with me – it was an image comprised of two sets of concentric circles, the centres of which were slightly offset. It made your eyes go funny and that was a good thing.

So I started on that basis, by updating the geometry shaders I discuss here to include multiple sets of shapes that are offset by a certain amount. It took quite a while to get this working in a way I was happy with (and to structure the HLSL in a way that was sensible and would allow me to add other shape types easily), but the result was pretty satisfying if nothing like the effect I set out trying to achieve!

I realised there was just too much being drawn in the shader so I set about adding some different paint modes to vary the effect created. As well as the original ‘OR’ logic (if a pixel contains a shape it’s drawn) I added AND, XOR and NOT modes that react differently, particularly where shapes overlap. For the AND and NOT modes I allow a number of overlaps to be specified, with AND any pixel that contains >= the number of overlaps is drawn, with NOT and pixel that contains < the number of overlaps is drawn.

By combining these modes and a lot (and I mean a lot) of tweaking I was finally able to achieve the type of effect I'd set out to create. The final version consists of two overlapping geometry shaders for the bulk of the effect, particles around the barrel of the weapon, and a smaller 'negative' geometry shader also around the barrel of the weapon.

As with most of these weapons, the actual mechanics of it were pretty straightforward to program. It acts really like a kind of RPG that must be 'charged' before being released, if anything it's even simpler than the RPG because I'm allowing this one to travel through buildings (I'm not sure if I'll keep it like that or not, it does seem a little weird).

I did also have to update the enemy AI to allow them to cope with a 'charge and hold' type weapon but that was pretty easy. The audio design for this one's gonna be fun!

Dev Time: 2 days
Total Dev Time: approx 136.5 days

previous | next

mockup_3x
First Stab At Updated Geometry Shader

mockup_3x
Adding Different Paint Modes To The Geometry Shader

mockup_3x
The Final Sonic Boom Effect

mockup_3x
Adjusting Enemy AI For ‘Charge And Hold’

Jetboard Joust Devlog #68 – Ray Of Hope!

I felt the latest weapon deserved a post to itself as it took a bit longer than the others and I’m particularly pleased with the result.

It’s called the ‘Gamma Ray’ and I was deliberately going for a kind of retro 50s sci-fi vibe with it. As with the bulk of the weapons (probably more so), there’s actually very little to coding the mechanics of it – probably around 90% of the development time here was spent on the visuals.

The ‘ray’ effect is all created with a custom shader. At its heart it’s an approximated sine wave (calculated using the smoothstep algorithm) – to get it looking more ‘electric’ I vary the amplitude of the wave at random each cycle.

I had a lot of issues finding a technique for generating random numbers in HLSL that I was happy with. I tried out a couple of algorithmic solutions but none of these seemed to look much good to me. In the end I used a second texture as a ‘noise’ lookup table, I created this texture myself by rendering to a RenderTarget2D in MonoGame so I could be sure the ‘noise’ was perfectly distributed. I’ll probably write a simple tutorial post on this subject and include some PNGs with different type of randomness.

I didn’t like using a consistent wavelength for the shader as it seemed to make things too uniform so I tried varying the wavelength per frame. This looked much better but I ran into an issue where the ‘end’ of the ray looked weird if it didn’t taper out to a point, which it wouldn’t do when there wasn’t an exact number of wave cycles across the length of ray.

I tried fading out the end to get around this – this worked OK but not great and looked weird when the ray ‘collided’ with enemies or buildings. In the end I settled on a solution whereby I taper out both the amplitude and ‘stroke width’ of the wave to zero, this seems to work fine and, even with a fractional amount of cycles, the ray now always tapers out to a nice point!

Lastly I applied a raster effect to the wave (again in HLSL) and overlaid two different rays with wavelengths cycling at different rates. The wavelength of both waves in tweened using a ‘Bounce’ tween algorithm so it seems to cycle regularly but in a fairly non-linear fashion.

The concentric circles at the muzzle of the gun and at the point the ray hits something are created using the geometric shaders I discuss here, though I’ve added a raster effect and a gradual fade out.

Dev Time: 2 days
Total Dev Time: approx 134.5 days

previous | next

mockup_3x
One Of The First Drafts Of The Raygun Shader

mockup_3x
The Finished Raygun Effect

mockup_3x
The Gamma Ray In Action

mockup_3x
Gamma Ray vs Particle Storm

Jetboard Joust Devlog #67 – Finger On The Pulse

Started on the more space-age weapons this week! Got three done which isn’t bad going I guess, I would have liked to get started on another but, as you’ll see below, I wasn’t happy with one of these and decided to start again from scratch.

I also made a couple of changes to my particle system, the main one was adding the ability to align particles left, right, up or down when they’re drawn. This has added a great deal of flexibility in designing the various particle fx which has been the bulk of the work here.

Plasma Rifle
I wanted the first weapon to be pretty close to the feel of the player’s weapon in Defender or Jet Pac (which was probably based on Defender anyway). The actual logic here is pretty simple, a beam is fired and the ‘back’ of the beam moves at a slower rate to the front. Tweaking the particle fx is what took the time and there are three different particle states here, one for the ‘head’ of the beam, one for the ‘tail’, and one for the rings that are formed around it.

I also went through several iterations of the explosion at the end of the beam, going through a bunch of ideas that looked decent but too ‘geometric’ before settling on the version you see here.

Originally I was just performing collision detection for the ‘head’ of the beam but I found this looked a bit weird when enemies moved into the tail and nothing happened to them. Now I also check to see if an enemy has moved into the tail of the beam and apply a smaller amount of damage if they have (based on the theoretical strength of the beam at that point).

Pulse Cannon
I have very fond memories of the two Turok shooters on N64 and my ‘Pulse Cannon’ is somewhat inspired by the ‘Pulse Rifle‘ in those games. It fires rapid bursts of energy with a short delay between each burst.

The mechanics of this weapon were very simple as it’s just basic projectiles moving in a straight line. Again, what took the time was getting the visuals right. here I have a sprite for the centre of the ‘pulse’ and three different particle generators, one for the ring around the pulse and two for its trail.

Spreader
The last of this batch of weapons was originally going to be based on the ‘triple blaster’ found in a bunch of ‘bullet hell’ style 2D SHMUPs. I spent almost a day going down this path and tweaking some ok looking ‘fireball’ style projectiles (well, the particles are OK, the sprites in front looking pretty lame) but, when the weapon was finally done, I was left feeling rather disappointed with the result. It just seemed rather bland and lacked anything to differentiate it from the other projectile-based weapons in the game (of which there are many).

So I went back to the drawing-board and instead engineered a weapon that creates an expanding field of energy. Even after about an hour of experimenting I could tell that this was going to be much more effective, and it was. Of course it took a long time tweaking the particles again but there’s only two different generators here so less than the previous two weapons.

I didn’t like the energy field just fading out at full ‘spread’ as I felt this looked a bit weird, so instead I made it contract back to a point which seemed to look pretty cool. The damage done by the field of energy is based on how much of the enemy overlaps the field and how concentrated the field is at that point, focussing the field at the end therefore also has implications in the use of the weapon as it means that damage done is super-concentrated at that point.

I’ll probably re-use the original ‘spreader’ bullets for a bespoke enemy weapon or something later in the game. I suspect I haven’t given up tweaking some of these effects either, particularly the plasma rifle – I like it but there’s still something that’s not quite sitting right with me. I think I may like my original version better in some respects.

Also, ‘spreader’ is a bit of a shite name for a weapon. Sound more like something you use to plaster walls or make a toasted sandwich. Must think of something better.

Dev Time: 4 days
Total Dev Time: approx 132.5 days

previous | next


The Original Plasma Rifle


The Current Plasma Rifle

mockup_3x
The Pulse Cannon

mockup_3x
The Original (Shit) Spreader

mockup_3x
The Reworked Spreader

mockup_3x
Some Gratuitous Action With The New Weapons

Jetboard Joust Devlog #66 – Out With A Bang!

Well, all the major coding on the conventional weapons is now done so there’s just a few bits and bobs before I move on to the more ‘futuristic’ weapon set.

Firstly, I had to design upgrade UI icons for the weapons I’ve added over the past few weeks. These are 32×32 icons so require more detail than the in-game sprites. I was pretty much a #pixelart noob before starting this game and don’t find this type of drawing easy, one of the reasons I went with a limited colour palette (other than liking the ‘gameboy meets spectrum’ aesthetic) was that it would considerably narrow down my options when it came to the art and thus make the drawing considerably less intimidating. I think that was a good move.

You can see the final icons here – I’m not sure, in retrospect, that a square format was the best format to choose for these as many weapons are much more ‘landscape’ in shape – particularly things like R.P.G.s, making them tough to fit in that space without them looking too spindly and weak.

The other major thing to do was add audio for the new weapons. As with the rest on the in-game FX, I designed all the sounds using the DSI Tempest. I stick mainly to the analog oscillators but also use the digital oscs for noise and (sometimes) a pure sine wave. I really love the Tempest for this type of sound design work, the eight-slot mod matrix makes it incredibly flexible, yet it’s really intuitive to use for a synth that’s so deep. Yeah, there’s a couple of things I really wish it had from a sound design perspective (individual level control over each analog osc and pre/post filter as a modulation target) but overall it’s a beast with just the right balance of flexibility and limitations.

I also used my cheapo Boss RV-100 ‘retro’ digital reverb unit and a couple of plug-ins for (sometimes fairly hardcore) compression and limiting.

Lastly, because I liked the chunky Gatling Gun bullets so much (see previous post) I’ve increased the size of the grenade and R.P.G. rocket. Also added a bit of spin to the grenade when it’s fired.

Getting the conventional weapon set done feels like a bit of a milestone so I’m pleased that’s done! next step – plasma rifle!!

Dev Time: 2 days
Total Dev Time: approx 128.5 days

previous | next

mockup_3x
Upgrade Icons For The Conventional Weapon Set

mockup_3x
Tweaking Sounds On The DSI Tempest

mockup_3x
Bigger Grenades With Added Spin!

Jetboard Joust Devlog #65 – Bullet Hell

For the last ‘conventional’ weapon in the set I’ve decided to create an old-fashioned Gatling gun.

‘What’s that?’ I hear you cry – ‘There’s already a Gatling gun in the alpha!’

You’d be right of course, but it’s bothered me for a while that the Gatling gun in the alpha doesn’t really react much like a ‘proper’ Gatling gun. It’s far too ‘polite’ and doesn’t have the all-important ‘wind up’ effect where the speed of fire starts slow but increases to ridiculously fast as you keep the trigger held. I remember particularly enjoying the Gatling gun in the underrated ‘Bulletstorm‘.

I’m still keeping the ‘old’ Gatling gun but this will be renamed ‘Uzi 9mm’ which seems more fitting for the way it operates.

Actually coding the ‘new’ Gatling gun was pretty straightforward. As usual I spent most of the time tweaking explosions and the particle effects for the muzzle flash and the bullet trail. For the muzzle flash I’m using a new geometric shader type called ‘burst’ based on offset circles. I was particularly pleased with the bullet explosions and will probably re-use this effect elsewhere in the game (maybe on a much larger scale for some real ‘oomph).

The gun gradually gets faster and more inaccurate as you hold down the trigger. It also recoils pretty badly. I’ve opted for super-big bullets which I think kind-of work (I think they’re funny anyway) even if they’re ridiculously big.

The bullets are the first time I’ve used sprite rotation in the game. I was a bit worried this would look out of keeping with the visual style (as the rotation is done at ‘full’ res rather than the game’s pixel resolution) but it seems to work fine.

So I’m pretty much done with the ‘conventional’ weapons now – just have to add sound FX for this one, the flamethrower, R.P.G. and grenade launcher.

Dev Time: 1.5 days
Total Dev Time: approx 126.5 days

previous | next

mockup_3x
The Original Gatling Gun – Now Re-christened Uzi 9mm

mockup_3x
New Geometric Shader – ‘Burst’
mockup_3x
Repeat Fire Takes A While To Get Going

mockup_3x
Does Jetboard Joust Now Qualify As A ‘Bullet Hell’ Game?

mockup_3x
Some Gratuitous Gatling Action

Jetboard Joust Devlog #64 – Rocket Science

Another day, another piece of overpowered weaponry. And on it goes…

This week’s project has been to add an R.P.G. And of course in this context that stands for ‘Rocket-Propelled Grenade’ rather than ‘Role Playing Game’.

In theory the R.P.G. is a very straightforward weapon to code. Shoot a projectile in a straight line that explodes when it hits something – job done. There’s nothing particularly complex about the mechanics of it at all.

What took the time in practice was tweaking the visuals. Because the R.P.G is a powerful weapon it needs to have a certain ‘wow’ factor attached, consequently I spent considerably more time animating the rocket’s travel and detonation than I have for any other projectile in the game.

When in flight the rocket has a spin animation and two particle generators, one that leaves a ‘thrust trail’ and one that generates a ‘flare’ at the rocket’s exhaust. For the explosions I made use of my new geometric shaders described in this post.

Another difference to other weapons is that the rocket is displayed ‘loaded’ into the launcher before it is fired. This means I have to cope with the scenario where the user is out of ammo (no rocket displayed) and also create an animation for when the next rocket loads. None of this was particularly complicated but it necessitated some changes in the way I deal with weapon attachments for the jetboard.

One area where the mechanics of the R.P.G. needed a bit of specialised treatment was in the distribution of damage when the rocket explodes. I had been working on a similar principle to the bombs and grenades in that damage would be applied equally around the rocket depending on how far away the enemy/player is. The problem with this was that, as the rocket detonates with a very powerful explosion, it was simply too easy to commit suicide by firing into a building or opponent at close range. To rectify this I created a kind of ‘safety zone’ behind the rocket. Characters positioned directly behind the rocket take significantly less damage, characters behind but above or below the rocket are still offered some protection but less so depending on how far away they are. You still have to be careful firing R.P.G.s when you’re low on health though!

Dev Time: 2 days
Total Dev Time: approx 125 days

previous

mockup_3x
Early Stages – Muzzle Flash And Recoil To Give The R.P.G. More ‘Heft’

mockup_3x
The R.P.G. Flight In Slow Motion

mockup_3x
Working On The Explosions

mockup_3x
Be Careful Using High Explosives When Your Health Is Low

Jetboard Joust Devlog #63 – Geometric Pixel Shader Tutorial

Been spending the last couple of days working on some geometric pixel shaders that I can use for various in game lighting effects to further juice up my explosions etc.

These may well be of use to others so I thought I’d get them into a serviceable state and do a mini-tutorial on their usage. OK, maybe ‘tutorial’ is too grand a word but I’ve commented the code thoroughly at least! Links to the HLSL source files for these shaders are included at the bottom of this article (scroll down).

I’m assuming the reader has a basic knowledge of HLSL – if not then there’s an excellent introductory tutorial here.

The shaders provided both draw a user-defined number of concentric shapes. The stroke width and spacing between the shapes can be set via user-defined parameters, as can the amount the spacing and stroke width increases at each iteration.

A parameter ‘multiply_increments’ allows the user to set whether the spacing/stroke width increment as applied linearly (by addition) or exponentially (by multiplication).

The supplied texture is used to draw the shapes (I often use a 2×2 white square), a user-defined tint can be applied to this.

All sizes, widths etc are calculated as a proportion of the texture size so usually between 0.0f and 1.0f though you can go larger than 1.0f if you wish some of your outer shape to be drawn outside of the texture (and therefore cropped).

Setting the shader parameters from your .net code would look something like the code below. Adjust these parameters over time to get the kind of trippy effects you see in some of the example GIFs. Maybe you could smooth these parameter changes using LERPing?

mockup_3x
Two Geometric Shaders Overlaid
Microsoft.Xna.Framework.Graphics.Effect shader = Game.Content.Load (“circles”);

// The tint that will be applied to the texture – set all values
// to 1.0 to leave the texture untouched
Microsoft.Xna.Framework.Vector4 tint;
tint.W = 1.0f; // alpha – 0.0f – 1.0f
tint.X = 1.0f; // red – 0.0f – 1.0f
tint.Y = 1.0f; // green – 0.0f – 1.0f
tint.Z = 1.0f; // blue – 0.0f – 1.0f
shader.Parameters [“tint”].SetValue(tint);

// The size of the first shape to be drawn
shader.Parameters [“size”].SetValue ( 1.0f );

// The stroke width of the first shape to be drawn
shader.Parameters [“strokewidth”].SetValue ( 0.1f );

// The initial spacing between shapes
shader.Parameters [“spacing”].SetValue ( 0.1f );

// The number of shapes
shader.Parameters [“repeats”].SetValue ( 3 );

// The amount by which spacing increases for each consecutive shape drawn
shader.Parameters [“spacing_increment”].SetValue ( 0.0f );

// The amount by which stroke width increases for each consecutive shape drawn
shader.Parameters [“strokewidth_increment”].SetValue ( 0.0f );

// Whether the spacing/stroke width increment as applied linearly (by addition)
// or exponentially (by multiplication).
shader.Parameters [“multiply_increments”].SetValue ( false );

// Adjust depending on how you’re doing your rendering
SpriteBatch.Begin (…);
shader.CurrentTechnique.Passes[0].Apply ();
SpriteBatch.End (…);

Probably also worth mentioning are the settings required to get the ‘endless loop’ effect you see in these GIFs. It’s pretty straightforward if the spacing and stroke width of shapes is consistent, but if not you need to tween the strokewidth and spacing so that they are the same for the second shape at the end of the loop as they were for the first shape at the start of the loop. It took me a while to get my head round this.

The code below shows some example values – don’t try and cut/paste this as it uses my own tweening classes and a wrapper class for the shader itself. It should be good enough to get an idea of how to set things up though…

// Initial stroke width relative to texture size
float width = 0.0025f;

// My wrapper class for the shader
shader = GeometryShader.CircleShader ();

// Used by my wrapper class – the size I’m drawing the texture on screen
shader.ScaleX = 506;
shader.ScaleY = 506;

// Set up initial spacing and stroke width for the shader
shader.Spacing = width;
shader.StrokeWidth = width;

// Spacing and stroke width will increase by 50% for each concentric shape drawn
shader.SpacingIncrement = 1.5f;
shader.StrokeWidthIncrement = 1.5f;
shader.MultiplyIncrements = true;

// Sets up the values to tween the size of the outer shape over a 30 frame seamless loop
// First two values are the start and end size
shader.TweenSize = new Tween (1.0f, 1.0f + shader.Spacing/shader.SpacingIncrement + shader.StrokeWidth/shader.StrokeWidthIncrement, 30, Tween.Linear);

// Sets up the values to tween the spacing over a 30 frame seamless loop
// First two values are the start and end spacing
shader.TweenSpacing = new Tween (width, width / shader.SpacingIncrement, 30, Tween.Linear);

// Sets up the values to tween the stroke width over a 30 frame seamless loop
// First two values are the start and end stroke width
shader.TweenStrokeWidth = new Tween (width, width / shader.StrokeWidthIncrement, 30, Tween.Linear);

And here are the actual HLSL source files. Note that I am pretty much a beginner at this stuff myself so I make no guarantees as to the suitability of this code for any purpose and I would welcome any contributions towards making it execute more efficiently.

I have plans to add more shape types at a later stage and combine these into one uber-shader that also also shapes to be combined in different ways. Watch this blog for updates…

circles.fx | squares.fx

If this is of use to you I’d welcome more followers on Twitter.

Dev Time: 2 days
Total Dev Time: approx 123 days

previous|next

mockup_3x
Two Circle Shaders Slightly Offset

mockup_3x
Square Shader With Additional Rotation Applied

Jetboard Joust DevLog #62 – Pulling The Pin

Been continuing with the ‘conventional’ weapons after finishing the dreaded flamethrower. Next one on the list – grenade launcher. Every self-respecting shooter should have one!

Thankfully this was a lot simpler than the flamethrower. A large chunk of the time was spent tweaking the grenade explosion – I wanted something that gave an ‘area of effect’ type flash and wasn’t able to do this without using a custom shader. Luckily I was able to re-use the ‘smoke’ shader I talked about here. I may tweak this some more but am pretty happy with it as is.

There were also a few issues with the movement of the grenade itself. I started with a simple ‘real world’ type physics model, the same I use for the falling pickups. This looked good but it was too hard to tweak the range for the different weapon levels and also hard to predict the range a grenade would travel for the enemy AI.

I ended up using LERPing for the horizontal movement. This meant I could predict and tweak the travel distance with 100% accuracy. When the grenade hits an obstruction LERPing is turned off and motion reverts to a ‘real world’ model.

Vertical motion remains a ‘real world’ model but I cheat a bit here as well, starting with a lighter ‘gravity’ applied to the grenade and increasing the gravity as the grenade reaches the end of its horizontal travel. This enables me to get a nice arc of travel for the grenade whilst keeping things playable and predictable for the enemy AI.

I’m still undecided as to whether I should allow grenade ‘suicide’ or only allow enemy grenades to damage the player…

Dev Time: 1.5 days
Total Dev Time: approx 121 days

previous|next

mockup_3x
Working On The Explosions

mockup_3x
Never Trust A Mutant With A Grenade Launcher!

mockup_3x
The Grenade Launcher Makes Earning Combos Easier!

mockup_3x
Remember The Martyrdom Perk In COD? Should I Allow This?

Jetboard Joust Devlog #61 – Flamethrower Blues pt. 2

Another huge lapse of time since the last update. Sorry! I’ve had my head down in contract work, been on holiday, had some private parking scammers issue court proceedings against me and had renovation work to do on a couple of rental properties. I can’t believe it’s been three months!

Contract’s over now though so back to it. I’m determined not to let ‘Jetboard Joust’ become vapourware. This post will be a bit sparse though as I can barely remember what I’ve been doing, it’s been spread over such a long period of time.

In the last post I spoke about getting the basics of the flamethrower action right. Now that was done I needed to make the flamethrower actually have an effect on enemies.

At a basic level this is very simple, I perform a straightforward ‘bounding box’ check on all the flamethrower particles and each enemy. Get the enemy to ‘burn’ in a visually convincing way wasn’t so simple though.

In my first approach I tried ‘sticking’ the flamethrower particles to the enemy once they came in contact. This just looked weird though as all the flames tended to appear in the same place rather than consuming the enemy as one would expect. It also threw up loads of other issues to do with the particles tracking the movement of the flamethrower (see previous post). After a while going down this route my code was starting to look so hacky, and the visuals were still so poor, that I decided to scrap it all and start again.

For my next approach I tried removing the flamethrower particles when they came into contact with an enemy and triggering a ‘burn’ animation instead. Even with a draft ‘burn’ animation this looked much better.

For the ‘burn’ animation itself I created a Flame class that utilised a similar particle effect to the flamethrower particles. After much tweaking I settled on the following ‘burn’ effect: whilst an enemy is burning flames appear at random locations over the enemy. Each flame has a sightly randomized lifespan. Flames may appear in front or behind the enemy, if they appear behind they are placed at the edges of the enemy so as not to be totally obscured from view. When a flame ‘dies’ it is replaced by another at a different location.

Next job was to get the enemy’s health to decrease in a way that made gameplay sense whilst the enemy burnt. I didn’t want health to decrease at the point of impact only, but for this decrease to continue as the ‘burn’ animation played out (to give the impression of the enemy’s health decreasing as they burnt).

What I ended up doing was maintaining a burn_damage variable for each enemy which stores how much it’s health should be depleted by over the course of a burn, and a burn_timer variable which stores the amount of frames the burn animation should last. When the Burn() method is called, burn_damage is increased appropriately and burn_timer set to at least 60 frames (more for very high damage values).

This approach gives a decent ‘slow burn’ effect whilst allowing me to tweak damage values easily to make gameplay sense. I also added something to make the flamethrower particles do less damage the nearer they are to the end of their lifespan.

Dev Time: 2 days
Total Dev Time: approx 119.5 days

previous|next

mockup_3x
The Finished ‘Burn’ Effect

mockup_3x
Enemy Health Depleting On A ‘Slow Burn’

mockup_3x
Flamethrowers At Dawn!

mockup_3x
The Flamethrower Upgrade Icon