Jetboard Joust Devlog #89 – Visual Aids!

For the past week or so I’ve been working on sorting out a few visual things that have been bugging me. I’ve also been busy with contract work and work on a rental property, and it’s been unbearably hot and the window is my office has jammed shut – this is why thing seem to have been moving slowly. Actually the coding has been going pretty fast when I’ve found time to do it and I feel like I’ve been zipping along compared to working on those damned bosses!

Anyway, here’s what I’ve been up to…

1. Scrolling Improvements
One things that’s been really annoying me has been a slight ‘judder’ to the scrolling of certain items. The more observant of you may have noticed this in some of the previous GIFs. It was obvious on some of the pickups and sometimes in the way the ground moved in relation to the buildings. There were a number of reasons for this…

Firstly, I had built the ground as a layer of parallax rather than an object in the world itself. This was dumb. I’ve transferred the ground tiles to actually be part of the world and move with the main game camera.

Secondly – rounding errors. This had me scratching my head for a while but I eventually figured out that the way the game scaled was the cause of the problem. I scale up all the game graphics based on the size of the screen and calculate their positions at full resolution (for smooth movement). As I position sprites from their centre point this meant that, if the scale size was an odd number AND the size of the sprite was an odd number you end up with a sprite of odd dimensions which is never going to be positioned consistently with a sprite of even dimensions (as positions always have to be rounded to an integer for display onscreen). The solution to this was to ensure that all sprites that can be positioned stationary on the ground have even dimensions.

Thirdly – rounding errors part 2! When sprites came to rest they would often land at some fractional x position which would lead to a similar problem as I’ve described above. The solution to this was to ensure that sprite positions are rounded to integers when they come to rest. This has no visual effect (as they’re rounded to integers for drawing anyway) but it makes for solid-looking scrolling.

2. Impact Shader
What seems like an eternity ago now I added a ‘judder’ effect along with camera shake to give a more visceral quality to explosions and collisions. This effect was causing performance issues on some machines (as it required the entire screen to be re-rendered twice with a custom shader) plus I was never entirely happy with it. See the original effect here.

Recently I made changes to the way buildings are rendered so that they are pre-rendered to individual offscreen images rather than being rendered ‘on the fly’ as tiles. This enabled me to create a ‘judder’ effect by rendering the individual buildings with a custom shader rather than the entire screen. It also meant I could change the offset of the effect subtly per building based on the epicentre of the explosion/collision. It looks better and should perform considerably better too.

3. Smoke
Again, what seems like an eternity ago, I added a smoke effect which I always felt looked a little too ‘high res’ for the rest of the art style and was also causing a few performance issues on some machines. You can see the effect here (I usually turn this off for recording GIFs as it overloads the GIF compression).

I’ve redone this smoke effect. Each smoke cloud is now rendered in one pass (rather than a separate pass for each ‘particle’ in the previous method). The particle positions are calculated on the CPU (trivial) and passed to the shader each frame.

This enables me to give a ‘posterizing’ effect, ie reducing the amount of alpha levels where the smoke particles overlap. I can also render at a size consistent with the rest of the art and scale up to draw on screen, plus I’ve added a pseudo ‘dither’ effect for more lo-fi goodness. I’ve also got a lot more flexibility now for adding smoke clouds of different sizes.

I liked the previous effect but I think this one is much more in keeping with the overall art style.

4. Burst Geometry
Wasn’t intending to do this but, in the process of rationalising all my shader FX into my ‘mother of all geometry shaders’ I realised I hadn’t covered the ‘burst’ effect that I use for the muzzle flash on the gatling gun. So I felt obliged to sort this out, then I realised there were problems with the algorithm so I had to change the algorithm, then I had to add proper fades, cropping and looping to it. I also sorted out memory management for the geometry shader sprites (as I’m using them a lot now) so that they’re pooled as opposed to being created and destroyed each time.

Dev Time: 5 days (bit of a guess, I kind of lost track with a lot going on)
Total Dev Time: approx 214.5 days

previous

mockup_3x
Scrolling Without The Jiggle

mockup_3x
The New Impact Shader

mockup_3x
A More Suitably Lo-Fi Smoke Effect

mockup_3x
New ‘Burst’ Geometry Shader
Advertisements

Jetboard Joust Devlog #88 – No No Fun!

There’s a section in Scott Rogers’ (pretty good) book on game design, ‘Level Up‘, where he talks about removing the ‘no fun’ from games. I’m paraphrasing here but essentially what he says is that if you identify the parts of your game that aren’t any fun and remove them, what you’re going to be left with is pure fun.

It’s a simple notion that almost sounds facetious but it actually makes an awful lot of sense, so this week I’ve been identifying a few things about the gameplay in Jetboard Joust that I don’t find any fun and figuring out ways to remove them.

1. Collecting Pickups
Though it’s an integral part of the game, constantly having to ‘land’ to collect pickups was proving to bit a bit of a chore. It would often lead into crashing into buildings by accident, getting stuck, losing momentum etc, all of which were no fun. Basically the game is generally too fast paced to allow for movements that require a lot of accuracy and I have to keep focussed on the core of the game which is blowing stuff up. This is not a platform game and it is not ‘Thrust‘!

So I have equipped the player’s jetboard with a tractor beam that automatically activates when it detects a pickup is nearby. Now the player just has to hover above a pickup in order to collect it allowing them to concentrate on the combat.

2. Pickup Generation – Ammo and Health
Whilst working on the bosses I realised a fundamental flaw in the way pickups were awarded. Previously they were only really awarded when an enemy was eliminated which meant that tackling a large enemy with an underpowered weapon would almost guarantee that the player would run out of ammo which was no fun at all. A similar issue existed for health pickups (though it wasn’t quite so detrimental to gameplay).

To overcome this issue I’ve allowed pickups to be awarded mid-battle. I have a tracker that tracks the mount of enemies killed, the amount of health deducted from enemies, and the amount of health lost by the player. If either of these passes a certain threshold a health or ammo pickup is generated as appropriate.

Ammo thresholds are based on the current armed weapon meaning that very powerful weapons that can take out a bunch of enemies at once (e.g. the RPG) are treated very differently from weaker weapons or weapons that can only really take out one enemy at a time. I still have to input and tweak these values but the structure is now there.

Lastly I decided to make the default weapon (the pistol) have infinite ammo. Seeing as I can never really have the player run out of ammo, allowing the default weapon to run out and automatically awarding an ammo cache (as I was previously doing) seemed like a pointless chore – it was a distraction from the core gameplay and no fun.

3. Pickup Generation – Rockets
Many people have commented on how much they like the jetboard ‘rocket attack’ and that it should be more integral to the game. Running out of rockets was no fun. Based on this feedback I have made the way that extra rockets are awarded more transparent (it’s based on the number of enemies killed and their difficulty) by integrating a visual indication of when the next rocket is to be awarded into the HUD. Now the rocket icon ‘charges up’ as enemies are killed making it easy to see when a new rocket will be awarded and thus allowing the player to make the most of their limited allowance.

4. Falling Off The Jetboard
Previously, if the player used the rocket attack to jump from their jetboard and the jetboard (but not the player) got blocked by a building mid-flight, the player would fall from their jetboard and lose a life. Losing a life like this was definitely no fun and often left players scratching their head wondering what had happened.

So I have got rid of that mechanic and implemented partially-destructible buildings instead. Now if the player’s jetboard gets blocked by a building whilst they are in mid-air above the building, the section of the building ‘above’ the jetboard will get destroyed. I may even add a few bonus items hidden inside buildings like to encourage this behaviour, destruction in games is generally fun!

5. The Gatling Gun
This weapon was simply too clunky. Even whilst playtesting I always felt slightly annoyed when I picked it up as it was both irritating to use and pretty ineffective, in other words it was no fun! The reasons for this were straightforward – the initial rate of fire was too slow and the recoil was too great. Upping the initial rate of fire and lowering the recoil have vastly improved the weapon handling and now, hopefully, this weapon will hold its own alongside the others.

6. Explosive Affiliation
I was always dithering about whether to allow the player to get blown up by their own explosive weapons (grenades, RPGs etc). Now I have decided that getting blown up by your own weapons is no fun, so I’ve removed it. This is not Call of Duty!

I have also added another subtle boost to the player in that, if the player destroys an enemy explosive (by shooting it), its ‘affilation’ is switched as if it was the player’s weapon in the first place. This allows the player to use an enemy’s weapons against them and, again, abides by the mantra of more destruction == more fun.

7. Explosive Damage
There were various inconsistencies with the way explosives worked which could make them difficult to predict and less fun to use. Consequently I’ve switched to using a raycasting algorithm for calculating explosive damage, this provides much more predictable (I hesitate to say ‘realistic’) results when explosive damage is blocked by buildings or other sprites.

As the shotgun also suffered from similar problems I’ve also switched to calculating shotgun damage using a raycasting method.

That’s all the ‘no fun’ that was really bothering me but if you’ve played the alpha and think of anything else please do let me know! Many of the above suggestions originate from player feedback.

Dev Time: 2.5 days
Total Dev Time: approx 209.5 days

previous | next

mockup_3x
The Tractor Beam – Crash Landings No Longer Necessary!

mockup_3x
Now You Can See When The Next Rocket’s Going To Be Awarded

mockup_3x
Working On Destructible Buildings

mockup_3x
The More Fun Gatling Gun

Testing A Raycasting Algorithm For Explosive Damage

Jetboard Joust Devlog #87 – Hidden Depths!

I always loved those bits in Super Mario World where you travelled down a pipe and entered a semi-secret room stuffed full of coins. Sometimes there was a mini-level down there – and the memory of discovering those hidden places, along with the way the background music shifted to a minor key, still gives me goosebumps. It’s one of my fondest gaming memories.

It’s replicated to an extent in other games. There’s the little side-caverns in Downwell, or the bonfires and merchant areas in Dark Souls. Often these places offer some kind of refuge from an otherwise hostile environment as well as a generous reward in the game’s currency or upgrades.

Though I’d never planned anything like this at the start of the game I wanted to add something similar to Jetboard Joust – and having the bosses guard hidden treasure chambers seemed like a good solution. Not only does it give a reason for the treasure chambers to be there (and a heightened sense of reward when they’re unlocked), but it means the bosses are semi-optional and don’t exist purely to block progress through the game (a common gameplay mechanic that I’ve never been overly fond of).

As I’d never intended having the player travel below ground level in the game, or a camera that moves on the vertical axis, introducing a subterranean component had a fairly substantial knock-on effect in exposing the general laziness of my coding and there were a number of things that had to be fixed in order to achieve this. Fortunately none of these presented serious issues but things could have been a lot easier if I’d have planned this from the start. So the lesson (as always) is – think very hard before you cut corners by saying to yourself ‘Oh, I’m never going to need to do x, y or z.’ as you’ll probably change your mind and it’s always easier to build functionality in from the start rather than try and retrofit it later!

I spent a long time on the art for both the chambers themselves and the entrance to the chamber but I must admit to having some help here. Whilst looking for reference material I came across a Unity asset pack that was remarkably ‘on point’ for the game’s visual style – in fact one of the images I used for reference when formulating the overall style was from this pack (I never realised it was an asset pack at the time as I found the original image on DeviantArt)! Though it made me feel somewhat dirty (why I don’t really know) I purchased this pack and the internal chamber backgrounds and the tower thing on the entrance originate there (with various degrees of editing involved). I may alter these more before release, not because I’ve done anything ‘wrong’ in using an asset pack, I just hate the idea of another game appearing with similar art when I’ve spent so long drawing everything else from scratch.

I’m pleased with the end result. There’s a bunch of details in there that I didn’t have to add but wanted to include for added atmosphere such as the drips falling from the chamber ceiling, the spooky eyes in the background, and the dust falling from the chamber doors as they open. I also wanted there to be a reason to use a weapon down there which is why the main reward is enclosed in a glass case! It’ll probably never give anyone goosebumps like Super Mario World but, once I add a some spooky background music, hopefully it’ll do a passable impression.

You can see the sequence of events for unlocking and entering a treasure chamber in the video – note that I’ve severely nerfed the boss for demo purposes!

Completing this means I’ve upped the progress level for the game to 80% complete on TIGSource – hurrah, major milestone! Unless I add another boos this should be the last significant addition to gameplay.

Dev Time: 5 days
Total Dev Time: approx 207 days

previous | next

mockup_3x
I Wonder How I Open This? At The Chamber Entrance…

Jetboard Joust Devlog #86 – Bosses Defeated!

At long bloody last!!

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

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

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

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

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

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

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

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

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

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

Finally I added audio for all the various attack stages.

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

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

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

Thank God that process is over!

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

previous | next

Jetboard Joust Devlog #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 #84 – Along Came A Spider…

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

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

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

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

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

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

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

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

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

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

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

previous | next

mockup_3x
The Final Art With All 24 Moving Leg Joints

Battling The Spinner – All Attack Stages In Action

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

God, these big enemies are hard!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

previous | next

mockup_3x
Fours Days Of Pixel-Pushing In Fifteen Seconds

mockup_3x
Fun With Collision Proxies

mockup_3x
Entering The Zombie Phase

Whoops – I Accidentally Added Boss Battles!

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

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

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

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

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

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

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

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

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

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

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

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

previous

mockup_3x
Abandoned First Draft – Too ‘Realistic’

mockup_3x
Abandoned Second Draft – Too ‘Mechanical’

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

mockup_3x
Almost Final Version – Later I made The Abdomen Pulse

Using Various Weapons To Take Out A Stinger

Jetboard Joust Devlog #81 – On A Roll!

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

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

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

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

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

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

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

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

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

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

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

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

previous | next



Abandoned Art Direction – ‘Tank’

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

Guns Tracking Player And A Nicer Rolling Action Round Corners


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

Jetboard Joust Devlog #80 – Squid’s In!

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

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

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

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

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

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

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

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

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

previous | next

mockup_3x
The Main Squocket Animation

mockup_3x
Squockets At Rest