Category Archives: Uncategorized

Jetboard Joust Devlog #78 – Return of the Evil Mothers

Too long since the last update. Had a lot of shit on – decided to fight a parking ticket issued by one of those fascist private parking companies and it ended up in court. I beat the tossers but it took so much time preparing the defence and everything I’m not sure if it was worth it, just did it on principle really as I don’t like scammers or bullies. Turns out these scumbags didn’t even have the right to operate on the land on which the ticket was issued in the first place!

Anyway, back on topic, the first major ‘new’ enemy is actually an ‘old’ enemy redone, but I don’t think there’s any shame in that. If you’ve been following this for some time you may remember the ‘Evil Mother‘ enemy. Well, I’d come to the conclusion that this enemy just wasn’t big enough and would work better (and make more sense) as some kind of mini mothership that spilled out its occupants when destroyed.

So I spent quite some time designing a kind of ‘bathysphere’ type craft. It’s actually several different sprites in one, the ship itself, the pilot, the ‘antennae’ on the top which acts as a weapon, plus the various lights. I’m pretty pleased with the result though a little worried it looks a bit too ‘2D’ and could do with some more shading or something to make it appear more ’rounded’.

I also increased the size of the enemies that spill out when the craft is destroyed and spent quite some time working on a much improved bullet that tracks the player’s movement in a similar way to the Limpet Mine. There’s also a ‘tell’ that the ship is going to fire as you can see the antennae at the top charging up.

The shaking effect is achieved by applying an offset to the ships position each frame. These offsets are always evenly distributed and chosen at random so it’s a very predictable type of brownian motion.

I think I’m going to use the original enemy design as more of a ‘swarm’ type enemy with a movement type that’s an homage to the original Space Invaders!

Dev Time: 3 days
Total Dev Time: approx 159 days

previous

Advertisements

Jetboard Joust Devlog #76 – It’s All Relative

Sometimes with code you just have to pick it all apart and start again – and that’s exactly what I’ve been doing for the last day and a half.

Like its main inspiration ‘Defender’, Jetboard Joust has a game world that ‘wraps’, ie once you leave one side of the world you enter at the other – a bit like Pac Man in his maze with the difference that, as the camera is permanently fixed on the player, the effect isn’t so immediately obvious.

To date I’ve been using the obvious approach to this, an approach that I’ve always used when coding this type of game. When the player leaves one side of the world the horizontal size of the world is added or subtracted to/from the player’s location and they appear at the other side. It’s straightforward in principle, seems to make logical ‘sense’, and for the most part works.

But there’s always been these little niggles when gameplay occurs around the area where the world ‘wraps’ and I’ve found myself writing lines and lines of code to circumvent issues to do with drawing (particularly some particle effects), collision detection, and AI. Most of these problems have been solvable without too much hassle but I kept thinking ‘there must be a better way…’.

Then, for no particular reason, a light bulb went off and I had the idea of dealing with wrapping relative to the player rather than to the world itself. In this scenario the player never ‘wraps’, their location just keeps increasing or decreasing as they travel in one direction, but if anything else in the game world finds itself more than half a world width away from the player the width of the world is added/subtracted to/from its location to position it on the other side of the player.

Whilst this method doesn’t really make logical ‘sense’ (static objects like buildings are jumping all over the place in the game world) it actually works much, much better in practice. The real beauty of this system is that if any glitches do occur due to the sudden jump in location caused by wrapping, they happen way off screen so the player is never aware of them – and as fast-moving objects such as projectiles, particles etc only really appear close to the player wrapping code can be completely omitted for these items.

Implementing this was a major change for the game engine and I proceeded very gingerly at first, making sure I preserved the ‘old’ method of doing things in case I needed to switch back, but it soon became obvious this was the right way to go. Various minor bugs have been completely eradicated and I was finding myself able to comment out large swathes of code. Debugging at the ‘wrap point’ is now pretty much a non-issue! I’ve eradicated a fairly major development headache in preparation for working on the enemies.

Dev Time: 1.5 days
Total Dev Time: approx 153.5 days

previous | next

mockup_3x
A Trip Round The World As Seen On The Game Scanner

mockup_3x
One Of The Vast Swathes Of Crap Code I Was Able To Dispense With

Jetboard Joust Devlog #73 – Hammer Action!

At last – the final weapon is done! If I think of a cracking idea for another one I might add more but I set myself the task of designing sixteen from the outset (seemed like a nice binary number) and this is #16!

This one’s called the ‘Gravity Hammer’ – much like the ‘Black Hole Blaster’ I didn’t really have much of an idea what I was after from the outset so was pretty much making this up as I went along.

The name comes from a weapon in ‘Halo’ that I came across when searching for weapon ideas – I’ve never played Halo but had a quick look at some footage on YouTube and the Halo version seems to be more of a melee weapon, like a massive axe or something. This isn’t what I wanted.

My version fires a kind of massive ball of gravity that sends anything it comes into contact with plummeting downwards with extreme force. It does damage not at the point of contact, but when the ‘hammered’ enemy hits the ground.

It took a while to code as, not only did I have to worry about the weapon visuals (which were pretty complex) but also the effect the ‘hammer action’ would have on other game sprites. I thought about having the ‘hammer’ just do damage when it made contact and skipping the ‘smashdown’ effect but I’m glad I went through with it as it’s really satisfying in practice. It’s particularly amusing when you have to hit an enemy several times as it looks like you’re playing basketball with them or something!

The visuals are comprised of three key elements. There’s the ‘gravity ball’ itself which consists of concentric eight-pointed stars drawn using my geometry pixel shader, a trail of particles left behind by the ball as it travels, and a larger ‘mandala’ type pattern which is actually a series of concentric six-pointed stars spinning very quickly so it looks like a more complex shape. There’s also another trail of particles left by the ball as its first ‘fired’, two particle effects for a ‘muzzle flash’, a simple animation for the barrel of the weapon when it’s active, and another particle effect for a kind of ‘pulse trail’ when the sequence is over. Altogether fairly involved, but as it was the last weapon I thought I’d go to town!

I also add a six-pointed star when the ‘gravity ball’ comes into contact with an enemy to exaggerate the ‘smash’ effect, a particle trail of ‘speed lines’ as enemies are smashed downwards, and the ubiquitous screenshake to make things seem more visceral.

You’ll see on some of the GIFs that the action swings ‘up and back’ first. This is how I originally had it as I was thinking of hammer throwing in the olympics. Twitter user @Sky_Armada helpfully pointed out that this seemed a bit arse-backwards so I tried it the other way and he was right! It feels much more natural and ‘hammer-like’ travelling downwards first.

At the moment I have this weapon destroying explosives and projectiles when it comes into contact with them, though it flips the affiliation of explosives (so one’s that would destroy the player now destroy enemies and vice versa). I’d like to add the ‘smash’ effect to explosives and projectiles too, or maybe reverse their direction or something? That’s on the ‘nice to have’ list though.

Next step is to do the audio and ‘upgrades’ pixel art for all the futuristic weapons, then I can get on with adding some more extreme enemies.

Dev Time: 2.5 days
Total Dev Time: approx 146 days

previous | next

mockup_3x
The ‘Final’ Visuals With A Downwards Smash

mockup_3x
Having A Smashing Time

mockup_3x
Playing Basketball With Your Enemies

Jetboard Joust Devlog #71 – (Black) Hole In One!

This was the first weapon that I really didn’t have much of a clue what I was going for when I started it and, ironically, it’s probably turned out to be the one I’m most pleased with!

When I set up the placeholder for this one ages ago it was called ‘Storm Bringer’ and I had an idea it was going to involve some kind of ‘particle storm’ type effect, a bit like those fireworks you get that fire out a ton of different sparks that go off in different directions.

However, I’ve already changed the ‘Spreader‘ weapon to be called ‘Particle Storm’ and, as that now does something very similar to what I intended this weapon to do, differentiating this weapon proved difficult.

I tried a series of variations with a bunch of particles moving in a constrained and stuttery ‘Brownian Motion’ type manner but this all looked shite and, to be honest, given that I’ve done so many of these weapons now I was beginning to feel like I was running out of ideas and motivation.

Then came a random source of inspiration. In my very skunkworks home studio I have a rack for audio gear that I’ve cobbled together over the years from various shitty pieces of Ikea furniture and stuff. In an attempt to make this more uniform (as nothing matched and my workmanship was so terrible) I covered the entire piece with Jack Kirby art from a bunch of old Spiderman and Fantastic Four comics I had as a kid.

On one small section of this there’s an image of a character disappearing into a kind of black hole, the image is drawn in negative and looks really striking. I had vaguely considered a weapon called ‘Black Hole’ (though I was worried it would be too similar to the ‘Sonic Boom‘) so I decided, largely out of desperation, to try switching the particles I was using to very dark circles with a light outline. I thought this would look ridiculous but, to my surprise, it actually looked kind of cool!

It’s not a single black hole though, so I hit upon the concept of a weapon that fires a series of mini black holes that suck the life force from enemies. Stephen Hawking would probably turn in his grave but I liked the idea. I’m calling it the ‘Black Hole Blaster’ which, thankfully, just about fits in the space I’ve reserved for weapon names in the HUD!

I worked on this ‘negative space’ effect some more, adding a layering system to my particle code so that I could draw all the white outlines ‘behind’ the black circles, this gave the effect of a unified black mass with a white outline which looked much better than a bunch of circles overlaid. As usual there was a lot of tweaking and messing around here (I didn’t really have any point of reference for the effect I was trying to create other than that one comicbook panel) but I’ve ended up with something I think works.

There’s five layers of particles in the final version two sets of black circles with light outlines (one smaller than the other) and the concentric circles you see overlaid which (I think) help to give the impression of some kind of black hole rather than simply black smoke. It was difficult to get these concentric circles subtle enough to suggest ‘black hole’ without overwhelming things, I had to do a lot of messing around with the frequency and distribution of them. It’s possible that I’ve erred to much on the side of caution and could do with a few more of them. It does look a bit like some kind of weird satanic flamethrower but I don’t think that’s necessarily a bad thing!

Lastly, whilst working on the collision detection (which was very straightforward) I thought it might be a nice touch if these mini black holes exerted a small gravitational force, actually sucking enemies towards them. This was pretty fiddly to code, and my initial version was ludicrously powerful, but it did seem to work and help to differentiate this weapon nicely from some of the others.

So I think I’m pretty much done with this one now. I’m really pleased with it, both in the way it looks, but also for the fact I’ve never seen a weapon quite like it in any other game (though some smartarse will no doubt point one out to me)!

Only two weapons left to go!!

Dev Time: 2 days
Total Dev Time: approx 140.5 days

previous | next

mockup_3x
The Jack Kirby Panel That became My Inspiration

mockup_3x
An Early Draft Of The Weapon

mockup_3x
The Final(ish) Version

mockup_3x
Too Much Suction!

mockup_3x
Black Hole Dogfight!

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

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

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 #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 #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?