next »

[bitbulldotcom]

Despite spending five years of my life at art college I don’t really consider myself an artist, or even a designer particularly. Yes I used to draw tons as a kid (and still do a bit now) and I like to make shit up – especially weird monsters and stuff, but I have enough of an eye for it to know that there are plenty of people out there much better at it than me.

So normally I prefer to work with other artists, but as I can’t really afford to pay anyone for this job and I’m already deep into a revenue-sharing venture with @PVBroadz as Joystick Junkyard this one needs to be all me. And getting back into the art after, pretty much, fifteen years off has been (and continues to be) a pretty steep learning curve.

This is why I can spend around two hours designing a stupid ground tile.

I’m pretty pleased with the way the ‘ruined city’ has been progressing but now it’s almost done I didn’t think the original ground tile worked so I set about designing a new one thinking this would be a simple job. It took an awfully long time going down blind alleys before I arrived at design #1 on the right, which was the first thing I was vaguely happy with.



The thing that enabled me to get there was thinking about Kirby dots. Jack Kirby was the genius artist behind all the classic Marvel comics and one of his signature techniques was his depiction of cosmic energy and explosions, ‘Kirby Dots’ or the ‘Kirby Crackle’. Basically he’d draw ‘in reverse’, filling in negative space with a repeated pattern to leave the outline of the shapes that would normally be drawn first in the space left behind. On the edges you were left with an area where the line between positive and negative space, or foreground and background, became blurred.



I was attempting to do this in a simplified way with my background tiles. Not to create an explosive effect but to blur the line between which shapes were ‘in front’ and which were ‘behind’ – and I think it kind of worked.

The problem with this design was that it looked great whilst I was working on it really blown up in Photoshop but when I looked at it in a game context is seemed kind of ‘fiddly’ to me, like there was too much detail in there or something.



I tried a few of things to fix this but none of them worked so as I last resort I thought I’d try simply blowing the whole thing up 200% – design #2. Strangely, whilst all the pixel art gurus tell you you should never combine two different pixel resolutions in one scene, I thought this looked much better.



So I edited the ‘blown up’ version to give it a bit more depth and added a touch more detail to make it seem more consistent with the overall pixel resolution – design #3. At the moment I like this. I hope still do after the weekend.



Don’t ever let anyone tell you that art isn’t just as hard as writing code.

Dev Time: 0.25 days
Total Dev Time: approx 16.75 days

[bitbulldotcom]

OK, so this isn't a blog post so much as a question for anyone who's watching.

As I'm gradually whittling down the art style I'm starting to find the main character a little out of place and am seriously thinking of replacing him with the (much simpler) little dude on the left here. What do y'all think? Any input appreciated - seems to have got a general thumbs up on Twitter...

[alvarop]

I feel like the new version is going towards the right direction and fits the style more. I'm really digging the tiles and style that you're going for. I still think it needs some type of tweaking, but the style overall feels unique enough, while also borrowing from some of that classic "videogame ruin" trope that a lot of games have going on lately (Titan Souls? Journey?)

The only thing I'm not so sure about is the skateboard itself.

If you still want to keep some type of continuity with the prequel, I guess you can allow the player to unlock the classic skin ?

Anyway, just my opinion.

[bitbulldotcom]

Great - thanks for the input. I hadn't had a go at re-designing the actual jetboard yet but I will do. I think I'm going to have a bunch of different jetboards that act as different weapon types.

[agersant]

New character sprite looks much nicer to me. More expressive and fits the mood better!

[bitbulldotcom]

New character sprite looks much nicer to me. More expressive and fits the mood better!

Excellent - thanks very much for the input. It's looking like I'm going to go with it...

[jctwood]

So is the protagonist in this also a giant, judging by the 'windows' and 'arches' in the new tiles? Really loving the artwork so far.

[bitbulldotcom]

So is the protagonist in this also a giant, judging by the 'windows' and 'arches' in the new tiles? Really loving the artwork so far.

Thanks!

Yeah, the perceived size is another reason why I prefer the simpler dude. Even though it's only a couple of pixels shorter he kind of looks a lot smaller and more in proportion to the background gfx.

[bitbulldotcom]

OK, thanks guys (and Twitter). Looks like the little guy's won the shootout - now I have some animations to redo!

[bitbulldotcom]

Major decision since the last update – I’ve decided to completely redo my main character!

If you’ve been following here or on Twitter you probably already know this (and might have even helped me out with the decision) but as the visual style of the game has progressed I’ve become increasingly unhappy with what was the main character. Even though I liked the design and animations in their own right they didn’t seem to fit with the way the game was developing – so it was time to go back to the drawing board.

I wanted to go for something smaller and more obviously ‘pixelly’. Ironically (given it took me about two and a half hours to design a floor tile last week) I managed to come up with something I was happy with in about three minutes(!) Feedback from Twitter and TIGSource was good so I went ahead and took the plunge. He he is doing a simple vertical thrust...



And picking up a bit of speed...



Redoing the animations took longer but wasn’t too painful. What I did notice when I tried the new design in-game was that everything looked kind of too small so I’ve bumped up the pixel scaling a notch. I think it looks much better like this. I never particularly liked the 'fall' anim before, this one is much better



Working with a smaller character and fewer pixels means that even a one pixel shift in an animation looks more extreme, consequently some of the animations are now much simpler. The jump animation in particular hardly animates at all – whatever I tried looked too much...

Lastly, as you’ll see from the images, I tried a new jetboard as the old one was always kind of a placeholder. Whilst I quite liked this it looked weird when the change was made to the rocket jetboard for the ‘weaponised boost’. As a consequence I think I’m going to leave the jetboard in rocket form all the time and change it when you pick up different weapons...



Dev Time: 0.75 days (including project setup)
Total Dev Time: approx 17.5 days

[bitbulldotcom]

More going over old ground as the game starts to develop it’s own visual style. It’s annoying but necessary – one has to take an organic approach to these types of things I think. Really I should stick with placeholder art and work on the design almost completely separately from the gameplay (as if I was working with another artist) but I find it very hard to do that. Consequently I’ve wasted at least two or three days so far which is kind of frustrating. Hey ho!

Anyway, the latest thing to be redone is the new life/appear animation. I did have the main character being shot from a Mario-style pipe as you’ll see here but that didn’t really seem in character any more. I wanted something more spacey and in keeping with the feel of Defender which is my main inspiration for Jetboard Joust.

So I started work on a ‘teleport’ effect. I knew I wanted the main character to dissolve into a kind of pixelated fog and the most appropriate way to achieve this seemed to be through a custom shader – down the HLSL rabbit hole again.

I started by creating a shader that reduced the pixel resolution of the drawn texture. I split the texture into a series of chunks and took a sample from the centre of each chunk which was returned as the colour to draw. Having no HLSL experience it took a while just to get to this stage. I have all my animations on sprite sheets so each sprite drawn is generally a small portion of a much larger texture, HLSL works with coordinates relative to the full texture (regardless of the region being drawn) so initially the results I was getting were pretty random (when they weren’t completely blank) but when I figured out to pass the coordinates of the cropped region to the shader and do my calculations based on that instead things started to progress pretty quickly.



Initial results were promising (though somewhat static) and the effect looked like something I could progress with. I added some motion by sampling from a random point in each chunk rather than the center (I do this every other frame) and a kind of ‘spark’ effect by inverting the colour balance every so often (currently every four frames). I also added the ability to sample from a smaller portion of the texture than that being drawn, effectively scaling up the sprite. Then I added the ability to set the alpha for the entire shader allowing it to fade out smoothly.



We were getting there now! This was all the functionality I really needed from the shader and the next stage was setting up some tweens in my main game code to control the various parameters. There’s quite a few tweens chained together in the final result, one controlling the sample size, one the scaling and one the transparency. I wanted it to look like tuning into a radio station sounds with big adjustments at the start (no reception) and small ones at the end (finding the point of best reception).



Once I was happy with that I added some more particles, trying to keep things fairly stylised looking. A small change to the particle generator was required to allow for imploding particles. There’s also a pixel particle generator which blurs the edges of the actual texture (this looked a bit too obviously square at low sample sizes).



And now I think almost done. Only thing that’s really bugging me is the very dark pixels from the shader when they get large, these look a bit too glitchy (not in a good way). May have to knock these back a bit or something. And there’s something about the small explosion/implosion particles not quite sitting right with the larger pixels – I might need to make these particle fx more ‘pixelly’ somehow…

One HLSL thing that had me stumped for a while was that, whilst I was tweaking and commenting out bits of code, the C# code that set an effect parameter in the shader suddenly started throwing a null pointer exception indicating that that parameter was no longer present in the shader. WTF? Turns out that, though I hadn’t removed the parameter declaration in the shader, I’d removed all references to it in the actual code so the compiler was optimising it out (doh)!

It may also interest you to know that I did all this thinking ‘Defender’ had a similar ‘implosion’ effect when the player’s ship appears – but it turns out it doesn’t at all – neither does the sequel ‘Stargate’! Damn childhood memories deceiving me.

Dev Time: 0.75 days (including project setup)
Total Dev Time: approx 18.5 days

[bitbulldotcom]

Wasn’t working much on Jetboard Joust last week – had to do an ad-free update of Flapping Bird for a distributor (yes, I did a ‘Flappy Bird’ clone – the shame)!

Anyway – back onto it this week and I’ve been doing more custom shader stuff, this time for the ‘level complete/next level’ cycle. I wasn’t looking forward to this to be honest as I thought it would be a really fiddly process but actually it went OK.

What’s going to happen when the level is complete is that a kind of ‘warp gate’ appears – enter the warp gate and you get transported to the next level. I wanted the level to disintegrate into pixels in much the same way the main character does when teleported in/out (see previous post).

The first thing though was to actually design the warp gate itself. I wanted something that felt a little ‘sci-fi’ and also a little ‘primitive’ to fit in with the ruins. I looked at various things for inspiration, not least the ‘hub portals‘ from ‘Turok – Dinosaur Hunter’ on the N64 (remember that game, it was ace!) which hold very fond memories for me. This page of concept art from Destiny was also a big influence.

I wasn’t too tough to arrive at a design I liked – and animating it (though very time consuming) was also pretty trouble free. I then spent quite a bit of time tweaking some particle fx to go with it – trying to keep a ‘pixelly’ feel. I’m really pleased with the end result now.



Implementing the ‘pixel dissolve’ for the entire level meant using a custom shader for ‘post-render’ fx. This was another first for me but fortunately pretty simple to implement. Rather than drawing the game world to screen I draw it to an offscreen image (RenderTarget2D in MonoGame) and then apply the shader when rendering this offscreen image to screen. As if often the case with this stuff, the hardest part is tweaking the tweens so that the dissolve feels ‘right’. I think it’s OK now but there’s still something bugging me about the ‘fade in’ a bit. I used the same shader I wrote for the teleport fx as described in the previous post.



Then it’s a matter of sequencing everything together which I have now done, though this procedure is too long to get across in an animated GIF…

1. Complete level
2. Warp gate appears (using teleport shader) –
3. Enter warp gate
4. Main character teleports out
5. Old level dissolves out
6. New level dissolves in
7. Main character teleports in



If you’re being observant you’ll notice that I’ve made the particles on the player teleport rather more ‘pixelly’. I’ve also updated the die/retry loop from the pipes of old to a new version using the teleport effect.

Next up will be some work on pickups and changing jetboards.

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

[bitbulldotcom]

Usually when working on in-game physics and stuff the best place to start is with what would be ‘correct’ in the real world. I only have a physics ‘O’ level (and that was a very long time ago) but that’s generally enough to get me by in the world of 2D gaming.

Sometimes though, what would be ‘correct’ in the real world just looks ‘wrong’ in an in-game context – and here’s an example.

In this GIF, if you can see make it out, you’ll see that when the jetboard hits an obstacle the ‘blast’ sprites and particles carry on past the jetboard when it stops – this is because they are ‘correctly’ initialised with the same velocity as the jetboard. In practice though, this looks pretty stupid. I guess I could run collision detection on the blast sprites and particles and have them also collide into the obstacle (this would be ‘correct’) but that would be pretty impractical, particularly for the particles – I also think it would still look kind of weird.



So what I’ve done instead is make the blast sprites and particles always move relative to the jetboard, therefore their velocity slows down and speeds up as the jetboard does. Even though far from physically ‘correct’ this looks much better in a 2D gaming context.



Dev Time: 0.25 days
Total Dev Time: approx 20.75 days

[bitbulldotcom]

Working on health pickups today – that means more pixel-pushing! Fortunately the health pickup itself was pretty straightforward. I wanted a spinning ‘First Aid’ type icon inside a bubble – the hardest thing to get right here turned out to be getting the spinning icon to look like it was inside the bubble whilst remaining legible and also sticking to minimal palette.

My solution in the end was (in Photoshop) to duplicate the bubble layer and place on top of the icon. Set the new overlaid layer to ‘screen’, reduce opacity considerably, delete everything bar the highlights and then apply the icon layer as a mask. This has the effect of only applying light highlights to the icon itself. It’s a bit of a cheat as I’m creating colours not in my original palette but it works and looks pretty good. I may have to revise this a little if and when I come to apply different palettes to the game.

Whilst designing this I couldn’t help but wonder how many pixel-pushers before me had designed health pickup icons – there should be some kind of repository of them somewhere!

Integration into the game was pretty straightforward as well, time consuming as I needed to set up a new ‘pickup’ superclass to handle collisions with the environment and manage getting collected etc but nothing overly complex. Designing the ‘collection’ animation took a bit longer, mainly tweaking the bubble particles that appear but drawing and animating that concentric ring effect took some time as well. Again – not difficult, just time consuming. I’m pleased with the end result though.



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

[Pixel Noise]

Haven't checked in for a while - this is looking great! I'm a bit late - but like the scanner. Both for it's function and musical staff aesthetic!

[agersant]

I'm also late by a few updates, great to see so much progress. Good job on these sweet shader effects!

[bitbulldotcom]

Thanks guys - the comments are much appreciated!

[bitbulldotcom]

Designing a game HUD is one of those things that always feel a bit of a drag to me. It’s not very exciting, not really part of the gameplay, and when it comes to coding often requires a lot of tedious repetition. You know the sort of thing – when you know exactly what you need to do and how to do it it’s just that it’s going to take a lot of typing to get there.

On the plus side, often when the HUD is added your game starts to feel much more like a game rather than an elaborate demo of some kind. This is good!

I spent a fair bit of time messing around with alternate layouts for the Jetboard Joust HUD. I’m pretty sure what type of info I want in there – obviously score and lives but also your currently selected weapon and the amount of ammo for it. It was tough to get everything in there whilst still remaining visually balanced and leaving enough space for the scanner.

I liked the idea of pretty big digits for the score and wanted something that looked vaguely ‘sci-fi’ whilst still being readable. In the end I designed my own font for this (though it was heavily based on Space Odyssey). For the small text I used the excellent 04b24 which is (with the exception of the letter ‘i’) a monospaced bitmap font.





I think it looks pretty good. The one thing I’m not sure about is displaying the amount of lives on the right-hand side. I’d rather have kept this area just for weapon info but as I can’t really think what else I might put in there other than amount of ammo and currently selected weapon it was looking rather empty.

Couldn’t end this post without a shout out to two of my favourite game HUDs…

Firstly the scroll from Ultimate Play The Game’s wonderful ‘Atic Atac’. Ultimate were pretty much experts in the art of taking up most of the screen with an elaborate HUD so that they could push the refresh speed in the little amount of screen real estate that remained for the actual game – ‘Gunfright’ being a great example. The ‘Atic Atac’ HUD though, with its roast chicken that gradually gets picked to the bones as your health depletes and its completely pointless ‘scroll’ legend remains an absolute classic.



And secondly the HUD from ‘Dead Space’ which, rather than take you to a separate screen, is actually projected into the game environment from your super-advanced tech helmet (or whatever it was called). This was a great way of presenting complex information to the player without disconnecting them from the game experience. Shame the game experience itself was so clunky though – I still shudder at the thought of that dreadful ‘Asteroids’ style minigame…



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

[bitbulldotcom]

Don’t you just hate it when something that you thought would take a couple of hours takes pretty much all day – and then you’re still not entirely happy with it?

Witness the spinning crate. A bit of a repeat of the floor tile episode this one – and another indicator of just how inexperienced I am with pixel art.

I needed something for a ‘weapon swap’ pickup. As it’s a swap (ie your original weapon gets left behind and a new one picked up) I needed a kind of ‘permanent’ storage system rather than something that gets destroyed on pickup like the bubble I’m using for extra health.

A crate seemed the obvious choice. Far from original I know, but it seemed as though it worked work and there’s something quite iconic about the pickup crate. I thought the crate could spin when you activated it and the crate icon change to show the weapon you’d just deposited.

Designing the crate itself was pretty easy...



...getting it to spin wasn’t. Firstly I made the schoolboy error of drawing every frame of the animation before prototyping it. Each frame looked great on its own but when I tested the animation I was gutted to discover I’d failed miserably. The crate didn’t really look like it was spinning – it looked like the pages of a book turning or something. Everything I’d done ‘should’ have worked (to my mind) and I was somewhat stuck to figure out what I’d done wrong.

So I did what I should have done in the first place if I’d have had half a brain – I went back to the drawing board and sketched out some simple prototypes. This (and studying a few classic ‘spinning cube’ demos) enabled me to see where the problem was. My art style is fully 2D which means that, really, there should be no perspective. However it turns out that without perspective it’s very difficult to judge what is ‘3D’ and what’s not (hence the ‘page turn’ effect). I tried adding some shading and this helped but the only way I could get the crate to look like a cube was to add some simple perspective. I think, really, this shouldn’t fit with the art style but it does seem to kind of work to me. I could only add perspective to the top of the crate though, otherwise it didn’t sit right on the ground!

Another issue which compounds the difficulty is trying to work with a strict eight colour palette (this makes gradually altering the brightness of things very difficult) and working in a ‘blown up’ pixel style. In most instances every pixel I use will be represented by at least three pixels on screen so a one pixel shift in the artwork actually represents quite a visual ‘jump’. In the (for now) final animation I only use a one pixel shift for the perspective and it almost seems too much...

 



In the animated GIF below you can see some rough prototypes followed by the ‘final’ animation as it stands at the moment...



1. The first approach – looks like a ‘page turn’
2. Adding shading – slightly better but still looks like a page turn.
3. Adding perspective – starting to look like a cube now.

Anyway – what doesn’t kill you makes you stronger and all that. The moral of today’s story kids is simple prototypes first!

Maybe I should have titled this post ‘Spinning Crate Gate’.

Dev Time: 0.75 days
Total Dev Time: approx 23.5 days

[bitbulldotcom]

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



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