Tag Archives: pixelart

Jetboard Joust Devlog #105 – Trailer Trash pt 2

Please wishlist Jetboard Joust on Steam here.

Well, the trailer’s finally done – thank God! As with the last instalment I ran into a few issues along the way and got distracted by (necessary) bugfixes. Here’s a brief summary of how things panned out…

1. Oh, Bugger!
The thing about doing a trailer is that it makes you capture and scrutinize a shedload of gameplay footage AND deviate from your ‘learned’ methods of playing your own game. The consequence of both these things is that you uncover new bugs.

I ran into a few new bugs when working on this section of the trailer, most of them related to trying out different weapon types on the bosses. The most significant of these was that there were major deficiencies in the raycasting algorithm I was using to work out damage caused by explosive weapons. Turned out I was only calculating collisions based on axis-aligned bounding boxes (fine for smaller enemies, not fine for the more complex outlines of some bosses). So I had to redo the algorithm to work properly with convex polygons.

There were also issues in the way damage was distributed via ‘proxies’ (e.g. different parts of the same boss) which had to be looked at and problems with the ‘particle storm‘ weapon which were very fiddly to debug.

2. Enemies and Weapons
The next twenty-ish second chunk of the trailer aims to give an overview of the variety of weapons and enemies in the game. I split the into eight 2.5ish edits, taking the timings from the ‘Enter The Gungeon’ gameplay trailer which seemed to pace the edits about as fast as you can get whilst still making sense of what’s going on. Managed to squeeze a brief glimpse of the weapon upgrade process in here too – I wanted to convey visually that there’s upgrade paths available for the weapons.

The edits were made by grabbing a shedload of footage and then whittling it down to the ‘best’ short segment. This was a time-consuming process. I set up levels artificially so I was only dealing with one enemy at a time – ‘real’ gameplay footage proved too confusing as there was just too much going on most of the time.

3. Bosses
The next twenty seconds or so provide a five second ‘reveal’ of the first four bosses. That’s only enough time to sneak a look at the first attack phase of each but I think that’s enough – I’m bit worried about giving too much away as it is. As with the previous stage, I had to grab a ton of footage and then whittle it down to the ‘best’ edits. I also had to bear in mind the transitions between the edits whilst grabbing the footage, i.e. make sure the player was positioned onscreen at a point where a smooth transition would be possible so the viewer’s eye never has to make a disconcerting jump. I found this was particularly important when dealing with very short cuts. I had to re-shoot a couple of edits in both this section and the last in order to get these transitions smooth.

4. Out With A Bang
Initially this section was simply a glimpse at the final boss fight but I felt that just cutting to titles after this seemed rather lame. Consequently I worked on a more ‘scripted’ take where the player flies over the final boss and then takes it out with an R.P.G. It’s not possible to do this in the actual game (the fight has about five stages) but it acts as a significantly more punchy ending to the trailer.

I had to do multiple takes of this to get it right as I needed to fly over the boss, shoot it accurately, and then position the player accurately in the middle of the screen all without doing anything visually unappealing like crash into the edges of the screen or flipping left/right too much. there were plenty of bloopers – including some where I fired the R.P.G. in completely the wrong direction.

5. Outro Titles
I ended up doing these in code and positioning them over the last section in After Effects using chromakeying. Initially I thought I’d animate them in After Effects but I just found this far too fiddly. Fortunately I was able to use the in-game logo ‘entrance’ without having to change anything much so it was mainly about animating the subheadings with the release date etc. I like the way the smoke is still dissipating in the background as the titles appear!

6. Back To The Beginning
Lastly, I went back to the start of the trailer. I was every-so-slightly over 1:30 seconds so I edited the initial titles down a bit. As some people had commented that the player appeared to come ‘out of nowhere’ a bit (I kind of agreed with this) I tried panning across to the player before going back to the alien babies/abductions. This seemed to work. I also made the player blink in this cut to bring him to life a bit (done in After Effects) and added ‘abduction’ and ‘mutation’ text with pans and zooms with the rest of the action.

Now I think we’re finally there. Next task – Steam page and assets!

Dev Time: 8 days
Total Dev Time: approx 300 days

previous | next

The Final Trailer In All Its Glory

mockup_3x
Raycasting Now Works Correctly With Convex Collision Polygons

mockup_3x
Fixing ‘Proxy’ Collision Detection Bugs

Jetboard Joust Devlog #103 – A Broader Palette

Well, I reckon this has been the longest break between devlog updates so far. I’ve had two contract jobs on, one of which turned into a bit of a never-ending spiral with the client refusing to pay me unless I kept adding additional functionality (for free). Shame, as it was kind of a nice project otherwise. I have a bit of a rule about not working for startups which I broke for that one as I knew the person involved and was interested in the concept.

I’ve also had a lot to do at a rental property I own which needed considerable TLC between tenants and which was built to a very shoddy standard. Grinding out and re-doing grouting between floor tiles in the bathroom was a horrendous job – hope I never have to do that again!

Anyway, you don’t want to hear about that shit. The bulk of the work on Jetboard Joust has been in finalising the main palettes for each of the five ‘worlds’ that comprise the game. I’m going to have four main palettes per world, plus a bunch of ‘bonus’ palettes that can be unlocked by completing specific levels.

I probably should have coded a tool to make this process easier but I just couldn’t face it when the time I had available was very piecemeal, generally half a day here and there between contract work and property maintenance! Consequently my working process was pretty inefficient, basically editing a big PNG of all the palettes in Photoshop before recompiling and running the game to see how things looked.

There are ten colours per palette in the game and the following items can all have a different palette applied (though in practice many share the same palette)

– Player
– Enemies (three types)
– Bosses
– Pickups
– Terrain
– Floor
– Background parallax (both layers)

To design the palettes I used a combination of reference material and inspiration from messing around with colour association using coolors.co and a simple colour ramp generator.

The actual palettes themselves I’ll list below and detail the specific inspiration where appropriate. These are all in the order they appear in the vids.

World One
I wanted to start the game with earthy, muted colours and then progress to more vibrant colours as the user moves through the worlds, as well as slowly introducing different palettes for different sprites. The first palette is the slightly gameboy-ish one I’ve been using from day one and I gradually add more subtle hues to this as we move on. There’s no specific inspiration for the palettes in this world though I was looking a bit at army camouflage designs for the third palette here which is currently named ‘Going Commando’.

World Two
Each of these palettes had a different inspiration, only two of them particularly related.

1. No Space To Scream
A good ‘segue’ palette from the muted colours of world one. This is inspired by the colour scheme for the branding of the original Alien movie.

2. Deep Dive
Inspired by photographs of coral reefs. As the boss in this world is a giant alien robot-fish this seemed appropriate somehow.

3. Neon Flux
Inspired by neon-heavy nighttime shots of cities, particularly Tokyo. Visually it has the feel of being a much more saturated version of the previous palette.

4. Aliens on Acid
Originally inspired by the ‘Alien’ colour scheme as was the first palette, only with colours so saturated it almost has an early arcade / ZX Spectrum feel.

World Three
We go back to a slightly more ‘muted’ feel for these palettes, all of which have their inspiration from vintage designs.

1. Stan and Jack
Inspired by the cheaply printed colours of early comic books, particularly the Marvel stuff.

2. Dead Red Revolution
Partly inspired by poster art from ‘Grindhouse’ style movies (I have a large poster for ‘Death Proof’ on the wall of my studio) and partly by the artwork for Red Dead Redemption which has a similar ‘vintage’ feel.

3. Forbidden Fruit
Inspired by a poster for the 50s sci-fi classic ‘Forbidden Planet’ – I’m really pleased with this one.

4. Retro Apocalypse
Inspired by some cover art for a 50s or 60s pulp sci-fi novel. I am not convinced by this one. It kind of works but some of the sprites just don’t. Needs more work!

World Four
All inspired by various ‘horror’ related themes! We move back to some pretty saturated colours for these ones.

1. Dead Evil
Inspired by the original posters for Sam Raimi’s ‘Evil Dead’ movie.

2. House of Hammers
Inspired by the poster art for various low-rent Hammer horror films. This is another one I’m particularly pleased with.

3. Toil and Trouble
I went for deliberately clichéd ‘Halloween’ style colours for this one. Very saturated and ‘in your face’ but I think it works.

4. Black Mass
Inspired by various different, more modern, horror film posters – as well as the artwork for the ‘American Horror Story’ TV series (which I thought was terrible and never made it past the first series).

World Five
These were mainly inspired by the manual artwork for early Atari arcade cabinets. I absolutely love that stuff and it also adorns the walls of my studio (alongside the aforementioned Death Proof poster and paintings by Basquiat and Tapies).

1. Rayguns at Dawn
Inspired by the ‘Space Duel’ manual art.

2. Planet X
I forget what inspired this specifically (oops) but I’m pretty sure it was the cover art for another vintage pulp sci-fi novel.

3. Gravity’s Rainbow
Inspired by the ‘Gravitar’ manual art. This is one of my favourite palettes in the game.

4. Prospero’s Cabinet
Inspired by the ‘Tempest’ manual art.

There’s still the bonus palettes to be finalised, I’ve done quite a few of them and there’s a lot of nods in there to 8bit home computers and consoles. That’ll be the subject of another post though! Hopefully things will move a little quicker over the next few weeks, next task is to fill in a few gaps in the audio then do a pretty much final teaser vid and get my Steam page up (I probably should have done the latter months ago).

Dev Time: 10 days (pretty broad estimate)!
Total Dev Time: approx 292 days

previous

World Two Palettes – Aliens and Oceanography

World Five Palettes – Atari Arcade Manual Art

mockup_3x
Awesome Atari Arcade Manual Art

mockup_3x
The Forbidden Planet Poster That Inspired One Of My Favourite Palettes

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 #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 #93 – Sucker Punch pt. 2

Well, I got there in time for Christmas (just)! The last boss is finally done, bar some polishing and tweaking of difficulty, and I’m extremely glad to have put this one to bed.

I ended up pulling out quite a few of the stops for this one (it’s the final boss after all) so there’s five/six separate stages to the fight and multiple different attacks and animations within each phase. The audio alone took around two solid days.

So here’s a description of each stage of the battle – I ended up switching the first stage (as described in my previous post) to stage two.

Stage One – Claws
In the first stage the Octopoid has grabby, snappy claws at the end of its tentacles which it lashes out at the player to cause large amounts of damage. It also has a secondary attack where it stops to fire mini black holes from its claws. I’m not entirely happy with the look of these mini black holes yet, that something I’m going to come back to.

The Octopoid moves pretty fast at this stage, and if you let yourself become entangled in its tentacles it can be pretty hard to break free!

To complete the stage the player has to destroy each claw – when a claw has taken a certain amount of damage it breaks off and falls to the ground. The rest of the boss is invulnerable to damage.

Stage Two – Dive Bomb / Black Holes
I wrote about this stage in the previous post so won’t go over it again here. It made sense to have the stage second as a) I thought it would look weird if the boss suddenly sprouted claws, and b) As the player is shooting at the boss’s mouth tentacles to cause damage it makes sense to have these destroyed at the end of the stage and I wanted the Cthulhu tentacles in play as long as possible!

Stage Three – Lasers
With its mouth tentacles destroyed, the Octopoid’s gnashing teeth are revealed and it begins to fire lasers at the player from the end of its tentacles. It moves pretty erratically in this stage as if it’s somewhat out of control.

To complete the stage the player must destroy each tentacle (once the end of a tentacle has taken a certain amount of damage the entire tentacle self-destructs). When each tentacle is destroyed the boss goes into a crazy spin which can be devastating to the player if they’re too close.

Stage Four – Dropping Squockets
By this stage the Octopoid is looking rather the worse for wear as it has lost all it’s tentacles. It still has plenty of fight left in it though! Its two attacks in this stage are a ram attack where it simply launches itself at the player, and the ability to spit out bubbles contain mini squocket enemies. These mini squockets are armed with rocket harpoons which they will launch at the player given the opportunity.

To complete this stage the player must keep ducking behind the boss and deal damage to its bulbous cranium. The front of the boss is invulnerable to weapons.

Stage Five – Phase Inversion
This stage is really an extension to stage four. The octopoid has lost half its skull by now, leaving its brain dangerously exposed. It still launches itself at the player in a ram attack but also spits out antimatter ‘ink’ based on the ‘Black Hole Blaster‘ weapon (which is probably going to be renamed the Phase Inverter but I’m not 100% decided on that yet).

Of course it’s the exposed brain that takes damage here and enables the player to move onto the final stage of the battle…

Stage Six – Skull Spin
There’s not much left of the Octopoid by now so it launches itself at the player in a fast and ferocious spinning attack whilst spitting out black holes as per stage two. If the player doesn’t keep moving here they will come a cropper pretty quickly as they’ll get sucked into a black hole and battered to kingdom come by what little the boss has left!

All the boss is vulnerable to damage now and, for added drama, I had it lose each eye and then its teeth as the player gradually pounds it into oblivion. Hopefully this makes for a fitting end to an epic battle!

I’ll be tweaking the difficulty of each stage considerably when I get to balancing the weapons and difficulty across the game (the next thing I’ll be working on) – I’ve nerfed the boss’s abilities quite considerably in the video so I could compress the whole battle into a reasonable space of time! Also this video (like most of them) has been blown up 150% as my computer is incapable of capturing 1280*720 at 60fps – it struggles even at this resolution. The rotations particularly look much better at the proper resolution. I need to find a solution to this for when I create my ‘proper’ promo reel.

Dev Time: 10 days (so that’s 19 days in total for this boss – groan)!
Total Dev Time: approx 237 days

previous | next

Jetboard Joust Devlog #92 – Sucker Punch pt. 1

Attack of the final boss!!!

Normally I’d cover off a boss in one blog post but a) this one is proving more complex than the rest and b) I might have some more contract work coming up (which will mean another break from gamedev) so, as I’ve now finished the art and stage one attacks, I’m just going to share what I’ve got. Working title for this one is the Octopoid.

I decided to base this boss on an octopus as octopi are pretty creepy and some scientists reckon they’re descended from aliens(!) Plus it fits with the slightly Lovecraftian feel of some of the art. I was expecting the art to be really painful but actually it all came together fairly painlessly. Though it still took a long time I never felt like I was going down endless dead-ends and just didn’t have a clue what I was doing as I did with the Snapper and the Stinger bosses. Maybe I’m getting better at this, maybe my reference material was better, probably a combination of the two.

What did take a long time to get right was the ‘mouth’. As you can see from the first example here, I originally started as a mouth with teeth which, whilst I was happy with the animation, didn’t feel quite right to me. It felt too much like a skull and not enough like an octopus. I tried replacing this with a ‘beak’ type structure similar to a real octopus but this was my one major dead-end. Even though I spent half a day or so on it it just looked like shite and I had to totally ditch that approach.

In the end I settled on a very Cthulhu-esque mouth as a collection of tentacles. This seemed to work really well. It was a pain to animate but I cheated slightly by partially recycling the animation I had already created for the Squocket tentacles.

The eyes also looked too ‘dead’ in the original art so I lightened these considerably, worked on the hypnotic effect, and also enlarged them to make them more bulbous and less like empty sockets.

By far the hardest thing to get right though were the tentacles. I based the code for these on the segments for the ‘Squirmer‘ boss but initially this approach just didn’t work (as you can see from the first image). The ‘physics’ was all wrong and the tentacles moved in far too rigid a fashion, making them look like skeletal arms rather than tentacles. It took a LOT of tweaking before I was happy with the overall movement – the final algorithm still has something of a mind of its own and is very dependent on the values ‘keyed in’. Really I should probably be tweening between set angles for each segment rather than just moving the tip and expecting the algorithm to sort everything else out, but setting individual angles for 24 segments would be very time consuming to prepare without an editor. I think the algorithmic approach is a pretty successful ‘smoke and mirrors’ compromise.

Once the art was done the next thing to do was to work on the boss’s general movement and attacks for stage one. For the general movement I have it gravitating towards a strict horizontal or vertical rotation which I think looks better, there will probably be more variation to this in later phases. It’s a big boss which makes its movement somewhat clunky by nature, I think I may need to ensure that the levels in which this boss appears don’t have buildings that are too high otherwise the battle will feel too cramped.

The boss ‘swims’ towards the player with pulse-type movements timed to coincide with the movement of its tentacles.

I ended up with three different attack moves…

Black Hole Blast
Most octopi spit ink. This one spits black holes which suck the player towards them and drains their energy. It took a while to get the black holes right – I’ve ended up with three different animated geometry shaders overlaid plus a particle effect to give the impression of debris being sucked in. In order to spit ink the Octopoid must open it’s front tentacles and leave its mouth-parts vulnerable, this is its stage one weak spot!

Tentacle Snap
if the player is positioned directly in front of the Octopoid when its tentacles are open there’s a chance it’ll dash forward and snap its tentacles in an attempt to trap the player. There’s a short ‘tell’ for this as just beforehand it’s eyes will flash and its whole body quiver. The tentacle snap attack can be devastating if delivered accurately.

Dive Bomb
If the player is in a suitable position the Octopoid attempts a dive-bomb/stomp attack whereby it rotates itself upright and then slams itself to the ground. It takes a while to recover from this and so the attack servers a dual purpose in that there’s a short time window post-attack where the player can fly above the Octopoid to reach its opposite side without damage, a maneuver which is next to impossible otherwise.

More attack stages to come – I also need to add audio for the various attacks so far as this boss seems strangely silent at the moment!

Dev Time: 9 days
Total Dev Time: approx 227 days

previous | next

mockup_3x
First Pass At The Art – Too Skeletal!

mockup_3x
Final Art With Bulbous Eyes, Better Tentacles & Cthulhu Mouth

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

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

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