Category Archives: Art

Jetboard Joust Devlog #10 – Custom Shaders & Health

You know that horrible sinking feeling when you realise you’ve done something really, really stupid and have just spent the best part of an hour ignoring something that was staring you straight in the face all along? Doh! Not good is it.

I’ve been looking at adding some kind of health/hp to both the enemies and main character in Jetboard Joust. I think the game is going to prove far too difficult if I go for a ‘instant death’ mechanic every time you hit an enemy, plus I want to add a variety of weapons so adding health gives me more scope for different weapons doing different levels of damage. It also gives a very obvious upgrade path for weapons should I decide to add an weapon upgrade system.

So I needed something visual to indicate when a collision has occurred, or when an enemy takes damage but is not destroyed altogether, but I didn’t want to go down the route of creating a specific animation per enemy as this would have proved extremely time consuming (and very difficult to change globally).

Initially I looked at creating a type of ‘white out’ effect using the stencil buffer in MonoGame. I felt sure this was the way to go and sunk a lot of time into this approach, not ever having used a stencil buffer before. Unfortunately I just couldn’t get this to work – part of the reason was due to my own stupidity (the ‘doh’ moment I mentioned above when I realised the code that initialised the DepthStencilState objects I was using wasn’t getting called), but part of the reason was undoubtedly to do with quirks of this feature in Monogame. When I saw that my partially-working code wasn’t running consistently on Android and iOS I decided to abandon this approach as it seemed likely to lead to too much pain and grief.

That left custom shaders as the only possible approach. Fortunately getting these to work was a lot easier than I’d been anticipating. You can’t compile the shaders natively under OSX (which is a pain) but they compile easily using the Monogame Pipeline tool under Windows and I can flip back and forward between Windows and OSX easily with VMWare Fusion. I’ll probably write a separate post explaining how to do this in detail.

You can see on the right the results of my custom shader experiments. Doing a simple ‘white out’ effect was easy. Slightly more tricky was getting the texture to invert in the way I wanted. A simple colour inversion is easy but produced colours that were way out of range of the limited palette I’m using and looked really odd. What I needed to do was invert the brightness of the texture but keep the colour balance intact – I seem to have got there with the following HLSL code. Probably very hacky but it seems to work (Maths was never really my strong suit).

float4 PixelShaderFunction(float2 coords: TEXCOORD0) : COLOR0
{
	float4 color = tex2D(s0, coords);
	if ( color.a>0 )
	{

		float r2 = color.r;
		float g2 = color.g;
		float b2 = color.b; 
			
		float t = r2+g2+b2;
		float rp = (r2/t)/0.3333;	
		float gp = (g2/t)/0.3333;
		float bp = (b2/t)/0.3333;

		color.rgb = dot(color.rgb, float3(0.33, 0.33, 0.33));			
		color.rgb = 1.0-color.rgb;
		color.rgb *= float3(rp, gp, bp);

		color.a *= alpha;
	}
	return color;
}

So the final shader does a simple ‘white out’ followed by alternating inverted and normal frames. The ‘normal’ frames have increased brightness which gradually fades out. I think it’ll do the job for now at least. I imagine I’ll be implementing a few more of these type of effects – HLSL seems like a rabbit hole I can’t stop myself from entering.

Finally I added some more particle effects (another slight addition to the particle generator required to get that ‘halo’ effect) and mini health bars which I think look kind of cool. When health is depleted these animate down rather than just jumping to the next value.

Dev Time: 1.5 days
Total Dev Time: approx 14 days

previous | next

mockup_3x
Before And After – My ‘Invert Brightness’ Shader

mockup_3x
The Final Shader Animated

mockup_3x
Custom Shader Effect In-Game With Health Bars

Jetboard Joust DevLog #9 – Jetboard Pyrotechnics

After I added the ‘thrust’ animations to the jetboard it became patently obvious that I needed something considerably more eye-catching for when the jetboard becomes weaponised. I’d also been thinking that I needed to increase the collision area of the jetboard when it’s used as a weapon as well (otherwise it’s just going to be too difficult to aim).

So I thought there was an opportunity to kill two birds with one stone here. By adding a kind of ‘fireball’ anim to the jetboard when it’s weaponised I not only get something more eye-catching, I also increase the area of the jetboard visually therefore giving me a legitimate excuse to increase it’s collison area as well!

I’m pretty pleased with the results. Took me a while to get the ‘fireball’ effect looking decent (as usual) but I think it works. I split the sprite in two so it appears the weaponised jetboard is travelling ‘through’ the fireball, also added some more particle fx and transformed the jetboard into a rocket so it becomes more obviously deadly.

Dev Time: 0.75 day
Total Dev Time: approx 12.5 days

previous | next

mockup_3x
Check Out The Fireworks

Jetboard Joust Devlog #8 – Thrust!

Best part of a day spent fiddling with the particle generator again!

I needed to add a ‘thrust’ effect to the jetboard and particles were the obvious way to go rather than trying to animate flames or something which would have a) taken me ages and b) probably looked shite.

As you can see from the images – my first attempt was a complete fail but I got there in the end. At least I think it looks pretty good now anyway.

The main extra functionality I needed to add to my particle generator code was the ability to set an initial velocity for the particle generator itself, ie so the particles appeared to be generated by something that was moving rather than from a simple static source. Back to ‘O’ level physics here! Without this the particles tailed behind the jetboard far too much, and if I simply fixed the particle generator to track the jetboard the flame looked much too ‘rigid’. This way I think it tails pretty nicely when you change direction. In fact I’m a bit worried it almost looks too ‘realistic’!?

The horizontal and vertical flames together perhaps look a little weird but I’m not really sure what to do about that at the moment. I think I need to shelve this particular rabbit-hole for a while and move onto something else.

Dev Time: 0.75 days
Total Dev Time: approx 10.75 days

previous | next

mockup_3x
First Attempt == Major Fail

mockup_3x
Looking Better After Much Tweaking

mockup_3x
Added Horizontal Thrusters

Jetboard Joust Devlog #6 – Die and Retry

Development on Jetboard Joust has suffered a bit of a hiatus since Christmas, mainly due to the fact that I’ve been spending far too long testing out alternative touchscreen control systems for ‘Attack of Giant Jumping Man’. I wrote about that (in probably far too much detail) here. Thankfully I’ll be reusing a bunch of that code in Jetboard Joust but more on that later.

Today’s main job has been completing the die/retry loop. I wanted this to feel like it was integrated into the gameplay rather than the sudden ‘cut’ you get on some games when everything just stops and you’re taken back to the start of a level. I think the world/enemy state will remain persistent between lives (if that doesn’t prove to be too much of a pain in the arse) so it’s important that the die/retry loop felt like a ‘long take tracking shot’ rather than some kind of full reboot.

So I settled on the idea of having the player fired out of a Mario-style pipe at the start of each life. This introduces the player to the world quite nicely and seems better than having them simply fall down from the top of the screen or just ‘be there’ which would have been the easiest options. There will be at least two of these pipes per level and I may also use them as a method of exiting the level (but again, more of that later).

When you fall off the jetboard the camera pans to the closest pipe that’s more than one screen width away from the player’s current position. This means I don’t have to make the player sprite ‘disappear’ somehow which I think would look pretty awkward – instead the ‘stunned’ player sprite is just scrolled offscreen.

I added a bit of recoil to the pipe as it shoots – it also wobbles a bit before firing but I couldn’t show that on the GIF due to Photoshop’s 500 frame limit on animated GIFs (there must be a better way of doing that but I haven’t figured it out yet).

As well as die/retry I’ve been fixing a bunch of bugs and quirks and improving some of the animations – such as adding a bit of compression whenever the character lands. I really need to animate that jetboard now!

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

previous|next

mockup_3x
The Die and Retry Loop – No Camera Edits Necessary

mockup_3x
Adding Some Compression On Landing

Jetboard Joust Devlog #5 – Another One Bites The Dust

Another case of #gamedev pottering here as I started work on one thing and got pretty much distracted with another. It was a constructive distraction though and has provided me with plenty of re-useable code so I’m not beating myself up about it.

I started work on the animation for falling off the Jetboard and got it to a stage where I was pretty happy with it, then thought it would look better if I added some dust as the player hits the floor. I decided to use the basic particle generator I’d created for the enemy explosions and added some additional functionality such as the ability to animate particles, apply gravity, and restrict the angle at which particles are fired.

This worked, but in the process of testing I accidentally had the dust particles generated whenever the jetboard landed on anything – and it looked good! Decided to refine this which meant quite a few changes to the particle generator – mainly the ability for one generator to manage particles generated from several locations (to save the costly instantiation of a new generator every time I need some dust). Pretty pleased with the results though the parameters still need a bit of tweaking – some of that dust is getting flung rather too far!

Next up was working on the collision detection and figuring out the various ways you can be knocked off your jetboard. I’ve pretty much nabbed the collision detection from ‘Attack Of Giant Jumping Man’ which has saved a bunch of time and I think I’m going to restrict items you can interact with to simple static platforms as this is a SHMUP in essence, not a platformer.

So, other than colliding with enemies, there’s three ways that you and your jetboard can become separated…

1. Jetboard hits obstacle mid-jump, player still moving freely
2. Player hits obstacle mid-jump, jetboard still moving freely
3. Player hits obstacle whilst in flight, jetboard moves freely

…I also had to cover the occurrence where both player and jetboard come into contact with the same obstacle mid-jump. In this instance (I think) it’s reasonable that the player is able to land on the jetboard and recover though I may restrict this based on how far the player falls.

I’m still not entirely happy with some of the player falling animations but we’re getting there. Probably going to bit a bit of a break from this now whilst I work on ‘Attack Of Giant Jumping Man’ for a bit. Next up will be implementing a simple ‘lose life/retry’ loop.

Dev Time: 1.5 days
Total Dev Time: approx 8.5 days

previous|next

mockup_3x
First Stab At Falling Animation

mockup_3x
Dust Particles In Action

mockup_3x
Three Ways To Fall Off A Jetboard #1

mockup_3x
Three Ways To Fall Off A Jetboard #2

mockup_3x
Three Ways To Fall Off A Jetboard #3

mockup_3x
Recovering From A Fall

Jetboard Joust Devlog #4 – Enemies and Explosions

When I code I have a tendency to ‘potter’ – that is, I’ll start off with the aim of doing something and end up getting distracted by various side-tasks along the way. Much as one might do when gardening!

So in this case I started off trying to get my first simple enemy done and ended up getting sidetracked into writing a particle generator to handle explosions and other FX in the game.

Consequently my initial enemy is still looking pretty crappy. I’m not happy with it at all actually. God this pixel art stuff is harder than it looks! All I wanted was a simple spinning ‘mine’ type thing that will remain largely static as a dumb target. The first attempt was OK but somehow looked wrong compared to the main character – like I was using too many colours or something, not contrasty enough. So I tried again giving it two ‘eyes’ this time and adding another frame to the animation. Still looks crap and now the animation looks all wrong too, like it’s not really spinning correctly. I know – even with four years at art school I should stick to code!

Anyway, in order to feel as if I was making some progress I decided one of these would do as a placeholder and moved on to implementing a simple ‘enemy’ base class and some basic collision detection for when the board is ‘fired’. Easy.

Next I needed explosions, and as this game is partly ‘Defender’ inspired it seemed some kind of particle-based explosion would be the way to go. I’ve never written a particle generator before so have no idea whether I’m going about this the best way (maybe I should have read up about it first) but am pretty pleased with where I’ve got to so far.

A ‘generator’ is instantiated with a max number of particles and a lifespan and chucks out max_particles/lifespan particles per frame.

Each particle has a velocity, decceleration and lifespan (defined at the generator level), each with a defined amount of variance. there’s also the option to set up a tween on the opacity of each particle. I calculate the tween values in advance.

So not much is being done per particle per frame other than calculate the new velocity and draw it. Thinking about it I could probably calculate the velocities in advance as well if I really needed to but not if I add additional factors like gravity which I plan to do. It should prove a very useful class throughout the game.

Another thing I’ve been a bit stuck on is getting the ‘camera’ on the scrolling world to perform to my satisfaction. Still not there on that one yet, hopefully have it resolved by the next installment!

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

previous

mockup_3x
‘Mine’ Type Enemy Attempt – Rubbish

mockup_3x
Tried Again – Still Hopeless!

mockup_3x
First Draft Particle Explosions – Look Like Fun?

Jetboard Joust DevLog #3 – Jumping And Thrusting

Another 1.5 days or so in and, surprise surprise, things aren’t going as quickly as I would like. This is mainly due to the art though which always takes me ages. There won’t really be that many main character animations in the game I guess so I might as well make the one’s that are there as good as I can get them (with my limited pixel-pushing ability).

First off the main ‘riding the board’ anim. This looked OK in Photoshop but in-game it didn’t seem to work. Seemed too wobbly and unnatural. Looking at a few vids people stay pretty still on skateboards/surfboards when they’re riding them and only wobble about when they’re going to fall off!

So after much trial and error I decided to ditch any kind of movement when the player is riding the board. I replaced this with three key positions that vary depending on how fast the board is moving. As the board moves quicker the player leans back more. I also added a couple of ‘spring’ frames so that when the board thrusts upwards the player ducks down slightly. The combo of these two things seems to work pretty well – though I’m not sure if the ‘leaning back’ position is too much ‘walk like an egyptian’! Any more animation just looked too ‘wobbly’ (that’s the trouble with having an 18*18 sprite, it’s very hard to do subtle movements).

Next up was the controls themselves. I was quite keen on this being a ‘two button’ only game but using the same button for thrust and reverse (long press for reverse) just wasn’t working. It was too easy to reverse by accident and too natural to expect holding ‘thrust’ to keep thrusting. So I’m moving to a three button system where the button left will be ‘reverse’, bottom right ‘thrust’ and top ‘fire’. This is pretty easy to play on the iPad but I’m a bit worried fat fingers will get in the way of the gameplay on smaller phones (such as the older iPhones which seem tiny now)!

A knock-on effect of this is that thrust now works based on a continual applied force than a single impulse so I had to tweak the various parameters involved until this felt right. I’ve ended up with less thrust being applied as you reach terminal velocity so there’s a kind of curve going on. I’ve no idea whether this follows the laws of physics but it certainly feels nicer form a gameplay perspective.

Last but definitely not least in terms of time was getting the ‘jump’ action correct. A core feature of the game is that your jetboard becomes a weapon when you’re not riding it so this has to look and feel right.

Getting the basic movement was pretty easy – pressing fire causes an impulse which make the jetboard fly dead straight for a certain distance (so it’s easier to aim). Getting the player to jump and return to the board was also very straightforward (there’s a bunch of scenarios you have to think about but none of them present and major issues).

What wasn’t so simple was getting the ‘jump’ animation for the player to work. As the jump movement is done in code it’s very hard to preview this in Photoshop so I felt I was kind of working blindly. My first effort (which took ages) wasn’t too awful but felt more like a weird mid-air run than a jump. In the end I had to make the animation sequence fairly complex – we start with a kind of ‘run’ movement which is played again in part as the player reaches the zenith of the jump, the anim then transitions to a ‘descent’ position which is held until the player lands back on the board. When he lands a short ‘spring’ animation is played.

I’m pleased with the way this works now though I’m sure it could still be better and will gladly take any comments! I messed around with the frame timings a lot. Will probably come back to it but it’s time to move on.

Next up – probably adding some really simple enemies to test targeting and a simple lose life/new life loop.

Dev Time: 1.5 days
Total Dev Time: approx 6 days

previous|next

mockup_3x
Board Like An Egyptian?

mockup_3x
Riding The Board Sprite Sheet

mockup_3x
Jump Anim – First Attempt (Ministry Of Silly Walks)?

mockup_3x
Jump To It!

Jetboard Joust DevLog #2 – Player Movement and Gameplay

Been working on the initial player movement for ‘Jetboard Joust‘ (my ‘Skateboard Joust‘ sequel) this week which, of course, also entails thinking about how the gameplay is going to work.

And the more I think about it the more I’m convinced that there’s enough ‘endless runners/jumpers/droppers/flappers/flyers/hoppers’ etc out there and I should really do something different.

So I fancy making the gameplay similar to, possibly the greatest arcade game of all time, Williams ‘Defender‘. A scrolling world that loops back on itself with a set number of enemies to destroy per level. It’s a format that doesn’t get much love nowadays but I have such strong memories of being huddled in awe around a ‘Defender‘ cabinet after going swimming on a Saturday as a kid that I think I should pay some kind of tribute to it.

Maybe the reason the format doesn’t see much action on mobile is that it requires a much greater degree of control than an ‘endless runner’. ‘Defender‘ had what seemed like a bewildering set of controls for an arcade game in it’s day. Of course, we’re all used to multi-button controllers nowadays but, as I wrote in a previous post, an iPad is most definitely NOT a gamepad so there’s no way I’m going to go down the fundamentally flawed ‘onscreen gamepad’ route.

For the mobile version I want to keep the controls as simple as possible and control everything via tapping either on the left or right of the screen. After running a few tests I think I can get this to work – tap on one side to thrust, tap and hold to reverse direction. Tap on the other side to fire (hold to repeat fire for weapons that support it).

This method means you’re almost always moving at a constant velocity left/right (unless turning) but in initial tests it seems to work OK and feel pretty intuitive. Much of the work is in getting the ‘bounce’ of the thrust action to feel right – more on that later…

Oh yeah – check out the parallax scrolling too! And I know the main character anims not working!

Dev Time: 2 days (including project setup)
Total Dev Time: approx 4.5 days

previous|next

mockup_3x
Don’t Remember Her At The Swimming Baths

mockup_3x
First Stab At Player Movement And Parallax


I Could Never Last More Than About Two Minutes

Jetboard Joust Devlog #1 – Overall Art Style

Looking back at my (frankly rather awful) ZX Spectrum title ‘Skateboard Joust‘ reminded me that there was always something pretty decent in the core gameplay concept of using your flying skateboard as a weapon when mid-jump.

As I need something else to work on whilst development on ‘Attack of Giant Jumping Man‘ slows down (hopefully temporarily) I thought about revisiting ‘Skateboard Joust‘ – almost as a penance for my sins in bringing such a dreadful game into the world into the first place! Maybe I can make a half-decent sequel and bring my gaming karma into alignment somehow?

I think I could get this mechanic to work as a simple two-button ‘endless scroller’ which might be nice for mobile and possibly even PC so I’ve been working on some visuals for the game with a view to making a prototype at least.

I’ve been going for a retro look in keeping with the game’s heritage, but rather than going for a full-on Spectrum emulation I’ve decided to keep to simple, restricted Gameboy-ish colour palette which I may change as the game progresses. The result is somewhere between Gameboy and Spectrum.

Game art is not my strongest suit and always takes me ages. I’d much rather be working with @PVBroadz but it this instance I need something I can crank out on my own. Pretty pleased with the result so far though – feel free to tell me what you think.

Dev Time: 2.5 days.

next


mockup_3x

Have I Got Any Better At Pixel Art In The Last 30 yrs?


mockup_3x

Test Animation For The Main Character


mockup_3x

Retro Revenge – Click For A Closer Look