Category Archives: Development

Jetboard Joust Devlog #26 – Pistols At Dawn

April 20, 2016 – 5:25 pm

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:

Automatic
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

mockup_3x
Improved AI To Circumnavigate Player More Effectively

mockup_3x
Shock And Awe? The Final Bullet Anim


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

mockup_3x
Pistols At Dawn – Proof That Violence Solves Nothing
By bitbull-uk | Also posted in Art, Game Design, Jetboard Joust | Comments (0)

Jetboard Joust Devlog #24 – It’s All About Class

April 7, 2016 – 2:40 pm

I want to have enemies on jetboards.

I didn’t really think about this at first – I thought that the enemies would be your usual SHMUP fare, different types of robots/spaceships and the like. But as the game’s called ‘Jetboard Joust’ it makes more sense to have at least some of the enemies riding jetboards like the player.

I’d also been thinking about the rpg-lite elements to the game. There’s going to be different ways to arm your jetboard and a weapon upgrade system – if I treated the enemies and jetboards differently I’d end up with far more combinations of opponent which would make things much more interesting. I guess its been Dark Souls (again) making me mull over this – the way the same basic enemy can present a very different challenge depending what weapon they’re armed with and what armour they’re wearing.

So I’ve been pulling apart my class structure to get something that’s much more flexible. First step was to create a generic ‘Board’ and ‘Rider’ class that represent, at the most basic level, a board and something that rides it. I then created the (somewhat randomly named) Surfer class which defines a Rider that animates in a similar way to the main player character (based on a 3×3 grid as described here). I split out a separate Jetboard class which extends Board – this contains the code for the ‘jetboard as weapon’ functionality which will probably only be available to the main character (as I think having enemies jumping off their jetboards will become too visually complex and confusing). There’s also a separate Weapon class which represents the base level weapon attachment for a board.

The fly in the ointment was with the enemy classes. There’s a bunch of generic ‘enemy’ code that deals with things like player collisions and collisions with projectiles. I couldn’t find a way to share this between enemies that were subclasses of Surfer and those that weren’t (ie won’t be riding jetboards) so I’ve had to (annoyingly) duplicate some of this in the EnemySurfer and GenericEnemy classes. There’s an IEnemy interface that allows both of these to be treated generically by various methods. Not having multiple inheritance is both a blessing and a curse sometimes.

Oh yeah, the base level Character class defines something that has health and can collide with the player and/or projectiles.

This all took some time – I hate retrofitting class hierarchies – but I took it slowly and carefully and once I was all done everything (amazingly) worked fine apart from one minor bug which was fairly easily quashed.

I’ve also designed my first jetboarding enemy – calling him ‘Skullhead’ for now.

Next step will be to add some basic enemy AI and get weapon attachments working.

Dev Time: 1.5 days
Total Dev Time: approx 26 days

previous | next

mockup_3x
The New Class Hierarchy

mockup_3x
Very Basic Jetboarding Enemy In Action
By bitbull-uk | Also posted in Jetboard Joust | Comments (0)

Jetboard Joust Devlog #19 -When ‘Correct’ Just Ain’t Right

March 22, 2016 – 12:48 pm

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 the first image, 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

previous

mockup_3x
Physically ‘Correct’ – Looks Like A Bug

mockup_3x
Physically ‘Incorrect’ – Looks Much Better
By bitbull-uk | Also posted in Jetboard Joust | Comments (0)

Jetboard Joust Devlog #18 -Enter The Warp Gate

March 17, 2016 – 12:29 pm

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
Total Dev Time: approx 20.5 days

previous | next

mockup_3x
The Final Warp Gate Design With Particles

mockup_3x
The Level Exit/Enter Dissolve Effect

mockup_3x
Entering The Warp Gate And Leaving The Level
By bitbull-uk | Also posted in Art, Jetboard Joust, MonoGame | Comments (0)

Jetboard Joust Devlog #17 – Beam Me Up, Dotty

March 4, 2016 – 9:03 am

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

previous|next

mockup_3x
Attempt #1

mockup_3x
Attempt #2

mockup_3x
Attempt #3

mockup_3x
Attempt #4 – Almost Done(!)
By bitbull-uk | Also posted in Art, Jetboard Joust, MonoGame | Comments (0)

Jetboard Joust Devlog #13 – Riding The Ruins

February 25, 2016 – 10:20 am

Mainly been pushing pixels over the last day or so. In my last post I mentioned that I wasn’t at all happy with the ‘boulder’ tile I’d been using for the foreground section of the landscape. In Jetboard Joust (unlike Defender) you interact with the terrain, and as my physics model is probably only going to allow for simple rectangle-based collisions this necessitates that the terrain is made up from a simple rectangle-based modular tileset. Rather than go for a ‘natural’ feel to the landscape I thought I let the restrictions dictate the visuals to an extent and try a kind of ruined, ominous ‘space city’. A bit like a sci-fi version of an old aztec temple or something.

I looked at a bunch of stuff for reference, the kind of thing that seemed to fit the best was an approach vaguely along the lines of ‘Fez‘, ‘Hyper Light Drifter‘, and some of the Capybara games such as ‘Superbrothers Sword & Sorcery‘. I was also thinking a lot about Dr.Seuss landscapes, particularly the Rinker Rink Fink which always struck me as being really weird and slightly spooky. Difficult to get that across in a rectangular tileset though – I’ll come back to that later.

First thing I did was design some solid ‘block’ tiles. When I was happy with these I tried a few different approaches to shading to add some depth. Couldn’t decide on which approach to go for so I asked for some input on Twitter. Most people preferred the approach on the left (the simplest) whereas i was drawn more to the one on the right (the most complex). In the end I went for the one in the middle which seemed to be a good compromise between depth and clarity. I did try the leftmost approach in-game but it just felt too ‘flat’ to me.

Next I designed a bunch more tiles, including some more open ‘connector’ tiles, and set about writing an algorithm to construct the buildings randomly. What was key here was to make sure that too many ‘solid’ tiles weren’t stacked up on one another without a connector as this looked odd. Then an algorithm to distribute the buildings was needed. What I found worked best was if the buildings were placed together in small ‘clumps’ with a slightly larger gap every three or four buildings or so – also if there were never two buildings of the same size next to each other.

Lastly I added some ‘chips’ to the tileset which are placed semi-randomly over the buildings so that they look a little battle-worn. These ‘chips’ may still need a bit of work but I think the feel is there.

I still need to add more tiles, especially some more ‘open’ ones with windows and arches or something, but I’m pleased with the end result. It has a certain atmosphere that I think works. Now I am unsure whether I need to change the main character and the ground tile to be more in-keeping. It’s a never-ending merry-go-round!

Dev Time: 1 days (including project setup)
Total Dev Time: approx 16.5 days

previous | next

mockup_3x
The Awesome Rinker-Rink-Fink

mockup_3x
First Draft – Three Different Approaches To Shading

mockup_3x
Modular Building Blocks Done


Flying Over The Ruined City
By bitbull-uk | Also posted in Art, Jetboard Joust | Comments (0)

Jetboard Joust Devlog #12 – All Terrain Vehicle

February 23, 2016 – 10:06 am

First things first – fixed the scanner wobble! I’m now rendering the scanner to an offscreen image (RenderTarget2D) before drawing to screen which means I don’t have to worry about any rounding errors due to the scaling of sprite locations.

Later I’m going to look at applying some custom shaders to this for a bit of ‘interference noise’ and to send the scanner a little haywire when you bump into things.

This’ll do for now though – the raster effect I’ve applied looks OK but unfortunately doesn’t really come across in the GIF which had to be compressed quite a bit to get within the 5mb limit for Twitter.

Next job was to add some terrain to the ‘Jetboard Joust’ world. This was pretty easy on the whole, only difficulty is that you end up with a lot of objects to check against for collisions – particularly when enemies need to interact with the terrain as well (which some of them will do).

To solve this I’ve opted for what I think is a fairly standard gamedev solution. The world is split into a bunch of ‘segments’, each of which contains two smaller segments (a bit like Russian dolls). I stop subdividing when we get to around screen size. The smallest segments contain pointers to the terrain elements that intersect them.

Now when collision checking I only need to iterate through terrain elements in the segment which intersect the sprite I am checking against, this makes collision checking pretty efficient as I can effectively discard half the elements in the world with one Rectangle.Intersects check.

You’ll see I’ve added the terrain to the scanner too – I like the ‘blocky’ way this looks, it reminds me of ‘Defender’ on the Atari VCS 2600.

I’m not at all happy with the tiles for the terrain yet – they need completely redoing so look at these as placeholder graphics. I’m thinking of attempting a kind of ‘strange ruined city’ type look.

If you’re very observant you’ll notice I added a slight automatic ‘boost’ when the player rides into the side of as terrain element. A proportion of the horizontal velocity is transferred to vertical velocity here which I think makes the game feel a lot more fluid.

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

previous | next

mockup_3x
All Terrain Jetboard

mockup_3x
Full Screen Shot – Click For A Close Look

mockup_3x
Ultra Old-School – Defender On The Atari 2600
By bitbull-uk | Also posted in Jetboard Joust | Comments (0)

Jetboard Joust Devlog #11 – Scanner Wobble

February 22, 2016 – 9:05 am

Just added a ‘Defender’ style scanner to show the location of enemies within the world. Not a lot to report here as this was one of those jobs where I knew what I had to do and just had to crank it out. Certain amount of experimentation with the ‘rasterization’ type effect which I think does the job but is unlikely to win me any awards.

One thing that’s bugging me is the fact the the enemy locations ‘wobble’ a bit as you can see from the GIF. I’ve run up against this type of thing before, it’s some kind of rounding issue which needs to be fixed. Thinking about it I might be better off rendering the whole scanner to an offscreen image each frame and then drawing that to screen at the appropriate offset. This would also allow me to draw with a custom shader and probably generate a cooler raster/tv type effect.

Dev Time: 0.5 days (including project setup)
Total Dev Time: approx 14.5 days

previous | next

mockup_3x
The (Currently Slightly Wobbly) Scanner In Action
By bitbull-uk | Also posted in Art, Jetboard Joust | Comments (0)

Jetboard Joust Devlog #10 – Custom Shaders & Health

February 19, 2016 – 11:51 am

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
By bitbull-uk | Also posted in Art, Jetboard Joust | Comments (0)

Jetboard Joust Devlog #8 – Thrust!

February 9, 2016 – 10:49 am
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
By bitbull-uk | Also posted in Art, Jetboard Joust | Comments (0)