Author Archives: bitbulldotcom

I have been programming games since I was about ten years old. I had my first titles, Subterranean Nightmare and (the frankly pretty terrible) Skateboard Joust, published on the ZX Spectrum when I was 15.
For the past 15 years I have been making a living developing games for mobile (feature) phones via my companies BitBull and Maturus Mobile. My games are served on all the major International operator portals, have regularly featured in the ELSPA charts and have won several Pocket-Gamer awards. In 2013 my original puzzle game ‘Puzzled Zombies’ was nominated for Pocket Gamer’s ‘Game Of The Year’ alongside entries from big players such as Namco and Electronic Arts.

Being an independent games developer is not easy. I’ve been doing this a long time yet am still tearing my hair out and learning new things pretty much every day. I still know nothing.

Get in touch via the BitBull website at http://www.bitbull.com.

Jetboard Joust DevLog #107 – A Day For Saving

The final major thing I wanted to do before releasing the beta (other than going back to the PC port) was implement multiple save ‘slots’ per game. It’s surprising how few games bother with this now but for me, it’s essential. Not only does it provide a loving nod back to the days of 8bit consoles, it allows the player to mess around with different upgrade paths and/or multiple members of the same family to maintain their own save state.

It’s not really a technical challenge either. What’s time consuming, as with most functionality of this nature, is designing and implementing the UI.

Fortunately I was able to cheat by recycling 90% of the UI for the upgrades screen (which I’d implemented in a pretty flexible manner to allow for different numbers of stats per weapon). This saved me a ton of time and allowed me to romp through this task pretty quickly.

The only real change I made from a UI perspective was the positioning of the ‘jetsuit’ and ‘jetboard’ icons. I also though the jetsuit looked a little static without any kind of animation so I implemented a few simple idle anims to bring things to life a bit.

On MacOS I have shifted location of the save files to ~/Library/Application Support rather than the default C# IsolatedStorage directory. This makes more sense and, crucially, means save files are preserved between builds (I wouldn’t be able to test it otherwise). As I’m using JSON for the save data I’ve also implemented a very simple encryption algorithm to obfuscate the files, it’s now now longer a trivial business for users to edit the file to change upgrade levels etc!

The game saves at the end of every level and at other key points, such as losing a life and upgrading a weapon – not every time the user picks up a coin or something. Consequently progress will be lost if the user quits in the middle of a level but I don’t think this matters – the end of the level is effectively the ‘save point’.

Testing seems to have gone relatively smoothly so far but I’m continuing to test as I do my final round of pre-beta playtesting.

Wishlist Jetboard Joust here, and view the trailer here, sign up for the beta here.

Dev Time: 2 days
Total Dev Time: approx 308 days

previous

mockup_3x
Close Up of the Jetsuit Idle Animation

mockup_3x
The ‘Save Slots’ UI

Jetboard Joust DevLog #106 – Full Steam Ahead

Yes, Jetboard Joust can now be wishlisted on Steam here. Your support is much appreciated, even if you don’t end up buying it each wishlist helps!

I’m getting rather behind on this devlog again and wanted to write something about the process of getting the Steam page up. Even if it’s not strictly ‘development’ per se, it’s an important part of the process and took me some time.

I started off by reading this excellent Reddit post on how to create a kick-ass Steam page. Lots of useful info there and I kept referring back to this throughout the process. I also spent quite some time looking at the pages of other games, especially those that are also in the same general genre (fast-paced pixelart SHMUP) such as Nuclear Throne and Enter The Gungeon.

The bulk of the work, of course, is creating image assets. I decided to do this using the in-game art rather than trying to illustrate the game in some other fashion. This was a decision largely borne out of necessity (it would have taken me ages to produce quality vector illustrations), but I also felt a pixel art approach would more accurately convey the spirit of the game. If I couldn’t get it to work with pixel art I’d try another method, maybe even commission someone else.

I started off working on rough layouts using art cut-and-pasted from the trailer just to see if what I wanted to do was going to be achievable. I knew I’d need to use at least one of the boss sprites as they were the only ones likely to have the necessary impact without being blown up a ridiculous amount. I settled on the ‘stinger’ boss as it seemed to work well within the proportions of the various steam ‘capsules’, the other bosses actually proved to be too large and complex.

When I had a layout I was happy with I built a much cleaner final version using art taken from the original sprite sheets.

A huge part of the game’s personality though is the particle and shader effects and without these my capsule images were looking rather static and boring. As these are all semi-transparent in-game and overlap other elements it was impossible to cut-and-paste them from gameplay footage and would have been extremely laborious to recreate them ‘manually’ in Photoshop. Consequently I was a bit stuck as to how to convey these in a static context.

After much head-scratching I came up with the idea of doing a pure black-and white palette for the game. I could then make only the particle and shader fx visible, capture these as gameplay footage, import them in to Photoshop as an alpha channel, position where I saw fit and apply colors and blending. This method, with a bit of post-editing, worked really well and, I think, enabled me to communicate the feel of the game pretty well in a static context without a lot of laborious Photoshop work. It was also extremely useful when it came to mocking up / embellishing screenshots. For the screenshots I also used a ‘green-screening’ technique whereby everything but key sprites are rendered in green making cut-and-paste from gameplay footage extremely easy.

Annoyingly the ‘angled’ logo I use in-game just didn’t work within the proportions of the Steam Capsule images, particularly the smaller ones, and its proportions meant it was either too big or too small when blown up in the exact multiples necessary to maintain the pixel integrity. Consequently I had to recreate a purely horizontal version of the logo which I did in illustrator and pasted into Photoshop as vectors. I think a ‘pure’ pixelart version would possibly have looked better but I’m not sure it would have justified the amount of time needed to do it, particularly given the differing size requirements.

Then there was also the text to write, a myriad of forms to fill in, emails to write to try and generate some publicity, tags to add and a press page to create. I was pretty much losing the will to live by the end of it (not the first time I’ve said that on this project) but it’s done now. Check out the final result here.

Dev Time: 6 days (including other marketing)
Total Dev Time: approx 306 days

previous | next

mockup_3x
Steam Main Capsule Image (click to enlarge)

mockup_3x
Steam Library Capsule Image (click to enlarge)


Blacked Out Gameplay Footage For Photoshop Alpha Channels

‘Green-Screening’ Makes Composing Screenshots Easier

Lerp Camera Motion Smoothing Tutorial and Example Code

Recently I’ve been revisiting at the way the camera works in Jetboard Joust (wishlist on Steam here!) something that has been a continual thorn in my side throughout the project.

When researching how to make the camera movement better I came across many references to Lerp smoothing but I found few, if any, detailed explanations as to how this works in practice and (particularly) ways to get around its significant limitations. Cue this post, by the end of which we’ll have a class that’ll move an object smoothly towards a target point and ‘brake’ so it reaches it exactly no matter how often and by how much the target is changed.

I’m just concentrating on one axis of movement here for simplicity but this approach can easily be applied to 2D or 3D vectors. For those of you with short attention spans you can just download the final class here.

So… Lerp is a quasi-acronym for ‘linear interpolation’ and used to create smooth movement between two points. It’s often used to smooth out camera movement but can equally be applied to sprites or anything else in 2D or 3D space. The basic equation for Lerp is very simple, it takes a position and target, works out the difference between them and then returns a value a specified amount along that path. Only values >0 and <1 are generally meaningful.

public static float Lerp(float position, float target, float amount)
{
     float d = (value2 - value1) * amount;
     return value1 + d;
}

If you are using this equation to move an object and each frame call it with the object’s current position (keeping the other values the same) the object will move a smaller distance each frame which results in a ‘slowing down’ effect as the objects reaches its target. Here’s an example of this type of motion applied to a sprite. In this case the sprite is moving approx 480 pixels at a frame rate of 60fps with a Lerp value of 0.025.


Basic Lerp Smoothing

Now this looks pretty good already but, as you’ve probably figured out, there are issues. The first one is that using this approach the object will never actually reach its destination – this can result in a slightly jerky looking motion as it reaches the end of its trajectory as well as presenting potential issues if you want to do something when the destination is reached.

One way of resolving this is to implement a minimum amount of movement per frame. This can be anything you want but for many applications it makes sense for this to be one pixel.

Here’s a simple ‘Lerper’ class that implements this – each frame the amount of movement (LerpVelocity) is calculated and, if the absolute value of this is less the minimum velocity we clamp it at the minimum velocity. Of course this means that the object might now be in danger of moving beyond its target point so we check for this at well and make sure it doesn’t.

public static float Lerp(float position, float target, float amount)
public class Lerper
{
    public Lerper()
    {
        Amount = 0.025f;
    }

    // Returns the amount of movement at this stage of the lerp
    private float LerpVelocity(float position, float target)
    {
        return (target - position) * Amount;
    }

    public float Lerp(float position, float target)
    {
        float v = LerpVelocity(position, target);

	// If this is less than the minimum velocity then
        // clamp at minimum velocity
        if ( Math.Abs(v) 0) ? MinVelocity : 0 - MinVelocity;

	position += v;
	// Now account for potential overshoot and clamp to target if necessary
        if ( (v= target))
        {
            position = target;
        }
        return position;
    }

    public float Amount
    {
        get;
        set;
    }

    public float MinVelocity
    {
	get;
	set;
    }
}

Here’s an example of this in action. As you can see it looks much better…


Lerp With Minimum Velocity Applied

Still we have limitations though if we’re looking for really smooth movement. The next glaringly obvious one is that Lerp is ‘ease out’ only, the object will be moving fastest at the start of the sequence which makes it look like it’s being fired from a slingshot rather than smoothly accelerating from rest.

To resolve this I’m going to apply an ‘Acceleration’ property to my Lerper class. This ensures that, if the object is increasing in speed, the increase doesn’t exceed a specified amount. This requires a variable to store the amount of movement each frame.

public class Lerper
{
    private float previous_velocity;

    public Lerper()
    {
        Amount = 0.025f;
        Acceleration = float.MaxValue;
    }

    // Returns the amount of movement at this staget of the lerp
    private float LerpVelocity(float position, float target)
    {
        return (target - position) * Amount;
    }

    // Returns the next position with lerp smoothing
    public float Lerp(float position, float target)
    {
        // get the amount to move
        float v = LerpVelocity(position, target);
        // don't allow increases in velocity beyond the specifed acceleration
        if ( v>0 && previous_velocity>=0 && v-previous_velocity>Acceleration )
        {
            v = previous_velocity + Acceleration;
        }
        else if (v < 0 && previous_velocity  Acceleration)
        {
            v = previous_velocity - Acceleration;
        }
        // If this is less than the minimum velocity then
        // clamp at minimum velocity
        if ( Math.Abs(v) 0) ? MinVelocity : 0 - MinVelocity;
        }
        // Remember the previous velocity
        previous_velocity = v;

        // Adjust the position based on the new velocity
        position += v;
        // Now account for potential overshoot
        if ( (v= target))
        {
            position = target;
        }
        return position;
    }

    public float Amount
    {
        get;
        set;
    }

    public float MinVelocity
    {
        get;
        set;
    }

    public float Acceleration
    {
        get;
        set;
    }
}

Here’s an example of this in action – now we have a nice ‘ease in’ to our Lerp motion. Here I’m using an acceleration value of 0.25f.


Lerp With Maximum Acceleration ‘Ease In’ Applied

There’s one other problem I’m going to address though. This ‘ease in’ effect works nicely if the object is initially at rest or moving in the same direction but if the object had previously been moving in the opposite direction we’re still going to get a nasty jolt. Here’s an example where I’m changing the destination to the opposite side before the previous Lerp has reached the end of its trajectory.


Sudden Changes In Direction Result in A Nasty Jolt

So we’re going to check for this in the code and again apply a maximum amount by which the velocity can change each frame. Remember that because we’re changing direction the absolute value of the current velocity at the point of change is the sum of the absolute value of both the current and previous velocities, ie a change in direction from 10 to -10 would result in a new velocity of -20.

A side-effect of this is that the object will probably end up moving away from the target until it’s gathered enough momentum to change direction. As the code that clamps to the target position assumes we are moving towards the target we have to max out the target value if this happens.

We also have a special case check for our minimum velocity here as we need to make sure that if the minimum velocity is applied its applied in the direction that moves towards the target (otherwise the object could get stuck moving in the wrong direction).

public class Lerper
{
    private float previous_velocity;

    public Lerper()
    {
        Amount = 0.025f;
        Acceleration = float.MaxValue;
        MinVelocity = 0;
    }

    // Returns the amount of movement at this staget of the lerp
    private float LerpVelocity(float position, float target)
    {
        return (target - position) * Amount;
    }

    // Returns the next position with lerp smoothing
    public float Lerp(float position, float target)
    {
        // get the amount to move
        float v = LerpVelocity(position, target);
        // don't allow increases in velocity beyond the specifed acceleration (ease in)
        if ( v>0 && previous_velocity>=0 && v-previous_velocity>Acceleration )
        {
            v = previous_velocity + Acceleration;
        }
        else if  (v  Acceleration )
        {
            v = previous_velocity - Acceleration;
            // we might actually end up moving away from the target
            // here in which case we adjust the target so we don't get
            // clamped to it later
            if (v  0 && previous_velocity  Acceleration )
        {
            v = previous_velocity + Acceleration;
            // we might actually end up moving away from the target
            // here in which case we adjust the target so we don't get
            // clamped to it later
            if (v > 0-MinVelocity)
                v = MinVelocity;
            else
                target = float.MinValue;
        }

        // If this is less than the minimum velocity then
        // clamp at minimum velocity
        if ( Math.Abs(v) 0) ? MinVelocity : 0 - MinVelocity;
        }
        // Remember the previous velocity
        previous_velocity = v;

        // Adjust the position based on the new velocity
        position += v;
        // Now account for potential overshoot and clamp to target if necessary
        if ( (v= target))
        {
            position = target;
        }
        return position;
    }

    public virtual void OnTarget(){}

    public float Amount
    {
        get;
        set;
    }

    public float MinVelocity
    {
        get;
        set;
    }

    public float Acceleration
    {
        get;
        set;
    }
}

Here’s what happens when you suddenly change the Lerp target with this code applied – as you can see we now have a nice smooth movement no matter how often we change the target value.


Lerp With Maximum Acceleration ‘Ease In’ Applied

And that’s pretty much it. You can download the final class file here – in the final version I’ve also added a MaxVelocity property, a delegate to be called when the object reaches its destination, and tidied up the code so its not quite so verbose.

If you are in the process of coding a camera for a 2D game I highly recommend you check out this excellent article.

If you are looking for something to move smoothly between two points over a specified number of frames then you’re probably better off using some kind of tweening rather than Lerp. Check out Robert Penner’s excellent tweening/easing functions or the ‘smoothstep’ algorithm approaches described here.


These articles take a lot of time and effort to put together. If you found this useful and would like to help me create more content like this like you can support me below – I really appreciate it!

Buy Me a Coffee at ko-fi.com

Granny Bait – The Making Of “Skateboard Joust”

Granny Bait: A term used back in the day to describe a game that had virtually no redeeming features but, because it had something ostensibly ‘youth’ in the title (and was cheap), would be bought in droves by clueless older folk as gifts for their disappointed grandchildren.

A while ago I wrote a post about ‘Subterranean Nightmare‘, my first commercial release for the ZX Spectrum. Whereas ‘Subterranean Nightmare‘ was something of a labour of love and represented a genuine attempt to create a decent game, my next title (I am somewhat ashamed to admit) was executed in a rather more mercenary manner. I can’t remember exactly what age I was when I started work on ‘Skateboard Joust’ but I was heading into my late teens. I was losing interest in videogames and starting to become far more interested in guitars, girls and beer. Guitars, girls and beer cost money though – and the best way I knew of to make a quick buck was to churn out another budget Spectrum title.

I never had the slightest interest in skateboarding but tying the game in with something that was relatively fashionable seemed like a good idea. I’d also never played ‘Joust‘, but I’d seen screenshots and knew it was made by the some people that made ‘Defender‘ (which I still rate as one of the finest videogames of all time) so it was bound to be pretty cool.

The central mechanic of the game involves destroying enemies with your skateboard which you can only do if you are mid-jump (not actually riding the board) and I still think this is a pretty sound gameplay concept. It’s not executed very well however and is extremely difficult to get the hang of (‘totally unplayable’ might be a better description). Then there’s the fact that, aside from a few pretty unimaginative powerups, this central mechanic is pretty much all there is to the game making it a fairly tedious experience.

The worst thing about the game though is that what appear to be the level backgrounds are actually in the foreground and serve no purpose other than to obstruct your view of a game that’s hard enough to play as it is. Making gameplay harder by simply obscuring what’s going on must surely be one of the most laughably bad game design ideas ever!

I remember borrowing chunks of code from my brother Tim (of I-Ball fame) who was always a much better coder than me, and recycling some of the graphics from ‘Subterranean Nightmare‘. I also added some of the most embarrassingly ‘wrong’ skate slang between the levels. Not my finest hour but I was paid a £2.5k advance by Silverbird which paid for a lot of beer.

The game was justifiably slated by Crash Magazine at the time, though in recent years some people have been rather kinder to it, notably the vg-junk blog. There’s also some drunk guy on YouTube who plays the game for around five minutes without realising that you can jump off your skateboard!

Bizarrely though the game had some devoted fans despite its awfulness – in the comments for this video there’s someone who seems to take great offence when people suggest that it might be a tad shit! I also ‘met’ the person who did the C64 version in this thread, turns out they got paid considerably more than I did for writing the original!

And no, I have no idea what I was thinking of when I designed those ‘extra’ life icons! They do look like some kind of demented frog!

World Of Spectrum entry here.

30 years later I’m now working on a sequel, ‘Jetboard Joust’, in order to balance out my karma for forcing such a terrible game onto the unsuspecting public. ‘Jetboard Joust’ builds on the central ‘Jetboard of Death’ mechanic and adds a whole lot more besides – you can wishlist it on Steam here and read about the development here.

30 years Later – The Sequel…
Read the instructions you fool!


The C64 Version (With At Least One Devoted Fan)!

cornflower
Recycled Graphics on Skateboards

cornflower
Yes, All That Shit Just Gets In The Way!

cornflower
Attack of The Roast Chickens

Jetboard Joust Devlog #105 – Trailer Trash pt 2

Please wishlist Jetboard Joust on Steam here.

Well, the trailer’s finally done – thank God! As with the last instalment I ran into a few issues along the way and got distracted by (necessary) bugfixes. Here’s a brief summary of how things panned out…

1. Oh, Bugger!
The thing about doing a trailer is that it makes you capture and scrutinize a shedload of gameplay footage AND deviate from your ‘learned’ methods of playing your own game. The consequence of both these things is that you uncover new bugs.

I ran into a few new bugs when working on this section of the trailer, most of them related to trying out different weapon types on the bosses. The most significant of these was that there were major deficiencies in the raycasting algorithm I was using to work out damage caused by explosive weapons. Turned out I was only calculating collisions based on axis-aligned bounding boxes (fine for smaller enemies, not fine for the more complex outlines of some bosses). So I had to redo the algorithm to work properly with convex polygons.

There were also issues in the way damage was distributed via ‘proxies’ (e.g. different parts of the same boss) which had to be looked at and problems with the ‘particle storm‘ weapon which were very fiddly to debug.

2. Enemies and Weapons
The next twenty-ish second chunk of the trailer aims to give an overview of the variety of weapons and enemies in the game. I split the into eight 2.5ish edits, taking the timings from the ‘Enter The Gungeon’ gameplay trailer which seemed to pace the edits about as fast as you can get whilst still making sense of what’s going on. Managed to squeeze a brief glimpse of the weapon upgrade process in here too – I wanted to convey visually that there’s upgrade paths available for the weapons.

The edits were made by grabbing a shedload of footage and then whittling it down to the ‘best’ short segment. This was a time-consuming process. I set up levels artificially so I was only dealing with one enemy at a time – ‘real’ gameplay footage proved too confusing as there was just too much going on most of the time.

3. Bosses
The next twenty seconds or so provide a five second ‘reveal’ of the first four bosses. That’s only enough time to sneak a look at the first attack phase of each but I think that’s enough – I’m bit worried about giving too much away as it is. As with the previous stage, I had to grab a ton of footage and then whittle it down to the ‘best’ edits. I also had to bear in mind the transitions between the edits whilst grabbing the footage, i.e. make sure the player was positioned onscreen at a point where a smooth transition would be possible so the viewer’s eye never has to make a disconcerting jump. I found this was particularly important when dealing with very short cuts. I had to re-shoot a couple of edits in both this section and the last in order to get these transitions smooth.

4. Out With A Bang
Initially this section was simply a glimpse at the final boss fight but I felt that just cutting to titles after this seemed rather lame. Consequently I worked on a more ‘scripted’ take where the player flies over the final boss and then takes it out with an R.P.G. It’s not possible to do this in the actual game (the fight has about five stages) but it acts as a significantly more punchy ending to the trailer.

I had to do multiple takes of this to get it right as I needed to fly over the boss, shoot it accurately, and then position the player accurately in the middle of the screen all without doing anything visually unappealing like crash into the edges of the screen or flipping left/right too much. there were plenty of bloopers – including some where I fired the R.P.G. in completely the wrong direction.

5. Outro Titles
I ended up doing these in code and positioning them over the last section in After Effects using chromakeying. Initially I thought I’d animate them in After Effects but I just found this far too fiddly. Fortunately I was able to use the in-game logo ‘entrance’ without having to change anything much so it was mainly about animating the subheadings with the release date etc. I like the way the smoke is still dissipating in the background as the titles appear!

6. Back To The Beginning
Lastly, I went back to the start of the trailer. I was every-so-slightly over 1:30 seconds so I edited the initial titles down a bit. As some people had commented that the player appeared to come ‘out of nowhere’ a bit (I kind of agreed with this) I tried panning across to the player before going back to the alien babies/abductions. This seemed to work. I also made the player blink in this cut to bring him to life a bit (done in After Effects) and added ‘abduction’ and ‘mutation’ text with pans and zooms with the rest of the action.

Now I think we’re finally there. Next task – Steam page and assets!

Dev Time: 8 days
Total Dev Time: approx 300 days

previous | next

The Final Trailer In All Its Glory

mockup_3x
Raycasting Now Works Correctly With Convex Collision Polygons

mockup_3x
Fixing ‘Proxy’ Collision Detection Bugs

Jetboard Joust Devlog #104 – Trailer Trash pt 1

Decided to split this devlog in two as making a videogame trailer is a fairly long process, particularly when you don’t know what the hell you’re doing! Plus there’s been a couple of other things that needed attending to before I felt I could really progress as I’d like.

1. Audio FX
Firstly I had to do some more work on the in-game audio. There were a number of actions I felt required fx that didn’t have any (some pretty important such as unlocking weapons and worlds) and a couple I wasn’t happy with. I spent a couple of days on this. There are now around 270 individual effects files in the game, and that’s not including background music and loops! I think the audio is a pretty distinctive part of the game due to the fact it’s all produced from scratch on analogue gear – no stock samples here, folks!

2. Performance Optimisations
Secondly, as I was recording a bunch of action footage I began to notice frame-rate drop at a few points where there was really intense action on screen. This was exclusively at places where enemies that release a bunch of ‘offspring’ are destroyed by a weapon that kills the enemy and all it’s offspring in one fell swoop (e.g. the jetboard attack). The resulting explosion-and-bonus-fest was just a bit too much.

So, I worked on some optimisations for the above. This included adding object pooling for every object that’s generated when an enemy is destroyed, combining multiple smaller explosions and/or smoke clouds that are very close together (and instantiated in the same frame) into one larger one, and pre-caching of the terrain elements that pickups might hit as they fall (rather than calculating this every frame). I’ve also let some offspring ‘escape’ in the above scenario as I didn’t like it when absolutely everything got destroyed. I no longer see any frame rate drop now, even when there’s a shitload of fireworks going on, and I’m running a Mac from 2008!

3. Start The Trailer
Before starting the trailer I read through a number of very helpful blogs on the subject by Kert Gartner and M. Joshua. Here is a particularly good one.

3.1 Choose The Tools
One of the most useful practical tips I picked up from these was a pointer to an app called Screenflow that will grab 1080 game footage at 60fps even on my ancient Mac. I’ve been through a bunch of these screen capture applications (Snapz Pro, Capto, Screenium) but Screenflow is the only one that will do this. Capto is cheap and neat (this is what I’ve used for most of my animated GIFs and devlog posts) but will sometimes compress really heavily for no apparent reason, Screenium is almost as good as Screenflow (and cheaper), will let you record a set area AND remembers this rea (really useful) but it still compresses a bit even at the highest settings (plus I found it’s editing tools a tad clumsy and prone to crashing). For the purposes of recording gameplay footage for trailers Screenflow definitely comes out tops.

3.2 Intro
Probably the hardest part of the trailer to get right is the first 15 seconds. You don’t want to lose the user’s interest and you have to attempt to communicate the core mechanics of your game in as short a time as possible (without being overly didactic). I’m still not sure I’m 100% there but I think what I’ve come up with does a reasonable job of communicating abductions, mutations, the jetboard attack and the general carnage of the game in that timeframe. To get this footage I used a combination of scripted events (i.e. faking things through coding) and playing through a set sequence over and over again until I managed to one-shot all the enemies in a way that looked effortless and ‘readable’ enough.

3.3 Shock & Awe
After this initial intro section comes just under another 15 seconds of what I’m referring to as ‘shock and awe’. This is a high-octane segment that focusses mainly on the destruction wrought by the jetboard attack but also features a couple of other weapons. This is all ‘real’ gameplay footage, I just recorded a load of stuff to get a variety of enemies and palettes. I deliberately try and move the action from one side of the screen to the other here.

3.4 Breathing Space
Lastly comes just over 10 seconds of ‘breathing space’. A longer cut in which we see the destruction of a boss, the opening of a treasure chamber and the discovery of a new weapon. This section has a certain amount of scripting (reducing the bosses health and getting rid of some onscreen distractions) but is largely the result of playthrough after playthrough to get things looking slick and pulled off in as short a time as possible.

I’ve tried to keep the player’s position onscreen consistent between cuts so that the viewer’s eyes can easily track what’s going on. I’m also zooming/panning across the action where appropriate in order to avoid ‘dead’ areas of screenspace and create variety. I thought this might be overly distracting but it doesn’t seem to be.

So now we have just under 45 seconds of trailer done which is approximately half of it. Next step, around 20 seconds on enemies and weapons, 20 seconds on bosses, and a five second closer!

Dev Time: 10 days (inc 2 days audio and 2.5 days performance optimisations)
Total Dev Time: approx 292 days

previous | next

Jetboard Joust Devlog #103 – A Broader Palette

Well, I reckon this has been the longest break between devlog updates so far. I’ve had two contract jobs on, one of which turned into a bit of a never-ending spiral with the client refusing to pay me unless I kept adding additional functionality (for free). Shame, as it was kind of a nice project otherwise. I have a bit of a rule about not working for startups which I broke for that one as I knew the person involved and was interested in the concept.

I’ve also had a lot to do at a rental property I own which needed considerable TLC between tenants and which was built to a very shoddy standard. Grinding out and re-doing grouting between floor tiles in the bathroom was a horrendous job – hope I never have to do that again!

Anyway, you don’t want to hear about that shit. The bulk of the work on Jetboard Joust has been in finalising the main palettes for each of the five ‘worlds’ that comprise the game. I’m going to have four main palettes per world, plus a bunch of ‘bonus’ palettes that can be unlocked by completing specific levels.

I probably should have coded a tool to make this process easier but I just couldn’t face it when the time I had available was very piecemeal, generally half a day here and there between contract work and property maintenance! Consequently my working process was pretty inefficient, basically editing a big PNG of all the palettes in Photoshop before recompiling and running the game to see how things looked.

There are ten colours per palette in the game and the following items can all have a different palette applied (though in practice many share the same palette)

– Player
– Enemies (three types)
– Bosses
– Pickups
– Terrain
– Floor
– Background parallax (both layers)

To design the palettes I used a combination of reference material and inspiration from messing around with colour association using coolors.co and a simple colour ramp generator.

The actual palettes themselves I’ll list below and detail the specific inspiration where appropriate. These are all in the order they appear in the vids.

World One
I wanted to start the game with earthy, muted colours and then progress to more vibrant colours as the user moves through the worlds, as well as slowly introducing different palettes for different sprites. The first palette is the slightly gameboy-ish one I’ve been using from day one and I gradually add more subtle hues to this as we move on. There’s no specific inspiration for the palettes in this world though I was looking a bit at army camouflage designs for the third palette here which is currently named ‘Going Commando’.

World Two
Each of these palettes had a different inspiration, only two of them particularly related.

1. No Space To Scream
A good ‘segue’ palette from the muted colours of world one. This is inspired by the colour scheme for the branding of the original Alien movie.

2. Deep Dive
Inspired by photographs of coral reefs. As the boss in this world is a giant alien robot-fish this seemed appropriate somehow.

3. Neon Flux
Inspired by neon-heavy nighttime shots of cities, particularly Tokyo. Visually it has the feel of being a much more saturated version of the previous palette.

4. Aliens on Acid
Originally inspired by the ‘Alien’ colour scheme as was the first palette, only with colours so saturated it almost has an early arcade / ZX Spectrum feel.

World Three
We go back to a slightly more ‘muted’ feel for these palettes, all of which have their inspiration from vintage designs.

1. Stan and Jack
Inspired by the cheaply printed colours of early comic books, particularly the Marvel stuff.

2. Dead Red Revolution
Partly inspired by poster art from ‘Grindhouse’ style movies (I have a large poster for ‘Death Proof’ on the wall of my studio) and partly by the artwork for Red Dead Redemption which has a similar ‘vintage’ feel.

3. Forbidden Fruit
Inspired by a poster for the 50s sci-fi classic ‘Forbidden Planet’ – I’m really pleased with this one.

4. Retro Apocalypse
Inspired by some cover art for a 50s or 60s pulp sci-fi novel. I am not convinced by this one. It kind of works but some of the sprites just don’t. Needs more work!

World Four
All inspired by various ‘horror’ related themes! We move back to some pretty saturated colours for these ones.

1. Dead Evil
Inspired by the original posters for Sam Raimi’s ‘Evil Dead’ movie.

2. House of Hammers
Inspired by the poster art for various low-rent Hammer horror films. This is another one I’m particularly pleased with.

3. Toil and Trouble
I went for deliberately clichéd ‘Halloween’ style colours for this one. Very saturated and ‘in your face’ but I think it works.

4. Black Mass
Inspired by various different, more modern, horror film posters – as well as the artwork for the ‘American Horror Story’ TV series (which I thought was terrible and never made it past the first series).

World Five
These were mainly inspired by the manual artwork for early Atari arcade cabinets. I absolutely love that stuff and it also adorns the walls of my studio (alongside the aforementioned Death Proof poster and paintings by Basquiat and Tapies).

1. Rayguns at Dawn
Inspired by the ‘Space Duel’ manual art.

2. Planet X
I forget what inspired this specifically (oops) but I’m pretty sure it was the cover art for another vintage pulp sci-fi novel.

3. Gravity’s Rainbow
Inspired by the ‘Gravitar’ manual art. This is one of my favourite palettes in the game.

4. Prospero’s Cabinet
Inspired by the ‘Tempest’ manual art.

There’s still the bonus palettes to be finalised, I’ve done quite a few of them and there’s a lot of nods in there to 8bit home computers and consoles. That’ll be the subject of another post though! Hopefully things will move a little quicker over the next few weeks, next task is to fill in a few gaps in the audio then do a pretty much final teaser vid and get my Steam page up (I probably should have done the latter months ago).

Dev Time: 10 days (pretty broad estimate)!
Total Dev Time: approx 292 days

previous

World Two Palettes – Aliens and Oceanography

World Five Palettes – Atari Arcade Manual Art

mockup_3x
Awesome Atari Arcade Manual Art

mockup_3x
The Forbidden Planet Poster That Inspired One Of My Favourite Palettes

Jetboard Joust Devlog #102 – It’s the Little Things…

So… following on from my last post about bugs, here’s everything that was on that Trello TODO list that’s more of an ‘improvement’ than a bug (though of course, fixing bugs is always an improvement)!

1. Different Damage Types
I’ve added different damage types – physical, fire, plasma and jetboard and given enemies the ability to be resistant (or vulnerable) to certain type of attack. Some weapons deal out a combination of damage attacks. I’ve also added armour upgrades that increase the player’s resistance to these various damage types.

2. Object Pooling
I’ve added object pooling as described here to the flamethrower and antimatter gun, both of which were spitting out a ton of new objects per frame which was causing some slowdown if a bunch of enemies appeared armed with the same weapon type.

3. Destructible Buildings / Enemy Bones
I’ve massively improved the animations for destructible buildings and also added rubble which interacts (to an extent) with the player. Buildings now take damage from explosive weapons as well as the jetboard attack, adding to the immersive destruction. Enemy bones and rubble now spin in the air when disturbed with great force – this can look pretty cool under certain scenarios, totally pointless in terms of gameplay but cool!

I’ve also been through and designed skulls for every enemy and added shrapnel as well as bones as that seemed more appropriate for seom enemies.

4. Improved Explosions
I’ve added a bunch more visual ‘snap and crackle’ to the explosions. Spent way to long on this for something that only last a few frames and ended up going down a complete rabbit-hole writing a custom shader based on Voroni patterns (to give the ‘crackle’ effect) which still doesn’t work quite the way I wanted but I think will get the job done. I spent time doing some frame-by-frame analysis of a bunch of pixelart explosions I liked – one thing that surprised me is that the initial ‘whiteout’ flash in many explosions is often preceded by a ‘blackout’ frame. Of course I had to add one!

5. Improved Camera
One of my many arch-nemesises (or should that arch-nemesi?) throughout this project has been the bloody camera. Been back and re-worked it yet again, radically simplifying the code and ending up with a result that’s much better for it. Still little work to do but I think it’s finally almost there. Whereas before I was positioning the camera based on speed/time moving in one direction and enemy position I now rely solely on enemy position and only use speed/time moving in one direction if there aren’t any enemies nearby. I also take difficulty into account when calculating the ‘weighting’ of enemies.

6. Improved Jetboard Attack Visuals
I felt this needed more ‘punch’. It was one of the first things I designed and, as a result, was looking somewhat lacklustre compared to the rest of the visuals. I’ve added particle trails to the jetboard, a subtle shader effect that approximates the attack area, camera shake and a camera jolt. I think the result has miles more ‘oomph’ than it did before.

Oh yeah, I also made the jetboard attack quench fire if the player is alight and safely detonate any ‘stuck’ explosives (cluster bombs or limpet mines).

7. Improved Bomber Enemy
I didn’t like the way these guys pretty much ignored the player as they were attacked, just soaking up bullets until they exploded. I’ve made them get much more aggro when they take damage now which gives them a load more personality.

8. Improved Mother Enemy
This enemy was a bit too much of a ‘bullet sponge’ as well. I revisited the art for this one as I felt it looked a little flat, then I reworked the enemies it gives birth to, making them much more aggressive so it feels more akin to the ‘swarmer’ enemy in Defender that inspired it. I also changed the ‘bullets’ it fires, replacing them with little ‘space invader’ type characters that have far more personality and are far less annoying (though no less difficult).

9. Improved Squocket Enemy
As mentioned in the last post, the AI for this enemy was buggy so I rewrote it. The bullets it fired were also pretty lame and quite annoying so I’ve replaced them with these little ‘baby squocket’ dudes which (can you see a theme here?) have far more personality and are harder but somehow less annoying and more ‘fair’ at the same time! The screen capture software I use went a bit glitchy when capturing the video for these so apologies for that!

10. Improved Baiter Enemy
More of the above here! The enemy itself I was happy with but it’s bullets were really annoying so I’ve replaced them with another little mini invader.

11. Re-routed Treasure Chambers
I had placed these deliberately sporadically throughout the game world so that it would take tons of plays through to get to all of them but in retrospect I think that would have been too annoying. Consequently I’ve reworked things so that you should be able to get all the key treasure from any particular world in three ‘passes’ (or less using teleports). This has meant there’s not much treasure at the outer reaches of the game ‘pyramid’ so I might have to add a few bonus treasure chambers in those outlying reasons to give players a reason to go there other than sheer completionism.

There’s been loads of other minor improvements too but those have been the major ones. Next step I think I need to finalise the main game palettes and then start thinking about a ‘final’ (?) demo movie! The end is almost in sight people…

Dev Time: 7 days (ish)
Total Dev Time: approx 282 days

previous

mockup_3x
Unlocking Plasma Armour

mockup_3x
Destroying Buildings And Playing Amongst The Rubble

mockup_3x
Explosions With More Snap & Crackle

mockup_3x
Bombers Are No Longer Bullet Sponges

Gratuitous Showing Off of the New Jetboard Visuals


The Improved ‘Mother’ Enemy, (Defender Swarmer)


The Improved ‘Squocket’ Enemy and It’s Offspring

mockup_3x
Re-routing the Treasure Chambers

Jetboard Joust Devlog #101 – Bug Days

Yup, it’s been a while (again). I’ve really had my head down trawling through a list of bugs and small(ish) improvements that I’ve been noting down in Trello over the past few weeks. Desperately trying to keep the motivation up. Have also had a bit of contract work on (which is welcome given the current state of the BitBull coffers) which isn’t over yet either.

So I’m just gonna bore you with a long list of these bugs as this shit is all part of the joy of gamedev. The improvements, which I’ll cover in the next post, are rather more interesting. As well as these there’s been a ton of other minor fixes and a lot of just going through and checking stuff over.

1. Max Out Weapon Damage
Weapons that dealt out damage for more than one frame were often inflicting more damage than they should if they came into contact with an enemy over the course of several frames. This was particularly apparent on bosses which often have a large vulnerable area and multiple ‘proxy’ parts that do damage to the main character. I now keep a ‘damage record’ for these weapons over the course of their lifespan to ensure they don’t exceed the maximum damage to any particular enemy.

2. Fake Frame Rate Judder
Sometime it could appear that the frame rate was juddering if multiple enemies were destroyed in quick succession. This is because I deliberately drop a frame with each explosion to add to the jolt effect. I’ve now implemented something so that this ‘drop frame’ can’t happen too much in quick succession.

3. Palette Fixes
There were multiple issues with things being drawn in the correct palette – particularly with weapons that should be drawn in the same palette as the enemy that fired them. These issues were exacerbated by the fact that I’ve now added three possible palettes for different enemy types. Been through and fixed all these.

4. Bones and Rubble Not Wrapping
Enemy bones and the rubble from destroyed buildings weren’t wrapping with the rest of the world in relation to the player. This had me scratching my head a bit at first – there are a ton of these sprites so I don’t want to check them for wrapping every frame. In the end I figured I could get away with just checking one per frame (the wrapping doesn’t have to be accurate as it always happens way outside the player’s view). This works fine and has zero performance impact!

5. Check Level Up Rate and Damage Scaling for All Enemies
Some of these were wrong so I’ve been through the laborious process of checking all the scaling parameters =for every enemy.

6. Splitting Crawlers
Under some scenarios the ‘crawler’ enemies were doing weird shit, splitting in two and stuff. I think I’ve fixed this (it was to do with the algorithm that positioned them sometime positioning them out of the player’s ‘wrap zone’) but it was such a hard bug to replicate I can’t be sure so I’ve also added some code to ‘paint over’ the bug should it happen again (I hope)!

7. Levels Completing Too Early
This could happen with enemies that split into multiple offspring when destroyed. Had to write something toi account for this in teh code that checks for level completion.

8. Parallax Scrolling Glitches
Keen observers may have noticed this on some of the GIFs – elements of the parallax scrolling kept moving when they shouldn’t and, on very rare occasions, could completely glitch out. This was a real pain in the arse to fix for something that should really be pretty simple – in the end I re-wrote pretty much all the parallax scrolling code from scratch.

9. RPG Anim Playing Constantly Post-Mutation
RPG weapon would glitch out if the enemy that was armed with it mutated. This was another one that was a real pain in the arse to fix (hard to replicate). In the end I figured out it was to do with object pooling.

10. Flamethrower Not Working On Egg Sacks
Easy fix

11. Jetsuit Pickup Not Wrapping
…and doing other weird shit like disappearing. I’d implemented this in a rather hacky way for some reason so went back and wrote it as a ‘proper’ pickup.

12. Invaders Getting Stuck
Blocks of invader enemies could get wedged between a high building and the top of the screen and end up not moving. Fairly straightforward fix.

13. Title Screen Glitch
Title screen could get weirdly offset if the player exited the game whilst in a treasure chamber(!). Fixed this along with a few other game over / exit issues.

14. Treasure Chamber Escape
Player’s could jump out of a treasure chamber using the jetboard attack and end up falling endlessly through the void beneath! Fixed.

15. Buggy Bombers / Gravity Hammer
Bomber enemies were glitching out sometimes when struck by the gravity hammer. Fixed this and have also gone through and checked a bunch of other enemies against the gravity hammer (which has probably ended up being the most PITA of all the weapons).

16. Player Jump Anim Constantly Playing
This could happen sometimes after a jetboard attack. Was surprisingly difficult to fix, largely because I haven’t touched that part of the code for something like three years now!

17. Teleports Skipping Levels
Fixed various bugs to do with the selection of levels when teleporting.

18. Teleports Blocking Chamber Entrances
Sometimes teleports and warp gates could appear over the treasure chamber entrance making it impossible to enter the chamber. Easy fix.

19. Disappearing HUD
Sometimes the HUD wouldn’t appear correctly on the upgrades screen meaning the user had no idea how much cash they had to spend. Fixed.

20. Enemies Appearing ‘Inside’ Buildings
Problems with some of the algorithms that position enemies as they teleport in. Fixed.

21. Scanner Rendering Of Destroyed Buildings
The scanner rendering of destroyed buildings was glitching out if the building was destroyed after it had wrapped relative to the player. Fixed, with some difficulty. At least this one was easy to replicate!

22. Explosive Raycasting Issues
There were some issues relating to the removal/blocking of enemies in the raycasting checks that are carried out for explosive weapons. Fixed these and also tweaked the raycasting code for much better damage distribution, plus made all explosive items inherit from the same class and got rid of a load of dodgy ‘cut and paste’ code.

23. Squockets Getting Stuck On Buildings
Sometimes the ‘Squocket’ enemies could get wedged somewhere and just keep banging their heads against a brick wall. I wasn’t entirely happy with the tracking code for this enemy anyway so re-wrote the bulk of it.

24. Limpet Mines and Collision Proxies
Limpet mines were sticking to collision proxies that weren’t transferring damage in their current state, rendering them pointless. Does that mean anything to you? Probably not, but it was an easy fix.

Dev Time: 7 days (very approximately)
Total Dev Time: approx 275 days

previous

mockup_3x
The Joy of a TODO List That’s Now DONE

Bug Day!

Jetboard Joust Devlog #100 – Die and Try Again!

This blog should really have been Configuring Things Out pt. 2 but I thought ‘Die and Try Again’ was more appropriate really.

Now all the enemies and weapons are finally done I’ve been going back over the game worlds, playtesting and (re)adjusting all the various character/weapon stats and levelling rates. The only way of balancing the weapons is to simply play the game a lot, and if I feel I’m either avoiding particular weapon because it’s too weak, or that I’m constantly gravitating towards a particular weapon because it’s too overpowered, I tweak the stats as appropriate. It’s been a very time consuming process and I have to say I’ve been at something of a low ebb whilst doing it.

Unlike fixing a bug, you don’t ever get to the point where you think something is ‘done’, and I know I’m going to have to go through this whole process again at least one more time to refine things further before the game is complete. It’s really getting to me now.

The thing that’s made this phase so much tougher than the first configuration ‘pass’ is that I’ve been through every single boss and mini-boss fight in the first four worlds and attempted to adjust the difficulty for each. There are over fifty of these and, by nature, they are supposed to be tough, so this entails a *lot* of failure both in terms of dying in-game and in terms of setting the difficulty level either too easy or too hard.

Most of these challenges are mini-boss battles featuring the Guardian enemy and a new weapon unlock or upgrade. To maintain a certain amount of narrative ‘flow’ (and to stop me being lazy) I’m having the enemies guarding the unlocks armed with the same weapon they are protecting. The strength of the enemy is heavily dependent on the strength of the weapon, therefore a tweak to the stats of said weapon (because I think it’s too weak or too strong in-game) has a knock-on effect in every single battle that features it. It’s a cyclical process and one that I’m starting to think could go on forever, like painting the Forth Bridge. On a good day though I see it more as a kind of gradual ‘whittling down’ with every pass getting me nearer to the ideal balance.

It also makes a difference what weapons are available to the player during these battles. I was choosing these weapons completely randomly (but based on a consistent seed) though towards the end of the process I realised this wasn’t working and I needed a better balance of weapon choices. Consequently I’ve divided the weapons into four categories – long range, short range, wide range and explosive, and I make sure a balance of weapons from each category is chosen. I think I may ditch the consistent seed as well so each time you enter a level the weapon choice is a lottery, albeit a balanced one.

There’s also been a myriad of bugs and other gameplay tweaks I’ve made along the way though at this stage I’m trying to restrict myself to fixing bugs/tweaks that actually affect the balance of gameplay and noting everything else down on Trello cards for later attention. There’s currently around fifty of the Trello cards (groan) and there’s at least another ten things I haven’t noted down yet!

I’ve also been back through the first four major boss fights and made a proper attempt to balance the difficulty of these with the (rough) stats the player should have achieved by that point in-game. If you’ve been following this blog you’ll remember how much time I’ve spent on these boss fights already, so it’s been doubly demotivating having to go back to them, debug them again, run through the fight procedure again and again AND again whilst discovering yet more bugs and issues that need fixing. On a positive note though, it’s been nice to revisit them in different colour palettes.

Lastly, and I know this is going to sound like archetypal first-world moaning, I’ve been surprised how physically exhausting this process has been. Basically playing (often ludicrously difficult) boss fights for eight hours a day for eight or nine days straight takes its toll. I try to be as careful as I can be about posture but my shoulders ache, my wrists and elbow joints ache, and my back is fucked. Yes, I know it’s not exactly working down a mine, but being physically in pain doesn’t do wonders for one’s motivation. I can’t wait to finish this game and take a break from this shit.

Oh yeah – one thing that’s kept me going through this process is the fact that I can just turn the game sound off and listen to music. I’ve finally succumbed to subscribing to Spotify and have been listening to a lot of Tangerine Dream. Strange coincidence – I finally got round to watching Netflix’s enjoyable Bandersnatch interactive movie at the same time and what does that feature? A ZX Spectrum game developer slowly going insane trying to finish a game whilst listening to lots of Tangerine Dream! Weird…

Right, on to those Trello cards…

Dev Time: 8.5 days
Total Dev Time: approx 268 days

previous

mockup_3x
The ‘Spinner’ Boss In Colour

mockup_3x
The ‘Squirmer’ Boss In Colour

R.P.G. Guardians. Die and Try Again – and Again, and Again…