next »

[bitbulldotcom]

Several months later and still no DevLog updates but I'm stoked to announce that Jetboard Joust has just launched on Nintendo Switch and Atari VCS! There's also been a significant update to the PC version that includes Linux support amongst other things. I'm still exhausted!

===

Jetboard Joust is now available on Steam here!

It's taken five years to get to this point and I'm exhausted. I hope to be posting some DevLog updates about the last few months but for now I hope some of you will download and enjoy the game - and if you do enjoy it, please leave a review!  





Join the Discord server



Jetboard Joust is a visually striking future-retro shooter in which you use a vast array of ridiculous weaponry to stop hordes of aliens from abducting your precious babies and turning them into mutants.

It's very much inspired by classic arcade shooters of the past, such as Defender and Joust, but with shedloads of extra features and modern indiegame twists. And it's kind of a very belated sequel to a (frankly pretty terrible) game I released on the ZX Spectrum around 30 years ago.



http://jetboardjoust.bitbull.com

====

The front page of this DevLog is looking rather dull so I'm going to update it occasionally with some recent GIFs of work-in-progress - scroll down for what was the 'real' first post...





First miniboss - the stinger, click to play video...



Second miniboss - the snapper, click to play video...



A new weapon - retro 50s sci-fi raygun!



Bullet hell - new Gatling gun weapon...



Using the grenade launcher to get combos...



Flamethrower vs Gatling Guns



===

Hi,

Around thirty years ago I had a game published for the ZX Spectrum called 'Skateboard Joust'.  It was pretty terrible.

Seeing as I'm not making any money from this 'indie dev' shit at the moment and my current major project is in (hopefully temporary) development limbo I've decided I'm going to build a sequel in an attempt to balance out my gaming karma. I don't really have much of an an idea where this is going to go but I'm hoping I have some fun and learn some stuff on the way.

I'm starting a DevLog and will post here when I update it if anyone's interested. So far I think I have general art style pretty much nailed down and have made a start on player movement and thinking about gameplay.  For more regular updates please follow me on Twitter.

Thanks for watching!

The original...


The sequel 4 days in...

[bitbulldotcom]

Another 1.5 days or so in and, surprise surprise, things aren’t going as quickly as I would like. This is mainly due to the art though which always takes me ages. There won’t really be that many main character animations in the game I guess so I might as well make the one’s that are there as good as I can get them (with my limited pixel-pushing ability).

First off the main ‘riding the board’ anim. This looked OK in Photoshop but in-game it didn’t seem to work. Seemed too wobbly and unnatural. Looking at a few vids people stay pretty still on skateboards/surfboards when they’re riding them and only wobble about when they’re going to fall off!

So after much trial and error I decided to ditch any kind of movement when the player is riding the board. I replaced this with three key positions that vary depending on how fast the board is moving. As the board moves quicker the player leans back more. I also added a couple of ‘spring’ frames so that when the board thrusts upwards the player ducks down slightly. The combo of these two things seems to work pretty well – though I’m not sure if the ‘leaning back’ position is too much ‘walk like an egyptian’! Any more animation just looked too ‘wobbly’ (that’s the trouble with having an 18*18 sprite, it’s very hard to do subtle movements).





Next up was the controls themselves. I was quite keen on this being a ‘two button’ only game but using the same button for thrust and reverse (long press for reverse) just wasn’t working. It was too easy to reverse by accident and too natural to expect holding ‘thrust’ to keep thrusting. So I’m moving to a three button system where the button left will be ‘reverse’, bottom right ‘thrust’ and top ‘fire’. This is pretty easy to play on the iPad but I’m a bit worried fat fingers will get in the way of the gameplay on smaller phones (such as the older iPhones which seem tiny now)!

A knock-on effect of this is that thrust now works based on a continual applied force than a single impulse so I had to tweak the various parameters involved until this felt right. I’ve ended up with less thrust being applied as you reach terminal velocity so there’s a kind of curve going on. I’ve no idea whether this follows the laws of physics but it certainly feels nicer form a gameplay perspective.

Last but definitely not least in terms of time was getting the ‘jump’ action correct. A core feature of the game is that your jetboard becomes a weapon when you’re not riding it so this has to look and feel right.

Getting the basic movement was pretty easy – pressing fire causes an impulse which make the jetboard fly dead straight for a certain distance (so it’s easier to aim). Getting the player to jump and return to the board was also very straightforward (there’s a bunch of scenarios you have to think about but none of them present and major issues).

What wasn’t so simple was getting the ‘jump’ animation for the player to work. As the jump movement is done in code it’s very hard to preview this in Photoshop so I felt I was kind of working blindly. My first effort (which took ages) wasn’t too awful but felt more like a weird mid-air run than a jump...



..in the end I had to make the animation sequence fairly complex – we start with a kind of ‘run’ movement which is played again in part as the player reaches the zenith of the jump, the anim then transitions to a ‘descent’ position which is held until the player lands back on the board. When he lands a short ‘spring’ animation is played.



I’m pleased with the way this works now though I’m sure it could still be better and will gladly take any comments! I messed around with the frame timings a lot. Will probably come back to it but it’s time to move on.

Next up – probably adding some really simple enemies to test targeting and a simple lose life/new life loop.

Dev Time: 1.5 days
Total Dev Time: approx 6 days

[bitbulldotcom]

When I code I have a tendency to ‘potter’ – that is, I’ll start off with the aim of doing something and end up getting distracted by various side-tasks along the way. Much as one might do when gardening!

So in this case I started off trying to get my first simple enemy done and ended up getting sidetracked into writing a particle generator to handle explosions and other FX in the game.

Consequently my initial enemy is still looking pretty crappy. I’m not happy with it at all actually. God this pixel art stuff is harder than it looks! All I wanted was a simple spinning ‘mine’ type thing that will remain largely static as a dumb target. The first attempt was OK but somehow looked wrong compared to the main character – like I was using too many colours or something, not contrasty enough. So I tried again giving it two ‘eyes’ this time and adding another frame to the animation. Still looks crap and now the animation looks all wrong too, like it’s not really spinning correctly. I know – even with four years at art school I should stick to code!



Anyway, in order to feel as if I was making some progress I decided one of these would do as a placeholder and moved on to implementing a simple ‘enemy’ base class and some basic collision detection for when the board is ‘fired’. Easy.

Next I needed explosions, and as this game is partly ‘Defender’ inspired it seemed some kind of particle-based explosion would be the way to go. I’ve never written a particle generator before so have no idea whether I’m going about this the best way (maybe I should have read up about it first) but am pretty pleased with where I’ve got to so far.

A ‘generator’ is instantiated with a max number of particles and a lifespan and chucks out max_particles/lifespan particles per frame.

Each particle has a velocity, decceleration and lifespan (defined at the generator level), each with a defined amount of variance. there’s also the option to set up a tween on the opacity of each particle. I calculate the tween values in advance.

So not much is being done per particle per frame other than calculate the new velocity and draw it. Thinking about it I could probably calculate the velocities in advance as well if I really needed to but not if I add additional factors like gravity which I plan to do. It should prove a very useful class throughout the game.



Another thing I’ve been a bit stuck on is getting the ‘camera’ on the scrolling world to perform to my satisfaction. Still not there on that one yet, hopefully have it resolved by the next installment!

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

[alvarop]

I'm digging the art-style of the new one, although I like how colourful the original is.

Following this one, looking forward to see where this goes.

[bitbulldotcom]

Thanks - glad you like it!

[bitbulldotcom]

Another case of #gamedev pottering here as I started work on one thing and got pretty much distracted with another. It was a constructive distraction though and has provided me with plenty of re-useable code so I’m not beating myself up about it.

I started work on the animation for falling off the Jetboard and got it to a stage where I was pretty happy with it, then thought it would look better if I added some dust as the player hits the floor...



I decided to use the basic particle generator I’d created for the enemy explosions and added some additional functionality such as the ability to animate particles, apply gravity, and restrict the angle at which particles are fired.

This worked, but in the process of testing I accidentally had the dust particles generated whenever the jetboard landed on anything – and it looked good! Decided to refine this which meant quite a few changes to the particle generator – mainly the ability for one generator to manage particles generated from several locations (to save the costly instantiation of a new generator every time I need some dust). Pretty pleased with the results though the parameters still need a bit of tweaking – some of that dust is getting flung rather too far!



Next up was working on the collision detection and figuring out the various ways you can be knocked off your jetboard. I’ve pretty much nabbed the collision detection from ‘Attack Of Giant Jumping Man’ which has saved a bunch of time and I think I’m going to restrict items you can interact with to simple static platforms as this is a SHMUP in essence, not a platformer.

So, other than colliding with enemies, there’s three ways that you and your jetboard can become separated…

1. Jetboard hits obstacle mid-jump, player still moving freely



2. Player hits obstacle mid-jump, jetboard still moving freely



3. Player hits obstacle whilst in flight, jetboard moves freely



…I also had to cover the occurrence where both player and jetboard come into contact with the same obstacle mid-jump. In this instance (I think) it’s reasonable that the player is able to land on the jetboard and recover though I may restrict this based on how far the player falls.



I’m still not entirely happy with some of the player falling animations but we’re getting there. Probably going to bit a bit of a break from this now whilst I work on ‘Attack Of Giant Jumping Man’ for a bit. Next up will be implementing a simple ‘lose life/retry’ loop.

Dev Time: 1.5 days
Total Dev Time: approx 8.5 days

[Pixel Noise]

Cool! I like the first and last animations the best. Really like the animation when the player hits the ground!

[bitbulldotcom]

Development on Jetboard Joust has suffered a bit of a hiatus since Christmas, mainly due to the fact that I've been spending far too long testing out alternative touchscreen control systems for 'Attack Of Giant Jumping Man' (which is beginning to seem like my life's work)...

I wrote about that (in probably far too much detail) here. Thankfully I'll be reusing a bunch of that code in Jetboard Joust but more on that later.

Today's main job has been completing the die/retry loop. I wanted this to feel like it was integrated into the gameplay rather than the sudden 'cut' you get on some games when everything just stops and you're taken back to the start of a level. I think the world/enemy state will remain persistent between lives (if that doesn't prove to be too much of a pain in the arse) so it's important that the die/retry loop felt like a 'long take tracking shot' rather than some kind of full reboot.

So I settled on the idea of having the player fired out of a Mario-style pipe at the start of each life. This introduces the player to the world quite nicely and seems better than having them simply fall down from the top of the screen or just 'be there' which would have been the easiest options. There will be at least two of these pipes per level and I may also use them as a method of exiting the level (but again, more of that later).

When you fall off the jetboard the camera pans to the closest pipe that's more than one screen width away from the player's current position. This means I don't have to make the player sprite 'disappear' somehow which I think would look pretty awkward - instead the 'stunned' player sprite is just scrolled offscreen.

I added a bit of recoil to the pipe as it shoots - it also wobbles a bit before firing but I couldn't show that on the GIF due to Photoshop's 500 frame limit on animated GIFs (there must be a better way of doing that but I haven't figured it out yet).



As well as die/retry I've been fixing a bunch of bugs and quirks and improving some of the animations - such as adding a bit of compression whenever the character lands. I really need to animate that jetboard now!



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

[bitbulldotcom]

This has been a bit of a tidying up session - sorting out a few things that have been niggling at me.

Firstly - the controls. The directional control work I've been doing on 'Attack Of Giant Jumping Man' made me rethink how I'm going to approach the control system somewhat. I thought I'd trying bolting on some of the experimental 'touch controllers' I did and see how they played as I'd really like to get a left, right, thrust and fire in there if possible.

The 'elastic' control system seemed to work pretty good so I've modified this a bit and this is what I think I'm going to go with. Basically it's a two-handed control system with two buttons on the right for thrust and fire and a directional control on the left. On the directional control a drag left or right orientates the player and accelerates whilst held whereas a long touch with no movement simply accelerates in the direction the player is currently facing. 

On the right the 'collision' area for the buttons takes up the entire right hand side of the screen divided as per the illustration. This makes it really easy to hit either button and the control system seems to work really well, at least for the moment.



Next up - camera. I misjudged what a pain in the arse this was going to be. Previously in 2D scrolling games I've done very simple camera tracking whereby the screen simply scrolls at a fixed rate whenever the player leaves a certain area and enters a 'buffer zone' towards the edges of the screen. Occasionally I'd get a bit more fancy and scroll to position the player so they gain a longer 'lookahead' depending on what direction they were facing.

A fixed camera rate looked crap in this game because the movement was very fast and there were too many abrupt stops or changes in direction which became very jarring to look at. I've added a certain amount of acceleration and decceleration to the way the camera moves to make the motion smoother. What was hard was to get the motion smooth whilst keeping up with the pace at which the player will move and change direction. I think it's pretty much there now but no doubt I will have to go back and rethink certain aspects yet again.



Lastly - collision detection. One scenario was bugging me whereby if you accelerated into the side of a floating block, then continued to accelerate whilst dropping, the board would fly off from beneath you when it dropped below the edge of the block. Whilst technically 'correct' this just felt too harsh in practice. Despite this, I still wanted the player to be knocked off if an attempt is made to fly beneath a floating block and the player clips the block but the board doesn't.

These two scenarios are the same as far as the collision detection algorithms are concerned and it's pretty hard to differentiate between them. What I've done as a compromise is only have the player knocked off in this scenario if the board is travelling at a certain velocity. So far this seems to do the trick!

This no longer sends you flying...



Whereas this does...



Dev Time: 0.5 days
Total Dev Time: approx 10 days

[bitbulldotcom]

Ok - best part of a day spent fiddling with the particle generator again!

I needed to add a ‘thrust’ effect to the jetboard and particles were the obvious way to go rather than trying to animate flames or something which would have a) taken me ages and b) probably looked shite.

As you can see – my first attempt was a complete fail...



...but I got there in the end. At least I think it looks pretty good now anyway!



The main extra functionality I needed to add to my particle generator code was the ability to set an initial velocity for the particle generator itself, ie so the particles appeared to be generated by something that was moving rather than from a simple static source. Back to ‘O’ level physics here! Without this the particles tailed behind the jetboard far too much, and if I simply fixed the particle generator to track the jetboard the flame looked much too ‘rigid’. This way I think it tails pretty nicely when you change direction. In fact I’m a bit worried it almost looks too ‘realistic’!?

Horizontal and vertical flames together perhaps look a little weird but I’m not really sure what to do about that at the moment. I think I need to shelve this particular rabbit-hole for a while and move onto something else...



Dev Time: 0.75 days
Total Dev Time: approx 10.75 days

[bitbulldotcom]

After I added the ‘thrust’ animations to the jetboard it became patently obvious that I needed something considerably more eye-catching for when the jetboard becomes weaponised. I’d also been thinking that I needed to increase the collision area of the jetboard when it’s used as a weapon as well (otherwise it’s just going to be too difficult to aim).

So I thought there was an opportunity to kill two birds with one stone here. By adding a kind of ‘fireball’ anim to the jetboard when it’s weaponised I not only get something more eye-catching, I also increase the area of the jetboard visually therefore giving me a legitimate excuse to increase it’s collison area as well!

I’m pretty pleased with the results. Took me a while to get the ‘fireball’ effect looking decent (as usual) but I think it works. I split the sprite in two so it appears the weaponised jetboard is travelling ‘through’ the fireball, also added some more particle fx and transformed the jetboard into a rocket so it becomes more obviously deadly.



Dev Time: 0.75 day
Total Dev Time: approx 12.5 days

[bitbulldotcom]

You know that horrible sinking feeling when you realise you’ve done something really, really stupid and have just spent the best part of an hour ignoring something that was staring you straight in the face all along? Doh! Not good is it.

I’ve been looking at adding some kind of health/hp to both the enemies and main character in Jetboard Joust. I think the game is going to prove far too difficult if I go for a ‘instant death’ mechanic every time you hit an enemy, plus I want to add a variety of weapons so adding health gives me more scope for different weapons doing different levels of damage. It also gives a very obvious upgrade path for weapons should I decide to add an weapon upgrade system.

So I needed something visual to indicate when a collision has occurred, or when an enemy takes damage but is not destroyed altogether, but I didn’t want to go down the route of creating a specific animation per enemy as this would have proved extremely time consuming (and very difficult to change globally).

Initially I looked at creating a type of ‘white out’ effect using the stencil buffer in MonoGame. I felt sure this was the way to go and sunk a lot of time into this approach, not ever having used a stencil buffer before. Unfortunately I just couldn’t get this to work – part of the reason was due to my own stupidity (the ‘doh’ moment I mentioned above when I realised the code that initialised the DepthStencilState objects I was using wasn’t getting called), but part of the reason was undoubtedly to do with quirks of this feature in Monogame. When I saw that my partially-working code wasn’t running consistently on Android and iOS I decided to abandon this approach as it seemed likely to lead to too much pain and grief.

That left custom shaders as the only possible approach. Fortunately getting these to work was a lot easier than I’d been anticipating. You can’t compile the shaders natively under OSX (which is a pain) but they compile easily using the Monogame Pipeline tool under Windows and I can flip back and forward between Windows and OSX easily with VMWare Fusion. I’ll probably write a separate post explaining how to do this in detail.

You can see below the results of my custom shader experiments. Doing a simple ‘white out’ effect was easy. Slightly more tricky was getting the texture to invert in the way I wanted. A simple colour inversion is easy but produced colours that were way out of range of the limited palette I’m using and looked really odd. What I needed to do was invert the brightness of the texture but keep the colour balance intact – I seem to have got there with the following HLSL code. Probably very hacky but it seems to work (Maths was never really my strong suit).

Code:

float4 PixelShaderFunction(float2 coords: TEXCOORD0) : COLOR0
{
	float4 color = tex2D(s0, coords);
	if ( color.a>0 )
	{

		float r2 = color.r;
		float g2 = color.g;
		float b2 = color.b; 
			
		float t = r2+g2+b2;
		float rp = (r2/t)/0.3333;	
		float gp = (g2/t)/0.3333;
		float bp = (b2/t)/0.3333;

		color.rgb = dot(color.rgb, float3(0.33, 0.33, 0.33));			
		color.rgb = 1.0-color.rgb;
		color.rgb *= float3(rp, gp, bp);

		color.a *= alpha;
	}
	return color;
}

So the final shader does a simple ‘white out’ followed by alternating inverted and normal frames. The ‘normal’ frames have increased brightness which gradually fades out. I think it’ll do the job for now at least. I imagine I’ll be implementing a few more of these type of effects – HLSL seems like a rabbit hole I can’t stop myself from entering.



Finally I added some more particle effects (another slight addition to the particle generator required to get that ‘halo’ effect) and mini health bars which I think look kind of cool. When health is depleted these animate down rather than just jumping to the next value.

Dev Time: 1.5 days
Total Dev Time: approx 14 days

[bitbulldotcom]

Just added a ‘Defender’ style scanner to show the location of enemies within the world. Not a lot to report here as this was one of those jobs where I knew what I had to do and just had to crank it out. Certain amount of experimentation with the ‘rasterization’ type effect which I think does the job but is unlikely to win me any awards.

One thing that’s bugging me is the fact the the enemy locations ‘wobble’ a bit as you can see from the GIF. I’ve run up against this type of thing before, it’s some kind of rounding issue which needs to be fixed. Thinking about it I might be better off rendering the whole scanner to an offscreen image each frame and then drawing that to screen at the appropriate offset. This would also allow me to draw with a custom shader and probably generate a cooler raster/tv type effect.



Dev Time: 0.5 days (including project setup)
Total Dev Time: approx 14.5 days

[alvarop]

The scanner looks like a musical staff with the enemies being the notes. Which is fine by me.

[bitbulldotcom]

The scanner looks like a musical staff with the enemies being the notes. Which is fine by me.

Haha - that hadn't occurred to me but you're right! Maybe I could follow that through somehow when I do the audio...

[flipswitchx]

Wow 30 years that's amazing. So far it's looking nice I really like the style of the background stuff going on. Nice particles. Gameplay looks fun. Love the minimap at the top. I imagine it'll be really satisfying to complete such a sequel 

[jctwood]

This looks intriguing! Have you decided on the monotone palette or will the player be able to select one like in the coloured example?

[bitbulldotcom]

Cheers guys - thanks for reading and thanks for the comments!

I haven't 100% decided on that colour palette but I know I want to work with very restricted and quite 'flat' colour. What I may do is apply different colour palettes to different levels.

Another update coming in a bit...

[bitbulldotcom]

First things first – fixed the scanner wobble! I’m now rendering the scanner to an offscreen image (RenderTarget2D) before drawing to screen which means I don’t have to worry about any rounding errors due to the scaling of sprite locations.

Later I’m going to look at applying some custom shaders to this for a bit of ‘interference noise’ and to send the scanner a little haywire when you bump into things.

This’ll do for now though – the raster effect I’ve applied looks OK but unfortunately doesn’t really come across in the GIF which had to be compressed quite a bit to get within the 5mb limit for Twitter.



Next job was to add some terrain to the ‘Jetboard Joust’ world. This was pretty easy on the whole, only difficulty is that you end up with a lot of objects to check against for collisions – particularly when enemies need to interact with the terrain as well (which some of them will do).

To solve this I’ve opted for what I think is a fairly standard gamedev solution. The world is split into a bunch of ‘segments’, each of which contains two smaller segments (a bit like Russian dolls). I stop subdividing when we get to around screen size. The smallest segments contain pointers to the terrain elements that intersect them.

Now when collision checking I only need to iterate through terrain elements in the segment which intersect the sprite I am checking against, this makes collision checking pretty efficient as I can effectively discard half the elements in the world with one Rectangle.Intersects check.

You’ll see I’ve added the terrain to the scanner too – I like the ‘blocky’ way this looks, it reminds me of ‘Defender’ on the Atari VCS 2600.



I’m not at all happy with the tiles for the terrain yet – they need completely redoing so look at these as placeholder graphics. I’m thinking of attempting a kind of ‘strange ruined city’ type look.

If you’re very observant you’ll notice I added a slight automatic ‘boost’ when the player rides into the side of as terrain element. A proportion of the horizontal velocity is transferred to vertical velocity here which I think makes the game feel a lot more fluid.

Here's a full size screenshot...



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

[bitbulldotcom]

Mainly been pushing pixels over the last day or so. In my last post I mentioned that I wasn’t at all happy with the ‘boulder’ tile I’d been using for the foreground section of the landscape. In Jetboard Joust (unlike Defender) you interact with the terrain, and as my physics model is probably only going to allow for simple rectangle-based collisions this necessitates that the terrain is made up from a simple rectangle-based modular tileset. Rather than go for a ‘natural’ feel to the landscape I thought I let the restrictions dictate the visuals to an extent and try a kind of ruined, ominous ‘space city’. A bit like a sci-fi version of an old aztec temple or something.

I looked at a bunch of stuff for reference, the kind of thing that seemed to fit the best was an approach vaguely along the lines of ‘Fez‘, ‘Hyper Light Drifter‘, and some of the Capybara games such as ‘Superbrothers Sword & Sorcery‘. I was also thinking a lot about Dr.Seuss landscapes, particularly the Rinker Rink Fink which always struck me as being really weird and slightly spooky. Difficult to get that across in a rectangular tileset though – I’ll come back to that later.



First thing I did was design some solid ‘block’ tiles. When I was happy with these I tried a few different approaches to shading to add some depth. Couldn’t decide on which approach to go for so I asked for some input on Twitter. Most people preferred the approach on the left (the simplest) whereas i was drawn more to the one on the right (the most complex). In the end I went for the one in the middle which seemed to be a good compromise between depth and clarity. I did try the leftmost approach in-game but it just felt too ‘flat’ to me.



Next I designed a bunch more tiles, including some more open ‘connector’ tiles, and set about writing an algorithm to construct the buildings randomly. What was key here was to make sure that too many ‘solid’ tiles weren’t stacked up on one another without a connector as this looked odd. Then an algorithm to distribute the buildings was needed. What I found worked best was if the buildings were placed together in small ‘clumps’ with a slightly larger gap every three or four buildings or so – also if there were never two buildings of the same size next to each other.



Lastly I added some ‘chips’ to the tileset which are placed semi-randomly over the buildings so that they look a little battle-worn. These ‘chips’ may still need a bit of work but I think the feel is there.



I still need to add more tiles, especially some more ‘open’ ones with windows and arches or something, but I’m pleased with the end result. It has a certain atmosphere that I think works. Now I am unsure whether I need to change the main character and the ground tile to be more in-keeping. It’s a never-ending merry-go-round!

Dev Time: 1 days (including project setup)
Total Dev Time: approx 16.5 days