Author Archives: bitbulldotcom

I have been programming games since I was about ten years old. I had my first titles, Subterranean Nightmare and (the frankly pretty terrible) Skateboard Joust, published on the ZX Spectrum when I was 15.
For the past 15 years I have been making a living developing games for mobile (feature) phones via my companies BitBull and Maturus Mobile. My games are served on all the major International operator portals, have regularly featured in the ELSPA charts and have won several Pocket-Gamer awards. In 2013 my original puzzle game ‘Puzzled Zombies’ was nominated for Pocket Gamer’s ‘Game Of The Year’ alongside entries from big players such as Namco and Electronic Arts.

Being an independent games developer is not easy. I’ve been doing this a long time yet am still tearing my hair out and learning new things pretty much every day. I still know nothing.

Get in touch via the BitBull website at http://www.bitbull.com.

Jetboard Joust Devlog #100 – Die and Try Again!

This blog should really have been Configuring Things Out pt. 2 but I thought ‘Die and Try Again’ was more appropriate really.

Now all the enemies and weapons are finally done I’ve been going back over the game worlds, playtesting and (re)adjusting all the various character/weapon stats and levelling rates. The only way of balancing the weapons is to simply play the game a lot, and if I feel I’m either avoiding particular weapon because it’s too weak, or that I’m constantly gravitating towards a particular weapon because it’s too overpowered, I tweak the stats as appropriate. It’s been a very time consuming process and I have to say I’ve been at something of a low ebb whilst doing it.

Unlike fixing a bug, you don’t ever get to the point where you think something is ‘done’, and I know I’m going to have to go through this whole process again at least one more time to refine things further before the game is complete. It’s really getting to me now.

The thing that’s made this phase so much tougher than the first configuration ‘pass’ is that I’ve been through every single boss and mini-boss fight in the first four worlds and attempted to adjust the difficulty for each. There are over fifty of these and, by nature, they are supposed to be tough, so this entails a *lot* of failure both in terms of dying in-game and in terms of setting the difficulty level either too easy or too hard.

Most of these challenges are mini-boss battles featuring the Guardian enemy and a new weapon unlock or upgrade. To maintain a certain amount of narrative ‘flow’ (and to stop me being lazy) I’m having the enemies guarding the unlocks armed with the same weapon they are protecting. The strength of the enemy is heavily dependent on the strength of the weapon, therefore a tweak to the stats of said weapon (because I think it’s too weak or too strong in-game) has a knock-on effect in every single battle that features it. It’s a cyclical process and one that I’m starting to think could go on forever, like painting the Forth Bridge. On a good day though I see it more as a kind of gradual ‘whittling down’ with every pass getting me nearer to the ideal balance.

It also makes a difference what weapons are available to the player during these battles. I was choosing these weapons completely randomly (but based on a consistent seed) though towards the end of the process I realised this wasn’t working and I needed a better balance of weapon choices. Consequently I’ve divided the weapons into four categories – long range, short range, wide range and explosive, and I make sure a balance of weapons from each category is chosen. I think I may ditch the consistent seed as well so each time you enter a level the weapon choice is a lottery, albeit a balanced one.

There’s also been a myriad of bugs and other gameplay tweaks I’ve made along the way though at this stage I’m trying to restrict myself to fixing bugs/tweaks that actually affect the balance of gameplay and noting everything else down on Trello cards for later attention. There’s currently around fifty of the Trello cards (groan) and there’s at least another ten things I haven’t noted down yet!

I’ve also been back through the first four major boss fights and made a proper attempt to balance the difficulty of these with the (rough) stats the player should have achieved by that point in-game. If you’ve been following this blog you’ll remember how much time I’ve spent on these boss fights already, so it’s been doubly demotivating having to go back to them, debug them again, run through the fight procedure again and again AND again whilst discovering yet more bugs and issues that need fixing. On a positive note though, it’s been nice to revisit them in different colour palettes.

Lastly, and I know this is going to sound like archetypal first-world moaning, I’ve been surprised how physically exhausting this process has been. Basically playing (often ludicrously difficult) boss fights for eight hours a day for eight or nine days straight takes its toll. I try to be as careful as I can be about posture but my shoulders ache, my wrists and elbow joints ache, and my back is fucked. Yes, I know it’s not exactly working down a mine, but being physically in pain doesn’t do wonders for one’s motivation. I can’t wait to finish this game and take a break from this shit.

Oh yeah – one thing that’s kept me going through this process is the fact that I can just turn the game sound off and listen to music. I’ve finally succumbed to subscribing to Spotify and have been listening to a lot of Tangerine Dream. Strange coincidence – I finally got round to watching Netflix’s enjoyable Bandersnatch interactive movie at the same time and what does that feature? A ZX Spectrum game developer slowly going insane trying to finish a game whilst listening to lots of Tangerine Dream! Weird…

Right, on to those Trello cards…

Dev Time: 8.5 days
Total Dev Time: approx 268 days

previous

mockup_3x
The ‘Spinner’ Boss In Colour

mockup_3x
The ‘Squirmer’ Boss In Colour

R.P.G. Guardians. Die and Try Again – and Again, and Again…

Advertisements

Jetboard Joust Devlog #99 – Weapons of Mass Destruction

One of the things that’s struck me whilst going through and actually playing Jetboard Joust (rather than working on individual parts in isolation) is that one of the most satisfying aspects of the game is when you get to take out loads of enemies in one go with a really destructive weapon such as the R.P.G. or Grenade Launcher.

So I decided to emphasise this side of the gameplay a little more before I finally drew a line under enemies and weapon types. I wanted to add some more ‘swarm’ type enemies and another super-destructive weapon to assist in taking them out.

Rather than work on new enemies from scratch (I really need to get this game done!!) I thought I’d re-engineer some of the ancillary enemies I’d created for the boss fights. There’s three of these, and they all fit together pretty well as a kind of ‘set’ of weird alien invertebrates – jellyfish, squid, and a kind of carnivorous worm!

Given the nature of these enemies, and that fact that they’re only going to exist in fairly large batches, I thought it would be nice to have them born from some kind of egg sack rather than teleporting into the game individually like everything else. I spent a fair bit of time working on a nice, pulsating egg sack(!) and think the end result works pretty well. The egg sack is the same for each time of enemy but I quite like the idea that you’re not quite sure what you’ll be in store for when you burst it open!

Then, just because I wanted to, I also added another enemy that’s like a really tiny version of the baiter-inspired enemy that acts as the game’s time cop. As it looks like a tiny UFO it’s also a reference to the big and little UFOs in Asteroids. These don’t spawn from egg sacks though!

The new weapon is something I’d been thinking about for some time (and even unsuccessfully experimented with a bit) but only became a solid idea after seeing the scene where Rico takes out the tanker bug in Starship Troopers (again, sorry to keep going on about that film).

I’m calling it the ‘Cluster Bomb’ – it fires a single explosive charge which splits into several smaller charges when it explodes, these smaller charges then repeat the procedure. Each charge is sticky, which means it will become attached to any enemy that comes into contact with it. The charges only detonate after a certain time period, not on impact.

As you can imagine, this weapon rapidly creates full-on mayhem. Originally I had each charge leaving a smoke trail when it explodes but, unfortunately, this was causing the refresh rate to drop when tons of charges were fired at once (by the player and enemies) so I think I’m going to have to stick to just using particles for most of the explosions. Shame, as it looked really cool with all the smoke, but I guess running all those individual custom shaders at once is asking too much. In later versions I’ve added a very slight randomness to the time the charges deonate so everything’s not quite so symmetrical, I think I prefer it like this.

I’ve also been working on a couple of new palettes. One using the (now slightly #indiedev cliché) red and black ‘Downwell’ style palette and another based on the colours available on the Commodore 64. I really like the C64 one. As I was always a Spectrum guy I’m realising the genius of whoever picked those 16 colours 35 years too late! I like the Downwell palette too but I couldn’t get it to work with visually with the background parallax so I decided to lose the background and stick with the three colours. It is retro after all…

Dev Time: 4 days
Total Dev Time: approx 259.5 days

previous | next

mockup_3x
Taking Out a Batch of Mini-Squockets with the Cluster Bomb

mockup_3x
Cluster Bomb vs Jellyfish

mockup_3x
Mass Destruction of Mini-Squirmers

mockup_3x
I Call These Enemies the ‘Little Bastards’!

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

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

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

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

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

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

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

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

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

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

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

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

previous | next

mockup_3x
Badass Bugs – Taking Out A Couple of Swoopers

mockup_3x
Mini Swooper Mayhem

Jetboard Joust Devlog #97 – Creepy Crawlies!

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

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

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

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

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

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

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

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

previous

mockup_3x
Close Up Of The Scuttler – Centipede Tribute Palette!

Jetboard Joust Devlog #96 – Splitting Up!

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

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

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

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

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

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

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

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

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

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

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

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

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

previous | next

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

mockup_3x
The Final ‘Splitter’ Design

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

previous

mockup_3x
Mapping Out The Levels

mockup_3x
Debug Output From The Auto-Levelling Code

mockup_3x
A New Type Of Minion Enemy

Jetboard Joust Devlog #94 – The Armed and the Dangerous

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

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

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

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

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

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

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

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

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

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

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

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

previous

mockup_3x
Using a ‘Bullet Sponge’ to Test Ammo Drops

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

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

Jetboard Joust Devlog #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 #91 – Global Navigation (You Are What UI)

Programming UIs is undoubtedly one of the most fiddly and tedious aspects of game development. They are frustrating to implement (it doesn’t really feel you’re working on part of the game), yet ironically they contribute a massive amount to game feel and overall user experience.

So it was with a certain amount of trepidation that I began work on the ‘necessary evil’ of implementing a map screen for Jetboard Joust so that users can view and plan their journey through the game. It’s been a good process though as it has forced me focus on some of the ‘macro’ aspects of gameplay which I have been thinking about a lot yet have never really nailed down until now.

Unlike most SHMUPs, progress through Jetboard Joust’s levels is non-linear to an extent. Levels are organised in a pyramid structure so that, on completion of one level, you have a choice of two levels to try next on the next ‘row’ (I’m calling them ‘sectors’) of the pyramid. This structure is taken directly from the ZX Spectrum game ‘The Pyramid‘ which had something of a cult following in the early 80s. It was never intentional but I’ve just realised that the player character in Jetboard Joust bears a certain resemblance to Ziggy from the ‘Pyramid’ games.

Originally I was going to have the entire game organised in one pyramid but, after a lot of thought, I decided that this wasn’t going to be practical as you would end up with a ridiculous amount of levels in each sector by the end of the game which would make finding levels that contained treasure etc overly frustrating.

Instead I am going to split the game into five ‘zones’, each of which has its own pyramid structure. Three (probably) of these zones will be directly accessible at the start of the game, the next two will need to be unlocked by gathering keys which are guarded by the game’s bosses. This is similar to the structure of the ZX Spectrum game ‘Sidewize‘ which I never played at the time (and only came across via Bitmap Books Spectrum Compendium) yet seems to have a lot of similarities to Jetboard Joust in the side-scrolling gameplay and crustacean-inspired aliens.

As the entire game world is going to end up being pretty large I needed another way for the player to navigate it other than the warp gates which simply move the player down to the next sector of the current zone. To solve this I have introduced teleports which allow the player to transport themselves to any other level which has a teleport activated. Teleports are activated by completing a level with a 100% survival rate (ie no babies abducted and mutated).

Of course, as well as designing a map screen, this meant I also had to design a teleport! I’ve tried to keep this looking like it’s from the same factory as the warp gates so the designs are pretty consistent. In retrospect I think I could have made it bigger but I’m not going to change that at the moment – it got a pretty good response on Twitter as it stands.

I’ve also added an additional cash bonus for completing a sector (an entire row of the pyramid). This gives another dimension to the gameplay and (hopefully) a reason for the player to visit more levels and stick at the game for longer. It meant I had to add a ‘sector clear’ section to the ‘Level Complete’ screen though!

The map itself wasn’t overly complex to implement, though drawing the lines that link the levels on the fly was fairly fiddly and it was also pretty time-consuming getting a zoom in/zoom out effect that looked decent. I wasn’t intending to have the map rendered at two different sizes but once I’d got the main map up and running it was clear that you needed to see things at a more ‘macro’ level when navigating between zones. I change palette as the player moves from zone to zone as well (this brought up a number of bugs in the palette-swapping code and shaders that needed to be fixed). I thought it would be good to allow a certain amount of ‘lookahead’ in the map so levels that contain bosses and/or special items are highlighted if they are within three sectors of the furthest points reached by the player.

The map can be viewed at any time via a link in the main menu and is brought up automatically when the player enters a teleport in order that they can select the level they want to travel to. I’ve spent quite a bit of time trying to ensure it feels chunky, intuitive and consistent with the rest of the game. Hopefully it’s all been worth it! The observant amongst you will still spot a few bugs in the video…

Dev Time: 8.5 days
Total Dev Time: approx 218 days

previous

mockup_3x
The Zoomed Out ‘Mini Map’ Gives An Overview of The Current Zone

mockup_3x
The Full Size Map

mockup_3x
Your Teleport Is Ready, Sir!

Clearing a Sector, Activating the Teleport, Selecting Next Level