The BitBull Blog

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

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

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