Category Archives: Game Design

Jetboard Joust Devlog #59 – Alpha Launch!

Woohoo – major milestone alert!!

I’ve finally got things to the state where I feel like I can release a playable alpha. Yes, there are still a few bugs and things I need to refine in the game design but I think we’re pretty much there. What’s also great is, thanks to the great flexibility of MonoGame, I can also release a MacOS version. The MacOS port only took me just over a day and I may detail that in another post.

For those of you who just want to cut to the chase and download the thing click here!

And for those of you who are actually interested in the devlog here’s a list of the significant additions in this final round of tweaks, many thanks to the folks who gave me feedback at the pre-alpha stage…

Pistol Range
It became obvious from user feedback that the range on the pistol (the default weapon) simply wasn’t enough. Players found they had to get unnaturally close to enemies to kill them which often meant they crashed into them by accident. Consequently I have increased the initial range of the pistol by about 75%, though to compensate I have made the damage done tail off as the bullet reaches the end of its range.

Its better than it was but I’m not convinced I’ve yet solved this issue. It’s a bit of a delicate balancing act as I want the weapon to be meaningfully upgradeable, yet also powerful enough to start with and not overpowered later on. Also, because the enemies use identical weapons to the player increasing a weapon’s range/damage also increases the difficulty of those enemies that use it!

Another more radical solution I’m considering is to significantly increase the pistol’s range yet further (and maybe give it unlimited ammo) yet not allow it to be upgraded. This would make the start of the game considerably more approachable for new players and increase its difficulty later on as players wouldn’t have a strong default weapon to fall back on. It would also put more emphasis on managing ammo levels later in the game which could be a good thing.

Playing Catch
It has always been a feature of the game that catching an enemy’s jetboard before it hits the ground give both an ammo and a shield boost and is therefore preferable to waiting until it hits the ground (generating only one type of pickup). I didn’t feel this was very clear though so I have added mini shield/ammo icons to the enemy jetboards as they fall which will hopefully communicate that there’s goodies on board and these things are worth collecting. The player also gets a ‘nice catch’ message if they do this indicating that it’s a good thing to do (catching jetboards is also the way to unlock new weapons)!

Extra Life / Jetsuit Indicators
Picking up your abandoned jetsuit after you lose a life is a central game mechanic as it’s the way to recover lost cash and not lose out on valuable upgrades. Similarly extra lives in the game are pretty rare so when they do appear the player isn’t going to want to miss out on them. I talked about adding pickup indicators and detectors for other bonus items here and decided I had to do the same for jetsuits and extra lives as they are arguably the most valuable pickups in the game!

Microsite
Yeah, not really part of the game dev but I thought I’d include it anyway. I needed a microsite or landing page to distribute the alpha so went ahead and built one. I’ve included a simple signup for for a mailchimp list. Goodness knows whether anyone will use it but hopefully it’ll server some purpose.

Update Tracking
I’ve added a very simple way for the game to poll the web server, check whether an optional or mandatory update is available and notify the player appropriately. The alpha build will also expire after a set date (currently the end of June so plenty of time to play).

I may now take a break from gamedev for a bit as I have had to take on some appdev contract work (fortunately a pretty nice project) to top up my dwindling coffers. I will have to try and get a youtube promo done over the next few weeks though, and hopefully get the word out about the alpha.

Thanks for watching and please stay tuned…

Dev Time: 4 days (inc microsite build)
Total Dev Time: approx 115.5 days

previous

mockup_3x
Making It More Obvious That There’s Booty On Falling Jetboards

mockup_3x
Pointing Out The Player’s Abandoned Jetsuit


You Don’t Want To Miss Out On An Extra Life Either!

Jetboard Joust Devlog #58 – Almost At Alpha!

So for the last couple of days or so I’ve been doing an awful lot of playtesting and making what should be the final round of tweaks, improvements and bugfixes for the playable alpha. A large amount of this has been general tweaks to difficulty levels and the like which would be too numerous to list here but here’s a few specifics as to what’s been included…

Weapon Stashing
In order to prevent the player from overpowering one weapon and simply sticking with that I now switch to the default weapon on losing a life and completing a level. This isn’t such a big deal at the moment as there are only three weapons but there will be a lot more in the final game. In addition to this, weapons are no longer automatically reloaded when ‘swapped out’ meaning it’s possible to stash an empty weapon. As a consequence I’ve also made weapon crates display the amount of ammo in the included weapon. Stashed weapons retain their ammo between levels.

Controls
I’ve tweaked the controls a bit so that they are a bit less ‘binary’ and it’s easier for the player to make smaller movements. There’s a fine line here between being able to make subtle movements and being able to move quickly when necessary. I’ve moved to using lerp-based interpolation for the player’s vertical speed and also added the ability to ‘brake’ (cancel horizontal motion) by pulling directly down on the controller.

Camera
Slight improvements to make the camera track better when running away from enemies (ie not track as if you’re trying to attack an enemy that’s behind you). Again there’s a fine line here as sometimes you are ‘dogfighting’ with an enemy that’s behind you so what I do is make a decision based on how long the player has been moving in the same direction. Rapid changes of movement tend to mean dogfighting, continuous movement tends to mean running away!

Input And UI Labelling
I’ve checked all the dialog buttons in the game for keyboard and controller input and labelled them appropriately depending on the input method being used. If the game receives any controller input I presume the player is playing with a controller, otherwise I assume a keyboard is being used. I’ve also made dialog buttons and a few other UI elements respond to mouse input just for a ‘belt and braces’ approach. the game itself can’t be played with a mouse though.

Instructions
I’ve added some pretty minimal (but hopefully sufficient) instructions and a diagram of controls for both keyboard and controller input.

Enemy Randomizer
I’ve made yet more tweaks to the code that generates the levels so there’s a much better distribution of enemies. I’ve added a ‘Config’ class that contains all the definitions for enemy/weapon intro levels and difficulty settings in one place so it’s much easier to edit.

Baiters/Bastards
These are the enemies that appear when the player is taking too long to complete a level. Originally I had it so they didn’t need to be destroyed in order to complete a level (as in Defender) but I thought it was a bit weird getting the ‘all enemies destroyed’ message when there were enemies still present. Now the baiters have to be destroyed too but no additional baiters will appear once all other enemies have been defeated.

Bugfixes
Fixed a bunch, one of the most amusing ones was where an enemy’s jetboard would continue to fire after the enemy had been killed (if it was armed with an automatic weapon). This was funny but I couldn’t leave it in.

Now I have to decide whether I’m going to create a proper installer for the alpha (and build it if so) or just distribute a zip file – then you should be able to have a go!

Dev Time: 2.5 days
Total Dev Time: approx 111.5 days

previous|next

mockup_3x
Weapon Crates Now Display The Amount Of Ammo Inside

mockup_3x
Alpha Instructions

Jetboard Joust Devlog #56 – Pointing Out The Obvious

Whoa – 100 days of development under my belt!

Kind of a brief entry this one – I thought I was done with adding extra gameplay stuff for the alpha but watching my son play the game I realised there were a few things that were a little unclear.

The main one was the location of ammo stashes. It’s really annoying when you run out of ammo (I’m still not 100% sure that I shouldn’t give the base weapon unlimited ammo) and sometimes, in the heat of battle, it’s hard to locate the nearest ammo cache onscreen or on the scanner. This is even more of an issue since I added enemy bones which clutter up the battlefield.

So I’ve added two new features to make it easier to locate ammo, shields and rocket pickups – I call these ‘pickup detectors’ and ‘pickup indicators’.

A ‘pickup indicator’ simply indicates the location of the nearest onscreen stash – they don’t appear if the user’s ammo, rockets or shields are maxxed out. Implementing these was fairly straightforward, though I did have a few issues getting the indicator to move nicely between two different stashes. In the end I settled on having the indicator ‘pop out’ and then ‘pop in’ again when the location of the nearest stash changes. In my libraries I have a method that allows one to set a ‘timed event’ on a particular sprite, this is an event that doesn’t get triggered until a certain amount of frames later. This functionality has proved extremely useful for this type of thing.

A ‘pickup detector’ shows the closest route to the nearest stash if it is not onscreen. I settled on a simple arrow at the edges of the screen for this – not subtle but it works. As these would be annoying if they hung around all the time they only appear when the user’s shields or ammo are critically low. The rocket detector appears whenever a rocket pickup is present as these are pretty rare and you don’t want to miss them when they do appear.

The ‘pickup detector’ was also pretty straightforward to implement – the most fiddly bit was getting the arrows to centre correctly depending on how many of them there are, even that wasn’t that much hassle though.

I think these features make the game considerably more playable – plus I just love the look of that tiny pixel text!

Dev Time: 0.5 days
Total Dev Time: approx 100 days(!)

previous


Pickup Indicators In Action


Showing The Pop In / Pop Out As The Closest Stash Changes

mockup_3x
Please Sir – Where’s The Nearest Ammo Stash?

Jetboard Joust Devlog #55 – The Bubblewrap Effect

Everyone loves popping bubblewrap, yet no-one really knows why. For some reason the combination of the sound and tactile response makes it incredibly satisfying despite being utterly pointless. I had a friend who use to refer to this type of action as being ‘urgey’ – once you’ve done it you have the urge to do it again, and again, and again…

I’ve always thought we should aspire to this ‘bubblewrap effect’ when designing games. Most games, even the supposed AAA ones, comprise a fairly limited set of repetitive actions. If you can make those actions an enjoyable experience in and of themselves, regardless of gameplay, then you are onto a winner because no matter how good the player is at playing your game they will be having fun and come back for more.

Recently I’ve seen this loosely referred to as ‘juice’ or ‘game feel’ but these terms are rather vague and are often used to refer to all sorts of things. I’m talking about something pretty specific here – make all your repetitive actions as ‘urgey’ as popping bubblewrap. Usually this is a combination of both visuals and audio.

Now I’d already spent a lot of time on this stuff in Jetboard Joust but, whilst surfing GDC talks on YouTube, I came across this excellent talk by Jan Willem Nijman of Vlambeer on adding these types of elements to your game. I’d already implemented many of the techniques he talks about (camera shake, gun recoil, enemy and player knockback etc) but he made me rethink some aspects and put a bit more effort in to areas that were somewhat lacking.

So – here’s what I’ve been working on as the result of @jwaaaap‘s talk.

1. Bigger Bullets
To be honest a) this would never have occurred to me and b)I never would have thought it would work if it did. I was using little pixel squares for bullets as 1) they seemed appropriate for the size of gun and 2) this worked in Defender so why fix what ain’t broke? But I thought – ‘what the hell?’ and gave it a go. I started increasing the size of the bullets a little and was amazed how much better this felt, so I increased them what I would have thought was a ridiculous amount and it felt even better! It makes no visual sense whatsoever but the pistol (and particularly) the gatling gun are so much more satisfying to shoot now. I haven’t tried playing with the accuracy yet but should really do that too…

2. Camera Knockback
I already have some pretty hefty recoil on weapons but @jwaaaap suggests also recoiling the camera a certain amount when a weapon is fired. This didn’t make a massive difference in Jetboard Joust, probably because the camera is generally moving pretty fast anyway, but it is noticeable under some circumstances so I left it in.

3. Explosion Delay
Adding a very slight delay when an enemy is destroyed adds to the ‘jolt’ effect and makes destroying enemies much more satisfying. It’s subtle but it works. I’m using a delay of 32ms. I had to be careful here to not implement the delay until the next frame (ensuring the first frame of the explosion is drawn before the delay occurs) and also to clamp the delay time so that destroying a bunch of enemies at the same time didn’t result in a massive delay. I also improved the first ‘flash’ frame of the explosion by adding a ‘threshold invert’ to my collision shader and making the circles that briefly appear larger, brighter and less pixelated. Enemies really look like they’re getting nuked now!

4. Permanence
I had been wanting to do something to make battles seem more ‘permanent’ for some time and @jwaaaap‘s talk was the kick up the arse I needed. I talk about adding smoke in my previous post but that’s still not really permanent so I also added bones that fall from enemies when they’re destroyed and collect on the ground as a permanent record of the carnage that’s ocurred there.

Adding the bones was easy, the trouble started when I decided that they were too static and should react if the player hit the ground near them or crashed into a building that they were resting on. I didn’t want to run collision checking on every bone (there can be tons of them by the end of a level) so worked out a system whereby the world is divided into a series of overlapping ‘bone zones’. When a bone is static it is added to a zone and an entire zone can easily be discarded from the collision detection process in one go. I’ve used this approach before and it works well but I got myself into a bit of a flap with it here, plus it took a long time tweaking the various parameters so that the bones seemed to get disturbed by the correct amount. It still looks a little odd sometimes but its much better than having them totally static.

I’d really like to add some permanent damage to the buildings but I haven’t yet figured out a way to do this that would be a) be cpu/memory efficient and b) not involve creating a load more pixel art. I will continue to give this some thought – it could be that I’m underestimating the memory available on modern devices as a spent so long developing for J2ME feature phones!

So I hope that was all worth it and makes my game feel a little more like popping bubblewrap. I’d like to say these were the last gameplay tweaks before I release the alpha but watching my son play it has led me to implement just a couple more things…

Dev Time: 2 days
Total Dev Time: approx 99.5 days

previous|next

mockup_3x
My… What Big Bullets You Have!

mockup_3x
These Bullets Are Ridiculous – But Somehow They Work!

mockup_3x
Explosion Delay (Exaggerated), Smoke, And Improved ‘Flash Frame’

mockup_3x
A Battle Amidst The Bones Of Fallen Enemies

mockup_3x
Bone Bashing – A Stupid Detail That Caused Me Much Grief!

Jetboard Joust Devlog #49 – Gun Control

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.

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

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, unlike the next one…

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, hence they look rather ‘chunky’ compared to the other jetboarding enemies.

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

previous | next


Whoops – Too Much Recoil On The Gatling Gun

mockup_3x
The Final Gatling Gun In Action

mockup_3x
The Magic Shotgun – Enemies Should Shield Each Other!

mockup_3x
Fixing The Magic Shotgun

mockup_3x
Trying To get The Bodyguard Looking A Bit More ‘Hench’!

mockup_3x
Bodyguards Doing What They’re Paid To Do

mockup_3x
Assassin Enemies Wielding Gatling Guns – Beware!

Jetboard Joust Devlog #47 –Having Difficulty With Difficulty

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(!) – as this is fundamental to the way the game plays I needed to ensure a certain amount of ‘baby-chasing’ enemies per batch. I know that sounds a bit dodgy!

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…

SortedDictionary<EnemyTypes, SortedDictionary<WeaponTypes, List>> 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

previous|next

mockup_3x
The Current State Of Play

Jetboard Joust Devlog #44 – Shotgun Logic

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

previous | next

mockup_3x
Almost There With The Particle FX

mockup_3x
Working On Collision Detection

mockup_3x
Damn – Shotgun Blasts Shouldn’t Work Through Buildings

Jetboard Joust Devlog #43 – You Bastard!

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

previous | next


The Main Character Design – Actually Three Separate Sprites!

mockup_3x
First Draft Of Enemy Motion – A Bit Clumsy

mockup_3x
Adding Attack/Retreat Behaviour. Much Nicer!

Jetboard Joust Devlog #42 – Evil Mothers

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

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

previous | next

mockup_3x
Original Enemy Design – Mother & Children

mockup_3x
Adding Motion And Particles To The Mother

mockup_3x
The ‘Birth’ Sequence

Jetboard Joust Devlog #40 – Bits and Bugs

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

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

previous

mockup_3x
Enemies Now Act More Sensibly In Small Gaps

mockup_3x
Added Floating Scores When Enemies Are Destroyed

mockup_3x
Designing A Custom Bitmap Font For In-Game Messages

mockup_3x
Adding Impact Effects To In-Game Messages