Monthly Archives: October 2018

Jetboard Joust Devlog #91 – Global Navigation (You Are What UI)

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

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

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

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

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

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

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

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

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

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

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

previous

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

mockup_3x
The Full Size Map

mockup_3x
Your Teleport Is Ready, Sir!

Clearing a Sector, Activating the Teleport, Selecting Next Level

Jetboard Joust Devlog #90 – Colour Coding

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

previous | next

mockup_3x
Restricted Palette – Grindhouse Film Posters / Russian Constructivism

mockup_3x
Inspired By The Manual Artwork For Atari’s ‘Space Duel’ Arcade Machines

mockup_3x
Inspired By The Manual Artwork For Atari’s ‘Gravitar’ Arcade Machines

mockup_3x
Inspired By The Manual Artwork For Atari’s ‘Asteroids’ Arcade Machines

mockup_3x
Inspired By The Original Tron Movie

mockup_3x
Very Garish Palette Inspired By The Original Defender Arcade Game, By Far The Biggest Influence On Jetboard Joust