Category Archives: Art

Jetboard Joust Devlog #38 – 2D Or Not 2D?

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

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

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

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

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

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

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

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

previous | next

First Attempt – Solid, But Too ‘Brick-Like’

More Open But The Arches Don’t Work

I Think This Is It – For Now!

Scrolling Through…

Jetboard Joust Devlog #37 – Shake, Rattle & Roll!

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

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

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

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

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

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

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

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

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

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

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

previous | next

One Of The First Impact Shader Attempts

Something A Little More Subtle

Adding Raster Lines For A ‘Shake’ Effect

Adding Scaling Spikes

Final (No Chance!) Impact Shader, Scanner Distortion & Camera Shake

Jetboard Joust Devlog #35 – Abductions & Mutations

Now we have our alien babies it’s time to make something horrible happen to them – seems cruel but this is a videogame right?

First step was to get the enemies to abduct them. This was rather harder than I thought as it required some reasonably complex changes to the AI in order to get the ‘chasing baby’ code to play nice with the ‘chase player’ code. Picking up ‘cargo’ in Jetboard Joust is more complex than in Defender as the terrain in Jetboard Joust can be interacted with whereas in Defender it’s just for show.

I didn’t really run into any issues I hadn’t come up against already when writing the ‘chase player’ code though so thankfully I could pretty much reuse the techniques I’d come up with there and blogged about earlier.

One thing I have implemented in order to get things to look vaguely ‘realistic’ is an ‘aggro range’ parameter for the enemies. This is the range within which enemies will actively chase the player – outside of the aggro range enemies will idle or attempt to abduct babies(!) When the aggro range is activated it becomes larger so the player must run a certain distance away from the enemy in order for it to go back to ignoring them.

If an enemy is in the process of abducting a baby the aggro range is shorter, however if the player shoots the enemy or strays too close it will still go on the offensive.

Another issue with the abductions was having the baby ‘jump’ to the middle of the board when picked up. In order to make this look decent I had to implement some code to check whether the enemy had passed ‘through’ the baby at the last update. This raised another issue though in that if a baby ended up positioned right next to a building it was impossible for the enemy to pass ‘through’ it – this was a pretty rare occurrence but impossible to avoid so I’ve implemented a necessary hack for these situations where a ‘pass through’ is not necessary. The baby jumps slightly but it’s better than it being impossible to pick up.

Next step – design a mutant! This was fun and I’m pleased with the results, I didn’t take me too long either. For inspiration I had in mind Space Invaders (of course), Cthulhu, and the aliens from District 9. The mutant animates slightly differently to other board-riding enemies but it wasn’t too tough to get this working OK – I’d already set the relevant methods up so they were easy to override.

Fortunately the actual transformation happens offscreen so this part of the sequence was very easy! Part of me thinks I should do some kind of onscreen transformation – or will that look a bit odd?

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

previous | next

Stay Away From My Babies!!

Babies Aren’t So Cute When They Grow Up


Jetboard Joust Devlog #34 – Making Babies

I’ve been thinking for a while that the basic ‘destroy all enemies’ objective in Jetboard Joust was a bit too one-dimensional and that I needed to add something to give the gameplay a bit more depth.

The obvious source to look for inspiration was Defender, to which Jetboard Joust is pretty much a homage, so look to Defender I did!

In Defender you protect these little coloured blob things which get carried off by a certain type of enemy. If an invader manages to get a blob to the top of the screen it mutates and becomes a lot more dangerous. I thought I may as well go the whole hog with the Defender homage thing and replicate this scenario – maybe I could have the player protecting radioactive cannisters which enemies carry off and then use to mutate themselves?

This seemed to make sense to I went about designing some radioactive ‘cargo’. Unfortunately, despite my best efforts, it was shit! The little cannisters were OK but drawing a decent radiation symbol in about 5×5 pixels proved beyond my abilities, and the cannisters on their own just looked too boring. Time to rethink!

According to the Wikipedia page for Defender the little coloured blobs that you defend are, in fact ‘astronauts’ (not that you’d guess it from just playing the game). This triggered a memory of them being referred to as ‘humanoids’ in the original game instructions (though i could be wrong about this).

Something with a bit more character seemed a good idea so I thought I’d go about designing the most basic ‘humanoid’ form I could in as few pixels as possible and see if that would work. What I came up with kind of looked like a baby version of ET so I thought – what if you were protecting alien babies? This seemed to make sense! Babies are inherently something that warrants protecting, they look cute and have character, and having them carried off by aliens has overtones of the whole alien abduction/conspiracy thing which I liked.

So now I have alien babies! I created a little ‘idle’ sequence for them and a ‘panic’ animation for when they’re abducted. I think they’re pretty cute! Glad I was so bad at drawing radiation canisters! Now to work on their abduction…

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

previous | next

Alien Babies – Panic Animation

Alien Babies – Idle Sequence

Jetboard Joust Devlog #32 – Knob Rocket

Rather a frivolous blog post this one but I feel I should document everything, warts and all – and this issue has cost me a worrying amount of time.

I needed to add a rocket pickup so I could limit the use of the jetboard ‘jump’ attack (will write more on this in the next post). This should have been a simple task but unfortunately my ‘pixel rocket’ ended up looking rather too much like a ‘pocket rocket’!

I tried an alternative which I thought was OK but several people on Twitter though it was still too phallic so it was back to the drawing-board again.

Eventually I got there. The issue really was that the ‘shaft’ of my rocket was only two pixels wide – this meant that the end always looked ’rounded’ instead of ‘pointy’. Thickening the shaft to three pixels allowed me to have a pointy end which, I think, removed any sexual connotations for all but the most filthy-minded of individuals (I can’t believe I’m actually writing this).

Oh yeah – I’ve also added a new enemy type, I’m calling this one the Minion!

Dev Time: 0.5 days
Total Dev Time: approx 33.5 days


Pixel Rocket Or Pocket Rocket?

The De-Willification Procedure

Final Rocket Pickup In-Game

Introducing The Minion

Jetboard Joust Devlog #28 – Bounty Hunter

So, with those annoying bugs out the way it’s time to start on what will probably be the last pickup – cash!

I want to have some kind of in-game currency for upgrading weapons and the like and I can’t see any point in getting too clever about it so I’m just going to stick with cold, hard cash. Plus I like the retro feel of having big spinning coins that get scattered all over the place – having an enemy dissolve into spinning coins is something of a videogame archetype after all.

The spinning coin wasn’t too hard too get right (at least compared to the spinning crate) but still took me a good couple of hours tweaking. I may well have different sizes of coin so this one, at 12px square, will either be the small or medium. I’m pretty pleased with it though I’m in two minds about whether the way some of the middle pixels flash a bit looks like light reflecting or just looks crap!

Once the coin was done the rest was pretty straightforward implementational stuff – the thing that took the longest was tweaking the particles etc for the ‘got coin’ effect. I also had to add a ‘cash’ element to the HUD.

So now I think I have all core gameplay elements in place really – now I need to start adding some enemies properly and get working on a first playable level. This is also the point where I need to decide if I’m going to do my main gameplay testing on mobile/touchscreen or PC/controller. Or both!

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

previous | next

The Spinning Coin

Bounty Hunting

More Bounty Hunting

Jetboard Joust Devlog #27 – Bang Go Some Bugs

Bit of a ‘clearing the decks’ session today as I get rid of a few bugs that have been irritating me. There were problems with the teleport sequence that I needed to fix (the jetboard weapon attachment not getting displayed correctly), the ‘lost the jetboard’ sequence was annoying me (as the main character carried on waving his arm all gung-ho even when it was obvious he was heading for certain death) and I needed some kind of explosion/disintegration effect for a destroyed jetboard.

None of these proved particularly heinous to sort thankfully so I could move on pretty quickly to tweaking the enemy explosions which I wasn’t entirely happy with. I wanted something a bit more dramatic but not too OTT and think I got there in the end – though my first attempts were way to extreme. Took a fair bit of tweaking though.

I tried adding a velocity deviation to the particles in the enemy explosion but I think I prefer it with the particles moving at a more uniform velocity. It’s not ‘realistic’ but it seems to fit with the visual feel to me, slightly more glitchy and geometric in quality.

Dev Time: 0.5 days
Total Dev Time: approx 29.5 days

previous | next

Improved ‘Lost Jetboard’ – Not So Gung-Ho Now!

Too Much ‘Shock And Awe’ For George W Bush Even?

Toned Down – Almost There

Final(!?) Explosion – More Uniform Particles

Jetboard Joust Devlog #26 – Pistols At Dawn

So – with the AI now looking respectable it’s time to get the first basic weapon in there!

I should add that before doing this I did improve the AI a bit since the last post – instead of just charging ‘through’ the player when moving to a safe distance it now makes an attempt to fly over or under instead. This looks a lot better, particularly when going ‘face to face’ on the ground and between obstacles.

The most basic weapon, other than the jetboard jump, is the pistol (has to be). Implementing a simple pistol shot should be easy but it took me rather a long time as, as ever, I started obsessing over the details. I started with a simple two pixel square as the bullet (that’s all the room I have to play with really) but wasn’t very happy with it so began using a simple particle effect to create a type of trail instead. This looked much better but when the entire trail disappeared at the end of the bullet’s range it looked rather odd so I had to implement a way to have the trail carry on moving and disappear at the same place as the ‘main’ bullet. Doing this in an efficient manner (ie not by creating loads of separate sprite objects) was a bit of a pain in the arse – I also had to think about what would happen when the bullet collided with an obstacle too.

Got there in the end though – and added a simple particle effect for when the bullet disappears or explodes. When everything slotted together it looked quite satisfying – like fireworks.

I also added a bunch of generic parameters that will apply to every weapon and affect the speed at which a weapon can be fired – these are:

Whether the weapon auto-fires when FIRE is held.

Repeat Rate
The quickest speed at which a weapon can be fired in succession.

Clip Size
The amount of ammo that can be fired before the weapon needs reloading.

Reload Time
The time the weapon takes to reload (doh)!

I think that should give me enough configurations to play with – reloading will happen automatically if enough time is left between shots.

Once all this was sorted getting the enemy AI to fire was pretty straightforward as all the board/weapon code is the same for both player and enemies. At the moment it just pumps FIRE when within a certain range of the player so I need to add some kind of reaction time parameters but it’s pretty effective.

Maybe rather too effective – an unexpected accident was the way the enemy keeps pumping the player full of bullets even after they’re dead ‘just to make sure’. I actually think this is pretty funny so will probably leave it in there – makes the enemies seem ultra vindictive and evil!

I need to tweak this a bit and iron out some other bugs that are annoying me next – then it’ll be on to creating ‘cash’ pickups when enemies are destroyed.

Dev Time: 1.5 days
Total Dev Time: approx 29 days

previous | next

Improved AI To Circumnavigate Player More Effectively

Shock And Awe? The Final Bullet Anim

A Very Vindictive AI – I’ve Created A Monster!!

Pistols At Dawn – Proof That Violence Solves Nothing

Animated GIFs of Gameplay Footage for Twitter on Mac OSX

I’ve been asked how I do this a few times on Twitter so thought I’d write a post about it. Haven’t done a ‘tutorial’ style post in a while. My bad.

Posting animated GIF images on Twitter is a very good way to get retweets and likes and build awareness of your game, but if you’re using a Mac there aren’t that many tools out there for the job. Most people seem to use GifCam on PC but there doesn’t seem to be a Mac equivalent.

In a nutshell I use Apple’s Quicktime Player to screen capture followed by a process in Photoshop to crop and convert to animated GIF. I tried a bunch of different tools and processes before deciding on this as by far the best way.

Make your GIFs 506 pixels wide by less than or equal to 506 pixels tall so that Twitter doesn’t resize them and make them all blurry (especially important for pixel art).

Photoshop has a stupid 500 frame limit for animated GIFs but you’ll probably hit Twitter’s 5mb size limit before this becomes a problem. It is, unfortunately, a problem sometimes though.

So, in detail…

1. Decide On An Emulator
I’m developing cross platform with Xamarin/MonoGame and have found by far the best emulator to use is GenyMotion for the Android platform. I use this for general development and for all screen capture. The iOS emulators are way to slow and grabbing video direct from iOS device is also too flakey and produces too many compression artefacts. The GenyMotion emulator is very fast and can be reliably run at 1:1 ration for pixel art – only downside is that the 1:1 function requires a ‘paid for’ licence.

Xamarin’s free Android Player is pretty good but at the time of writing there are bugs in the handling of key events which means I can’t use it for my purposes.

2. Capture
I use Apple’s Quicktime Player for this. I was using Snapz Pro but it only seems to capture up to 30fps. To screen capture from Quicktime Player just click ‘done’ on the first dialog that pops up then go to File->New Screen Recording. From there it’s self-explanatory.

3. Edit
This step is optional as you can do it in Photoshop. I find it much easier to crop the video to the section I want using Apple’s outdated but incredibly useful QuickTime Player 7 Pro. This is another paid app I’m afraid but it really makes the process a lot less painful.

4. Import Into Photoshop
Open your video in Photoshop and crop it to size. You can ‘scale up’ later when saving as a GIF so you could crop to 50% of your final size (or even less). This can look good for pixel art. Then I do the following procedure…

5. Adjust Colour Profile
– Edit->Assign Profile->Generic RGB Profile
Your mileage may vary on this but I find that screen captures from Quicktime always seem too dark when importing into Photoshop. This alleviates that issue to an extent.

6. Create Layers
Open the animation window (Window->Animation) and in the menu at the top rioght of the animation window select ‘Flatten Frames Into Layers’. This may take some time. Once this is done select the original movie layer (it will be the bottom layer in the layers palette) and delete it.

7. Create Frames
Back to the animation window menu now – this time select ‘Make Frames From Layers’.

8. Save As GIF
You are now ready to export your animation. For some reason I’ve found that Photoshop often does something weird with the first frame, like it’s assigned a different colour profile or something. You can check this by moving the timeline marker in the animation window and seeing if everything looks OK. If it doesn’t you can more the ‘start’ marker to just beyond the problem frame (you can also use these start/end markers to crop the timeline if you didn’t edit your video as described in step 3).

Use ‘Save For Web’ to export and you will have to mess around with the colour settings to get your animation under 5mb. Even if your image contains no transparency keep ‘transparency’ checked as without it file size jumps up dramatically (maybe photoshop uses this to only update areas of each frame that change). Note that you can scale up your image at this point – be sure to select ‘Nearest Neighbour’ scaling for pixel art.

I’ve found that the ‘loop’ setting keeps getting set back to ‘once’ when other parameters are changed so make this the last thing that you do. Changing colour options and the like can result in a lengthy ‘beachball of death’ depending on the size of your GIF so when you see this don’t panic just wait it out.

It’s easy to set up a Photoshop Action to cover steps 5 through 7.

That’s it. Any questions or comments please contact me here or on Twitter.

Jetboard Joust Devlog #23 – Spinning Crate Gate

Finally got the spinning crate sorted thanks to some pointers from very helpful Twitter user @grayhaze.

Seems obvious when you think about it but really the cube should get wider whilst it spins, not narrower as I had it (unless the perspective was ridiculously exaggerated). Another good tip from @grayhaze was to try drawing things from the top when approaching problems like this – if I’d have done that in the first place I wouldn’t have wasted anything like as much time.

So with that in mind I was able to create a ‘flat on’ spinning crate without having to add any perspective – and it doesn’t look like a page turning!

Next task was to actually make the weapon swap happen which, whilst pretty straightforward, involved a lot of setting up of additional classes and code restructuring so was fairly time consuming – note the way the weapon attachment on the jetboard changes in the GIF on the right.

I’m glad this has been put to bed now. Now I need to do some proper work on the enemies which is going to involve even more code restructuring (groan) so you may well not hear from me for a while…

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

previous | next

It Should Get Wider, Stupid!!

Weapon Exchange Sequence Finally Done