Jetboard Joust Devlog #82 – A Sting In The Tail!

To say that I’m glad to be finished with this next enemy would be something of an understatement. It’s been painful. I knew these more elaborate enemies would be time consuming but this one has caused me all sorts of headaches and I’m really, really sick of it. So sick of it in fact that I’m not even sure whether I’m pleased with the end result any more.

I started out with a plan to create a kind of ‘robot/alien wasp’ type creature called a ‘stinger’ and it was fairly straightforward to knock up a version with placeholder art, splitting the creature into three separate sprites for head, thorax and abdomen that could move independently. Getting the final art right though was an absolute nightmare. I think this was due to a number of reasons…

1. Wasps are very dark, consequently reference photos were very unclear on detail. Also creating a dark sprite that stands out from a dark background with a very limited colour palette is tough.

2. Insects in general are pretty ‘fiddly’ creatures. The things that distinguish their character are actually pretty small and/or spindly which make them very hard to render in low resolution. I found the legs particularly hard and gave up trying to render mandibles as whatever I did they just looked like a beak.

3. One of the things that characterises a wasp is (obviously) the stripes on their abdomen. These are hard to render at low resolution as angled stripes just look too ‘jaggy’ and going for straight stripes just makes the abdomen look like a boiled sweet, too cartoony and not ‘creepy’ enough.

I started off trying to make the sprite look too realistic, relying too much on reference photography. I then went down a complete ‘robot’ path, trying to create a creature partly from sprites that I’d already designed (mainly the ‘upgrade weapon’ icons). This had potential but was too bitty and I felt going full-robot lacked the creepiness I was after (never go full-robot)! Things only really started together when I sketched out a very stylised wasp by hand and went for an approach that was 50% ‘real insect’ and 50% ‘steampunk’. I stuck with very stylised angles where possible and this seemed to work, particularly on the legs which I was having massive problems with (I ended up separating these out as individual sprites). I reckon I was 3.5 days on the art for this alone.

Thankfully coding the movement wasn’t too problematic, AI is very simple but seems to work nicely. The gamma-ray that it fires from its ‘sting’ was a bit of a pain in the arse as I had to redo my original gamma-ray code to cope with being aimed at an angle, this meant I needed to use raycasting for the collisions. Fortunately I could reuse code from the ‘shredder‘ weapon but still, this was non-trivial due to my lack of foresight in the way the original gamma-ray was implemented!

There’s a two-stage attack pattern whereby the player must destroy the creature’s abdomen first. At this point the creature becomes faster, more aggressive, and starts to spit poisonous space-venom! The venom-spitting effect is created with particles.

I still need to add some custom audio and maybe work on the explosions a bit more (these ones don’t seem bit enough and bigger enemies also need bigger bones!) but, for now, this one is finally done. Six bloody days!!!

*** edit *** ….and, I’ve just realised when I grabbed this video that I had immunity on the player for debug purposes (groan). That’s why the enemy’s attacks aren’t doing any damage!! I need a break!

Dev Time: 6 days
Total Dev Time: approx 171 days

previous

mockup_3x
Abandoned First Draft – Too ‘Realistic’

mockup_3x
Abandoned Second Draft – Too ‘Mechanical’

mockup_3x
Third Draft – Still Sucks But Finally Heading In The Right Direction

mockup_3x
Almost Final Version – Later I made The Abdomen Pulse

Using Various Weapons To Take Out A Stinger

Advertisements

Jetboard Joust Devlog #81 – On A Roll!

In the late 1970s, when kids played with proper toys rather than tablets and smartphones, there was this marvellous toy called ‘BigTrak‘. I always wanted one, but they were way too expensive to buy and probably cost around £10k per year in batteries. I’m sure the reason there’s so many SUVs on the roads today is that all these 40-something-yr-old men are buying them as some kind of mid-life BigTrak substitute. I still think the BigTrak design looks pretty cool even today.

This enemy, the ‘crawler’, was very much inspired by BigTrak, but it wasn’t just a nod to seventies nostalgia. At the moment gameplay seems to gravitate very much towards the top of the screen and I wanted something other than pickups to take the player closer to the ground and amongst the buildings. A ground-based enemy seemed the logical choice to do this.

Usually I’d work on the art first but in this case I thought I’d run a few code tests first to see if the ‘tank’ type enemy I had planned had any kind of hope of succeeding. Maths is not my strong point, and as this vehicle would have to perform the impossible feat of traversing vertical slopes and 90° changes of gradient I needed to make sure it wasn’t going to look like arse before I wasted loads of time on the art.

To my surprise my initial tests worked very well. There’s no ‘physics’ at play here, the wheels (working independently) simply traverse the outer edge of the terrain in the most basic way. I then work out the angle between the wheels (i.e. the axle) and place and orientate the chassis based on this. It’s not physically ‘correct’ by any means as the distance between the wheels changes depending on the terrain but, as it’s performing impossible feats anyway, I didn’t think this mattered – I could get away with a telescopic axle! In the final version I added something to make the wheels roll more nicely around corners but other than that I stuck with my first approach, I made a couple of attempts to make things more ‘realistic’ but both ended up looking worse than the original.

Satisfied that I could make this work I then began work on the art. There were two keys things I had to bear in mind here. Firstly, the design needed to be such that the distance between the wheels could change without looking ridiculous as described above, and secondly that the vehicle could travel in either direction. I think you can get away with simply flipping sprites for left/right when they’re small but with larger sprites like this that approach can look pretty ropey.

At first I was working on a ‘tank’ type idea that was similar to BigTrak. I spent several hours on this but wasn’t happy with anything I came up with. Everything looked too clunky or too much like a motorbike. So I started experimenting with some radical changes and in the ended settled on a kind of armoured ‘push me/pull you’ design that I felt worked much better. It’s a complex affair though, the final unit comprises eleven different sprites, so getting these all lined up and positioned correctly was a very fiddly business!

Getting the guns to track the player was also fairly tortuous as one has to consider the rotation of the vehicle as well as the previous rotation of the gun to make things work smoothly. People with more of a maths brain probably find this stuff easy. I don’t, but I got there in the end.

The AI wasn’t simple either. For individual vehicles it’s pretty straightforward, but when they appeared in batches I was getting issues (as with the Squocket enemy) of them overlapping too much. In the end I created a ‘hive mind’ class that acts as a controller for a bunch of vehicles. This class works out the ideal positioning of each vehicle and then the individual vehicles track to this position.

Lastly I have the pilots of the vehicle man jetboards and make a last-ditch attempt to attack the player when their vehicle is destroyed. There’s a specific class for this type of enemy too (I’m calling it the Kamikaze) but it’s pretty much one of the basic minions with tweaked parameters.

EDIT: Aaarggh – I thought I was done but whilst working on some screengrabs for this post I ran into a hideous bug to do with the world wrapping (remember I talked about that here?). I was getting all sorts of problems caused by the vehicle wrapping at a different time to any of the buildings it was in contact with. Very difficult to find a solution for this so in the end I’ve settled on a bit of a hack whereby the vehicle stops moving if it’s very close to the edge of the world. This seems to work OK and I don’t think it will be too obvious in practice.

So, the most complex enemy to date but I’m pleased with the end result. I think I only really need a couple more like this and I can move on…

Dev Time: 4 days
Total Dev Time: approx 166 days

previous | next



Abandoned Art Direction – ‘Tank’

mockup_3x
The Finished Design – ‘Push Me/Pull You’

Guns Tracking Player And A Nicer Rolling Action Round Corners


Using A Variety Of Weapons To Dispatch Two Crawlers (Enlarged 150%)

Jetboard Joust Devlog #80 – Squid’s In!

This latest enemy was inspired by the rockets in ‘Scramble‘, the other seminal side-scrolling shooter (along with ‘Defender‘) that defined the genre for me in the early days and paved the way for the likes of Nemesis, Salamander, Gradius, and all that came after.

I didn’t want to have bog-standard rockets though. Every other enemy in the game is humanoid to a degree (when I do have spaceships etc there’s an obvious humanoid pilot). I feel this imbues them with much more personality – so I began working on ways to ‘humanize’ a rocket.

I was thinking about Tomohiro Nishikado’s original sketches for ‘Space Invaders’, which were in part inspired by aquatic life like jellyfish and crabs, when I hit upon the notion that giant squid are not only very rocket-like in form but also have great Cthulhu overtones which links in to some of the other art in the game (the Mutants in particular).

So I decided to name this enemy a ‘squocket’ – a cross between a squid and a rocket. What I didn’t consider though was how much of a bastard those tentacles would be to animate! The main animation took me the best part of a day and is probably the most fiddly piece of pixel art in the game so far. I’m pleased with the end result though, I decided to make the animation symmetrical because it was simpler and also felt more ‘Space Invaders’ that way.

There’s also an idle animation as the squockets wait for the player to approach. This is much simpler but still took a while finding a nice way to make it loop. In the end I decided on a five frame ‘back and forth’ animation for this.

The movement of the squockets was pretty easy to code – I work out the angle between the squocket and the player and ‘lerp’ towards this. What I was finding was that multiple squockets began to overlap after a while (often almost exactly aligning) which looked pretty daft, so to counter this I started polling the player’s position only around four times a second and adding a certain amount of randomness to the polling time, this has pretty much alleviated the issue though I may work a bit more on this – maybe adding a ‘ram’ attack or something.

I also had to deal with squockets becoming ‘stuck’ on the side of buildings if there was a building between them and the player. To solve this I have the squocket rotate upwards if it hits the left or right of a building and to a horizontal position if it hits the top of a building. This seems to enable them to find their way around pretty well. I did play around with a ‘lookahead’ sprite placed a certain distance in front of the squocket and using this to navigate around buildings but this approach almost worked too well (they would avoid buildings so effectively that the player could hide too easily).

Lastly I gave them the ability to fire (I actually re-use the bullets from the original ‘spreader’ weapon) and added a simple ‘tell’ animation prior to firing.

Dev Time: 2 days
Total Dev Time: approx 162 days

previous | next

mockup_3x
The Main Squocket Animation

mockup_3x
Squockets At Rest

Jetboard Joust Devlog #79 – Space Invaders

In my last post I wrote about maybe recycling the old ‘Evil Mother’ enemy into something based on the classic ‘Space Invaders‘ aliens, and that’s exactly what I’ve ended up doing!

I like the idea of including a few homages to the classic arcade shooters of yesteryear in Jetboard Joust, and as ‘Space Invaders’ was really the granddaddy of them all it’s an obvious choice. I wasn’t sure whether the formation/movement of the invaders would work within the horizontal/scrolling format of Jetboard Joust but, with a few tweaks, it actually seemed to work out pretty well.

It wasn’t too tricky to code either. I was worried that get the whole batch of invaders to move together around buildings and stuff would be a pain but it was pretty straightforward in the end.

What I do is move all the invaders as a batch rather than treating them as individual sprites. Collision detections are still handled individually and, when an invader collides with a building, it sends a message back to the batch telling it to change direction. When the batch is initiated I make sure it doesn’t take up more vertical space than the space between the highest building and the top of the screen so I know it’s never going to get stuck.

Probably the trickiest thing was deciding how to treat a batch of invaders when attacked by the ‘Gravity Hammer‘ weapon. Moving the whole batch at once would just look dumb so I needed a way of having individual enemies break formation when hammered and then return to the appropriate position once they recover.

To achieve this I have a property for each invader that stores its location within the batch separate from its position on screen. If the invader is forced to break formation it is relatively simple for it to return to its batch position. Though it wasn’t strictly necessary I also decided to have individual invaders track horizontally with the batch even when hammered (so only their vertical position is displaced). It just seemed to look better this way.

In keeping with the original I have the invader’s speed and rate of fire increase as individual invaders are destroyed.

Dev Time: 1 day
Total Dev Time: approx 160 days

previous | next

mockup_3x
Admit It – You’ve Always Wanted To Play ‘Space Invaders’ With A Flamethrower!

Using The Plasma Rifle To Dispense With A Batch Of Invaders


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

Jetboard Joust Devlog #77 – Keeping Your Enemies Close…

Been working on some new jetboarding enemies over the past few days, so around a day of pixel-pushing and a day of coding with the extra half day fixing bugs caused by the new ‘world wrap’ technique I described in my previous post. I’ve also been rejigging my sprite sheets so the art used for the jetboard and weapon attachments is duplicated on the enemy sprite sheet (fewer spritebatch calls to the GPU needed and should also make things easier if/when I add alternate colour palettes).

Fortunately new jetboarding enemies are relatively simple from a code point of view as a much of their ‘personality’ is defined by tweaking parameters already present in the AI. I also have a fairly decent template for doing the animations now too. Here are the new enemies that have been added, names are just codenames really so may well change…

1. The Master Minion
This is really just a bigger, stronger, and slightly more dangerous version of the omnipresent ‘minion’, the game’s cannon fodder. They’re quicker to snatch your babies away and mutate too!

2. The Ninja
Small, fast, light, very aggressive, but also pretty weak. This guy is very dangerous and performs a ‘pincer movement’ around the player really frequently making him a tough opponent to deal with.

3. The Aggressor
This guy is strong, fairly nimble, and very aggressive when you rile him but he’s actually pretty dumb and will let you sneak up behind him and get in the first shot. A bit like some of the knights in ‘Dark Souls’ (well, kind of)! You can tell which way he’s facing by looking at the scanner. This enemy required some custom AI work.

4. The Thug
This guy is very big and strong and takes a lot of ammo to dispatch. He’s pretty slow though, and not the brightest lamp on alien street either. I was particularly pleased with how the art for this one worked out.

5. The Snatcher
All this guy cares about is stealing your babies and trying to mutate. It’s like he’s a kind of half-mutant already and is desperate to finish the job. He’s a bit of a coward and will actively try and avoid the player unless directly engaged – watch him though, as he’ll snatch away your progeny and mutate really quickly if you don’t keep an eye on the scanner! This enemy required the most custom AI work.

This brings the total of enemy types to 12, I think I’m going to try and bring it closer to 20 and want to add some ‘miniboss’ type enemies with much larger sprites. few more smaller ones to do yet though…

Dev Time: 2.5 days
Total Dev Time: approx 156 days

previous | next

mockup_3x
The Master Minion – Upgraded Cannon-Fodder

mockup_3x
The Ninja – Fast And Dangerous

mockup_3x
The Aggressor – You Won’t Like Him When He’s Angry

mockup_3x
The Thug – Strong But Easily Outwitted

mockup_3x
The Snatcher – A Devious Coward

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 #75 – A Farewell To Arms

At last – weapons are done!

This past few days has been 50% pushing pixels and 50% working on shaders for the weapon effects I decided I wasn’t really happy with.

For the grenade launcher I designed a new grenade as I felt the old one was really pretty shite in the cold light of day. Instead of a more ‘traditional’ type of grenade I went for something that looked a bit more sci-fi and this seemed to work better right off the bat. I probably only spent about half an hour doing it (if that) which is ridiculous compared to the amount of time I spent tweaking the previous version. You can see the original here.

For the plasma rifle I felt the old effect was too overblown so went for something rather simpler using a shader rather than particles. The new effect is just one sprite drawn with a custom shader that renders a fade with a low ‘bit depth’ to look pixelated. It also draws small gaps between the (imaginary) pixels. I much prefer the result and it’s considerably more akin to the player’s weapon in Defender which is what I was going for. You can see the original here.

The particle storm (originally ‘spreader’) is a weapon that’s caused me much pain and grief. The original effect (which you can see here) wasn’t bad at all but I felt it seemed a bit clunky compared to the other weapons, too pixelated or something. The new version adds a new sprite at each frame which is drawn with a custom shader to give a blend effect, there’s also some particles that decay very fast at the front of the ‘beam’. To be honest I’m still not 100% satisfied with this but I think it’s much better than the original. I’ll probably come back to this (yet again) at a later date but for now I’m parking it. It’s in the right ballpark now at least.

The pixel-pushing I had to do was drawing version of all the ‘futuristic’ weapons for the upgrade screens. I really don’t have clue what I’m doing with this type of pixel art and the process often feels akin to a monkey trying to write Hamlet by bashing out random keys on a typewriter. It might have been easier if I’d have sketched the weapons out by hand first, the fact that I had no real point of reference for what they should look like made things even harder!

I’m pleased with the end results though I think. The particle storm is maybe still a bit weird (that weapon’s been a bastard to get right all round). I’m also a bit undecided about the pulse cannon – it looks fairly badass in most respects but there’s something about it that reminds me of whale(!) which I don’t really like.

I’m particularly pleased with the gamma ray and sonic boom but in some respects these were the easiest as I was referencing common retro sci-fi tropes.

Dev Time: 3 days
Total Dev Time: approx 152 days

previous | next


The Newly Designed Grenade


The New, Simpler, Plasma Rifle Shader Effect


The New Particle Storm (Why Is This One Such A Bastard To Get Right)?


Pixel Art For All Weapon Upgrades

Jetboard Joust Devlog #74 – Hit Sounds!

For the past few days I’ve been completing the audio for the new ‘futuristic’ weapon set. It’s been quite a task, only eight weapons but over thirty sound files in all including variations.

The process has been the same as for the bulk of the Jetboard Joust audio. I do everything using hardware, most of which is analog, and then some final processing (limiting, eq, compression) in Logic Pro. Very occasionally I’ll add some additional fx using plug-ins (pitch-shifting and saturation were used here), and sometimes I’ll end up layering two different sounds in Logic when I feel a sound is ‘almost there’ but just requires a little extra.

Once the sound is done I then import it into the game to get the level balance right and then either back to Logic for some final tweaks or, sometimes, right back to the drawing board if things really aren’t working in context. Though I was always watching a GIF of the weapon in question when designing, sometimes when you hear it in-game it just doesn’t work. Sounds that are overly reliant on bass frequencies are often particularly problematic as they can clash with the background music and are low in perceived volume (see Fletcher Munson).

Overall this process seems to work well for me. The hardware is fun to tweak, has tons of analog character, and seems to provide the right balance of flexibility and restrictions. If I tried doing the same thing in the digital realm with something like Native Instruments Komplete for example (which I own) I would just get bogged down with all the options.

The key piece of hardware I’m using for this project is the DSI Tempest – a six voice, multitimbral synth/drum machine. It has two analog and two digital oscillators. For this project I’m tending to restrict myself to the analog oscillators but will sometimes use the digital ones for noise samples.

For the hardware fx I’m limiting myself to the four aux sends on my mixing desk. I use a Roland RV-1000 digital reverb, a JHC DX-77 digital delay (both picked up really cheap on eBay), and an Echolution2 Ultra Pro delay pedal. I have a distortion unit on the last send which I switch between the awesome Malekko B:Assmaster and a Waldorf 2-Pole analog filter.

I don’t use any bitcrushers or anything like that. I’m going for a sound that’s pretty much a full-on aural assault in the way I remember Defender being but trying to create that vibe through distortion and the overall timbres used rather than restricting sample rates and bit depth. The result is a kind of hi-fi/lo-fi hybrid.

Dev Time: 3 days
Total Dev Time: approx 149 days

previous | next

mockup_3x
Some Of This Gear Was Abused, None Of It Was Harmed

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