Author Archives: bitbull-uk

I have been programming games since I was about ten years old. I had my first titles, Subterranean Nightmare and (the frankly pretty terrible) Skateboard Joust, published on the ZX Spectrum when I was 15.
For the past 15 years I have been making a living developing games for mobile (feature) phones via my companies BitBull and Maturus Mobile. My games are served on all the major International operator portals, have regularly featured in the ELSPA charts and have won several Pocket-Gamer awards. In 2013 my original puzzle game ‘Puzzled Zombies’ was nominated for Pocket Gamer’s ‘Game Of The Year’ alongside entries from big players such as Namco and Electronic Arts.

Being an independent games developer is not easy. I’ve been doing this a long time yet am still tearing my hair out and learning new things pretty much every day. I still know nothing.

Get in touch via the BitBull website at http://www.bitbull.com.

Jetboard Joust Devlog #21 – HUD’s Up!

March 24, 2016 – 1:15 pm

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

previous | next

mockup_3x
HUD Elements In Close Up

mockup_3x
HUD in game (click for a closer look)

mockup_3x
Getting A Roasting In Atic Atac

mockup_3x
Gunfright – More HUD, Less Game

mockup_3x
Dead Space – Nice HUD, Shame About The Gameplay
Posted in Art, Game Design, Jetboard Joust | Comments (0)

Jetboard Joust Devlog #20 – Got Health

March 22, 2016 – 7:49 pm

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

previous | next

mockup_3x
Got Health – No Jogging Required
Posted in Art, 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
Posted in Development, 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
Posted in Art, Development, 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(!)
Posted in Art, Jetboard Joust, MonoGame | Comments (0)

Jetboard Joust Devlog #16 – Back to the Drawing Board

March 1, 2016 – 5:50 pm

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

If you’ve been following on TIGSource or 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.

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.

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

previous | next

mockup_3x
The New Guy – Simple Vertical Thrust

mockup_3x
Now He’s Picking Up A Bit Of Speed

mockup_3x
Riding The Rocket Board And Weaponised Boost

mockup_3x
Falling Off
Posted in Art, Jetboard Joust | Comments (0)

Jetboard Joust Devlog #14 – Negative Space

February 26, 2016 – 9:23 am

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
Posted in Art, Jetboard Joust | 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
Posted in Art, Development, Jetboard Joust | Comments (0)

Implementing A Custom C# Generic Type Enumerator

February 23, 2016 – 12:00 pm
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()
		{
		}
	}
}
Posted in Uncategorized | 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
Posted in Development, Jetboard Joust | Comments (0)