Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Chatting about life in general, videogames, making videogames and stuff. No adverts/team requests.
User avatar
BitBullDotCom
Remakenaut
Posts: 101
Joined: Thu Dec 10, 2015 2:31 pm
Contact:

Re: Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Post by BitBullDotCom » Mon Jun 18, 2018 8:14 am

Thanks - that's good to hear! I always feel a bit like it's all held together with string and sticking plasters, difficult to take a step back!
====

James Closs, Director & Wielder of Code, BitBull Ltd

http://www.bitbull.com | http://www.joystickjunkyard.com

@BitBullDotCom | @JunkyStickJoy

====

User avatar
BitBullDotCom
Remakenaut
Posts: 101
Joined: Thu Dec 10, 2015 2:31 pm
Contact:

Re: Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Post by BitBullDotCom » Thu Jun 21, 2018 2:10 pm

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.

Image

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.

Image

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!

Image

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.

Image

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.

Image

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

James Closs, Director & Wielder of Code, BitBull Ltd

http://www.bitbull.com | http://www.joystickjunkyard.com

@BitBullDotCom | @JunkyStickJoy

====

User avatar
Tam Toucan
Team RR
Posts: 412
Joined: Mon Jan 06, 2014 3:57 pm
Location: My head
Contact:

Re: Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Post by Tam Toucan » Fri Jun 22, 2018 1:49 pm

Interesting reading the game dev decisions. All seem like good improvements. Is this the start of the last 10% (that takes 90% of the time) :)

User avatar
BitBullDotCom
Remakenaut
Posts: 101
Joined: Thu Dec 10, 2015 2:31 pm
Contact:

Re: Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Post by BitBullDotCom » Tue Jun 26, 2018 8:57 am

Tam Toucan wrote:
Fri Jun 22, 2018 1:49 pm
Interesting reading the game dev decisions. All seem like good improvements. Is this the start of the last 10% (that takes 90% of the time)
Haha - don't say that - I won't be finished for another 25 years!!

I reckon it's about 80% complete though really I'm hoping it's a bit more than that. A lot will depend on whether I decide to add extra background graphics or not. I am still undecided about the overall game structure, i.e. whether to split the levels into a series of 'worlds' (similar to the old speccie game Sidewize) or simply to have the whole thing as a linear playthrough like the old school arcade games.
====

James Closs, Director & Wielder of Code, BitBull Ltd

http://www.bitbull.com | http://www.joystickjunkyard.com

@BitBullDotCom | @JunkyStickJoy

====

User avatar
BitBullDotCom
Remakenaut
Posts: 101
Joined: Thu Dec 10, 2015 2:31 pm
Contact:

Re: Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Post by BitBullDotCom » Wed Jul 11, 2018 10:54 am

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

Image

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.

Image

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.

Image

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.

Image

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

James Closs, Director & Wielder of Code, BitBull Ltd

http://www.bitbull.com | http://www.joystickjunkyard.com

@BitBullDotCom | @JunkyStickJoy

====

User avatar
Tam Toucan
Team RR
Posts: 412
Joined: Mon Jan 06, 2014 3:57 pm
Location: My head
Contact:

Re: Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Post by Tam Toucan » Thu Jul 12, 2018 6:03 pm

Nice job on the smoke effect. I'd originally said it wasn't right for the rest of the art style. Much better now.

User avatar
BitBullDotCom
Remakenaut
Posts: 101
Joined: Thu Dec 10, 2015 2:31 pm
Contact:

Re: Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Post by BitBullDotCom » Wed Jul 18, 2018 7:57 am

Tam Toucan wrote:
Thu Jul 12, 2018 6:03 pm
Nice job on the smoke effect. I'd originally said it wasn't right for the rest of the art style. Much better now.
Thanks! Yeah, I thought it was here that I'd had that feedback. It was always bugging me slightly, that effect, and getting feedback that confirms your own suspicions is often the thing that pushes me into actually doing the work to fix it so thanks again!

I'm just back from a few days away visiting Lisbon (very nice city) and now have a couple of weeks contract work on (bit of a drag but the coffers are empty so it's good it's come up really) so might be a while before I post the next update. I think the next thing I'm going to add is the ability to work with different colour palettes.
====

James Closs, Director & Wielder of Code, BitBull Ltd

http://www.bitbull.com | http://www.joystickjunkyard.com

@BitBullDotCom | @JunkyStickJoy

====

User avatar
BitBullDotCom
Remakenaut
Posts: 101
Joined: Thu Dec 10, 2015 2:31 pm
Contact:

Re: Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Post by BitBullDotCom » Thu Oct 11, 2018 1:48 pm

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

Image

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

Image

'Gravitar'...

Image

'Asteroids'...

Image

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

Image  

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

Image

More to come, suggestions welcome...
====

James Closs, Director & Wielder of Code, BitBull Ltd

http://www.bitbull.com | http://www.joystickjunkyard.com

@BitBullDotCom | @JunkyStickJoy

====

User avatar
BitBullDotCom
Remakenaut
Posts: 101
Joined: Thu Dec 10, 2015 2:31 pm
Contact:

Re: Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Post by BitBullDotCom » Wed Oct 31, 2018 9:11 am

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.

Image

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

Image

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

Image

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…

Image

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

James Closs, Director & Wielder of Code, BitBull Ltd

http://www.bitbull.com | http://www.joystickjunkyard.com

@BitBullDotCom | @JunkyStickJoy

====

User avatar
BitBullDotCom
Remakenaut
Posts: 101
Joined: Thu Dec 10, 2015 2:31 pm
Contact:

Re: Jetboard Joust - Defender-Inspired Cute Retro SHMUP - Alpha Now Available For MacOS and Windows

Post by BitBullDotCom » Tue Nov 27, 2018 8:18 pm

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.

Image

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.

Image

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!

Image

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

James Closs, Director & Wielder of Code, BitBull Ltd

http://www.bitbull.com | http://www.joystickjunkyard.com

@BitBullDotCom | @JunkyStickJoy

====

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest