Category Archives: Jetboard Joust

Jetboard Joust Devlog #85 – Conqueror Worm

Yes, it’s been too long since the last update. Far, far too long. This last boss has been the most time-consuming of them all, but I don’t really mind as I’m really pleased with the end result and the bosses are now (just about) finally out of the way which is an enormous weight off my shoulders!

I wanted a kind of creepy giant worm for this one. In my head it would be somewhere between the giant sandworms of Dune and the real-world creepfest that is the Bobbit worm. It ended up having a healthy dose of H.R. Giger in there too! I’m currently calling it the ‘squirmer’.

Before starting on the art I thought I’d better knock out a quick prototype of worm-type movement as, if I couldn’t get that right in code, no amount of pixel-pushing would make things look any good. I spent some time pondering how to do this and in the end settled on a very simple skunkworks physics type approach (it’s probably less than ten lines of code) which, to my immense surprise, worked out incredibly well. There’s a really nice ‘slither’ effect to the tail motion which I really hadn’t predicted at all.

To get this effect I first move the head of the worm. I then iterate through each segment in turn (from the head downwards) and see if the distance to the previous segment is greater than a specified ‘joint length’. If it is I move it towards the previous segment by the appropriate amount. I then store the amount of movement as momentum so that the next frame each segment will move according to its stored momentum as well as being pulled by the next segment along. That’s the basic principle anyway.

Once I knew I had that pretty much nailed I started on the art. It didn’t take too long to get something that had the vibe I was looking for, what did take a long time for this one was animating it. The motion of the teeth itself was fairly simple but, for some reason, getting the mouth to look right around the teeth whilst it was opening and closing was tricky. I ended up having to make the whole head expand and contract slightly. For some masochistic reason I decided I should try making the whole mouth rotate (it just seemed as if it should do this) but the process of splitting everything out to get this to work ended up being extremely fiddly and time-consuming. I think it was probably worth the effort though.

I also spent a long time dithering over eyes. I went through multiple options as I felt it needed something ‘eye like’ for character, but everything I tried looked too cartoony or fish-like. At the end of the day it just seemed creepier without any eyes at all so I stuck with just simple antennae.

The tentacles at the side of the head also took a while. It felt like I needed something here and I tried a number of things (including extending jaws like the Bobbit worm) but none of them really did it for me. The tentacles seemed to work OK but, again, they were difficult and time-consuming to animate.

The segments didn’t take too long to get right though I was quite a while on the larger segments that ended up loosely based on the spiny shells from Super Mario.

To get the ‘glow’ effect for the segments I have a duplicate sprite in a much lighter colour palette. This is placed behind the ‘normal’ sprite and I vary the opacity of the ‘normal’ sprite’. It took a fair bit of tweaking before I was happy with this effect.

Once all the art and basic movement was done (around eight or nine days in) I could finally start on the attacks. There are three phases to the battle, in each phase only the tail segment is vulnerable so the squirmer must be destroyed one segment at a time until only its head remains. As each segment disappears (and when it moves to the next phase) its movement gets faster.

Stage One
The squirmer spits out eggs which, once they hatch, spawn mini carnivorous worms that move very fast and attack the player.

Stage Two
The squirmer uses an ‘extending mouth’ attack inspired by H.R. Giger’s Alien. These ‘extending mouths’ both attack the player and serve to defend the squirmer from the player’s attacks.

Stage Three
The ‘extending mouth’ attack become more powerful, the mouths are larger, more aggressive, and have a greater range. They also shoot laser beams.

The ‘extending mouth’ effect is based on the same code for the tail of the main boss but with adjustments made for tethering the tail to a fixed point. It took a fair bit of tweaking for this to look right but I think it seems fairly convincing now, or as close as I can probably get anyway!

I added a few a new audio effects, a sound for the squirmer’s teeth gnashing and rotating, firing eggs, eggs hatching, and a new laser sound which I’m particularly pleased with. As with all the sounds, these were created on the DSI Tempest.

Oh yeah, I’ve also finally added some bigger explosions and a special ‘boss’ explosion. I spent about a day on explosions alone as I’ve also created smaller ones to give more variety between the various enemies.

OK, I think I’ve gone on enough now. Next I have to go through the bosses (the first two mainly) checking a few things and making a few improvements – then I’m done with this and on to what should be the final major gameplay addition!

Dev Time: 11 days
Total Dev Time: approx 196 days

previous

mockup_3x
Skunkworks Physics – Tail Motion Proof of Concept

mockup_3x
The Eyes Don’t Have It

mockup_3x
Finally – The Art Pretty Much Done
mockup_3x Extending Mouth Attack Inspired By HR Giger

Advertisements

Jetboard Joust Devlog #84 – Along Came A Spider…

I’m pretty resigned to the fact that these bosses are going to take me ages now, and the fact that I’ve finally come to this realisation weirdly makes the process of creating them considerably easier to deal with. Also I think I’ve made all the edits that the code needs to cope with enemies with multiple ‘hit spots’ and the like so I’m no longer having to go back and rework old code, this alone makes the process considerably less frustrating.

So, whilst this one took me knocking on six days and was still really hard work it felt like the easiest of the lot. I think a large contributing factor to this was the fact that the art came together really quickly (I was done in just over a day) and I feel much more in my comfort zone when I’m coding rather than pushing pixels.

I based the spider’s head and abdomen on ‘real’ reference material, though I also referenced much more stylised representations. I took the layout and proportion of the legs from a robot spider image I found somewhere on the net but changed the look and feel completely to fit in with the overall game style.

Animating the legs, mandibles and abdomen was done in code. This wasn’t difficult but was extremely time consuming as there’s so many moving parts (24 leg sections) which, as MonoGame is pretty ‘raw’, all have to be lined up and connected manually by working out pixel grid references and such. This is a pain in the arse – I guess engines like Unity and Unreal have ‘drag and drop’ tools that make this type of process much easier but generally I don’t like the bloat and overhead that comes with those types of tools and prefer the fact that MonoGame is pretty low level.

I’m calling this enemy the ‘spinner’ and it has three attack phases…

Stage One
In this stage the spinner is attached by a web strand to the top of the screen. It tracks the player very fast horizontally when in its ‘retracted’ state or attempts to divebomb the player when the player moves beneath it. This is the only way to get it to expose it’s fleshy, pulsating abdomen which must be destroyed in order to move to the next stage. When it hits the ground after a divebomb attack it spits out a burst of fireballs.

Stage Two
With its abdomen destroyed the spinner detaches from its web and begins to chase the player very aggressively. At regular intervals it will fire off bursts of a triple laser beam. In order to move to the next stage the player must shoot off all of its legs – its head and body are invulnerable until this happens.

Stage Three
Now legless, the spinner alternates between a mad spin attack in which it fires off a single laser at increasing speed, and a kamikaze style attack where it attempts to ram the player (its mandibles do a lot of damage). All of its body parts are now vulnerable to attack.

Generally I’m really pleased with this boss. There’s still something about the ‘lightbulb’ on its abdomen in stages two and three I’m not sure about so I may rework this but generally I think all the attacks are working pretty well, just need to be balanced in-game properly. I even had some time to add some custom audio for the lasers and fireballs, still need to go back and add this for the other bosses.

And I still need to add boss-sized bones and explosions!

Dev Time: 6 days
Total Dev Time: approx 185 days

previous | next

mockup_3x
The Final Art With All 24 Moving Leg Joints

Battling The Spinner – All Attack Stages In Action

Jetboard Joust Devlog #83 – Somethin’ Fishy Goin’ On…

God, these big enemies are hard!

I thought six days on the last one was extreme but this one has taken me pretty much eight full days. Probably over 50% of that time spent on the art. Basically these have pretty much morphed into ‘miniboss’ type creatures with multiple attack patterns (and in this case even spawning smaller enemies) which was never my intention but I feel like I have to kind of go with the flow. I am really struggling with motivation now though, this project is dragging on and on and ON and to be spending so much time on one thing at this late stage is extremely demoralising. I need to be earn some sodding money. Enough of my moaning though…

I decided to make this enemy a giant deep sea fish as deep sea creatures are weird, alien and creepy looking and have already been used for inspiration on some of the other enemies such as the squocket. My main source of inspiration was a fish called the fangtooth which seemed to have the right balance between looking weird and dangerous whilst maintaining an iconic fishy shape. I’m calling it the ‘snapper’.

Creating the basic shape in pixelart wasn’t too difficult and I didn’t go down nearly as many dead-ends as I did with the stinger so the process, whilst just as time-consuming, wasn’t nearly as frustrating. Most of the time I always felt like I was making progress. The scales were the hardest part to get right – it’s large area to cover and it’s tough to get the balance right. Not enough detail and things look flat and boring, too much detail and things look too ‘photographic’ and don’t gel with the rest of the game’s style. When the scales were defined as a simple filled pattern they looked too ‘flat’, like I’d obviously filled a stencilled area. If I applied too much shading to them they almost looked too ‘3D’ and ‘realistic’. In the end I offset the scales based on a pattern of concentric circles to give a slightly rounder shape to the body, limited myself to three different scale tones and didn’t allow a change of tone within an individual scale. This took forever but it finally seemed to give me the right degree of detail whilst maintaining a sense of stylised simplicity.

I thought the teeth and gills would be hard to draw but actually those parts came together really quickly, as did the ‘skull’ for the zombie attack phase. The spikes on the spine were rather more finicky and still need a bit of tidying up.

The other reason this took so long was that collision detection on an enemy of this size gets rather more complex. When I began work on the game I didn’t have ‘boss’ type enemies in mind so assumed I could implement a simple ‘one size fits all’ collision detection system. Unfortunately this doesn’t cut it when you have enemies that are complex shapes, some areas that act as ‘hot spots’ for damage, and other areas that you may want to collide with the player but not actually take damage themselves. I needed to find a way to allow for all this whilst avoiding having to go back and redo old code (particularly checking all the weapons again).

In the end I came up with a ‘CollisionProxy’ class. A CollisionProxy is spawned from a parent (the main sprite) and will both take and inflict damage on behalf of its parent (or not depending on the configuration). It also renders with a custom shader in sync with its parent when taking damage. Any sprite can have any number of proxies. So far this system seems to work well and I’ve hardly had to change any of my core code to implement it.

There’s also polygon-based collision detection on this enemy. Up until now I have been able to get away with simple rectangle-based collision detection. Thankfully I had already implemented SAT-based collision detection for convex polygons when I first ported my game engine to MonoGame so I had no extra work to do there – Thank God!! I think trying to add something like that at this stage would probably have killed me!

In its final(?) incarnation the snapper has three attack phases…

Stage One
Tracks the player fairly slowly. Unleashes either an aggressive charge/snap attack or spawns electric jellyfish from its mouth. Its jaws do more damage than the rest of its body and it will only take damage if you fire directly into its mouth (this was a PITA to implement collision-wise).

Stage Two
Loses its flesh and becomes a steampunk zombie fish. In this mode tracking of the player is faster and it’s two mounted ‘shredder‘ weapons are armed and fully dangerous. You need to destroy the engine mounted on its side to proceed to the next phase.

Stage Three
Now on its last legs (if it had any) the snapper tracks the player very quickly. It’s only defence at this point is a very aggressive kamikaze charge attack.

And that, at last, is it. Painful, but I think it was probably worth it. I’ve had some of the best feedback for the game so far from some of these images on Twitter. There’s still a few things I’m not 100% happy with. Art-wise the final phase needs some more engineering where the engine used to be and I might try getting rid of the eyeball on the zombie skull and replacing with a more skull-like eye socket. The second phase is also a bit weird – at the moment the whole enemy can take damage but it recharges until the engine is destroyed (so there’s a separate health meter for the engine). This is confusing. I should probably have the main enemy not take damage at this point and only have a health meter for the engine.

The difficulty will need some tweaking but I’ll have to do that in the context of the game more. Generally, I must admit, I am not a big fan of boss fights as they are often done so badly. In my opinion a good boss fight should seem ridiculously tough at first but be relatively straightforward once you’ve worked out a strategy. You shouldn’t die before you’ve even had a chance to get a decent look at the boss and it shouldn’t be a schlep to get there on every retry either. Though I thoroughly enjoyed both Dark Souls and Demon Souls to the point of obsession I found the ‘rinse and repeat’ style run to the bosses immensely tedious. I gave up at the final boss on both games because of this – life was simply too short! The bosses in this game will be optional and protect hefty rewards/upgrades rather than blocking your progress in the game.

I also still need to add some larger explosions befitting an enemy of this size!!

Dev Time: 8 days
Total Dev Time: approx 179 days

previous | next

mockup_3x
Fours Days Of Pixel-Pushing In Fifteen Seconds

mockup_3x
Fun With Collision Proxies

mockup_3x
Entering The Zombie Phase

Whoops – I Accidentally Added Boss Battles!

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

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