Monthly Archives: February 2016

Jetboard Joust Devlog #14 – Negative Space

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 (including project setup)
Total Dev Time: approx 16.75 days

previous | next

mockup_3x
Kirby Dots or the Kirby Crackle – Genius

mockup_3x
Design #1 – Too Fiddly

mockup_3x
Design #1 Blown Up – Negative Space

mockup_3x
Design #2 – The Laws Of Pixel Art Say This Shouldn’t Work

mockup_3x
Design #3 – Here’s Hoping I Don’t Start To Hate It Later
Advertisements

Jetboard Joust Devlog #13 – Riding The Ruins

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

Implementing A Custom C# Generic Type Enumerator

I’ve just run up against something in ‘Jetboard Joust’ whereby I needed to implement a custom generically-typed enumerator that I could enumerate through using the foreach statement along the lines of…

FooBar enumerator;
foreach( Foo foo in enumerator )
{
	// do some stuff
}

Unfortunately I found Microsoft’s documentation on this to be vague to the point of being misleading, and most of the StackOverflow answers weren’t much use either.

So here’s a simple example that defines a custom generic-type enumerator (implementing the IEnumerable and IEnumerator interfaces) that can be iterated through using the foreach statement. I’ve commented on the things that I found slightly odd – the main one being the fact that MoveNext() is called before the first object has been retrieved.

I’m using Xamarin and possibly Mono operates slightly differently than ‘native’ .net but it shouldn’t do.

Hope this helps someone…

using System.Collections.Generic;
using System.Collections;

namespace com.bitbull
{
	public class FooEnumerator:IEnumerable,IEnumerator
	{
		#region properties
		private Foo[] foo=new Foo[24];
		private int count;
		#endregion

		public FooEnumerator()
		{
		}

		/*
		 * Called at the start of each foreach statement and it
		 * would appear this is the best place to initialize your 
		 * counter. Note that, unintuitively, I start on -1 rather
		 * than zero as MoveNext is called before the first object in
		 * the enumeration is retrieved
		 */
		public IEnumerator GetEnumerator()
		{
			count=-1;
			return this;
		}

		/*
		 * I'm not really sure why you need this here but 
		 * it won't compile without it
		 */
		IEnumerator IEnumerable.GetEnumerator()
		{
			return this.GetEnumerator();
		}

		/*
		 * Called each iteration of foreach BEFORE the current
		 * object is retrieved. Unintuitively this means that if
		 * you start your count on zero you will miss the first
		 * object in your enumeration.
		 * 
		 * Should return true or false depending on whether there
		 * are further objects available to iterate through
		 */
		public bool MoveNext()
		{
			if (count>=foo.Length)
			{
				return false;		
			}
			else
			{
				count++;
				return (count<foo.Length);
			}
		}

		/*
		 * I am not entirely sure when this gets called but you 
		 * need to implement it! It doesn't seem to get called at
		 * the start of each foreach statement which is what I 
		 * presumed would happen. I reset the counter here anyway
		 * as it seems the sensible thing to do but this method
		 * never seems to get called in my code.
		 */
		public void Reset()
		{
			count=-1;
		}

		/*
		 * Returns the current object in the enumeration
		 * called on each iteration of foreach
		 */
		public Foo Current
		{
			get { return foo[count]; }
		}

		/*
		 * I'm not really sure why you need this here but 
		 * it won't compile without it
		 */
		object IEnumerator.Current
		{
			get{ return this.Current; }
		}

		/*
		 * You need to implement this as well, again I'm not
		 * really sure why this is really necessary.
		 */
		public void Dispose()
		{
		}
	}

	public class Foo
	{
		public Foo()
		{
		}
	}
}

Jetboard Joust Devlog #12 – All Terrain Vehicle

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

Jetboard Joust Devlog #11 – Scanner Wobble

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

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 #7 – Control, Camera, Action!

This has been a bit of a tidying up session – sorting out a few things that had been niggling at me.

Firstly – the controls. The directional control work I’ve been doing on ‘Attack Of Giant Jumping Man’ made me rethink how I’m going to approach the control system somewhat. I thought I’d trying bolting on some of the experimental ‘touch controllers’ I did and see how they played as I’d really like to get a left, right, thrust and fire in there if possible.

The ‘elastic’ control system seemed to work pretty good so I’ve modified this a bit and this is what I think I’m going to go with. Basically it’s a two-handed control system with two buttons on the right for thrust and fire and a directional control on the left. On the directional control a drag left or right orientates the player and accelerates whilst held whereas a long touch with no movement simply accelerates in the direction the player is currently facing.

On the right the ‘collision’ area for the buttons takes up the entire right hand side of the screen divided as per the illustration. This makes it really easy to hit either button and the control system seems to work really well, at least for the moment.

Next up – camera. I misjudged what a pain in the arse this was going to be. previously in 2D scrolling games I’ve done very simple camera tracking whereby the screen simply scrolls at a fixed rate whenever the player leaves a certain area and enters a ‘buffer zone’ towards the edges of the screen. Occasionally I’d get a bit more fancy and scroll to position the player so they gain a longer ‘lookahead’ depending on what direction they were facing.

A fixed camera rate looked crap in this game because the movement was very fast and there were too many abrupt stops or changes in direction which became very jarring to look at. I’ve added a certain amount of acceleration and decceleration to the way the camera moves to make the motion smoother. What was hard was to get the motion smooth whilst keeping up with the pace at which the player will move and change direction. I think it’s pretty much there now but no doubt I will have to go back and rethink certain aspects yet again.

Lastly – collision detection. One scenario was bugging me whereby if you accelerated into the side of a floating block, then continued to accelerate whilst dropping, the board would fly off from beneath you when it dropped below the edge of the block. Whilst technically ‘correct’ this just felt too harsh in practice. Despite this, I still wanted the player to be knocked off if an attempt is made to fly beneath a floating block and the player clips the block but the board doesn’t.

These two scenarios are the same as far as the collision detection algorithms are concerned and it’s pretty hard to differentiate between them. What I’ve done as a compromise is only have the player knocked off in this scenario if the board is travelling at a certain velocity. So far this seems to do the trick!

Dev Time: 0.5 days
Total Dev Time: approx 10 days

previous | next

mockup_3x
Screen Division For Touchscreen Controls


Trying To Get A Smooth Tracking Camera


This No Longer Sends You Flying…


…Whereas This Still Does!

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