Category Archives: Uncategorized

Jetboard Joust Devlog #98 – Not *That* Kind of Bug!

Onto the last of the ‘classic videogame’ enemies now, this one draws its inspiration mainly from the wonderful ‘Space Invaders’ style shooter ‘Galaxian‘ and, to a lesser extent, its sequel ‘Galaga’. It’s also heavily inspired by my recent re-watching of Paul Verhoven’s marvellously cheesy Sci-Fi gorefest ‘Starship Troopers’. I’m calling it the ‘Swooper’!

I’d been thinking of doing a Galaxians-style enemy for some time but it was watching the ridiculous (but genius) scene in Starship Troopers where Rico takes out the tanker bug that really cemented the idea in my head. A similar bug would fit perfectly into the Jetboard Joust world and also really suit the ‘Galaxians’ style of attack.

So I started by working on the basic movement style which was really very simple, I use LERPing to rotate the enemy towards the player whilst applying a constant velocity in the direction the enemy is currently facing. This worked fine once I’d tweaked the parameters, resulting on a nice circling motion of the enemy round the player which I felt was quite insect-like.

What was more complex was to get the enemies flying in formation. My standard approach to this kind of problem, and one I also used in this case, is to create a ‘hive mind’ class that manages the positioning of all the enemies. The individual enemies can report back to the ‘hive mind’ with various info regarding their environment but it’s the hive that tells them where to position themselves.

I tested a number of different algorithms for this – the one I ended up with allocates a leader for the hive who operates effectively as a solo entity with the movement pattern I described above. The hive mind calculates the ideal positioning of the other enemies in the swarm and I use LERPing again to move them towards this ideal position as well as to rotate them to align with the leader’s current rotation.

If certain parameters are met some of the swarms member’s will go solo, leaving the pack to chase the player in a more aggressive manner. The hive mind class manages this to make sure the entire swarm doesn’t break up at once.

I was particularly pleased with the way the swarm reorganises itself once one of its members is destroyed or goes solo to chase the player!

The art for this enemy came together very quickly (for a change) – I used the tanker bug from Starship Troopers as my only reference and it just kind of worked! The thing that took longest was getting the rotation of the wings to line up properly when the bugs are in flight. My only slight worry with the art is that I’ve used very dark colours – this makes it look pretty badass most of the time but it might be too hard to see clearly in some palettes.

I was so pleased with the way this enemy came together that I added a smaller version, the Mini-Swooper! This operate in exactly the same way as the larger version only more of them can leave the pack at once and they don’t fire at the player, they just attack them physically. They are also faster.

As a footnote – until looking it up just recently I was always convinced that ‘Galaxian’ was called ‘Galaxians’. It actually freaked me out a bit it was called ‘Galaxian’! Must be one of those collective false memory things like being convinced the Monopoly man wore a monocle!

Dev Time: 2 days
Total Dev Time: approx 255.5 days

previous | next

mockup_3x
Badass Bugs – Taking Out A Couple of Swoopers

mockup_3x
Mini Swooper Mayhem

Advertisements

Jetboard Joust Devlog #97 – Creepy Crawlies!

No prizes for guessing the classic arcade game that’s the inspiration for this latest enemy – yup, it’s another of Atari’s masterpieces – Centipede! Working title for this enemy is the ‘Scuttler’ (I already have a ‘Crawler‘ and a ‘Squirmer‘)!

The mechanics of this enemy are pretty simple, I thought the hardest thing to get right would be the algorithm that makes the segments ‘follow’ the head (I’ve had to right similar code in the past and got myself into a right mess) but the code I came up with, unbelievably, worked pretty much right of the bat!

There’s probably a better way of doing it but my basic approach here is to ‘remember’ the direction each segment is travelling and to continue moving in that direction by default each frame. If the total horizontal and vertical distance between one segment and the next is less than the desired segment spacing no movement occurs. If the segment aligns horizontally or vertically with the segment in front we switch orientation (i.e. from horizontal to vertical or vice versa). This seems to work well enough for my purposes but if anyone has any better ways of doing this I’d be interested to hear them as it’s a gamedev problem I seem to run into quite a bit.

Unlike the Atari Centipede I don’t have any mushrooms to run into to initiate a change of direction so I had to improvise a bit here. Changing direction when it hits buildings was an obvious one, but I also have it switch direction when it hits the edge of the screen (i.e. camera area) and, with a certain amount of leeway, when it aligns with the player on the opposing axis. This approach seems to maintain an authentic ‘Centipede’ feel whilst working within the confines of the Jetboard Joust gameplay.

I also added a slight ‘sway’ to the segments as they move as a fixed horizontal or vertical movement just seemed too ‘static’ in context even though it would have been truer to the original game. I want to tip my hat to these classics rather than slavishly replicate them.

Of course I also had to have the centipede splitting into two when it’s health is reduced which means things can get pretty manic (in a good way, though I’ve toned it down a bit since this video as things were getting too out of hand too quickly).

I’ve also been working on a Centipede style retro arcade palette but have been running into a few issues trying to get this to look good across all sprites. The red outline you can see is used on some of the sprites in the original arcade game. I like the way it looks here as I designed the sprite around it but it looks terrible on many of the sprites I’ve already designed so I think I’m going to have to use a more generic approach. If I ever make another game I’m going to make sure I treat my outline colour as a completely separate part of the palette – lesson learned!

Dev Time: 2 days
Total Dev Time: approx 253.5 days

previous

mockup_3x
Close Up Of The Scuttler – Centipede Tribute Palette!

Jetboard Joust Devlog #96 – Splitting Up!

Bit fed up with parameter tweaking, so before I finish the final first round of config by going through the treasure chamber guardians and bosses I thought I’d try and get the final non-jetboarding enemies wrapped up.

There’s going to be three of them in all I think, and I’m pretty keen to have each of them be a mini-homage to a classic arcade game, much like of already included one to Space Invaders. First up is Asteroids and an enemy I’m tentatively calling the ‘splitter’.

Originally I had imagined this enemy being a kind of giant jellyfish that split into smaller versions of itself when attacked, but then I happened across the first Starship Troopers movie whilst late-night channel surfing one evening.

It’s a pretty good movie and I haven’t seen it for ages so I ended up sticking with it to the end, and whilst watching it occurred to me that the theme of humans battling off waves of attacks from an insectoid alien race (often with fairly ‘conventional’ weaponry) wasn’t too far removed from Jetboard Joust!

I also thought that the gelatinous ‘brain bug’ at the end of the movie would work very well as an enemy that could split into smaller versions of itself so I used this as the inspiration behind my designs for the ‘splitter’. I drew inspiration partly from the movie and partly from an illustration I found from a 1970s board game version of the book which was simpler and more comic-like.

Rather than try and draw the entire enemy as one piece of art I wanted to build it from smaller components so I could easily make versions at different sizes. First off I created a pulsing body. I tried a number of different versions of this and ended up using a variation of the segments from the ‘squirmer‘ boss. The segments all pulse at the same rate with but start from a randomised offset.

I then added a series of eyes based on the eyes from the ‘spinner‘ boss and a mouth based on the mouth from the mini worms that the ‘squirmer’ gives birth to. It took a while to get the placement of the eyes right, the end result heavily references the movie ‘brain bug’.

Once I was happy with the general placement of the eyes and mouth I needed to make them feel part of the pulsing body as, when simply placed statically they looked far too ‘stuck on’.

I ended up linking each facial feature with a body segment and changing the location of that feature based on the current scale of that segment. This seemed to work pretty well in giving the impression that the features and body were joined rather than overlaid layers.

Enemy movement, as in Asteroids, is very straightforward as – a simple linear motion with a reflective bounce when an obstruction is hit. What was slightly tricky was deciding what to do when the enemy left the camera area. Originally I had it wrapping immediately to the other side of the camera (true to Asteroids). This was kind of cool, and I really liked the fact it was true to its roots, but unfortunately it made the gameplay way too intense – particularly when other enemies were encountered at the same time. I didn’t like the way it made the scanner look broken either.

So I tried simply having them wrap when they reach the edge of the game ‘world’ but this wasn’t intense enough and kind of dull. Eventually I settled on a halfway house between the two, if the enemies are offscreen or nearing the edge of the screen a decision is made as to whether the quickest route to the player is to travel in the same direction or to reverse direction (I take world wrapping and the current player velocity into account). The enemy switches direction (or not) based on this. This keeps the gameplay intense as things tend to cluster round the player but it still makes sense within the overall gameplay paradigm – and it doesn’t make the scanner look like it’s broken.

Something else I’ve been doing which has taken up at least a day of this dev time is working on a ZX Spectrum themed palette and improving some of my palette code. I can now have three different palettes for enemies as opposed to just one. Whilst doing this I discovered some bugs in my palette shaders which were particularly apparent when dealing with 100% RGB values as are used in some of these retro palettes, these are now fixed.

Dev Time: 4 days
Total Dev Time: approx 251.5 days

previous | next

mockup_3x
The Brain Bug from the 1970s Starship Troopers Board Game

mockup_3x
The Final ‘Splitter’ Design

Asteroids-Style Wrap Logic – Too Much Mayhem / Broken Scanner!


The Final ‘Splitter’ Alongside Other Enemies – ZX Spectrum Palette

Jetboard Joust Devlog #95 – Configuring Things Out pt. 1

This is one of those devlog entries that seems kind of dull because there’s been a lot of ‘under the hood’ type goings on and not a lot of eye-candy to show for it.

But, it’s taken time and it’s really important to the game’s development so I’m going to blog it anyway, boring or not!

What I’ve been focussing on is the overall structure of the game world and how difficulty progresses throughout the game. At this stage it has been very much a first pass at this, as much about providing the tools to allow me to tweak gameplay efficiently as it has been about balancing the gameplay itself.

I’ve broken down what I’ve been doing into three key tasks:

1. Code Refactoring
As with any game of significant scope, there are multiple interconnected parameters that affect gameplay difficulty in Jetboard Joust and it’s a hell of a lot easier to tweak things if the code that manages these parameters is in one place rather than split across a myriad of individual class files. Consequently I’ve set up a static ‘Config’ class that contains all the algorithms and configuration parameters for pretty much anything to do with rewards and difficulty throughout the game. This has involved a lot of tedious cut and paste but I know it’ll be worth the effort in the long run (it already has really). I’ve set up generic parameters here for the amount things like enemy health and weapon damage/difficulty scale throughout the game so at least I have a baseline to work with and can tweak individual scaling from there if necessary.

2. Mapping
I’ve created a template in InDesign for mapping out levels in each of the game worlds and have been through this with a first pass attempt at placing weapon unlocks and new enemy ‘reveals’ in each. There seems to be enough content to fill four level ‘pyramids’ of around twenty rows each with a reveal rate of a new enemy or weapon every couple of rows. I need a couple of different ‘non-jetboarding’ enemy types but was expecting that anyway, I added an additional jetboarding enemy to span the difficulty gap between the ‘minion’ and ‘master minion’ which was fairly simple to do. I may make the fifth and final world smaller, probably ten rows, with the final boss right at the end.

3. Auto-Levelling
In order to be able to arbitrarily test game difficulty I need to be able to jump to a particular level and have an idea how the player might have ‘levelled up’ at that point. What weapons will they have unlocked and how powerful will they be? What will their base health be? It’s not straightforward to figure this stuff out so I ended up writing an algorithm that takes a destination point within the game pyramid, figures out the location of each treasure chamber before that point, then does a mock play though of the game to unlock each treasure item. On the way I collect the cash that would be awarded for defeating enemies, rescuing babies, and completing ‘sectors’ (rows of the pyramid). Once cash is earned it is spent on the most expensive upgrade available.

It took quite a while to test this code and get it working but it’s going to be invaluable for testing as I can now start the game at any point and have the player ‘levelled up’ as appropriate. Using this code I can also monitor things like how long it will take to level up a particular weapon, how much a player might earn for completing a level at the point weapons are unlocked (hence what a sensible starting price for updates might be) and all sorts of other stuff I haven’t even thought of yet!

4. Basic Gameplay Testing
Using the code above I began going through the game to check and tweak parameter scaling at key points (i.e. the ‘reveal’ level for each weapon and enemy) to make sure things seemed sensibly balanced. Unsurprisingly they were way off to start with but after much fiddling I’ve reached the point where relationships at least seem workable, haven’t done the treasure chamber guardians and bosses at all yet though.

One thing that became apparent was that weapons that are unlocked earlier in the game need to have a greater number of upgrade levels than ones that come later on, otherwise they either ‘max out’ too quickly and end up becoming useless on high level enemies or they cost far to much to upgrade in the early stages. This was particularly apparent with the default weapon (the pistol) so I ended up adding a new default weapon (the .45 magnum, essentially a pistol on steroids) which is unlocked about halfway through the game and has enough grunt to take the player through to the end of the game.

I also ran into a shedload of bugs, it’s been ages since I looked at many of these enemies/weapons so there’s a ton of small issues created by various changes I’ve made. Fixed a bunch of them as I went along (partly why this phase took so long) but I’ve still got a very long TODO list in Trello!

Dev Time: 6 days
Total Dev Time: approx 247.5 days

previous

mockup_3x
Mapping Out The Levels

mockup_3x
Debug Output From The Auto-Levelling Code

mockup_3x
A New Type Of Minion Enemy

Jetboard Joust Devlog #94 – The Armed and the Dangerous

So far this year I’ve been focussing on weapons and the weapon unlock/upgrade mechanic in preparation for doing the wider gameplay and difficulty balancing. I’ve broken this down into three key areas…

1. Ammo Drops
It became clear whilst testing the bosses that the way I was calculating ammo drops was flawed and I needed a better method. The method I eventually came up with is simpler than its predecessor, works far more effectively and should ‘scale’ automatically as weapons are upgraded and the player faces enemies that soak up more ammo. For each weapon I now work out the maximum amount of damage that can be done to any enemy from a clip’s worth of ammo (the amount contained in a single ammo drop). I then scale this amount based on the accuracy of the weapon in question (weapons that have a lower accuracy scale down more as one must assume that not every shot will hit its target). Once the player has dealt out damage to any combination of enemies that exceeds the resultant ammo refresh rate a new ammo drop is awarded. It’s important to record the damage dealt as the amount of damage that would be dealt if the enemy had infinite health, otherwise enemies that are destroyed by the attack score too little and this can really skew the system.

To test this I set up a ‘sponge’ enemy that does nothing but takes loads of damage and tried out all the different weapons on it in turn, tweaking the accuracy scaling and checking the method I was using to calculate the max damage per clip was correct on each one. This was easy for weapons that simply fire bullet-style projectiles but more complex for weapons like the flamethrower. For ‘area of effect’ style weapons like the grenade launcher, RPG and sonic boom I can only really approximate an idea of maximum damage.

Whilst in the process of the above I got pretty distracted re-working the shotgun blast effect as it still didn’t seem to give an accurate indication of the blast’s area of effect. This is the third time I have re-worked this(!)

2. Weapon Switching
To date the player has only been allowed to carry one weapon at a time. If the currently armed weapon runs out of ammo they were automatically switched to the default weapon (pistol) which has infinite ammo. If they wanted to arm a more powerful weapon again (pretty much guaranteed) they would have to pick one up from a weapon crate AND find an ammo drop to recharge it should it have run out.

I decided this mechanic was no fun and therefore, according to the Scott Rogers principle, had to go. Now I am allowing the player to carry two weapons at once – the default weapon with infinite ammo and a (generally) more powerful secondary weapon. If the secondary weapon runs out of ammo the player is switched automatically to the pistol as before but this time all they need to do to recharge it is collect an ammo drop. The new mechanic seems to feel much more natural and fun to me, though I’m a little worried it might give the player the opportunity to over-exploit powerful weapons but we shall see…

As an adjunct to the above I also implemented a key to switch weapons so that the player can switch to the pistol if they want to save ammo on powerful but understocked weapons such as the RPG.

3. Weapon Unlocks
Previously, in order to unlock a weapon, the player had to catch the jetboard of an enemy that was armed with it. This worked OK, but it was a bit easy and I didn’t really think it made a big enough deal of the weapon unlock process.

I’ve decided instead to have weapon unlocks as a type of treasure. Rather than being guarded by a boss, the treasure chambers that contains these weapon unlocks will be guarded by a fleet of enemies armed with the weapon in question. This enables me to make more of the treasure chamber mechanic, adds another layer to the gameplay, and also allows me to use the big ‘weapon upgrade’ icons (which I was rather pleased with) in-game as pickups.

It didn’t take me long to design these ‘guardian’ enemies but I spent a fair bit of time on implementing some special AI for them. Firstly I enabled them to swoop down and steal the player’s health pickups to heal themselves (I may allow other enemies to do this once the reach a certain level), and secondly I implemented a special ‘wrap attack’ whereby if a bunch of them have been chasing the player in the same direction for some time a few will take advantage of the world wrapping by peeling off and heading in the opposite direction to meet the player head on!

The video demonstrates unlocking the shotgun by defeating a small fleet of enemy guardians. They’re pretty tough opponents – as you can see I had to rely pretty heavily on the jetboard attack here and was pretty lucky managing to take out three of them in one go!

Dev Time: 241.5 days
Total Dev Time: approx 4.5 days

previous

mockup_3x
Using a ‘Bullet Sponge’ to Test Ammo Drops

mockup_3x
Enemy AI Now Enables Them To Steal the Player’s health Pickups

Unlocking The Shotgun – Note The Guardian’s ‘Wrap Attack’ Technique

Jetboard Joust Devlog #86 – Bosses Defeated!

At long bloody last!!

Finally finished all the boss battles – well, I say ‘all’ but I do have an idea for a fifth but I’m not going to add that until the rest of the game is complete (if I do at all).

Looking back through my files I started this process on the 13th March, so that’s around 2.5 months of elapsed time. It used to take me that long to bang out an entire J2ME game! No wonder it’s been doing my head in. There’s been the blogging as well of course, and preparation of GIFs etc for Twitter, plus a couple of bank holidays and (unlike most indie devs) I’m determined to maintain a sensible work/life balance so I only allow myself to work on this four days a weeks (otherwise I’d go completely nutso). Still, I think that’s far too long by anyone’s standards. Ironically though, despite the fact that I’m probably at the lowest-ebb I’ve been motivation-wise throughout this ridiculous project, in these bosses I’ve completed the work I’m probably most proud of throughout.

So this last week or so I’ve mainly been tweaking the first two bosses, the Stinger and the Snapper, to make them live up to the standard of the last two. When I started this process I had no intention of creating boss fights – these were just going to be ‘normal’ enemies (only larger), but as time went on I just had to admit to myself – ‘Face it, these are boss fights and you should approach them as such’. Consequently I needed to go back to the first two and approach them with this mindset.

1. The Stinger
This battle only comprised of two stages so I felt I had to add a third stage to make it consistent with the others. I added a second stage attack whereby, once the stinger’s abdomen is destroyed, it reveals a hive that unleashes a swarm of mini-stingers to attack the player.

To create the swarming effect I have a HiveMind class that is basically an invisible sprite that either tracks the player or returns to the boss. The individual creatures always swarm around this central point in an offset eliptical motion which looks random yet somehow predictable.

I also added audio for the various attack stages and made a bunch of code changes under-the-hood to make the way things were structured consistent with the other bosses (this was my first boss so some of the code was pretty hacky as I worked out the best approach to do things).

Oh yeah, I also now have the boss’s creepy legs get shot off one at a time in the third stage for added drama!

2. The Snapper
I spent quite a long time on this one as I just wasn’t happy with the ‘rhythm’ of the gameplay in the second and third stages. The motion and attacks were too clumsy and the ‘shredder’ weapon fired in the second stage was pretty much impossible to avoid which made the whole fight feel too random.

So I completely pulled apart the AI for the movement and improved it considerably, including adding a ‘reverse’ attack which I think plays out pretty well. I also swapped the shredder weapon for limpet mines which are can be shot or avoided by the player.

In the third stage I improved the exposed ‘brain’ animation considerably and turned this into the boss’s weak point for said stage (this seemed too obvious an opportunity to pass up). I also added another attack for this stage where bubbles containing strange fossilised plankton creatures are fired from the boss’s ‘exhaust pipe’.

Finally I added audio for all the various attack stages.

3. General Testing
Then I went through all the bosses testing them against the Flamethrower and Gravity Hammer weapons as these operate rather differently from the other weapons.

The Gravity Hammer particularly is a right pain in the arse as it affects the motion of any enemy it touches, effectively taking control of an enemy for a short period of time. As I never really planned for this properly when I structured my initial code it leaves things open to some nasty bugs. Oh well, lesson learned!

I also made sure each enemy and mini-enemy has an appropriate icon on the scanner (not really happy with the stinger one – looks too much like an aerosol can), added an obvious ‘hit’ effect for when the player takes damage by touching a boss, and finally applied some explosions worthy of such giant enemies.

Thank God that process is over!

Dev Time: 6 days
Total Dev Time: approx 202 days

previous | next

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