next »

[dario_zubovic]

Oh god, this game looks wonderful! Tried demo and feeling of the game is fantastic. Really juicy

Windows build appears to be working perfectly with Wine 3.0 on Ubuntu. There is only a small bug that is probably Linux-only: game appears fullscreen on one monitor, but centered around edge between two monitors. Workaround is to turn off one monitor and restart the game.

[bitbulldotcom]

I had the very same issues in my current projet, a space trading game, where the world wraps both horizontally and vertically, and I too was writing a lot of code, trying to handle the edge cases. I too came to the solution of calculating all other objects relative to the player, by putting the player in the middle of my world when calculating and then adding the offsets to the other objects. This made pathfinding, collision detection and autopiloting a lot easier

It's always great when you have that Heureka-moment!

Nice one!

I've written so many (albeit much simpler) games where that happens but have never thought of doing it the 'player relative' way before. It makes life so much easier!

[bitbulldotcom]

Oh god, this game looks wonderful! Tried demo and feeling of the game is fantastic. Really juicy

Windows build appears to be working perfectly with Wine 3.0 on Ubuntu. There is only a small bug that is probably Linux-only: game appears fullscreen on one monitor, but centered around edge between two monitors. Workaround is to turn off one monitor and restart the game.

Hey - thanks for playing - glad you like it and thanks very much for the feedback!

It's even juicier now with all the new weapons in  watch this space and I'd love to have you playtest the beta when I finally get to that stage!

[bitbulldotcom]

Been working on some new jetboarding enemies over the past few days, so around a day of pixel-pushing and a day of coding with the extra half day fixing bugs caused by the new ‘world wrap’ technique I described in my previous post. I’ve also been rejigging my sprite sheets so the art used for the jetboard and weapon attachments is duplicated on the enemy sprite sheet (fewer spritebatch calls to the GPU needed and should also make things easier if/when I add alternate colour palettes).
Fortunately new jetboarding enemies are relatively simple from a code point of view as a much of their ‘personality’ is defined by tweaking parameters already present in the AI. I also have a fairly decent template for doing the animations now too. Here are the new enemies that have been added, names are just codenames really so may well change…

1. The Master Minion
This is really just a bigger, stronger, and slightly more dangerous version of the omnipresent ‘minion’, the game’s cannon fodder. They’re quicker to snatch your babies away and mutate too!



2. The Ninja
Small, fast, light, very aggressive, but also pretty weak. This guy is very dangerous and performs a ‘pincer movement’ around the player really frequently making him a tough opponent to deal with.



3. The Aggressor
This guy is strong, fairly nimble, and very aggressive when you rile him but he’s actually pretty dumb and will let you sneak up behind him and get in the first shot. A bit like some of the knights in ‘Dark Souls’ (well, kind of)! You can tell which way he’s facing by looking at the scanner. This enemy required some custom AI work.



4. The Thug
This guy is very big and strong and takes a lot of ammo to dispatch. He’s pretty slow though, and not the brightest lamp on alien street either. I was particularly pleased with how the art for this one worked out.



5. The Snatcher
All this guy cares about is stealing your babies and trying to mutate. It’s like he’s a kind of half-mutant already and is desperate to finish the job. He’s a bit of a coward and will actively try and avoid the player unless directly engaged – watch him though, as he’ll snatch away your progeny and mutate really quickly if you don’t keep an eye on the scanner! This enemy required the most custom AI work.



This brings the total of enemy types to 12, I think I’m going to try and bring it closer to 20 and want to add some ‘miniboss’ type enemies with much larger sprites. few more smaller ones to do yet though…

Dev Time: 2.5 days
Total Dev Time: approx 156 days

[bitbulldotcom]

Too long since the last update. Had a lot of shit on – decided to fight a parking ticket issued by one of those fascist private parking companies and it ended up in court. I beat the tossers but it took so much time preparing the defence and everything I’m not sure if it was worth it, just did it on principle really as I don’t like scammers or bullies. Turns out these scumbags didn’t even have the right to operate on the land on which the ticket was issued in the first place!

Anyway, back on topic, the first major ‘new’ enemy is actually an ‘old’ enemy redone, but I don’t think there’s any shame in that. If you’ve been following this for some time you may remember the ‘Evil Mother‘ enemy. Well, I’d come to the conclusion that this enemy just wasn’t big enough and would work better (and make more sense) as some kind of mini mothership that spilled out its occupants when destroyed.

So I spent quite some time designing a kind of ‘bathysphere’ type craft. It’s actually several different sprites in one, the ship itself, the pilot, the ‘antennae’ on the top which acts as a weapon, plus the various lights. I’m pretty pleased with the result though a little worried it looks a bit too ‘2D’ and could do with some more shading or something to make it appear more ’rounded’.

I also increased the size of the enemies that spill out when the craft is destroyed and spent quite some time working on a much improved bullet that tracks the player’s movement in a similar way to the Limpet Mine. There’s also a ‘tell’ that the ship is going to fire as you can see the antennae at the top charging up.



The shaking effect is achieved by applying an offset to the ships position each frame. These offsets are always evenly distributed and chosen at random so it’s a very predictable type of brownian motion.

I think I’m going to use the original enemy design as more of a ‘swarm’ type enemy with a movement type that’s an homage to the original Space Invaders!

Here's some bullet dodging showing the new bullet motion...



And here's a mothership/gravity hammer duel...



Dev Time: 3 days
Total Dev Time: approx 159 days

[bitbulldotcom]

In my last post I wrote about maybe recycling the old ‘Evil Mother’ enemy into something based on the classic ‘Space Invaders‘ aliens, and that’s exactly what I’ve ended up doing!

I like the idea of including a few homages to the classic arcade shooters of yesteryear in Jetboard Joust, and as ‘Space Invaders’ was really the granddaddy of them all it’s an obvious choice. I wasn’t sure whether the formation/movement of the invaders would work within the horizontal/scrolling format of Jetboard Joust but, with a few tweaks, it actually seemed to work out pretty well.

It wasn’t too tricky to code either. I was worried that get the whole batch of invaders to move together around buildings and stuff would be a pain but it was pretty straightforward in the end.

What I do is move all the invaders as a batch rather than treating them as individual sprites. Collision detections are still handled individually and, when an invader collides with a building, it sends a message back to the batch telling it to change direction. When the batch is initiated I make sure it doesn’t take up more vertical space than the space between the highest building and the top of the screen so I know it’s never going to get stuck.

In keeping with the original I have the invader’s speed and rate of fire increase as individual invaders are destroyed.

Here's a GIF showing a batch of invaders being dispatched with the flamethrower...



And here's a movie showing a batch of invaders being dispatched with the plasma rifle (sorry, forgot to record audio!)...



Probably the trickiest thing was deciding how to treat a batch of invaders when attacked by the ‘Gravity Hammer‘ weapon. Moving the whole batch at once would just look dumb so I needed a way of having individual enemies break formation when hammered and then return to the appropriate position once they recover.

To achieve this I have a property for each invader that stores its location within the batch separate from its position on screen. If the invader is forced to break formation it is relatively simple for it to return to its batch position. Though it wasn’t strictly necessary I also decided to have individual invaders track horizontally with the batch even when hammered (so only their vertical position is displaced). It just seemed to look better this way.

Here's a short clip showing a batch of invaders being attacked with the Gravity Hammer...



Dev Time: 1 day
Total Dev Time: approx 160 days

[bitbulldotcom]

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.

Here's a short video of some squockets in action...



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

[bitbulldotcom]

In the late 1970s, when kids played with proper toys rather than tablets and smartphones, there was this marvellous toy called a ‘

‘. 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 (ugh!)...



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 - here's a clip of everything in action.



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 in the previous post) 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. Here's a clip (enlarged 150%) showing a battle with two crawlers with the player using a variety of weapons to dispatch them (he only just makes it)..



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

[bitbulldotcom]

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.

Here's a first abandoned attempt. With this one I was trying to make the enemy look too realistic and relying too much on reference photography. It sounds dumb but their is probably around  a day's work here included the various blind alleys I went down (actually it was all really one blind alley)!



Here's a second abandoned direction. As I wasn't getting anywhere with the 'realistic' approach I tried going down a complete ‘robot’ path, creating a creature partly from sprites that I’d already designed (mainly the ‘upgrade weapon’ icons). I felt this one had some kind of vague 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). This is the first version I posted on Twitter. It still sucks but it's getting there. The mandibles look horrible (like a stubby beak) and the abdomen is too 'tubby' and clumsy looking but the thorax, legs and bulk of the head are actually looking OK.



And here's pretty much the final version. I've got rid of the 'beak' and replaced with some dangly mouth parts, replaced the 'real' abdomen with a clanky, steampunk-esque fuel tank, and created a more detailed and less clumsy 'sting'. After this I also made the abdomen pulse a bit. I reckon it took me 3.5 days of painful pixel-pushing to get to this stage!



Thankfully coding the movement wasn’t too problematic, the 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

[bitbulldotcom]

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. Here's how it progressed - four days work in fifteen seconds...



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

Here's a video showing all three attack stages...



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

[bitbulldotcom]

I dunno why hardly anyone comments on this devlog, maybe it's too GIF-heavy which is putting people off. Showing a lot of views so I'm guessing some people are reading it - whoever you are, thank you for paying attention! 

Anyway, 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

[bitbulldotcom]

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!

Here's a quick vid showing all stages of the final boss battle - this one works out a draw!



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

[bitbulldotcom]

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

[bitbulldotcom]

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. Here's a close-up of the chamber entrance...



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  – hurrah, major milestone! Unless I add another boss this should be the last significant addition to gameplay.

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

[bitbulldotcom]

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

[bitbulldotcom]

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.

Here's a quick clip - note no judder with the objects on the ground...



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

[bitbulldotcom]

I know – it’s been a while! I didn’t call, I didn’t write etc etc.

I’ve been really busy with a few pieces of contract work over the Summer. Really glad to have had that as funds have been dwindling somewhat – and once that was over I decided to have some time off (something I rarely do unless I’m actually going away).

Anyway, back on it and decided to (not) ease myself in gently with a fairly mammoth task that’s been on my list for some time now – that of implementing alternate palettes.

I wanted to have ‘proper’ alternate palettes (not just throw some kind of tint over everything) and there seemed to be two ways I could have gone about this. 1) I could implement a shader to swap colours at runtime, drawing to an offscreen buffer and using that as the source for my sprites rather than the original, or 2) I could mess with the palette data in the 8bit PNGs as they’re loaded and re-instantiate the source images from the byte data each time the palette has changed.

I have already used the second approach in a J2ME game I produced a while ago so had a bunch of code to hand for swapping PNG palettes, however I decided to go for the first approach here for three main reasons – 1) Instantiating images from byte streams can be a drain on resources as it requires a lot of memory allocation and garbage collection, 2) I have had bad experiences with instantiating images from byte streams in some versions of MonoGame (see here) and 3) I was going to have to edit some of my existing shader code to cope with palette swapping anyway so figured I may as well do the whole thing in HLSL.

Before I even started on the shaders I had a lot of rationalisation of my sprite sheets to do in order to minimise the amount of images that need to be redrawn each time a palette swap takes place. I’ve decided to allow different palettes per sprite sheet and have therefore consolidated my sprite sheets into seven key components – player, enemies, pickups, terrain, floor, parallax and HUD. Each one can have a different palette applied as part of a palette ‘set’ though often multiple sheets will share the same palette.

Next I had to write the palette swap shader itself. I pass a palette image to the shader as a lookup table, the shader compares each colour being drawn to a reference palette and, if it matches, swaps the colour with the colour at the same index in the new palette.

This fairly straightforward approach seemed to work OK but I was getting some strangeness where colours weren’t always matching or were matching wrongly. This seemed to be almost random and I have no idea whether it was to do with MonoGame scaling the images or rendering into a different colour space or what. I fixed it by having my code find the closest matching colour in the reference palette rather than looking for a (more or less) exact match.

Once the basic palette swapping appeared functional I had to go through some of my existing shader code and edit this to cope with multiple palettes. Some shaders had colours from the original palette hard-coded in there (this was fairly easy to change) – others used algorithms for colour inversion and brightness that I was never entirely happy with (ever notice pixels going a bit yellow-y on some of the GIFs, particularly during the ‘teleport’ effect). I changed both these algorithms to only work from a strict colour index and now they work much better.

Lastly I had to go through all the particle effects (groan) and make sure the tints applied to them were from the appropriate palette. This was particularly time-consuming on weapons as I had to apply a different palette depending on whether the weapon was affiliated with the player or an enemy.

And, of course, I actually have to design some palettes. Not quite sure how I’m going to approach this in-game yet but I’ve included some examples of my initial attempts. I think I’m going to go for more subtle palettes (like the original) as the defaults and then include the more garish/extreme palettes as ‘one offs’ and/or player unlockables. With some of these I’m restricting the colours available to give an even more blocky/retro feel.

Dev Time: 5 days
Total Dev Time: approx 219.5 days

Here's a palette inspired by grindhouse movie posters (especially 'Death Proof') and Russian Constructivism(!)



And a few inspired by the manual artwork for some of Atari's arcade cabinets, first 'Space Duel'...



'Gravitar'...



'Asteroids'...



Here's one inspired by the original Tron movie - inside the mainframe...

 

And lastly, I simply had to do one based on the original Defender arcade game as that's been the main inspiration for Jetboard Joust...



More to come, suggestions welcome...

[bitbulldotcom]

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.

Here's the 'zoomed out' mini-map...



And the more detailed 'zoomed in' version for selecting levels...



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

[bitbulldotcom]

Final boss fight!!

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 image above, 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’. It was a double PITA getting the tentacle movement to work consistently whilst the boss was moving and rotating!

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

[bitbulldotcom]

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