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

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.

Woohoo - major milestone alert!!! I now have a playable alpha ready for MacOS and Windows. Limited weapons and enemies but... it's there!! Any feedback is much appreciated!

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

Working on weapon upgrade UI...

Working on shotgun weapon...

A new enemy - 'the bastard'

Another new enemy - 'the mother'

====

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 it should be fun getting there.

I'm starting a dev blog http://bit.ly/1SOs8Qs and will post here when I update it if anyone's interested.

Thanks for watching!

The original...

The sequel 4 days in...

Last edited by BitBullDotCom on Tue May 09, 2017 2:15 pm, edited 5 times in total.

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.

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!

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.