next »

[bitbulldotcom]

I’d been thinking for a while that I needed a slightly more visceral feel to the collisions in Jetboard Joust, particularly when the main character crashes into the terrain but also when he’s taking damage from enemies.

So I’ve spent the last couple of days working on this by applying three different effects, the amount of each effect applied depends on the strength of impact (ie the speed the player is travelling or amount of damage taken) and is tweened back to zero over a short period of time, roughly 0.25 seconds. The three effects are as follows…

1. Scanner Distortion
It didn’t make sense to me that the scanner display should remain pristine when you’re taking a pummeling. Though the scanner is part of the HUD I imagine it as being embedded in the player’s helmet or something so it should appear to suffer as the player does whilst still maintaining enough legibility to make the game playable. I’ve achieved this by applying a ‘pixelator’ type shader that is based on my ‘teleport’ shader with a few changes. As well as changing the amount of pixelation based on the strength of impact I also add a small amount of brightness and noise which gives the impression of old-school CRT interference.

2. Camera Shake
This effect has become so much a staple of indie games that it’s almost a cliché by now but, what the hell – it looks good! Applying the effect was a bit more complex than I thought as it needs the appearance of randomness without being genuinely random (because a genuinely random shake can appear to stick at times). My final approach was to take a {1,0} vector, rotate pseudo-randomly, and then multiply the camera offset by the strength of impact on the x and y axis. For the pseudo-random rotation I always rotate by at least 90deg from the last ‘shake’ and then add another random amount between 0 and 180deg, this gives the appearance of randomness but always ensures there’s a ‘whole lot of shaking going on’. I also keep track of the ‘static’ camera position so that the ‘shaken’ position is always offset from the ‘static’ position and you don’t get a ‘brownian motion’ type effect with the camera movement which would upset the standard camera taking of the player.

3. Impact Shader
This was the effect that took the longest to get right. In my head I wanted an effect applied to the terrain that was kind of a cross between ‘double vision’ and the ‘vibration lines’ you might see on static illustrations to give the impression of movement. I also wanted the effect to look a bit glitchy.

First step was, whilst the effect was in progress, render the entire terrain to an offscreen image rather than rendering directly to screen. The shader could then be applied to the entire terrain rather than each individual component of it which would be both inefficient and cause visual issues.

I then started by applying a shader that simply rendered the whole terrain in a flat colour with some scaling distortion applied, the scaling varying according to strength of impact. I found I had to apply this shader three times in order to get the ‘double vision’ effect on the top, left and right of each building.



This was too extreme so I toned things down a bit...



I then tried applying some raster lines to the effect and found this looked best if I applied horizontal raster lines when the shader was distorting vertically and vice versa. This gave a ‘vibration line’ effect around the buildings.



Next I tried randomizing the amount of scaling every x pixels – so there would be more distortion at certain, regular, points. This gave a ‘spiky’ effect to the shader that I thought looked pretty cool.



Lastly I varied the amount of scaling distortion on each axis based on the direction of the player’s travel and also added a certain amount of pixelation, again dependent on the direction of travel. I’m pretty pleased with the effect now though it has taken a hell of a lot of tweaking to get this far. No doubt I won’t be able to resist tweaking it some more either!

Here's the (possibly) final effect with scanner distortion, camera shake and latest version of the  impact shader.



Dev Time: 1.5 days
Total Dev Time: approx 44 days

[bitbulldotcom]

2D or not 2D? That is the question!

It’s funny how this stuff works. You design sprite A and are perfectly happy with it, then you add sprite B which you feel is even better and sprite A now seems rather lacklustre in comparison. So you go back and tweak sprite A – which is great, only sprite B now seems to have lost its sheen a bit and needs a bit more work. And on and on it goes…

Looking back on this Devlog I’ve been through this process a few times and this week I’ve been bitten by the bug yet again. Even though I know this is a 2D game I was feeling that the buildings that make up the terrain just felt a little too 2D (22D?) and needed something to give them a bit more depth.

I remembered how @PVBroadz had been through similar a process when we were working on Attack Of Giant Jumping Man (he blogged about it here) and I felt a similar solution would work for Jetboard Joust.

So I started redrawing the buildings – keeping the same ‘space aztec’ feel but this time imagining that they were viewed from a kind of flattened ‘side on’ perspective, a bit like Zelda’s ‘top down’ 2D only from the side. As I’m restricting myself to an 8 colour monochrome palette it was tough to get the shading right (really I think the side section should be darker but then I run out of dark tones) but I think the result looks pretty good.



Trouble is, these versions, whilst they certainly looked more solid, seemed too heavy and ‘brick like’ in-game. I attempted to counter this by designing a bunch of more ‘open’ tiles and making sure there was at least one ‘open’ tile between each ‘solid’ tile. The more ‘open’ tiles were a lot harder to get right and I spent a long time fiddling about with the way the shadows worked.



The ‘open’ tiles seemed to work but I didn’t think the arched tiles I had designed (even though I was pleased with them individually) fitted in with the overall, more geometric look of the game. Consequently I decided to bin these (always difficult when you’ve spent some time on something) and create a bunch more based on more geometric forms instead. I also added a subtle one-pixel indent between the ‘solid’ tiles which also seemed to break up the regularity a bit.



I’m pleased with the end result now and think the buildings look much better than they did. There is still room for improvement (isn’t there always) and I think with a bit of effort I could get some really interesting Escher-style connections going on – for now it’s time to park it though!

Dev Time: 1.5 days
Total Dev Time: approx 45.5 days

[darthlupi]

What a great combination of games you are going for there!
I like the attack you perform with the jet board, but I couldn't help thinking it looked a bit chaotic and hard to predict.

I was thinking it might be rad and easy to predict if the flow was somethign like this:

1. Player triggers / charges the board attack -
   a. Maybe this creates a line on the screen or beam showing where the board would go.
   b. Player freezes on the screen during this time.
2. Player unleashes board attack and instead of jump with board the plyer jumps up and the board shoots out.
3. Board finishes it's attack boomerangs back and player lands on it.

The reason this came to mind while watching the videos was that it looked hard to determine what the risk / reward was  for such an awesome combo creating move.  It felt like you were just flinging your player into doom.

The jumping straight up move would make it so that you would always know where the player was and risk leaving him vulnerable to attack.

This was just a quick impression from watching videos, but I felt like MAYBE it would be cool in the game and possibly worth sharing?

[bitbulldotcom]

What a great combination of games you are going for there!
I like the attack you perform with the jet board, but I couldn't help thinking it looked a bit chaotic and hard to predict.

Hi There!

Thanks very much for your input - the jump attack is actually a lot easier to predict than it probably looks! Because you have the scanner (which isn't always on show in the GIFs) it's very easy to see what's ahead and gauge if it's safe to jump, also the 'kill range' of the board is pretty large. If it becomes a problem I might give the player some kind of temporary invincibility but I don't think it will really need it at the moment.   

[bitbulldotcom]

Yeah I know, it’s been a while!

I’ve been working on the in-game audio fx for Jetboard Joust and it’s taken some time. That and I’ve had some time off over the Summer – it’s not often we get much sunny weather here in the UK so when we do you need to make the most of it.

As making music is pretty much an obsession of mine I am in the fortunate position of owning a reasonable amount of noise-generating hardware and software. For a project like this though one needs to set restrictions so I decided to create all the FX using the DSI Tempest.

The Tempest is billed as an ‘analog drum machine’ but really it’s much more than that. It’s a very flexible, polytimbral, six voice analog synth with a bunch of samples in there for added spice. I wanted a definite ‘retro’ feel to the FX without going down the road of actually emulating a SID chip or equivalent and felt that limiting myself to the six voices and two analog oscillators of the Tempest would give me that.

In addition I used a few outboard fx, mainly the Waldorf 2-Pole analog filter. This is a fantastic little unit and pairs great with the Tempest. The ‘rectify’ function brings a kind of analog bitcrushing type effect and the addition of a resonant high-pass filter means I could get even more gritty than the Tempest can go on its own (which is pretty gritty anyway). The 2-Pole can beef things up really nicely without totally destroying the bottom end (an unfortunate side-effect of the Tempest’s otherwise great-sounding onboard distortion). I also used the Sherman Filterbank 2 but, whilst I love the Sherman, it was really a little OTT for the job in hand and the Waldorf did just fine on its own on the whole.



As an experimental indulgence and for a bit of authentic ‘retro’ feel I purchased a couple of vintage digital fx units on ebay for around £30 each – a Boss RV-1000 reverb and a JHS DX-777 delay. I was really pleased with the way both of these worked out, they both sound really cool in their own way and restricting myself to these two units for ‘aux send’ type fx meant I could mix and record everything ‘live’ through my hardware mixer (a Soundcraft Spirit M12) – no software mixing and plug-ins required!



I think the Tempest worked out great for this task. It’s a machine that tends to get a bit of a slagging off for its (admittedly piss poor) MIDI implementation and arguably underpowered sequencer but there’s plenty to love about it and I don’t think I could have done this on any other single piece of gear. The real beauty of it from a sound-design perspective is its extremely flexible modulation capabilities – five envelopes, three of which are assignable to pretty much any parameter, and an eight-slot modulation matrix offer an awful lot of flexibility. Add to that the ability to sequence and layer different voices and you have an extremely flexible sound design tool.

So I wasn’t designing the FX totally ‘blind’ I’d grab some gameplay footage for the appropriate effect and import this into Logic Pro. I’d then set the tempo and cycle length in Logic to match the tempo and beat duration on the Tempest. This way I could get the Tempest in sync with gameplay footage and tweak away whilst watching.

I’m pleased with the audio so far – it seems to have the full-on, in-your-face, vintage Defender/Robotron vibe I was going for. I still need to work on balancing some of the sounds and there are issues with some sounds cutting off and not playing properly in the MonoGame Windows GL port but think I can finally get back to coding for a bit and stop driving my family insane. You can hear all of the sounds (over sixty of them) here or click the video link below to get an idea of how the audio feels in-game.



Dev Time: 6.5 days (at least)
Total Dev Time: approx 52 days

[bitbulldotcom]

Been tidying up some loose ends that were annoying me before I can (finally!) start work on some new enemy types!

1. Fixed ‘Invisible JetBoard’ Bug
If the player destroyed an enemy whilst it was teleporting in the enemy’s jetboard would remain static and invisible in the world. Fixed this so that a teleporting enemy’s jetboard drops down properly.

2. Cropped Jetboard Bug
This one had been ‘bugging’ (groan) me for some time, it appeared that enemy jetboards were getting randomly cropped on occasion for no apparent reason. Turned out that it was a crop at all but the board wasn’t always orientating correctly when the enemy changed direction.

3. Particles Going Weird On Level Exit
You can see this issue at the end of the video here. To get the level transform effect I render the entire world to a back buffer and then apply a custom shader when rendering to screen – turns out that optimisations I made to my particle system meant I was rendering direct to screen all the time and ignoring the back buffer (oops).

4. Various ‘End Of Life’ Bugs
There were various problems to do with a player getting killed when already dead and controls still operating the jetboard when the player was dead – these were largely to do with the fact that enemies continue shooting at the player even when he’s already dead ‘just to make sure’. I like this though, it’s funny, so I kept it and fixed the bugs.

5. Disallow Enemy Abductions/Mutations When Player Dead
Not really a ‘bug’ per se but I didn’t like the fact that enemies could carry on abducting babies and mutating when the player couldn’t do anything about it – it didn’t seem ‘fair’ somehow. Now they just hover when the player is in the ‘lost life’ state which, though it doesn’t make logical sense, seem to work from a gameplay perspective.

6. Add Floating Scores
I just like these and nearly always put them in my games – something very old school arcade’ about them.



7. Improve AI In Small Gaps
Enemies were doing some pretty stupid things when the player took cover in a gap between two buildings. This was the result of an algorithm I wrote to calculate the closest building to the player which didn’t work properly, and part of the AI which tries to move away from the player if overlapping (ie avoid ‘kamikaze’ style behaviour). Now, when in a small gap, the enemy should move to the edge of the building that’s furthest from the player, turn around and start firing. It’s tricky to get this stuff right and fixing this took a while!



8. Improve Message Font
This was probably the bulk of the work. Previous in-game messages appeared on the scanner – I didn’t like this for two reasons; it got in the way of the action on the scanner and it necessitated the use of a very small font which made the messages unclear. Double fail. I have moved messages to the main game area which seems to work OK, designed a custom bitmap font for them based on the font I’m using for the HUD (but smaller), and also added ‘impact shader’ effects. Still a bit worried about them getting in the way of the action but actually it seems to work OK (I tried placing them over the ‘ground’ at the bottom of the screen as well but this didn’t seem to work so well).





Hopefully my next post will have a new enemy type!

Dev Time: 2.5 days
Total Dev Time: approx 54.5 days

[bitbulldotcom]

Really glad to be working on some new enemy types after wading through what seemed like an endless sludge of audio design and bugfixes! Feels like I’m finally making proper progress again.

I’m calling this enemy the ‘bomber’ – very much inspired by its namesake in Defender of course. I started by designing an enemy that was visually similar to the Defender bomber, a kind of robotic cube thing, but just couldn’t get anywhere with this. It seemed too devoid of personality compared to the other enemies in the game. I then tried designing a more humanoid robot with a jetpack but couldn’t get this to work within the restricted colour palette and resolution either. A fairly frustrating start.

Eventually I thought I’d try something with wings, I was originally thinking of a cross between a robot and a WW2 bomber, kind of like the planes in 1942, but as I started drawing it morphed into this sort of robotic angel which I liked – it reminds me of Antony Gormley’s ‘Angel Of The North‘. I added some particle FX and extra shading later but this was the basic sprite...



I wanted to keep the AI as simple as possible so settled on a simple algorithm that moves in alternate horizontal and vertical bursts towards the player. If contact is made with a building the sprite moves upwards until it is above the level of the building, thus freeing it to move left and right.

Surprisingly this straightforward algorithm worked OK, I was afraid the enemy would get stuck in endless loops against buildings if the player remained stationary and it did – but this was easily resolved by adding some randomness to the amount of movement in each ‘burst’.

The bomber drops bombs in its stationary phase between each burst of movement. The bombs are actually more like mines in that they float in the same place rather than fall to the floor...



I thought the bombs looked rather too 'static' once placed so added a small amount of oscillation to make the floating more interesting and a ‘warning’ vibration before the bomb detonates...



And that was pretty much it – there’s a few more subtle things going on like the damage inflicted by a bomb being proportional to how far the player is away from it but I won’t bore you with too many details. A here's a longer grab of the enemy in action - now on to the next one…



Dev Time: 2 days
Total Dev Time: approx 56.5 days

[bitbulldotcom]

Another new enemy in the bag – this one’s called the ‘mother’! At least that’s what I’m referring to it as now anyway.

As with the previous enemy it’s heavily inspired by one of the enemies from the original Defender, in this case the ‘pod’. The main ‘selling point’ of the pod is that when it’s destroyed it releases a bunch of smaller, faster enemies called ‘swarmers’ that use kamikaze tactics to attack the player.

The ‘mother’ works in pretty much the same way. As I’m going for a more ‘character’ based approach to most of my enemies I thought it would be nice to have the original enemy split in to smaller ‘mini me’ versions of itself when destroyed – a kind of mother/child thing.

For the design of the enemy I went for a kind of insectoid ‘space invader’ type approach. It’s consistent with the design of the ‘mutant’ enemy and also I knew I could get this to work at a very small size for the ‘children’. Strangely the hardest thing to get right here was the eyes which I wanted to look like a cross between real eyes and some kind of electronic ‘scanner’ – as though the eyes are on an LED screen or something with a lot of interference.



I’ve made the ‘mother’ probably a bit more dangerous in its original incarnation than the Defender ‘pod’. The AI tracks the player in ‘bursts’ similar to the ‘bomber’ enemy but not restricted to either purely horizontal or vertical movement. It uses a similar simple technique to avoid getting stuck in between buildings as well, ie when it collides with a building it will move upwards until above the level of the building. It also fires slow-moving bullets.

The ‘children’ were basically an extension of the ‘mother’ class with different motion parameters so, thankfully, it didn’t take long to get these up and running at all. I added particle effects to both, a kind of anti-gravity field or something. Note how these get disturbed when the enemy collides with a building or takes damage!



I spent quite a while tweaking the motion parameters of both mother and children, both to get them to feel right in relation to each other and also to get the children to feel like they were moving in a ‘swarm’ without working too obviously in unison. The actual ‘birth’ sequence took a while to get right as well, it needs to be slow enough to see what’s going on yet fast enough to feel like the children are being propelled out as speed. I also added some particles to the birth sequence to give is some more ‘pazazz’. Needs audio too..



Here's a little video compilation of some evil mothers... can only capture at 30fps unfortunately.



Dev Time: 2 days
Total Dev Time: approx 58.5 days

[bitbulldotcom]

The next enemy is the last from Defender I need to (loosely) implement. The Defender version is called the ‘baiter’, a small UFO that appears if you take too long to complete a level and gives you all kinds of grief. My version is similarly evil so I’m calling it simply ‘The Bastard’ – because it’s a bit of a bastard.

I thought I’d keep a ‘flying saucer’ aspect to the character design so we have a little alien dude piloting a UFO. It didn’t take me too long to get the basic design sorted but the animation was a bit of a pain. The little spinning antennae at the bottom of the UFO needed to animate at a different rate to the rotation of the UFO itself which meant I needed to split the enemy into two different sprites. Then I thought the pilot looked a bit static and I should try and animate him simply so it looked like he was flipping various controls to steer the craft – this looked rubbish on a loop so I split this out into yet another separate sprite and chose the animation frame randomly rather running on a sequence. It also animates a lot slower than the craft itself. Final touch was to add some particles for an ‘anti-gravity’ type effect.



I could base the motion heavily on the motion for the ‘mother‘ (see above post) which is one of the reasons this enemy was fairly quick to implement. Every 10 frames the ‘bastard’ samples the player’s location and moves towards it. It’s much faster than the ‘mother‘ and the sampling rate is more frequent which makes it a lot more dangerous! To add a slightly more erratic feel I skip the sampling of the player’s location every three iterations or so.



This straightforward AI worked pretty well but I wasn’t happy with the way the enemy sometimes hovered over the player. I improved this by making the enemy ‘retreat’ when it collided with the player or fired a bullet. It alternates the retreat by flying to the top right, top left or directly above the player. This attack/retreat motion, whilst still pretty ‘dumb’, looked considerably more ‘intelligent’ than simply ramming the player the whole time.



The ‘bastard’ is pretty dangerous – maybe too dangerous. Now I’ve got a few different enemy types in place I think I’m going to have to start working on different weapons and the weapon upgrade system so I can see how these enemies play out against a more powerful opponent. The ‘pistol’ I’ve implemented so far is to be the most underpowered weapon in the game after all.

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

[bitbulldotcom]

Time to leave enemies for the time being and move on to weaponry – really the last missing piece of the puzzle. If I’m going to make any new enemies they need to be tougher and it’s impossible to gameplay test them effectively with the underpowered pistol which is all I had implemented up to this point.

The first weapon I wanted to build was a shotgun, but before I got into designing the weapon itself I needed to think a little harder about how weapon swapping and ammo supply works in the game.

Up to this point if you run out of ammo you basically have no useable weapon available. This makes logical sense but seems kind of harsh. It becomes impossible to defend oneself so, unless there is an obvious ammo cache onscreen, death is pretty much inevitable. I needed to find a balance between keeping the necessity to drop down and pick up ammo caches (I like this part of the gameplay), not leaving the player totally ‘high and dry’ and not leaving them overpowered either.

My current solution to this is to use the pistol as a default weapon. If your current weapon runs out of ammo you will switch to the pistol automatically – if your pistol runs out of ammo then an ammo cache will automatically drop onscreen making it easy to reload but still, hopefully, enough of a pain to make the player try and avoid this situation if possible. Your ‘old’ weapon is placed in a weapon crate somewhere in the world meaning it can be retrieved and is not lost for good. These aspects of the game design may well need tweaking but at the moment this seems to provide a decent balance between the various parameters.

So, once the above was implemented, shotgun time! I thought the shotgun would be a pretty easy weapon to create but as it turned out I was wrong, no surprise there then.

First thing I did was work on the visuals. I ended up adding three different particle effects – one to represent the ‘pellets’, one for smoke from the barrel, and one as a kind of abstract explosion effect to give some idea of the effective range of the blast. I also added a very short sprite-based ‘muzzle flash’ animation. My weapon superclass already handles barrel recoil and recoil for the player so I put a nice bit of knockback in there to make the blast seem pretty weighty.



Lastly – collision detection. This is the part that I thought would be easy (as the shotgun blast is a one frame ‘hit check’) but turned out to be more complicated. You can’t get away with simple rectangle-based collisions (as I use in the rest of the game) as the blast range is really an arc, like a slice of pie. Fortunately some time ago I spent a while implementing some SAT-based collision detection routines in my game libraries so I could call on them now – luckily they worked (which is a good job as I remember SAT-based collision checking was pretty complex and I had no desire to go back rooting around that code)! What I do is approximate the blast ‘arc’ with a simple polygon and check whether that intersects the enemy’s collision rectangle. This seems to work fine (though I ended up widening the ‘hit range’ around the muzzle of the shotgun more than you see in the GIFs). I calculate the damage done to each enemy based on the distance from the muzzle both horizontally and vertically – a maximum 50% reduction in damage each way.



The next issue to raise it’s head was that I had to stop the shotgun blast being effective through buildings. This seemed like it was going to be complicated, I’d have to trace a line between the blast and the point it hit the enemy and see if any buildings intersected it, but I managed to implement a much cheaper solution which seems to work fine. All I do is see if there’s a side of a building between the shotgun muzzle and the enemy. If there is and the muzzle is below the level of the top of the building I assume the blast is blocked (as it would be the vast majority of the time). If the muzzle is above the top of the building and the top of the enemy is below the top of the building I also assume the blast is blocked. These two simple checks seem to cover off most scenarios realistically enough.



Once the shotgun was working as a weapon for the player I then needed to try arming the enemies! Because of the way I have structured my classes this was pretty simple but unfortunately it uncovered limitations in the enemy AI.

Up to this point I had been assuming an ideal place to shoot at the player is with the barrel of the weapon level with the centre of the player. This is still true with the shotgun but it won’t be true for all weapons (for example a grenade launcher) and there also needs to be additional logic for when an enemy decides whether to fire or not which takes into account the blast range of the shotgun.

So what I’ve done is implement two different methods as part of my Weapon superclass. One returns the ideal height at which to fire at the player and the other returns ‘true’ if the weapon is likely to hit the player if fired. These can both be overridden in the subclass to provide more weapon-specific logic. This architecture works great – enemies with shotguns are pretty deadly now and I’ll easily be able to extend to different weapon types to make enemies automatically change their behaviour based on which weapon they are carrying.

Last touch was to design some audio for the shotgun blast. I was going to leave any additional audio and do it all in one batch but seeing that shotgun fired and not make a sound was disturbing me!



Dev Time: 2.5 days
Total Dev Time: approx 62 days

[bitbulldotcom]

Ah, UI work! Truly the most enjoyable part of building a game. I love building user-interfaces, it’s so much more fun that all that irritating ‘gameplay’ stuff. How I wish I could churn out menus and buttons and fiddle with bitmap fonts all day!

Not.

Building a decent user-interface is often a fiddly and mind-numbing task, yet it’s an absolutely essential part of the overall gameplay experience so cannot be skimped on. Fortunately the only menu-driven part of Jetboard Joust is the ‘weapon upgrade’ stage so I don’t have too much to worry about, but I need to get it right nevertheless.

Seeing as I have just finished the first alternative weapon I decided to bite the bullet (no pun intended) and just get on with the weapon upgrade screens. As expected it was a fairly fiddly and time-consuming task.

So, first step – design the UI. This part wasn’t so bad, I knew what info I had to get across so just went for a layout that was as clear and straightforward as possible whilst retaining a degree of visual interest. I wanted to keep consistent with the game HUD as well so in that sense a large part of the ‘look and feel’ was already defined. It took a few hours to get something I was happy with.



Only problem was it became apparent that I needed a second, larger bitmap font in order to bring some variation to the design. I went for one in the style of the numbers in the HUD which seemed to work well but, as with all bitmap fonts, it took a lot of fiddling around to get it working correctly.



I also thought I needed larger icons for the upgradeable items so had to design an icon for the pistol and shotgun. At the moment I’ve set this at 32*32 though am wondering whether I might need to accommodate different sizes.



Next step – build the design in code. I decided to do all the drawing in code so that it would be easy to expand the text boxes etc if I needed to rejig the design. Again, a pretty tedious and time-consuming process. It paid off though as there were a couple of instances where I needed to change things in the layout (due to underestimating the space I’d need for text) and this was simply a matter of changing the value of a couple of variables rather than redrawing everything in photoshop. The UI is drawn in three separate layers, the background ‘connectors’, the boxes and lastly the text and icons.

I then needed to get the text read ‘live’ from actual data. As it may not just be weapons that are upgraded I defined an IUpgradeable interface that specifies
the functionality an object must implement to be ‘upgradeable’. Maximum and minimum values are set for the various stats and upgrade costs and the values for each ‘level’ calculated on the fly. Spent quite a while on this and implementing it in the two weapons I’ve design so far.

This all worked fine but I couldn’t help feeling that the UI just felt rather ‘dull’. I needed something to give it a bit more life so decided to try and implement a kind of ‘radio static’ type effect along the lines of the interference effect you get on the scanner when the player takes damage. The scanner interference shader was the obvious place to start and by using this, and an awful lot of tweaking, I was able to get an effect I was happy with. I didn’t end up changing the shader code at all, just messing with various parameters. Only the layer with the text and icons is drawn using this shader.

Last task – make it work! I’ve tried to make the process as clear as possible for the user and give visual feedback where necessary – I’ll also add auditory feedback at a later stage. You can see I’ve ‘greyed out’ the upgrade cost and button if the user doesn’t have enough cash and show a confirmation message if the user does purchase an upgrade. the process is fairly simple so hopefully I shouldn’t need much more than that but I’d be interested in any feedback…



Dev Time: 5 days (told you this was time-consuming)
Total Dev Time: approx 67 days

[bitbulldotcom]

Yeah, I know, been a bit quiet round here. Had a bit of time off!

Been working on some more ‘polish’, implementing stuff I’d been putting off for a while and getting various aspects of the gameplay to work together. Here’s what’s been on my ‘to do’ list these past few days…

Add More Cash
I only had one denomination of coinage which clearly wasn’t going to be enough to cover all the cash rewards in the game, not without spawning a ludicrous amount of pickups anyway, so I’ve designed and added a few more. Now there’s five different types of coin 1, 5, 10, 50 and 100. I may have to add a 500 later on.



Bloodstains
One of my favourite mechanics in the ‘Souls’ games is the way that, when you die, you lose all your ‘souls’ (the game’s currency) and can only retrieve them by returning to the place you last died and touching your bloodstain. It can be incredibly annoying losing all the ‘cash’ you’ve earned but it really makes dying something to be avoided (unlike in many modern games where dying is practically meaningless) and adds an extra tension to the next life too. I’ve implemented a similar mechanic whereby you lose all your cash on death and have to return to your abandoned jetsuit in order to retrieve it.



Weapon Unlocks
I’ve now properly implemented the feature whereby picking up an enemy’s jetboard unlocks the weapon they were carrying for your own use. A weapon crate will automatically spawn when this happens giving the user a chance to pick up the weapon they have just unlocked.



Upgrade Equipment
I’ve properly implemented this as part of the gameplay cycle so you are given a chance to upgrade equipment at the end of each level. This took longer than it should! Also added the jetsuit itself as an upgradeable item.



Redo Jetboard Particle FX
I was never that happy with the vertical thrust effect on the jetboard so I’ve redone this giving it a more ‘anti-gravity’ quality. I’ve also tweaked and re-aligned the particle fx for the horizontal thrust.



That’s it. I am getting there, slowly. The next task is to revisit the ‘difficulty’ algorithms for level creation to make them take account of different weapon and enemy levels.

[bitbulldotcom]

With all the core gameplay elements pretty much in place it’s time to get back to some serious gameplay testing and start thinking in more detail about how I manage the difficulty curve within the game.

I’d already put quite a bit of thought into this as discussed here, but, as is so often the case, Jetboard Joust has grown in complexity fairly significantly since I posted that and my ‘procedural difficulty’ code needed to be reworked in a major way.

I’m still starting from a similar standpoint in that I allocate a difficulty value for each level and then create random waves of enemies that total that difficulty score. Now, however, I have different RPG-style ‘character-levels’ of enemies and weaponry to consider.

Firstly what I do is allocate a series of character-level ‘stats’ to each enemy and weapon type. I set a minimum and maximum value for each stat and the values in between are calculated automatically. Some values (e.g. health, weapon range) are consistent across all enemies and weapons but not all. Every weapon and enemy has a ‘difficulty’ stat.

I then create an EnemyDefinition for each enemy/weapon combo. This is a lot of definitions as I have to have create a separate definition for every combination of each character-level of enemy and weapon.

When a level is created my first approach was to split the total difficulty score into a set of six ‘batches’ of enemies that are released at set time intervals. The enemies that make up each batch were chosen at random from the EnemyDefinition collection. If a batch of enemies is destroyed the next one is released immediately.

This worked pretty well but the combination of enemies was too random and in order to get a more playable selection I needed to implement a few restrictions…

1. Every enemy and weapon type have an ‘intro level’ so that they don’t appear until a certain level of the game has been reached.

2. Every enemy and weapon type have a’level up rate’ that affects the way their ‘character-level’ progresses throughout the game – so, for instance, an enemy with a ‘level-up rate’ of 2 and an ‘intro level’ of zero could only appear at character-level 1 for the first two levels of the game, then at character-level 1 or 2 for game levels 3 and 4 and so on.

3. Only certain enemies will try and abduct the alien babies(!) and as this is fundamental to the way the game plays I needed to ensure a certain amount of ‘baby-chasing’ enemies per batch.

After implementing these restrictions the enemy selection was much better but I realised the process was still flawed. As I was choosing enemies from the set of EnemyDefinitions at random (albeit with the above restrictions) the selection was skewed towards certain types of enemies. There would always be many more valid definitions for lower ‘intro-level’ enemies (especially as we have a definition for every character-level and weapon combo) resulting in far too many of certain enemy types in the game.

To solve this I needed to create a structure to store the valid EnemyDefinitions that was not simply a flat list – so I created the wonderfully-named EnemyDefinitionBucket class.

A EnemyDefinitionBucket contains a horrible-looking data structure that’s defined like this…

Code:

SortedDictionary<EnemyTypes, SortedDictionary<WeaponTypes, List<EnemyDefinition>>> dictionary;

..so first we have a collection of every valid EnemyType in the bucket, then for each EnemyType a collection of each valid WeaponType, and finally for each EnemyType/WeaponType combination a list of each valid character-level of enemy and weapon that fits that combination.

Now when I choose a random EnemyDefinition I first select a random EnemyType, then a random WeaponType, and finally a valid EnemyDefinition that matches that combination. This ensures that all enemies and weapons appear on equal footing.

Only that wasn’t quite good enough! In practice the enemy/weapon selection needs to be skewed towards those that have an ‘intro level’ nearest the current game level. Hence the reason I have used SortedDictionary rather than a standard Dictionary – this way the enemy and weapon type ‘keys’ can be indexed in order of ‘intro level’ and I can implement a sine-based distribution curve that favours the ‘higher’ items when choosing at random. The EnemyDefinitions are also stored in a sorted List and selected in a similar way.

Finally I think that’s done it, now on to tweaking the various ‘character stats’ which is another rabbit-hole.

And, sorry, this post doesn’t contain much to look at so I’ve just included some random gameplay footage – finally found an app Capto that grabs at 60fps!



Dev Time: 3 days
Total Dev Time: approx 74.5 days

[bitbulldotcom]

Since the last post I’ve mainly been tweaking – playing the game over and over again, adjusting the various difficulty parameters and noting down and fixing various bugs that crop up. My aim at this stage is to get to the point where I have an ‘alpha’ version that can exist as a playable demo, albeit with a very limited set of weaponry and enemies. I’m getting there!

So, in no particular order, heres some of the stuff I’ve been working on…

The Dawdle Police
I’ve made the ‘bastard‘ enemies operate similar to the ‘baiters’ in Defender in that they only appear once the player has spent a certain amount of time trying to complete a level and (unlike other enemies) don’t need to be destroyed in order to complete a level. More bastards appear the longer the player hangs around adding even more of a sense of urgency to the proceedings.

The Pyramid
Some of the more observant readers may be wondering why there are two warp gates that appear at the end of each level. Well, in a nod to ZX Spectrum ‘classic’

, the gate you choose affects the level you’ll appear in next, so rather than a linear arrangement of levels we have a pyramid-type structure with each row defining the difficulty level and each column a different combination of enemies, terrain and weaponry. I will probably add special collectables at certain locations to add an exploratory element to the game. I’ve always had this functionality planned from the start but have only just implemented it properly.

Mutant Frenzy
In another nod to Defender, now if you’re careless enough to let all your babies get abducted a ‘mutant frenzy’ is unleashed! Every jetboard-riding enemy mutates and every remaining attack wave is released. Basically it’s total chaos and you probably won’t last long after this happens!

Score Combos
Killing enemies in quick succession now ups a bonus multiplier which multiplies both the score and cash awarded. It’s a good way to earn extra cash and I like the way it adds to the ‘pinball’ feel of racking up large amounts of points.



Extra Lives
Extra life pickups now appear when a certain score threshold is reached. You’re going to need them!



Game Over
I’ve added a fixed number of lives per game and the ‘game over’ message. Spent quite a while tweaking the ‘game over’ effect!



Jetsuit and Jetboard Upgrades
I’ve now fully implemented the code that makes your jetboard and jetsuit upgradeable items. The upgrade state of all equipment is now persistent across games.



Plus a myriad of other small improvements and bugfixes.

I may now add one extra weapon type (machine gun) and possibly a couple of extra enemy types before moving on to add a few elements of missing game audio, background music, and then a first implementation of overall menu UI.

Dev Time: 5.5 days
Total Dev Time: approx 80 days

[bitbulldotcom]

This week I’ve added a couple of extra jetboarding enemies and a new weapon – and I think I have enough content now for a playable demo! Just need to to sort the main menu out (groan) add a few more sound fx and (probably) background music. Here’s a bit more about the new stuff that’s been added…

The Gatling Gun
In operation this is really like a rapid-fire pistol, therefore it was pretty easy to subclass the existing ‘pistol’ weapon and change a few parameters to get it working. The hardest thing was getting the recoil to feel right – I wanted enough recoil for it to feel slightly ‘out of control’ and unwieldy but (obviously) not enough to be unplayable. I’ve given it a slightly lower damage-per-bullet than the pistol but this is more than made up for by the rapid firing. Here's a version with too much recoil...



...and here's the finished weapon in action...



Improved Shotgun Blast
One thing I realised whilst playtesting was that the existing shotgun blast was just nuking everything within its range rather than taking account of the fact that some enemies would shield others from the blast, like this...



Fixing this accurately seemed like it would be a mathematical nightmare (I’m not too strong on geometry) but I managed to implement a slightly ‘fuzzy’ solution which I think will be good enough. What I do is order all the enemies that intersect the blast region by their distance from the gun barrel. I then iterate through them in order creating a vertical ‘blocked zone’ for each one based on the combined height of the previous enemies in the list. If more than 50% of the current enemy intersects this ‘blocked zone’ I assume it has been shielded from the blast. It works here anyway...



The Assassin
This type of enemy is pretty similar to the omnipresent ‘minion’ only they don’t try and abduct babies, they just go all out for attacking the player. This enemy uses the ‘skullhead’ sprite that I’d already designed and required no additional AI work (just adjusting existing parameters) so it was really easy to get up and running, and they're pretty deadly...




The Bodyguard
Bodyguards have a pretty specific AI in that their main aim in life is to protect other enemies that are in the process of baby-snatching. I thought this would be pretty simple to get working but it was a lot harder than I thought to get something that looked decent. This is the basic framework of rules I ended up with…

– Bodyguards seek out the closest baby-snatcher to protect
– Once a bodyguard gets close enough to protect someone they’ll never desert them
– Only two bodyguards can protect a baby-snatcher at one time
– If there’s more than one bodyguard protecting a baby-snatcher they’ll stand guard on opposite sides
– Bodyguards never stray to far horizontally from the baby-snatcher they;re protecting but they will move vertically to attack the player

…there’s a bit more to it than that but these are the key AI decisions that are made. Bodyguards have a lot of health but move relatively slowly and I’ve tried to design the sprite to reflect this, it took a while getting them to look 'hench' with so few pixels to work with...



And here they are in action...



I haven’t fully playtested all this yet but will be doing so over the next few days as I add the outstanding audio fx.

Dev Time: 3 days
Total Dev Time: approx 83 days

[bitbulldotcom]

Woohoo – it’s my 50th DevLog!! Sadly no-one is throwing me a party (or any money).

Just been finishing off the final pieces of missing audio for the alpha version. As before I’ve done everything using the DSI Tempest and a couple of fx processors – namely an ancient Boss RV-1000 reverb and, this time, a Pigtronix Echolution 2 on delay duties.

The only one that caused an issues was the ‘combo’ effect – I wanted an arpeggio-style sequence that played for longer depending on how much of a combo was awarded. Pretty easy to build the audio from a series of separate notes and step forward each time another enemy is destroyed in the combo ‘chain’, harder to stop several notes from all playing at once if several enemies are destroyed simultaneously (ie with a single shotgun blast).

So I built a ‘SequenceAudioPlayer’ class that steps forward in the sequence each time Play() is called but that queues notes to be played after a set interval if Play() is called too quickly. This way I get a nice ascending arp even if multiple enemies are dispatched at once.

You can hear a bunch of the new sounds (as well as some of the old ones) in these short gameplay vids.







Dev Time: 1.5 days
Total Dev Time: approx 84.5 days

[bitbulldotcom]

Happy New Year readers (I presume I have some readers here judging by the views even though comments are pretty rare)! I meant to post this before Christmas but it got overlooked in the holiday mayhem - plus I've had a raging cold/flu which has just morphed into sinusitis. Nice.

This has been another one of those tasks I’d been putting off for a long time. The main app framework, options menu, instructions, etc etc.

I already had a set of classes that handled all this stuff, including a menu, instructions, highscores, about pages and a bunch of other functionality but it was incredibly bloated and old. In fact, looking back at the original file I see I created the first version in 2003 so that’s 13 years ago! It’s been ported from JavaME and had all sorts of cruft in there to deal with the idiosyncrasies of ancient mobile phones plus maintaining backwards compatibility with titles that will (thankfully) never see the light of day again. It’s served me well but it was time to start again (more or less) from scratch – even though I knew that was to be a fairly painful process.

So I kept some classes that were written comparatively recently and were relatively bloat-free (the actual menu itself and the highscore management stuff) and got rid of everything else, adding the necessary code back in a piece at a time, refactoring it, and going through every line to trim all the bloat. It took me over a day just to get the thing to compile!

A part of the process I also streamlined all the graphics scaling to work with pixel-art games (where everything is drawn from one set of graphics rather than loading in a separate set for different screen-sizes) and improved some of the visual UI feedback, animations and tweening. There may be a bit too much ‘bounce’ in some of the tweens, I’m using an ‘exponentially decaying parabolic bounce’ tweening algorithm that is all over the web but I can’t find anything to specify the ‘amount’ of the bounce and the maths is a bit over my head. I will try and get my head around it at a later date.

And now I have a streamlined, bloat-free ‘main app’ class that manages the main menu, highscores and instructions. There is still some functionality I need to add (and some that has moved to new classes) but I have ditched almost 4000 lines of confusing and redundant code which is a good feeling. Here's the main menu in action...



One aspect that I spent a fair bit of time on was the formatting of the instructions pages. I wanted a system that would be very easy to edit, reuse, and apply to other elements of the app (such as about screens etc) so created generic InAppDoc and InAppDocViewer classes. An InAppDoc is created from an XML document which defines various elements such as pages and paragraphs of text but can also have custom elements that can be rendered by a specific game (such as individual sprites or sprite groups). It should be straightforward to extend this system to cope with localisations or even to add custom tags for more complex page layouts etc. An example of the XML used to create the series of test pages on the right is here. I need to fix those flashing arrows!



Dev Time: 7 days
Total Dev Time: approx 91.5 days

[maiscrudo]

Awesome devlog!
I really like the game concept, it reminds me of Falcon Patrol on c64, the radar in particular.
Love the physics and also dig the visual style, a mix of downwell and Luftrausers.
Nice work with shaders, I always end up in blasphemy everytime I have to deal with them.
This is actually a game I would play a lot.

[bitbulldotcom]

Awesome devlog!
I really like the game concept, it reminds me of Falcon Patrol on c64, the radar in particular.
Love the physics and also dig the visual style, a mix of downwell and Luftrausers.
Nice work with shaders, I always end up in blasphemy everytime I have to deal with them.
This is actually a game I would play a lot.

Thanks very much for the feedback - really glad you like it!!

Funny you mention Luftrausers as I'd never actually seen it until a couple of days ago when I was watching some conference talks by the guys from Vlambeer - I need to improve the way my camera works and I think I could learn a lot from that game - it looks very cool.

[bitbulldotcom]

Been really ill over Christmas with a very heavy cold/flu and it hasn’t got any better this year as it appears to have developed into sinusitis. Now at least I know why I can barely walk up the stairs without feeling like my head’s going to split open.

So it’s been tough trying to work this week – but I’ve managed to get some done! It was quite a relief not to have to dive right into coding but to start with a fairly significant art task instead – the design of the game logo.

I had an idea of the type of thing I wanted but, as with all art projects, I started by gathering reference material and trying to whittle down ‘stuff I like’ into ‘stuff I like but might have a vague hope of achieving with my limited skills in a reasonable amount of time’.

I eventually settled on four key reference logos…



1. National Petrol
The ‘National’ brand is long-since defunct but I have fond memories of it from my childhood as National petrol stations were the only place in the UK that you could buy Smurfs! I really the the dynamism and simplicity of the main pictogram which has an almost Soviet constructivist feel.

2. Go Jetters – CBeebies
I’d never heard of this TV show (my kids are too old) but I was looking after my niece and nephew over the holiday and they had an activity book from the series. The ‘jet’ reference is obviously relevant and again I like the simplicity. The oblique effect on the type is subtle but adds a lot of dynamics.

3. Trans Am – Ultimate Play The Game
OK so this one’s kind of horrible but cool at the same time. As a kid the ‘Ultimate’ games were like the holy grail of Spectrum gaming. I originally looked at the ‘Jet Pac’ logo for obvious reasons but thought it too heavy and overworked. There’s more of a sense of motion to the ‘Trans Am’ logo and I like the ‘silver dream machine’ feel to it – even if that 70s airbrushed effect is something I’d normally avoid like the plague. It works in context.

4. Asteroids – Atari
I’m a massive fan of the Atari arcade service manual art but the trouble with it as reference is that it’s very intricate and would take more time and skill than I have at my disposal to pull off effectively. The nice thing about the ‘Asteroids’ logo is that it uses a very straightforward typeface in a pretty straightforward manner yet still works extremely well.

I decided to start working in Illustrator rather than Photoshop and to restrict myself to pure black and white. Restrictions are good – and I knew that if I had something that looked good in a single colour it would be easy to add colour later whereas trying to retrofit a colour logo into black and white can be a nightmare. It’s a similar approach to the one I’m taking with the actual game art.

Once I had my reference in place I began experimenting with different typefaces*. Initially I thought I needed something that looked a bit ‘sci-fi’ but, despite finding some nice fonts, everything I tried looked either incorrectly proportioned or too gimmicky. Here's some of my failed attempts...



The only typeface that seemed to hit the spot was Helvetica Neue Black Oblique which is very similar to the font used in the Asteroids logo. I rotated the letters anti-clockwise so that the uprights sat directly vertical, spaced the letters very tightly (so much so that some of them joined together) and finally felt like I had something I could work with. I also sheared the logo slightly so that it sat at an exact 25% gradient in order to make it easier to convert to pixel art.

Next step was to add something to make the logo seem more unique and give it more of a feeling of motion. I started by add some ‘wings’ to the tops of the ‘J’ characters based on the ‘winged helmet’ of the National logo. This worked right away! I tried some more curvaceous and illustrative alternatives as well but these all seemed too flouncy so the hard-edged brutalist approach won out ( a good job really as it would be a whole lot easier to realise as low-res pixel art). I also added similar ‘wings’ to the right side of the logo which seemed to balance better.

I then tried to increase the motion effect by adding Dyno-Rod style arrow-type shapes at the top-left of letters where there was a lot of negative space. As well as making the lettering seem more dynamic this also had the benefit of filling in the negative space, thus making the letters seems as if they were spaced more evenly.

Lastly I felt the logo needed something to kind of tie it all together a bit more so I experimented with various ‘underline’ effects and illustrative elements, eventually settling for a simple ‘double underline’ consistent with the National-style ‘wings’ on the letters. It doesn’t look like it but the little angled section on the right of the underline took a long time to get right!

Once this was in place I noticed that the ‘wings’ gave the type an almost 3D effect – I liked this (for some reason it reminded me a bit of the 20th Century Fox logo) so I tweaked the angles and lengths to exaggerate the effect.



At this point I was pretty happy with the vector version so I moved on to converting it to low-res pixel art. I began working at a resolution of 256 pixels wide as this seemed to scale nicely for the title screen.

The most time-consuming stage of creating the pixel art version was tidying up the original, rasterized, black and white version so that it looked as good as possible. I realigned all the angled lines so that any that run parallel ‘step up’ at the same time and also changed the angle at the end of the ‘wings’ so that this ran at 45 degrees which looked a lot tidier and didn’t really seem to affect the overall feel.

After this it was a matter of playing around with outlines, drop-shadows and highlights in Photoshop until I found something I liked then tidying it up manually. The final stage was to add some ‘shine’ to the letters (a bit like the ‘Trans Am’ logo) and a final bit of texture by manually dithering the edges of the ‘shine’ and adding some rivets.



I’m pretty pleased with the end result – it looks clear, dynamic, and has a kind of accidental retro/art-deco sci-fi quality that I like. Reminds me of ‘Flash Gordon’ or some of the work by French comic artist Moebius, neither of which are reference points to be ashamed of. The pixel art version could still do with more texture (possibly) but it was hard to do this with the limited palette I’d set myself, and these things can always be better so maybe I’ll revisit at some stage – for now though it’s time to get it integrated into the game! Here is is at 2:1 res...



* Whilst doing this I came across this really useful tool – it’s like Shazam for fonts and actually works (did for me anyway)!

Dev Time: 2 days
Total Dev Time: approx 93.5 days