Monthly Archives: April 2018

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!