next »

[alvarop]

That is one beautiful title, really cool to see the process!

[bitbulldotcom]

That is one beautiful title, really cool to see the process!

Thanks! Honestly, the feedback means a lot - it's pretty hard work motivating oneself on a project like this sometimes when working completely solo!

[bitbulldotcom]

OK - this one's not a 'proper' DevLog post but I've been looking at the way the in-game camera works and using Lerp smoothing. I decided to write a small tutorial about it with some example code here - may be of interest to some!

Basic Lerp Smoothing:


Lerp With Minimum Velocity Applied:


Lerp With Maximum Acceleration ‘Ease In’ Applied:


Oops - Sudden Changes In Direction Result in A Nasty Jolt


Lerp With Maximum Acceleration ‘Ease In’ Applied

[bitbulldotcom]

In the unlikely event that you’ve been reading this blog from the beginning you might remember that the camera in Jetboard Joust has always been something of a bugbear for me.

Way back in the early stages of development I wasted countless hours trying to get a camera action that I was happy with but, after failing miserably (once I started to add enemies the camera tracking solution I described in the blog post above proved woefully inadequate), decided to go for the simplest solution of locking the camera to the player centre-screen and leaving it at that.

Thing is – this kind of worked. Maybe because the camera is horizontal-only and the player’s horizontal motion smoothly accelerates and decelerates with no sudden changes? The game was perfectly playable and there were no sudden camera movements that looked out of place or anything.

But… it was just a bit boring and I always thought I could make it better, so as I’m nearing ‘playable alpha’ stage I decide once more to revisit. I set up a separate ‘Camera’ class (rather than putting all the camera code in the main game class as I had before) and attempted to approach things a bit more methodically.

Though it probably seems blindingly obvious I had a bit of an epiphany on realising that camera motion is really comprised of two separate elements, the camera target (ie what you want to be the centre of attention) and the way the camera moves to that target.

I decided to tackle the camera motion itself first. Many online articles talk about Lerp smoothing as the de-facto way to deal with this so this seemed a good place to start. Rather than working with Lerp smoothing on the camera right away I tried applying it to some sprite motion so it was much easier to see what was going on. The results of this really require a separate post so I’ve explained the process in a small tutorial with some example code here. The net result was an extended Lerp class that moves an object smoothly towards a target no matter how often (and by how much) the target position changes.

Now I had a way of making the camera track smoothly I set about working on the camera target (what the camera is moving towards). This was a lot harder! My thought process here had three key stages…

1. Player Velocity
One of my main concerns about the camera being centred all the time was that, if the player was moving quickly, lookahead was limited to half the screen width. In ‘Defender’ (the main inspiration for Jetboard Joust) the camera seems to be focussed something like 25% of the screen width if front of the player so I started with similar approach. I took a maximum lookahead value, worked out the player’s current velocity relative to the maximum possible velocity, and then placed the camera target the same proportion of the maximum lookahead value in front of the player.

The end result was OK but, as it doesn’t take long for the player to accelerate to top speed, the camera was moving far too quickly to its farthest position. Jetboard Joust plays differently to Defender in that there is more ‘dogfighting’ style gameplay when dealing with enemies (rather than hurtling in one direction as fast as possible) and somehow the camera movement needed to reflect this. So I tried a different approach…



2. Directional Duration
For my second attempt I set up a variable that gradually increased/decreased in value depending on how long the player was travelling in a particular direction. So, from stationary, if the player was travelling left it would take approx five seconds for the value to reach -1.0 (the minimum possible) and the inverse for travelling right. I then multiplied the maximum lookahead value by this variable and set the camera target appropriately. If the player changes direction I set the variable to zero for a quick turnaround.

This worked much better than my first attempt – the camera seemed to track fairly naturally with a long lookahead distance if the player was travelling any distance left and right and not switching erratically in the midst of battle. There were a couple of problems with this approach though, I didn’t like the obvious lag as the camera tried to ‘catch up’ with the player when accelerating from stationary and too often I’d end up forced to do battle at the edges of the screen.



3. Enemy Location
For my third attempt I adopted an entirely different tactic. I totally ignored player movement and instead positioned the camera entirely based on the location of nearby enemies (limiting this at a maximum value to ensure the player remains onscreen). I tried two approaches here:

3a. Enemy Position
Firstly I tried positioning based on how many enemies were to the left or right of the player. So I’d start by dividing 1.0 by the number of enemies within range and then adding or subtracting this number to a variable based on whether each enemy was to the left or right of the player. The result was a number between -1.0 and 1.0 which gave an indication of where the action was relative to the player – this number was multiplied by the max lookahead value to give the camera target position.

This strategy had some interesting results in the way the camera swung towards the action but overall it was too unreliable, I’d often find my attention was on a particular enemy and the camera would suddenly swing away as there were more enemies behind me or something. So I tried something simpler…

3b. Closest Enemy
This time, based on the logic that 99% of the time the closest enemy would be the one the player was concentrating on in a dogfight I simply targeted the camera at the closest enemy to the player (whilst ensuring the player remained onscreen).

The result of this was strangely compelling! Although the camera lurched left and right far too much it made the gameplay seem more intense, dynamic, and somehow just more ‘fun’. I was really surprised about how much the gameplay was enhanced by this simple approach – I just needed to find a way to tone it down a bit.




4. All Of The Above
So what I did next was use all of the above approaches and apply a weighting to each of them, hoping that this would provide some kind of ‘happy medium’. Fortunately, with a bit of tweaking, it did!

I still felt I could improve things further though so I made this weighting dynamic. I fixed the weighting based on player velocity at 25% and based the remaining 75% on either the closest enemy (if any enemies are within range) or the directional duration.

Another tweak I made was to slightly bias the ‘closest enemy’ calculation based on the direction the player is facing so that enemies in front of the player are considered ‘closer’ (I reduce the distance by 75%) than those behind. This makes the camera more likely to stick on enemy the player is currently engaged with.

The result is a camera that doesn’t lag, gives a long lookahead if the player is covering a lot of distance (and no enemies are present), and pans to the centre of the action when a dogfight is in place. I think it works pretty well.



I’m particularly pleased with the way the camera snaps to the closest enemy. I don’t know if it’s still too motion-sickness-inducing (maybe) but it feels much more visceral, seems to help with gameplay, makes it easier to get combos, and, in certain situations, just makes the player feel like a complete badass! So I think I’m going to park the camera now and wait for user feedback before I go tweaking it further…



Dev Time: 2.5 days
Total Dev Time: approx 96 days

[SolS]

Been lurking for a while but I just wanted to say that I love the look of this game! I really like Joust too so it looks like a lot of fun to play!

I can relate to the struggles of motivation on a solo project, plus I've been dealing with major sinus pains too so I know how hard that can make working on anything. Glad to see you making so much progress on this!

[bitbulldotcom]

Been lurking for a while but I just wanted to say that I love the look of this game! I really like Joust too so it looks like a lot of fun to play!

I can relate to the struggles of motivation on a solo project, plus I've been dealing with major sinus pains too so I know how hard that can make working on anything. Glad to see you making so much progress on this!

Thanks very much for the feedback - I'm glad you like it!

Thanks also to the folks who listed this as their favourite DevLog in the voting thread - it means a lot. If anyone has questions or wants me to go into more detail or anything just let me know. Past couple of days I've been focussing on adding more 'juice' - currently working on rendering geometric shapes using shaders for a stylized smoke effect. This is very early stages but I think I can get it to work...

[bitbulldotcom]

For the past few days I’ve been working on adding some more ‘juice’ to Jetboard Joust – the sort of small details that don’t really add anything to gameplay per se but, when combined, add an awful lot to game feel (hopefully). I’ll go over most of these in a separate post but one element seemed to deserve a post of it’s own – smoke.

I wanted to add smoke as a way of increasing a sense of ‘permanence’ to the combat. Explosions are over and done in less than a second but smoke could hang around for ten seconds or so and build up depending on how much destruction is going on.

I wasn’t after a ‘realistic’ smoke effect but something more stylised to fit in with the rest of the game art. It seemed logical to use circles as the base for the effect but I felt pretty sure I’d want these circles to increase in size over time, maybe quite dramatically, so I didn’t want to rely on scaling sprites for this. I decided to use custom shaders instead as this should give me much more control.

So the first step was to use a custom shader to draw a simple filled circle. Initially I thought the geometry behind this would be quite complex but, in fact, it’s just simple pythagoras. Here’s the approach in pseudo code…

Code:

// get coordinates relative to centre of circle
float x = 0.5-coords.x;
float y = 0.5-coords.y;
// fill the entire space
float radius = 0.5;

if ( x*x + y*y <= radius*radius )
{
// return a color
}
else
{
// discard
}

…I’d be lying if I said I got to this stage quickly though! Though it didn’t take me long to figure out the maths, I spent far too long passing the shader a region of a texture to draw rather than the entire texture and getting confused as to why my results were all off (forgetting that coords.x and coords.y are relative to the entire texture to be drawn, not the region). When I started passing a simple 2×2 image to the texture everything clicked into place.

Once I’d successfully drawn a filled circle it was pretty easy to expand that technique to draw concentric rings and the like, and to animate these by basing their radii on parameters that are passed to the shader and change each frame. You can see the results of these early experiments in the post above.

Next step was to find a way of applying motion to these circles that looked suitably smoke-like. I started by simple applying a uniform velocity to several circles distributed across a certain range, e.g. -60d to +60d, as well as increasing the circles size over time. First attempt at this wa a complete fail, an interesting fail but a fail nonetheless!



When I finally got this to work the way I intended it didn’t look too bad as a starting point so I added a couple more parameters to make things more interesting – a ‘deceleration’ parameter (so that the velocity of the circles decayed over time), and a ‘buoyancy’ parameter (so that the circles gradually floated upwards over time). I also decreased the opacity of the circles over time so that they gradually faded out.



This looked much better but the results were still far too uniform, forming very obvious geometric patterns as the circles intersected. To stop this I added a certain amount of randomisation to both the circles initial velocity and their ‘buoyancy’ – this produced a much more smoke-like effect – still stylised but not overly ‘geometric’.



I was almost there now but felt that the smoke cloud was dissipating too quickly and lacked some kind of ‘weight’ to it’s centre. I fixed this by adding additional batches of circles with a decreasing initial spread and velocity with the final one staying pretty much in the same place. This looked a lot better.

Lastly I experimented with adding pixelation to the shader so that the circles were drawn at the ‘game’ pixel resolution rather than the ‘screen’ pixel resolution. Unfortunately I felt this looked pretty crappy – one of those things that ‘should’ have worked but didn’t! So I left things as they were but I did add a gradually increasing amount of pixelation over time so that when the circles have pretty much faded out they kind of ‘dissolve’ out rather than just disappearing.



Actually I couldn’t stop there – I thought the centre of the smoke cloud looked too ‘solid’ to start with so added a small particle effect to imitate ash or something. It’s subtle but it just breaks things up a little. Click on the GIF below for a longer video...



I’m pretty happy with the final result – watch this space for a mini-tutorial on using shaders to draw geometric shapes. I think I might end up using that technique again in this game…

Dev Time: 1.5 days
Total Dev Time: approx 97.5 days

[bitbulldotcom]

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

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! Delay exaggerated here to make it really obvious...



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

[thekosmonaut]

nice blog, lots of info here

[bitbulldotcom]

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. Here they are close up...



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(!)

[bitbulldotcom]

Another fairly quick entry today – I now have a title screen!

This didn’t take too long to put together once I’d designed the logo – most of the time was spent messing around with different motion types. I knew I wanted the logo to move, and each word to move separately, but it took a while to get something I was happy with.

My first attempt (below) had each word moving parallel to the ‘slant’ of the logo but for some reason I found this a bit disturbing, like the words were scraping against each other or something. There was something almost sexual about it and not in a good way. yes, I know that probably makes me weird. maybe it’s too extreme but I found it the visual equivalent of hearing nails scrape down a blackboard (if any of you are young enough to remember blackboards).



My second attempt (below) had each word moving in a less uniform elliptical motion. I preferred this so have stuck with it for now. I did also have to separate each word on the logo and also separate the actual letters from the background which took some pixel-pushing (there’s actually four sprites here).



Adding the parallax was easy as I could pretty much just use the classes that handle this in-game with a few minor tweaks. I’m pretty pleased with the end result and think it’s certainly presentable enough for the alpha version.

Dev Time: 0.5 days
Total Dev Time: approx 100.5 days

[foofter]

I usually don't especially like minimal color gameboy-esque style, but I have to say that those alien plants in the background are just beautiful! 

[bitbulldotcom]

Thanks! I may add more of those so the flora changes as you progress through the levels...

[bitbulldotcom]

Here's a quick 'work in progress' post - got a basic loop going that will probably form the foundation for the background music. Probably too loud in this clip in comparison to the FX but it shows the direction I think I'm headed...

[bitbulldotcom]

Well, the background music’s finally done and it’s taken what seems to be an indeterminable amount of time.
It’s partly because I had to put a proposal together for some contract work in the middle of it – which made the process seem to drag on longer than it should, but also because I decided I had to sort out the ridiculous mess of cabling (of various varieties) that had overtaken my studio and was making it difficult to work. Each of those tasks took at least two days. Here's those cables after I sorted them out...



I guess 8.5 days total dev time isn’t too bad for the amount of background audio that’s in there but, even accounting for the aforementioned increased in elapsed time, it still seems to have been a rather lengthy and unnecessarily painful process. Here’s how it went down (and sorry for the crackling in some of this audio – seems to be problem with running Windows on a Mac)…

1. Main Theme
I knew from the get go that I was going to utilise the same approach for the background music that I had for the in-game FX, ie all analog synths for the sounds and as few software plug-ins as possible when mixing. I needed to have a rough idea of the style of music I was going for though so started by playing the game alongside a few different tracks to see what worked best. I tried a number of different electronic artists, eventually settling on the ‘Detrimentalist’ album by Venetian Snares as my favourite, with particular reference to the tracks ‘Kyokushin’ and ‘Bebikukorica Nigiri’, the latter featuring a bunch of ‘chiptune’ type sounds which seemed particularly appropriate.

Once I had a general ‘vibe’ in mind I started creating some drum patches and banging out some beats on The DSI Tempest trying to get something that worked, using a combo of the Moog Sub 37 and Mother 32 for bass and lead duties. As often as possible I’d try and listen to what I was creating alongside a recording of the in-game fx so I could try and create sounds that weren’t going to mask and/or fight against each other to much. I found this pretty difficult to be honest.

After about a day I had a simple loop that I was generally happy with and began to work up some variations on it. I probably spent a couple of days playing around with different variations, whilst running into various technical difficulties syncing up all my gear in the process (ah – the joys of MIDI and analog)! Here's that loop, though at this stage far too loud (and bass heavy) in comparison to the in-game fx...



Then I started trying to combine all these variations into a single cohesive piece of music and this is where I started to run into problems. It didn’t work. I think this was partly because my variations were all too different and didn’t ‘flow’ together, and partly because I was trying too hard (and with too little talent) to ape Venetian Snares and the result was too full-on and tuneless.

I was getting pretty frustrated by this point. Four days in and I still didn’t have anything resembling a main theme. Then I remembered a piece of music I’d written ages ago for a J2ME game called ‘Battle Snake’ that I had always been rather fond of. I decided to dust this off and see if it would work for Jetboard Joust – fortunately it seemed like it might!

The (as it stands) final theme is a mash-up of ‘Battle Snake’ (with new sounds) and some of the variations I originally created for ‘Jetboard Joust’. I’m still not entirely happy with all the sounds here, particularly some of the more distorted ‘guitary’ type synth sounds which seem to conflict too much with the in-game fx. I may well replace these with something less harmonically rich.



Thankfully I could also use some of my original variations for the other sections of game audio so that time wasn’t entirely wasted…

2. Baiter Theme
The player has approximately two minutes and twenty seconds to complete each level in Jetboard Joust before the pace is upped and the ‘Bastard’ enemies (equivalent to the Baiters in Defender) start to attack. I thought my original (rather full-on) loop would work better for this section of the game and so created a separate piece of music for this that’s more ‘high-tension’.



3. Lost Life / Level Complete
These are short sections based on the repeated section of ‘Battle Snake’ that now forms the ‘hook’ of the main theme. An ascending progression for ‘level complete’ and a descending progression for ‘lost life’.

4. Planet Ambience
OK so this isn’t a piece of music as such but I wanted some kind of background audio during the ‘quiet’ periods of the game such as at the start of each level before enemies attack and at the end of each level once all enemies are destroyed. I’ve gone for a sort of retro sci-fi spooky ambience here with analog wind effects and vintage ‘sample and hold’ type noises that trigger seemingly randomly. I also added a weird interference loop which was the sound of some of my gear accidentally wired up incorrectly that I kind of liked. I think the planet ambience gives a nice contrast to the more full-on background music.

5. Upgrade Theme
One of the variations on my original theme was a type of minimal ‘spooky’ loop with bell-like synth effects and a lot of vintage delay. In the end this didn’t work as part of the main theme (it was too downbeat) but it seemed to work really well over the upgrade screens. I also added the wind noises from the planet ambience in here too.



6. Title Theme
I quite liked this being underplayed as well so stuck to just using the ‘planet ambience’ here with a bunch of samples of the ‘bell’ sounds from the ‘upgrade theme’ triggered randomly (all part of the same minor scale though so not entirely random). Again this has a kind of ‘vintage sci-fi’ feel which I liked. I also added spot fx for ui actions on the menu.



Now that I’ve written all that up it seems like rather a lot of work so I don’t feel quite so bad about it taking over eight days to complete – bearing in mind I had to code all these into the game as well and managed to fix a couple of other bugs whilst I was at it. I’m bloody glad to be moving on from it though…

Dev Time: 8.5 days
Total Dev Time: approx 109 days

[bitbulldotcom]

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

[bitbulldotcom]

OK people, I think I'm ready for alpha at last! But before I put this thing live 'properly' here's a sneak peek. If anyone fancies downloading this and letting me know if they run into any heinous issues that would be great. This is for the Windows version - I have a MacOS version too if anyone's interested...

Particularly like to hear from anyone who can try this on a 32-bit Windows system as I don't have access to one.

Jetboard Joust Alpha Download

[alvarop]

Game crashes for me after the gamepad screen. Windows 10 PRO though, 64 bit.

[bitbulldotcom]

Game crashes for me after the gamepad screen. Windows 10 PRO though, 64 bit.

Ah - bummer! I guess I'm going to have to try duplicating my VM and upgrading to Win10.  I think if it crashes at that point it's probably something to do with the custom shaders but that's a wild guess at the moment. Can you view the instructions/about screens OK?

Thanks very much for taking the time to test and feed back though, even if it's bad news! You're the first person to report an issue and it's really helpful.


 

[alvarop]

Yeah I can view the other screens just fine. I just can't get into the game