Category Archives: Game Design

Granny Bait – The Making Of “Skateboard Joust”

November 6, 2019 – 4:53 pm
Granny Bait: A term used back in the day to describe a game that had virtually no redeeming features but, because it had something ostensibly ‘youth’ in the title (and was cheap), would be bought in droves by clueless older folk as gifts for their disappointed grandchildren.

A while ago I wrote a post about ‘Subterranean Nightmare‘, my first commercial release for the ZX Spectrum. Whereas ‘Subterranean Nightmare‘ was something of a labour of love and represented a genuine attempt to create a decent game, my next title (I am somewhat ashamed to admit) was executed in a rather more mercenary manner. I can’t remember exactly what age I was when I started work on ‘Skateboard Joust’ but I was heading into my late teens. I was losing interest in videogames and starting to become far more interested in guitars, girls and beer. Guitars, girls and beer cost money though – and the best way I knew of to make a quick buck was to churn out another budget Spectrum title.

I never had the slightest interest in skateboarding but tying the game in with something that was relatively fashionable seemed like a good idea. I’d also never played ‘Joust‘, but I’d seen screenshots and knew it was made by the some people that made ‘Defender‘ (which I still rate as one of the finest videogames of all time) so it was bound to be pretty cool.

The central mechanic of the game involves destroying enemies with your skateboard which you can only do if you are mid-jump (not actually riding the board) and I still think this is a pretty sound gameplay concept. It’s not executed very well however and is extremely difficult to get the hang of (‘totally unplayable’ might be a better description). Then there’s the fact that, aside from a few pretty unimaginative powerups, this central mechanic is pretty much all there is to the game making it a fairly tedious experience.

The worst thing about the game though is that what appear to be the level backgrounds are actually in the foreground and serve no purpose other than to obstruct your view of a game that’s hard enough to play as it is. Making gameplay harder by simply obscuring what’s going on must surely be one of the most laughably bad game design ideas ever!

I remember borrowing chunks of code from my brother Tim (of I-Ball fame) who was always a much better coder than me, and recycling some of the graphics from ‘Subterranean Nightmare‘. I also added some of the most embarrassingly ‘wrong’ skate slang between the levels. Not my finest hour but I was paid a £2.5k advance by Silverbird which paid for a lot of beer.

The game was justifiably slated by Crash Magazine at the time, though in recent years some people have been rather kinder to it, notably the vg-junk blog. There’s also some drunk guy on YouTube who plays the game for around five minutes without realising that you can jump off your skateboard!

Bizarrely though the game had some devoted fans despite its awfulness – in the comments for this video there’s someone who seems to take great offence when people suggest that it might be a tad shit! I also ‘met’ the person who did the C64 version in this thread, turns out they got paid considerably more than I did for writing the original!

And no, I have no idea what I was thinking of when I designed those ‘extra’ life icons! They do look like some kind of demented frog!

World Of Spectrum entry here.

30 years later I’m now working on a sequel, ‘Jetboard Joust’, in order to balance out my karma for forcing such a terrible game onto the unsuspecting public. ‘Jetboard Joust’ builds on the central ‘Jetboard of Death’ mechanic and adds a whole lot more besides – you can wishlist it on Steam here and read about the development here.

30 years Later – The Sequel…
Read the instructions you fool!




The C64 Version (With At Least One Devoted Fan)!




cornflower

Recycled Graphics on Skateboards




cornflower

Yes, All That Shit Just Gets In The Way!




cornflower

Attack of The Roast Chickens





			

			
			
				

				

					By bitbull-uk
					|
					Also posted in Development, Gamedev Flavoured Waffle
					|
					Tagged , , 
					|
					Comments (1)
				

			



			

				
Jetboard Joust Devlog #91 – Global Navigation (You Are What UI)

				
October 31, 2018 – 8:55 am

				



Programming UIs is undoubtedly one of the most fiddly and tedious aspects of game development. They are frustrating to implement (it doesn’t really feel you’re working on part of the game), yet ironically they contribute a massive amount to game feel and overall user experience.


So it was with a certain amount of trepidation that I began work on the ‘necessary evil’ of implementing a map screen for Jetboard Joust so that users can view and plan their journey through the game. It’s been a good process though as it has forced me focus on some of the ‘macro’ aspects of gameplay which I have been thinking about a lot yet have never really nailed down until now.


Unlike most SHMUPs, progress through Jetboard Joust’s levels is non-linear to an extent. Levels are organised in a pyramid structure so that, on completion of one level, you have a choice of two levels to try next on the next ‘row’ (I’m calling them ‘sectors’) of the pyramid. This structure is taken directly from the ZX Spectrum game ‘The Pyramid‘ which had something of a cult following in the early 80s. It was never intentional but I’ve just realised that the player character in Jetboard Joust bears a certain resemblance to Ziggy from the ‘Pyramid’ games.


Originally I was going to have the entire game organised in one pyramid but, after a lot of thought, I decided that this wasn’t going to be practical as you would end up with a ridiculous amount of levels in each sector by the end of the game which would make finding levels that contained treasure etc overly frustrating.


Instead I am going to split the game into five ‘zones’, each of which has its own pyramid structure. Three (probably) of these zones will be directly accessible at the start of the game, the next two will need to be unlocked by gathering keys which are guarded by the game’s bosses. This is similar to the structure of the ZX Spectrum game ‘Sidewize‘ which I never played at the time (and only came across via Bitmap Books Spectrum Compendium) yet seems to have a lot of similarities to Jetboard Joust in the side-scrolling gameplay and crustacean-inspired aliens. 


As the entire game world is going to end up being pretty large I needed another way for the player to navigate it other than the warp gates which simply move the player down to the next sector of the current zone. To solve this I have introduced teleports which allow the player to transport themselves to any other level which has a teleport activated. Teleports are activated by completing a level with a 100% survival rate (ie no babies abducted and mutated).


Of course, as well as designing a map screen, this meant I also had to design a teleport! I’ve tried to keep this looking like it’s from the same factory as the warp gates so the designs are pretty consistent. In retrospect I think I could have made it bigger but I’m not going to change that at the moment – it got a pretty good response on Twitter as it stands. 


I’ve also added an additional cash bonus for completing a sector (an entire row of the pyramid). This gives another dimension to the gameplay and (hopefully) a reason for the player to visit more levels and stick at the game for longer. It meant I had to add a ‘sector clear’ section to the ‘Level Complete’ screen though!   


The map itself wasn’t overly complex to implement, though drawing the lines that link the levels on the fly was fairly fiddly and it was also pretty time-consuming getting a zoom in/zoom out effect that looked decent. I wasn’t intending to have the map rendered at two different sizes but once I’d got the main map up and running it was clear that you needed to see things at a more ‘macro’ level when navigating between zones. I change palette as the player moves from zone to zone as well (this brought up a number of bugs in the palette-swapping code and shaders that needed to be fixed). I thought it would be good to allow a certain amount of ‘lookahead’ in the map so levels that contain bosses and/or special items are highlighted if they are within three sectors of the furthest points reached by the player.


The map can be viewed at any time via a link in the main menu and is brought up automatically when the player enters a teleport in order that they can select the level they want to travel to. I’ve spent quite a bit of time trying to ensure it feels chunky, intuitive and consistent with the rest of the game. Hopefully it’s all been worth it! The observant amongst you will still spot a few bugs in the video…             


Dev Time: 8.5 days

Total Dev Time: approx 218 days


previous






mockup_3x

The Zoomed Out ‘Mini Map’ Gives An Overview of The Current Zone


mockup_3x

The Full Size Map


mockup_3x

Your Teleport Is Ready, Sir!












Clearing a Sector, Activating the Teleport, Selecting Next Level






		
	

				

				

					By bitbull-uk
					|
					Also posted in DevLogs, Jetboard Joust
					|
										Comments (0)
				

			



			

				
Jetboard Joust Devlog #83 – Somethin’ Fishy Goin’ On…

				
April 12, 2018 – 10:04 am

				



God, these big enemies are hard!


I thought six days on the last one was extreme but this one has taken me pretty much eight full days. Probably over 50% of that time spent on the art. Basically these have pretty much morphed into ‘miniboss’ type creatures with multiple attack patterns (and in this case even spawning smaller enemies) which was never my intention but I feel like I have to kind of go with the flow. I am really struggling with motivation now though, this project is dragging on and on and ON and to be spending so much time on one thing at this late stage is extremely demoralising. I need to be earn some sodding money. Enough of my moaning though… 


I decided to make this enemy a giant deep sea fish as deep sea creatures are weird, alien and creepy looking and have already been used for inspiration on some of the other enemies such as the squocket. My main source of inspiration was a fish called the fangtooth which seemed to have the right balance between looking weird and dangerous whilst maintaining an iconic fishy shape. I’m calling it the ‘snapper’.   


Creating the basic shape in pixelart wasn’t too difficult and I didn’t go down nearly as many dead-ends as I did with the stinger so the process, whilst just as time-consuming, wasn’t nearly as frustrating. Most of the time I always felt like I was making progress. The scales were the hardest part to get right – it’s large area to cover and it’s tough to get the balance right. Not enough detail and things look flat and boring, too much detail and things look too ‘photographic’ and don’t gel with the rest of the game’s style. When the scales were defined as a simple filled pattern they looked too ‘flat’, like I’d obviously filled a stencilled area. If I applied too much shading to them they almost looked too ‘3D’ and ‘realistic’. In the end I offset the scales based on a pattern of concentric circles to give a slightly rounder shape to the body, limited myself to three different scale tones and didn’t allow a change of tone within an individual scale. This took forever but it finally seemed to give me the right degree of detail whilst maintaining a sense of stylised simplicity.


I thought the teeth and gills would be hard to draw but actually those parts came together really quickly, as did the ‘skull’ for the zombie attack phase. The spikes on the spine were rather more finicky and still need a bit of tidying up.        


The other reason this took so long was that collision detection on an enemy of this size gets rather more complex. When I began work on the game I didn’t have ‘boss’ type enemies in mind so assumed I could implement a simple ‘one size fits all’ collision detection system. Unfortunately this doesn’t cut it when you have enemies that are complex shapes, some areas that act as ‘hot spots’ for damage, and other areas that you may want to collide with the player but not actually take damage themselves. I needed to find a way to allow for all this whilst avoiding having to go back and redo old code (particularly checking all the weapons again).


In the end I came up with a ‘CollisionProxy’ class. A CollisionProxy is spawned from a parent (the main sprite) and will both take and inflict damage on behalf of its parent (or not depending on the configuration). It also renders with a custom shader in sync with its parent when taking damage. Any sprite can have any number of proxies. So far this system seems to work well and I’ve hardly had to change any of my core code to implement it.


There’s also polygon-based collision detection on this enemy. Up until now I have been able to get away with simple rectangle-based collision detection. Thankfully I had already implemented SAT-based collision detection for convex polygons when I first ported my game engine to MonoGame so I had no extra work to do there – Thank God!! I think trying to add something like that at this stage would probably have killed me!     


In its final(?) incarnation the snapper has three attack phases…


Stage One

Tracks the player fairly slowly. Unleashes either an aggressive charge/snap attack or spawns electric jellyfish from its mouth. Its jaws do more damage than the rest of its body and it will only take damage if you fire directly into its mouth (this was a PITA to implement collision-wise).


Stage Two

Loses its flesh and becomes a steampunk zombie fish. In this mode tracking of the player is faster and it’s two mounted ‘shredder‘ weapons are armed and fully dangerous. You need to destroy the engine mounted on its side to proceed to the next phase.


Stage Three

Now on its last legs (if it had any) the snapper tracks the player very quickly. It’s only defence at this point is a very aggressive kamikaze charge attack.


And that, at last, is it. Painful, but I think it was probably worth it. I’ve had some of the best feedback for the game so far from some of these images on Twitter. There’s still a few things I’m not 100% happy with. Art-wise the final phase needs some more engineering where the engine used to be and I might try getting rid of the eyeball on the zombie skull and replacing with a more skull-like eye socket. The second phase is also a bit weird – at the moment the whole enemy can take damage but it recharges until the engine is destroyed (so there’s a separate health meter for the engine). This is confusing. I should probably have the main enemy not take damage at this point and only have a health meter for the engine.


The difficulty will need some tweaking but I’ll have to do that in the context of the game more. Generally, I must admit, I am not a big fan of boss fights as they are often done so badly. In my opinion a good boss fight should seem ridiculously tough at first but be relatively straightforward once you’ve worked out a strategy. You shouldn’t die before you’ve even had a chance to get a decent look at the boss and it shouldn’t be a schlep to get there on every retry either. Though I thoroughly enjoyed both Dark Souls and Demon Souls to the point of obsession I found the ‘rinse and repeat’ style run to the bosses immensely tedious. I gave up at the final boss on both games because of this – life was simply too short! The bosses in this game will be optional and protect hefty rewards/upgrades rather than blocking your progress in the game.


I also still need to add some larger explosions befitting an enemy of this size!!


Dev Time: 8 days

Total Dev Time: approx 179 days


previous | next






mockup_3x

Fours Days Of Pixel-Pushing In Fifteen Seconds


mockup_3x

Fun With Collision Proxies


mockup_3x

Entering The Zombie Phase










Whoops – I Accidentally Added Boss Battles!






				

				

					By bitbull-uk
					|
					Also posted in Art, Development, DevLogs, Jetboard Joust, MonoGame
					|
					Tagged , 
					|
					Comments (1)
				

			



			

				
Jetboard Joust Devlog #81 – On A Roll!

				
March 8, 2018 – 1:52 pm

				



In the late 1970s, when kids played with proper toys rather than tablets and smartphones, there was this marvellous toy called ‘BigTrak‘. I always wanted one, but they were way too expensive to buy and probably cost around £10k per year in batteries. I’m sure the reason there’s so many SUVs on the roads today is that all these 40-something-yr-old men are buying them as some kind of mid-life BigTrak substitute. I still think the BigTrak design looks pretty cool even today.


This enemy, the ‘crawler’, was very much inspired by BigTrak, but it wasn’t just a nod to seventies nostalgia. At the moment gameplay seems to gravitate very much towards the top of the screen and I wanted something other than pickups to take the player closer to the ground and amongst the buildings. A ground-based enemy seemed the logical choice to do this.


Usually I’d work on the art first but in this case I thought I’d run a few code tests first to see if the ‘tank’ type enemy I had planned had any kind of hope of succeeding. Maths is not my strong point, and as this vehicle would have to perform the impossible feat of traversing vertical slopes and 90° changes of gradient I needed to make sure it wasn’t going to look like arse before I wasted loads of time on the art.


To my surprise my initial tests worked very well. There’s no ‘physics’ at play here, the wheels (working independently) simply traverse the outer edge of the terrain in the most basic way. I then work out the angle between the wheels (i.e. the axle) and place and orientate the chassis based on this. It’s not physically ‘correct’ by any means as the distance between the wheels changes depending on the terrain but, as it’s performing impossible feats anyway, I didn’t think this mattered – I could get away with a telescopic axle! In the final version I added something to make the wheels roll more nicely around corners but other than that I stuck with my first approach, I made a couple of attempts to make things more ‘realistic’ but both ended up looking worse than the original. 


Satisfied that I could make this work I then began work on the art. There were two keys things I had to bear in mind here. Firstly, the design needed to be such that the distance between the wheels could change without looking ridiculous as described above, and secondly that the vehicle could travel in either direction. I think you can get away with simply flipping sprites for left/right when they’re small but with larger sprites like this that approach can look pretty ropey. 


At first I was working on a ‘tank’ type idea that was similar to BigTrak. I spent several hours on this but wasn’t happy with anything I came up with. Everything looked too clunky or too much like a motorbike. So I started experimenting with some radical changes and in the ended settled on a kind of armoured ‘push me/pull you’ design that I felt worked much better. It’s a complex affair though, the final unit comprises eleven different sprites, so getting these all lined up and positioned correctly was a very fiddly business!          


Getting the guns to track the player was also fairly tortuous as one has to consider the rotation of the vehicle as well as the previous rotation of the gun to make things work smoothly. People with more of a maths brain probably find this stuff easy. I don’t, but I got there in the end.


The AI wasn’t simple either. For individual vehicles it’s pretty straightforward, but when they appeared in batches I was getting issues (as with the Squocket enemy) of them overlapping too much. In the end I created a ‘hive mind’ class that acts as a controller for a bunch of vehicles. This class works out the ideal positioning of each vehicle and then the individual vehicles track to this position.


Lastly I have the pilots of the vehicle man jetboards and make a last-ditch attempt to attack the player when their vehicle is destroyed. There’s a specific class for this type of enemy too (I’m calling it the Kamikaze) but it’s pretty much one of the basic minions with tweaked parameters.  


EDIT: Aaarggh – I thought I was done but whilst working on some screengrabs for this post I ran into a hideous bug to do with the world wrapping (remember I talked about that here?). I was getting all sorts of problems caused by the vehicle wrapping at a different time to any of the buildings it was in contact with. Very difficult to find a solution for this so in the end I’ve settled on a bit of a hack whereby the vehicle stops moving if it’s very close to the edge of the world. This seems to work OK and I don’t think it will be too obvious in practice.  


So, the most complex enemy to date but I’m pleased with the end result. I think I only really need a couple more like this and I can move on…


Dev Time: 4 days

Total Dev Time: approx 166 days


previous | next










Original Code Experiment For Rolling Action 










Abandoned Art Direction – ‘Tank’


mockup_3x

The Finished Design – ‘Push Me/Pull You’










Guns Tracking Player And A Nicer Rolling Action Round Corners












Using A Variety Of Weapons To Dispatch Two Crawlers (Enlarged 150%)





				

				

					By bitbull-uk
					|
					Also posted in Art, Development, DevLogs, Jetboard Joust, MonoGame
					|
										Comments (1)
				

			



			

				
Jetboard Joust Devlog #80 – Squid’s In!

				
February 28, 2018 – 1:03 pm

				



This latest enemy was inspired by the rockets in ‘Scramble‘, the other seminal side-scrolling shooter (along with ‘Defender‘) that defined the genre for me in the early days and paved the way for the likes of Nemesis, Salamander, Gradius, and all that came after. 


I didn’t want to have bog-standard rockets though. Every other enemy in the game is humanoid to a degree (when I do have spaceships etc there’s an obvious humanoid pilot). I feel this imbues them with much more personality – so I began working on ways to ‘humanize’ a rocket. 


I was thinking about Tomohiro Nishikado’s original sketches for ‘Space Invaders’, which were in part inspired by aquatic life like jellyfish and crabs, when I hit upon the notion that giant squid are not only very rocket-like in form but also have great Cthulhu overtones which links in to some of the other art in the game (the Mutants in particular).


So I decided to name this enemy a ‘squocket’ – a cross between a squid and a rocket. What I didn’t consider though was how much of a bastard those tentacles would be to animate! The main animation took me the best part of a day and is probably the most fiddly piece of pixel art in the game so far. I’m pleased with the end result though, I decided to make the animation symmetrical because it was simpler and also felt more ‘Space Invaders’ that way.


There’s also an idle animation as the squockets wait for the player to approach. This is much simpler but still took a while finding a nice way to make it loop. In the end I decided on a five frame ‘back and forth’ animation for this.


The movement of the squockets was pretty easy to code – I work out the angle between the squocket and the player and ‘lerp’ towards this. What I was finding was that multiple squockets began to overlap after a while (often almost exactly aligning) which looked pretty daft, so to counter this I started polling the player’s position only around four times a second and adding a certain amount of randomness to the polling time, this has pretty much alleviated the issue though I may work a bit more on this – maybe adding a ‘ram’ attack or something.


I also had to deal with squockets becoming ‘stuck’ on the side of buildings if there was a building between them and the player. To solve this I have the squocket rotate upwards if it hits the left or right of a building and to a horizontal position if it hits the top of a building. This seems to enable them to find their way around pretty well. I did play around with a ‘lookahead’ sprite placed a certain distance in front of the squocket and using this to navigate around buildings but this approach almost worked too well (they would avoid buildings so effectively that the player could hide too easily).     


Lastly I gave them the ability to fire (I actually re-use the bullets from the original ‘spreader’ weapon) and added a simple ‘tell’ animation prior to firing.


Dev Time: 2 days

Total Dev Time: approx 162 days


previous | next






mockup_3x

The Main Squocket Animation


mockup_3x

Squockets At Rest










Sparring With Some Squockets






				

				

					By bitbull-uk
					|
					Also posted in Art, DevLogs, Jetboard Joust
					|
										Comments (1)
				

			



			

				
Jetboard Joust Devlog #79 – Space Invaders

				
February 22, 2018 – 8:57 am

				



In my last post I wrote about maybe recycling the old ‘Evil Mother’ enemy into something based on the classic ‘Space Invaders‘ aliens, and that’s exactly what I’ve ended up doing!


I like the idea of including a few homages to the classic arcade shooters of yesteryear in Jetboard Joust, and as ‘Space Invaders’ was really the granddaddy of them all it’s an obvious choice. I wasn’t sure whether the formation/movement of the invaders would work within the horizontal/scrolling format of Jetboard Joust but, with a few tweaks, it actually seemed to work out pretty well.


It wasn’t too tricky to code either. I was worried that get the whole batch of invaders to move together around buildings and stuff would be a pain but it was pretty straightforward in the end.


What I do is move all the invaders as a batch rather than treating them as individual sprites. Collision detections are still handled individually and, when an invader collides with a building, it sends a message back to the batch telling it to change direction. When the batch is initiated I make sure it doesn’t take up more vertical space than the space between the highest building and the top of the screen so I know it’s never going to get stuck.


Probably the trickiest thing was deciding how to treat a batch of invaders when attacked by the ‘Gravity Hammer‘ weapon. Moving the whole batch at once would just look dumb so I needed a way of having individual enemies break formation when hammered and then return to the appropriate position once they recover.


To achieve this I have a property for each invader that stores its location within the batch separate from its position on screen. If the invader is forced to break formation it is relatively simple for it to return to its batch position. Though it wasn’t strictly necessary I also decided to have individual invaders track horizontally with the batch even when hammered (so only their vertical position is displaced). It just seemed to look better this way.


In keeping with the original I have the invader’s speed and rate of fire increase as individual invaders are destroyed.  


Dev Time: 1 day

Total Dev Time: approx 160 days


previous | next






mockup_3x

Admit It – You’ve Always Wanted To Play ‘Space Invaders’ With A Flamethrower!










Using The Plasma Rifle To Dispense With A Batch Of Invaders












Using The Gravity Hammer To Break Batch Formation






				

				

					By bitbull-uk
					|
					Also posted in Development, DevLogs, Jetboard Joust, MonoGame
					|
					Tagged , 
					|
					Comments (0)
				

			



			

				
Jetboard Joust Devlog #78 – Return of the Evil Mothers

				
February 19, 2018 – 4:02 pm

				



Too long since the last update. Had a lot of shit on – decided to fight a parking ticket issued by one of those fascist private parking companies and it ended up in court. I beat the tossers but it took so much time preparing the defence and everything I’m not sure if it was worth it, just did it on principle really as I don’t like scammers or bullies. Turns out these scumbags didn’t even have the right to operate on the land on which the ticket was issued in the first place!


Anyway, back on topic, the first major ‘new’ enemy is actually an ‘old’ enemy redone, but I don’t think there’s any shame in that. If you’ve been following this for some time you may remember the ‘Evil Mother‘ enemy. Well, I’d come to the conclusion that this enemy just wasn’t big enough and would work better (and make more sense) as some kind of mini mothership that spilled out its occupants when destroyed. 


So I spent quite some time designing a kind of ‘bathysphere’ type craft. It’s actually several different sprites in one, the ship itself, the pilot, the ‘antennae’ on the top which acts as a weapon, plus the various lights. I’m pretty pleased with the result though a little worried it looks a bit too ‘2D’ and could do with some more shading or something to make it appear more ’rounded’.


I also increased the size of the enemies that spill out when the craft is destroyed and spent quite some time working on a much improved bullet that tracks the player’s movement in a similar way to the Limpet Mine. There’s also a ‘tell’ that the ship is going to fire as you can see the antennae at the top charging up.


The shaking effect is achieved by applying an offset to the ships position each frame. These offsets are always evenly distributed and chosen at random so it’s a very predictable type of brownian motion.


I think I’m going to use the original enemy design as more of a ‘swarm’ type enemy with a movement type that’s an homage to the original Space Invaders!


Dev Time: 3 days

Total Dev Time: approx 159 days


previous | next






mockup_3x

Final Artwork And Fire Animation










Dodging Bullets












Mothership vs Gravity Hammer & Gamma Ray






				

				

					By bitbull-uk
					|
					Also posted in Art, Development, DevLogs, Jetboard Joust, MonoGame
					|
										Comments (0)
				

			



			

				
Jetboard Joust Devlog #77 – Keeping Your Enemies Close…

				
February 7, 2018 – 1:11 pm

				



Been working on some new jetboarding enemies over the past few days, so around a day of pixel-pushing and a day of coding with the extra half day fixing bugs caused by the new ‘world wrap’ technique I described in my previous post. I’ve also been rejigging my sprite sheets so the art used for the jetboard and weapon attachments is duplicated on the enemy sprite sheet (fewer spritebatch calls to the GPU needed and should also make things easier if/when I add alternate colour palettes). 


Fortunately new jetboarding enemies are relatively simple from a code point of view as a much of their ‘personality’ is defined by tweaking parameters already present in the AI. I also have a fairly decent template for doing the animations now too. Here are the new enemies that have been added, names are just codenames really so may well change…


1. The Master Minion

This is really just a bigger, stronger, and slightly more dangerous version of the omnipresent ‘minion’, the game’s cannon fodder. They’re quicker to snatch your babies away and mutate too!


2. The Ninja

Small, fast, light, very aggressive, but also pretty weak. This guy is very dangerous and performs a ‘pincer movement’ around the player really frequently making him a tough opponent to deal with.


3. The Aggressor

This guy is strong, fairly nimble, and very aggressive when you rile him but he’s actually pretty dumb and will let you sneak up behind him and get in the first shot. A bit like some of the knights in ‘Dark Souls’ (well, kind of)! You can tell which way he’s facing by looking at the scanner. This enemy required some custom AI work.


4. The Thug

This guy is very big and strong and takes a lot of ammo to dispatch. He’s pretty slow though, and not the brightest lamp on alien street either. I was particularly pleased with how the art for this one worked out.


5. The Snatcher

All this guy cares about is stealing your babies and trying to mutate. It’s like he’s a kind of half-mutant already and is desperate to finish the job. He’s a bit of a coward and will actively try and avoid the player unless directly engaged – watch him though, as he’ll snatch away your progeny and mutate really quickly if you don’t keep an eye on the scanner! This enemy required the most custom AI work.


This brings the total of enemy types to 12, I think I’m going to try and bring it closer to 20 and want to add some ‘miniboss’ type enemies with much larger sprites. few more smaller ones to do yet though…


Dev Time: 2.5 days

Total Dev Time: approx 156 days


previous | next






mockup_3x

The Master Minion – Upgraded Cannon-Fodder


mockup_3x

The Ninja – Fast And Dangerous


mockup_3x

The Aggressor – You Won’t Like Him When He’s Angry


mockup_3x

The Thug – Strong But Easily Outwitted


mockup_3x

The Snatcher – A Devious Coward




				

				

					By bitbull-uk
					|
					Also posted in Art, DevLogs, Jetboard Joust
					|
					Tagged 
					|
					Comments (0)
				

			



			

				
Jetboard Joust Devlog #72 – Stick To Your Guns!

				
January 4, 2018 – 2:57 pm

				



For the penultimate (hurrah!) weapon I decided to go for a heat-seeking ‘limpet mine’ as I don’t currently have anything like that in the game. Not sure if this counts as a ‘conventional’ or ‘futuristic’ weapon as it’s really somewhere between the two. 


Most of the coding was done on this before Christmas and I am currently suffering from a heavy cold so excuse the brevity of this blog entry!


It wasn’t that tough a weapon to put into action, for the motion I work out the ideal vector between the mine and its target and then ‘lerp‘ the mine’s horizontal and vertical velocities towards this value (with a set maximum ‘acceleration’).


I found that sometimes mines were getting stuck against the edge of buildings if the nearest target was on the other side of a building, so I implemented a very simply AI that moves the mine to the top of a building if its path is blocked. This seems to work fine and gives pretty amusing results in some scenarios.


The other simple AI I added is a check to see if a target already has a mine attached. If it does, and the HP level of the target is low enough to be knocked out by it when it explodes, further mines will seek alternative targets to prevent them being wasted. This is pretty satisfying in-game as you can just fire a bunch of mines into a swarm of enemies and trust them to find their individual targets.


Actual development of this weapon took about a day and a half, the extra time was spent improving my mother-of-all-geometry-shaders to draw triangles, six and eight pointed stars and add decent-looking fades for all these various shapes. The six-pointed star is used when the mine explodes and I will definitely be using these elsewhere in the game too.


Oh yeah, enemies with limpet mines are rather too dangerous at the moment! I am going to have to implement some kind of enemy-specific ‘pause and reload’ functionality for all the weapons.    


Dev Time: 3 days

Total Dev Time: approx 143.5 days


previous | next






mockup_3x

(Vaguely) Intelligent Selection of Target


mockup_3x

Not Getting Stuck On Buildings


mockup_3x

A Sticky Situation


mockup_3x

One of the New Geometry Shaders – Six Pointed Star




				

				

					By bitbull-uk
					|
					Also posted in DevLogs, Jetboard Joust
					|
										Comments (1)
				

			



			

				
Jetboard Joust Devlog #71 – (Black) Hole In One!

				
December 19, 2017 – 1:19 pm

				



This was the first weapon that I really didn’t have much of a clue what I was going for when I started it and, ironically, it’s probably turned out to be the one I’m most pleased with!


When I set up the placeholder for this one ages ago it was called ‘Storm Bringer’ and I had an idea it was going to involve some kind of ‘particle storm’ type effect, a bit like those fireworks you get that fire out a ton of different sparks that go off in different directions.   


However, I’ve already changed the ‘Spreader‘ weapon to be called ‘Particle Storm’ and, as that now does something very similar to what I intended this weapon to do, differentiating this weapon proved difficult.


I tried a series of variations with a bunch of particles moving in a constrained and stuttery ‘Brownian Motion’ type manner but this all looked shite and, to be honest, given that I’ve done so many of these weapons now I was beginning to feel like I was running out of ideas and motivation.


Then came a random source of inspiration. In my very skunkworks home studio I have a rack for audio gear that I’ve cobbled together over the years from various shitty pieces of Ikea furniture and stuff. In an attempt to make this more uniform (as nothing matched and my workmanship was so terrible) I covered the entire piece with Jack Kirby art from a bunch of old Spiderman and Fantastic Four comics I had as a kid.


On one small section of this there’s an image of a character disappearing into a kind of black hole, the image is drawn in negative and looks really striking. I had vaguely considered a weapon called ‘Black Hole’ (though I was worried it would be too similar to the ‘Sonic Boom‘) so I decided, largely out of desperation, to try switching the particles I was using to very dark circles with a light outline. I thought this would look ridiculous but, to my surprise, it actually looked kind of cool!


It’s not a single black hole though, so I hit upon the concept of a weapon that fires a series of mini black holes that suck the life force from enemies. Stephen Hawking would probably turn in his grave but I liked the idea. I’m calling it the ‘Black Hole Blaster’ which, thankfully, just about fits in the space I’ve reserved for weapon names in the HUD!


I worked on this ‘negative space’ effect some more, adding a layering system to my particle code so that I could draw all the white outlines ‘behind’ the black circles, this gave the effect of a unified black mass with a white outline which looked much better than a bunch of circles overlaid. As usual there was a lot of tweaking and messing around here (I didn’t really have any point of reference for the effect I was trying to create other than that one comicbook panel) but I’ve ended up with something I think works. 


There’s five layers of particles in the final version two sets of black circles with light outlines (one smaller than the other) and the concentric circles you see overlaid which (I think) help to give the impression of some kind of black hole rather than simply black smoke. It was difficult to get these concentric circles subtle enough to suggest ‘black hole’ without overwhelming things, I had to do a lot of messing around with the frequency and distribution of them. It’s possible that I’ve erred to much on the side of caution and could do with a few more of them. It does look a bit like some kind of weird satanic flamethrower but I don’t think that’s necessarily a bad thing!      


Lastly, whilst working on the collision detection (which was very straightforward) I thought it might be a nice touch if these mini black holes exerted a small gravitational force, actually sucking enemies towards them. This was pretty fiddly to code, and my initial version was ludicrously powerful, but it did seem to work and help to differentiate this weapon nicely from some of the others. 


So I think I’m pretty much done with this one now. I’m really pleased with it, both in the way it looks, but also for the fact I’ve never seen a weapon quite like it in any other game (though some smartarse will no doubt point one out to me)!  


Only two weapons left to go!!


Dev Time: 2 days

Total Dev Time: approx 140.5 days


previous | next






mockup_3x

The Jack Kirby Panel That became My Inspiration


mockup_3x

An Early Draft Of The Weapon


mockup_3x

The Final(ish) Version


mockup_3x

Too Much Suction!


mockup_3x

Black Hole Dogfight!




				

				

					By bitbull-uk
					|
					Also posted in Development, DevLogs, Jetboard Joust, MonoGame, Uncategorized
					|
										Comments (1)