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 #11 – Scanner Wobble

February 22, 2016 – 9:05 am

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

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

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

previous | next

mockup_3x
The (Currently Slightly Wobbly) Scanner In Action
Posted in Art, Development, Jetboard Joust | Comments (0)

Jetboard Joust Devlog #10 – Custom Shaders & Health

February 19, 2016 – 11:51 am

You know that horrible sinking feeling when you realise you’ve done something really, really stupid and have just spent the best part of an hour ignoring something that was staring you straight in the face all along? Doh! Not good is it.

I’ve been looking at adding some kind of health/hp to both the enemies and main character in Jetboard Joust. I think the game is going to prove far too difficult if I go for a ‘instant death’ mechanic every time you hit an enemy, plus I want to add a variety of weapons so adding health gives me more scope for different weapons doing different levels of damage. It also gives a very obvious upgrade path for weapons should I decide to add an weapon upgrade system.

So I needed something visual to indicate when a collision has occurred, or when an enemy takes damage but is not destroyed altogether, but I didn’t want to go down the route of creating a specific animation per enemy as this would have proved extremely time consuming (and very difficult to change globally).

Initially I looked at creating a type of ‘white out’ effect using the stencil buffer in MonoGame. I felt sure this was the way to go and sunk a lot of time into this approach, not ever having used a stencil buffer before. Unfortunately I just couldn’t get this to work – part of the reason was due to my own stupidity (the ‘doh’ moment I mentioned above when I realised the code that initialised the DepthStencilState objects I was using wasn’t getting called), but part of the reason was undoubtedly to do with quirks of this feature in Monogame. When I saw that my partially-working code wasn’t running consistently on Android and iOS I decided to abandon this approach as it seemed likely to lead to too much pain and grief.

That left custom shaders as the only possible approach. Fortunately getting these to work was a lot easier than I’d been anticipating. You can’t compile the shaders natively under OSX (which is a pain) but they compile easily using the Monogame Pipeline tool under Windows and I can flip back and forward between Windows and OSX easily with VMWare Fusion. I’ll probably write a separate post explaining how to do this in detail.

You can see on the right the results of my custom shader experiments. Doing a simple ‘white out’ effect was easy. Slightly more tricky was getting the texture to invert in the way I wanted. A simple colour inversion is easy but produced colours that were way out of range of the limited palette I’m using and looked really odd. What I needed to do was invert the brightness of the texture but keep the colour balance intact – I seem to have got there with the following HLSL code. Probably very hacky but it seems to work (Maths was never really my strong suit).

float4 PixelShaderFunction(float2 coords: TEXCOORD0) : COLOR0
{
	float4 color = tex2D(s0, coords);
	if ( color.a>0 )
	{

		float r2 = color.r;
		float g2 = color.g;
		float b2 = color.b; 
			
		float t = r2+g2+b2;
		float rp = (r2/t)/0.3333;	
		float gp = (g2/t)/0.3333;
		float bp = (b2/t)/0.3333;

		color.rgb = dot(color.rgb, float3(0.33, 0.33, 0.33));			
		color.rgb = 1.0-color.rgb;
		color.rgb *= float3(rp, gp, bp);

		color.a *= alpha;
	}
	return color;
}

So the final shader does a simple ‘white out’ followed by alternating inverted and normal frames. The ‘normal’ frames have increased brightness which gradually fades out. I think it’ll do the job for now at least. I imagine I’ll be implementing a few more of these type of effects – HLSL seems like a rabbit hole I can’t stop myself from entering.

Finally I added some more particle effects (another slight addition to the particle generator required to get that ‘halo’ effect) and mini health bars which I think look kind of cool. When health is depleted these animate down rather than just jumping to the next value.

Dev Time: 1.5 days
Total Dev Time: approx 14 days

previous | next

mockup_3x
Before And After – My ‘Invert Brightness’ Shader

mockup_3x
The Final Shader Animated

mockup_3x
Custom Shader Effect In-Game With Health Bars
Posted in Art, Development, Jetboard Joust | Comments (0)

Jetboard Joust DevLog #9 – Jetboard Pyrotechnics

February 15, 2016 – 11:57 am

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

Jetboard Joust Devlog #8 – Thrust!

February 9, 2016 – 10:49 am
Best part of a day spent fiddling with the particle generator again!

I needed to add a ‘thrust’ effect to the jetboard and particles were the obvious way to go rather than trying to animate flames or something which would have a) taken me ages and b) probably looked shite.

As you can see from the images – my first attempt was a complete fail but I got there in the end. At least I think it looks pretty good now anyway.

The main extra functionality I needed to add to my particle generator code was the ability to set an initial velocity for the particle generator itself, ie so the particles appeared to be generated by something that was moving rather than from a simple static source. Back to ‘O’ level physics here! Without this the particles tailed behind the jetboard far too much, and if I simply fixed the particle generator to track the jetboard the flame looked much too ‘rigid’. This way I think it tails pretty nicely when you change direction. In fact I’m a bit worried it almost looks too ‘realistic’!?

The horizontal and vertical flames together perhaps look a little weird but I’m not really sure what to do about that at the moment. I think I need to shelve this particular rabbit-hole for a while and move onto something else.

Dev Time: 0.75 days
Total Dev Time: approx 10.75 days

previous | next

mockup_3x
First Attempt == Major Fail

mockup_3x
Looking Better After Much Tweaking

mockup_3x
Added Horizontal Thrusters
Posted in Art, Development, Jetboard Joust | Comments (0)

Jetboard Joust Devlog #7 – Control, Camera, Action!

February 4, 2016 – 2:09 pm

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

Jetboard Joust Devlog #6 – Die and Retry

February 3, 2016 – 5:29 pm

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

Directional Control Systems for Touchscreen Games

January 21, 2016 – 5:58 pm
A while ago I wrote a blog post entitled An iPad Is Not A GamePad describing my aversion to virtual ‘d-pad’ (I’ll call them ‘v-pad’) style controls for touchscreen games.

Well, whaddya know – a potential publisher for ‘Attack Of Giant Jumping Man’ has asked to see the game working with a ‘v-pad’ style control system as he’s worried the existing ‘swipe’ control system is not intuitive enough. Personally I just think we need to improve the way we communicate how the existing system works – but, as I’m never one to let my prejudices get in the way of improving the game experience, I decided to roll up my sleeves and see if I could get a decent ‘v-pad’ style control system going. It wasn’t easy and I’ve documented my experiments here. I’ll cover button placement in another post as this one got rather out of control!

First off, as I knew I was going to be experimenting with several different control methods, I had to completely separate the ‘controller’ logic from the ‘game’ logic. I guess this is something that’s pretty standard practice with other application designs (MVVM, MVC etc) but I never really think about doing it with games as (usually) you know what the control method is going to be from the outset and the game is designed with this in mind. Ultimately it makes more sense to keep the controller logic abstracted though (especially in today’s cross-platform world) and, now I’ve been through the pain, I will definitely be approaching game design this way in future. It allows a bunch of different control systems to be easily tested/switched without any alteration of the game code.

So I came up with a generic ‘controller’ interface that produces the usual ButtonPressed / ButtonReleased type events as well as allowing polling to see whether a particular button is held down and the position of two ‘virtual analog thumbsticks’ which produce values between -1.0 and 1.0 on both the horizontal and vertical axis. Basically pretty much an abstracted representation of the XBox Controller.

Next stage was to experiment with some different controllers, I’ll go through each of these in turn…

The Virtual D-Pad
This is the simplest approach of the lot. Basically a virtual button for up/down/left/right that produces a binary KeyHeld result if the user is pressing the screen in the appropriate place.

This method is very easy to implement but, in my opinion, sucks for the following reasons (many of which apply to all v-pad style controllers).

1. It requires an overlay on the screen to show the user where to press. This uses up valuable screen real-estate and potentially gets in the way of the action.

2. It requires the same size controller whatever the physical size of the device, therefore is much more problematic on small devices. A fact that’s blindingly obvious but a lot of developers ignore is that people’s thumbs are the same size whether they’re using an iPhone 4s or an iPad. Think how much research goes into designing the perfect d-pad size for a console controller, now imagine sticking one of those on top of a 4s screen – kind of get in the way of the action wouldn’t it?

3. It requires the user to hover their finger/thumb over the same area of the screen all the time. Again, using up valuable screen real-estate and potentially getting in the way of the action. As above, on a physically smaller device this is even more of an issue.

4. It’s too easy to stray off the controls. With a physical controller you can feel your thumbs resting on the controls without actually pressing them – it’s very unlikely you’ll slip onto the wrong control accidentally, let alone slip off the entire controller. Modern touchscreen devices however are designed to be as super-smooth as possible with no tactile differentiation between the screen itself and the ‘dead’ frame of the device. This makes it all to easy to stray into the ‘dead zone’ without realising it.

You could implement your own tactile feedback solution, ie vibrate the device when the user strays into the ‘dead zone’, but there are a number of issues with this. Firstly, not all devices support a vibrate function (iPads and tablets don’t tend to) and auditory feedback is likely to be annoying – secondly, in order to implement this you are reliant on getting a ‘TouchReleased’ event when the user strays into the ‘dead zone’ and for that event to be accurate enough to warrant doing something with. In my tests on an iPad 4, when moving quickly that event could be generated up to 45 pixels from the edge of the screen – that’s 0.25inch so probably within the bounds of a ‘normal’ release event.

As you can tell, I’m not a fan of this option and can’t really see any situation where it’s decent control method to use. This brings us on to…

The Virtual Thumbstick
This method is similar to the ‘Virtual D-Pad’ described above. However, instead of simply checking whether we have pressed a virtual button to determine directional control we measure the distance of TouchPressed and TouchReleased events from a central point and use this to compute a value between -1.0 and 1.0 on the horizontal and vertical axis. This can be converted to a binary event if necessary by testing against a threshold value. A TouchReleased event resets all values to zero.

The computation I use for calculating the x and y values is something like this…

//
// Calculates thumbstick values and y between -1.0 and 1.0 where px and py
// are the distance of the touch event from the centre of the virtual thumbstick
// and radius is the distance required to produce a maximum value
//
public static void CalculateThumbstickValues( out float x, out float y, int px, int py, int radius )
{
// Work out x and y distances as a proportion of radius
x /= radius;
y /= radius;

if ( x>1.0f ) x=1.0f;
else if ( x<-1.0f ) x=-1.0f;

if ( y>1.0f ) y=1.0f;
else if ( y<-1.0f ) y=-1.0f;
}

This method has certain advantages of the ‘Virtual D-Pad’ method. It’s not restricted to binary events and, importantly, it doesn’t require the user to target one area of the screen quite so much as any deviation from the ‘edge’ of the thumbstick area reads as a maximum value. Consequently I find it works much better.

It still suffers from the fact that it requires some kind of visual overlay (though technically only the very centre point of the thumbstick needs to be marked), that it’s restricted to one area of the screen (so better make sure it’s not getting in the way of anything important), and (worst of all) that a user can still easily stray into the ‘dead’ zone (effectively letting go of the thumbstick).

Given these problems I thought I’d work on a couple of variations of the ‘Virtual Thumbstick’…

The Floating Thumbstick
This method is identical to the ‘Virtual Thumbstick’ with the difference that the thumbstick isn’t fixed to a set centre point – instead the location of the stick changes every time a TouchPressed event is received.

The advantages of this method are twofold – no visual overlay is required and the user can direct their input to a location on the screen that doesn’t get in the way of the in-game action (possibly making it less likely that they will stray into the ‘dead zone’).

One disadvantage of this method is that the player has to make a small drag motion for each TouchPressed event in order to generate any kind of directional data. On some types of games this might become an issue.

Another disadvantage is that if the player generates their original TouchPressed event near to the edge of the screen (say at the left edge) it then becomes impossible to move left without first releasing touch.

Generally I found that this control method works very well as long as the game in question is designed for one-handed play. On games that require two-handed play players will tend to position their thumbs permanently over the same area of the screen anyway, pretty much negating any advantage this control method brings.

The Elastic Thumbstick
This method takes the idea of the ‘Floating Thumbstick’ one step further. As well as centering on TouchPressed the thumbstick also centres after a defined period of inactivity, though in this instance it continues to read its last ‘set’ value.

As an example – on a thumbstick with a radius of 50 pixels a swipe to the right of 50 pixels will generate a value on the x axis of +1. If the user doesn’t release and doesn’t move their finger the thumbstick will be re-centred but continues to read +1 on the x-axis until a significant movement in the other direction on the same axis is made.

The thumbstick is also recentered if the user makes a sudden change of direction, so a swipe to the right of 50 pixels on the same thumbstick followed immediately by a swipe to the left of 50 pixels will result in the thumbstick being recentered in the +50 position (now reading 100% left).

The advantage of this approach over the ‘Floating Thumbstick’ is that it takes a much less significant movement to change direction on either axis. Consequently the problem of centering the thumbstick at the edges of the screen is negated and the amount of screen real estate required to process movement (and therefore be blocked by your user’s fat thumbs) is reduced by approximately 50%.

The only real disadvantage is that this control method doesn’t allow for ‘decceleration’, ie setting a thumbstick to max and then reducing this value – however, in practice this won’t make a lot of difference on most games and no difference at all on games that are using the thumbstick as a ‘binary’ controller.

In practice I found this method to operate best on two-handed games or on one-handed games where no decceleration is required and quick changes of direction are key to gameplay. It’s more finicky to set up than the others but well worth the effort.

NOTE: I also tried a similar approach by polling average movement on the touchscreen every few frames but this was pretty much a disaster.

The Sticky Elastic Thumbstick
OK, the names are getting pretty ridiculous now and a ‘sticky elastic thumbstick’ sounds distinctly dodgy but who cares. This is a new one based on gameplay testing I’ve just been doing on Jetboard Joust. It operates exactly like the ‘elastic thumbstick’ above with the difference that a straightforward touch event with no movement generates the values the thumbstick was set at the last touch release rather than zeroing the thumbstick and waiting for another movement.

This has the effect of a drag motion being required to set the direction but no movement being required to continue to move in that direction which makes control a lot easier and makes it a hell of a lot less likely that the players thumbs stray onto the ‘dead zone’. It seems to work extremely well on Jetboard Joust.

The Event-Driven Thumbstick (Swipe Controls)
This method is based on the ‘Floating Thumbstick’ with the key difference that it does not support continuous polling of thumbstick values. Instead it is event-based – a thumbstick event begins on TouchPressed (when the thumbstick is centered) and ends in one of two ways…

1. A TouchReleased event is generated within a specified time (approx <750ms)
2. The thumbstick is 'moved' to it's maximum position on any axis (different thresholds can be set for different axis if necessary)

… either of these causes an event to be sent to the game which is then processed appropriately.

The real advantage of this control method is that (with certain games) it allows one-handed operation where two-handed operation would normally be necessary (for example LEFT, RIGHT and JUMP). This in turn means that the user is free to swipe anywhere on the screen and that their thumbs and fingers are far less likely to get in the way of the action. Using this method also means that there's no requirement for the user to 'hover over' or touch any particular point of the screen for any length of time, again meaning that less of the action is likely to be obscured by fat fingers.

The disadvantage of this method is that the game needs to be suited to event-driven rather than continuous polling-based control. A game that requires a character to run in certain directions for long periods of time for example would be annoying to control by endless swiping, though there may be workarounds for this (e.g. swipe to move, tap to stop moving).

In practice I find the event-driven method to be the best way of controlling touchscreen games providing the game design is suited to it and the game can be operated one-handed. The event-driven method can enable very accurate control, obscures the screen far less than other methods, and never really runs the risk of the user losing control by straying into the 'dead-zone'. It's still our preferred control method for 'Attack Of Giant Jumping Man'.

Out of the two-handed methods the ‘elastic thumbstick’ seems to be the best compromise in this instance. 'Attack Of Giant Jumping Man' requires the user to make quick directional changes and the ‘elastic thumbstick’ allows for this whilst obscuring a minimum of the screen real-estate.

mockup_3x
Seriously, Just Don’t!
Posted in Uncategorized | Comments (0)

Jetboard Joust Devlog #5 – Another One Bites The Dust

January 5, 2016 – 3:14 pm

Another case of #gamedev pottering here as I started work on one thing and got pretty much distracted with another. It was a constructive distraction though and has provided me with plenty of re-useable code so I’m not beating myself up about it.

I started work on the animation for falling off the Jetboard and got it to a stage where I was pretty happy with it, then thought it would look better if I added some dust as the player hits the floor. I decided to use the basic particle generator I’d created for the enemy explosions and added some additional functionality such as the ability to animate particles, apply gravity, and restrict the angle at which particles are fired.

This worked, but in the process of testing I accidentally had the dust particles generated whenever the jetboard landed on anything – and it looked good! Decided to refine this which meant quite a few changes to the particle generator – mainly the ability for one generator to manage particles generated from several locations (to save the costly instantiation of a new generator every time I need some dust). Pretty pleased with the results though the parameters still need a bit of tweaking – some of that dust is getting flung rather too far!

Next up was working on the collision detection and figuring out the various ways you can be knocked off your jetboard. I’ve pretty much nabbed the collision detection from ‘Attack Of Giant Jumping Man’ which has saved a bunch of time and I think I’m going to restrict items you can interact with to simple static platforms as this is a SHMUP in essence, not a platformer.

So, other than colliding with enemies, there’s three ways that you and your jetboard can become separated…

1. Jetboard hits obstacle mid-jump, player still moving freely
2. Player hits obstacle mid-jump, jetboard still moving freely
3. Player hits obstacle whilst in flight, jetboard moves freely

…I also had to cover the occurrence where both player and jetboard come into contact with the same obstacle mid-jump. In this instance (I think) it’s reasonable that the player is able to land on the jetboard and recover though I may restrict this based on how far the player falls.

I’m still not entirely happy with some of the player falling animations but we’re getting there. Probably going to bit a bit of a break from this now whilst I work on ‘Attack Of Giant Jumping Man’ for a bit. Next up will be implementing a simple ‘lose life/retry’ loop.

Dev Time: 1.5 days
Total Dev Time: approx 8.5 days

previous|next

mockup_3x
First Stab At Falling Animation

mockup_3x
Dust Particles In Action

mockup_3x
Three Ways To Fall Off A Jetboard #1

mockup_3x
Three Ways To Fall Off A Jetboard #2

mockup_3x
Three Ways To Fall Off A Jetboard #3

mockup_3x
Recovering From A Fall
Posted in Art, Game Design, Jetboard Joust | Comments (0)

Jetboard Joust Devlog #4 – Enemies and Explosions

December 21, 2015 – 4:04 pm

When I code I have a tendency to ‘potter’ – that is, I’ll start off with the aim of doing something and end up getting distracted by various side-tasks along the way. Much as one might do when gardening!

So in this case I started off trying to get my first simple enemy done and ended up getting sidetracked into writing a particle generator to handle explosions and other FX in the game.

Consequently my initial enemy is still looking pretty crappy. I’m not happy with it at all actually. God this pixel art stuff is harder than it looks! All I wanted was a simple spinning ‘mine’ type thing that will remain largely static as a dumb target. The first attempt was OK but somehow looked wrong compared to the main character – like I was using too many colours or something, not contrasty enough. So I tried again giving it two ‘eyes’ this time and adding another frame to the animation. Still looks crap and now the animation looks all wrong too, like it’s not really spinning correctly. I know – even with four years at art school I should stick to code!

Anyway, in order to feel as if I was making some progress I decided one of these would do as a placeholder and moved on to implementing a simple ‘enemy’ base class and some basic collision detection for when the board is ‘fired’. Easy.

Next I needed explosions, and as this game is partly ‘Defender’ inspired it seemed some kind of particle-based explosion would be the way to go. I’ve never written a particle generator before so have no idea whether I’m going about this the best way (maybe I should have read up about it first) but am pretty pleased with where I’ve got to so far.

A ‘generator’ is instantiated with a max number of particles and a lifespan and chucks out max_particles/lifespan particles per frame.

Each particle has a velocity, decceleration and lifespan (defined at the generator level), each with a defined amount of variance. there’s also the option to set up a tween on the opacity of each particle. I calculate the tween values in advance.

So not much is being done per particle per frame other than calculate the new velocity and draw it. Thinking about it I could probably calculate the velocities in advance as well if I really needed to but not if I add additional factors like gravity which I plan to do. It should prove a very useful class throughout the game.

Another thing I’ve been a bit stuck on is getting the ‘camera’ on the scrolling world to perform to my satisfaction. Still not there on that one yet, hopefully have it resolved by the next installment!

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

previous

mockup_3x
‘Mine’ Type Enemy Attempt – Rubbish

mockup_3x
Tried Again – Still Hopeless!

mockup_3x
First Draft Particle Explosions – Look Like Fun?
Posted in Art, Development, Jetboard Joust | Comments (0)

Jetboard Joust DevLog #3 – Jumping And Thrusting

December 16, 2015 – 1:01 pm

Another 1.5 days or so in and, surprise surprise, things aren’t going as quickly as I would like. This is mainly due to the art though which always takes me ages. There won’t really be that many main character animations in the game I guess so I might as well make the one’s that are there as good as I can get them (with my limited pixel-pushing ability).

First off the main ‘riding the board’ anim. This looked OK in Photoshop but in-game it didn’t seem to work. Seemed too wobbly and unnatural. Looking at a few vids people stay pretty still on skateboards/surfboards when they’re riding them and only wobble about when they’re going to fall off!

So after much trial and error I decided to ditch any kind of movement when the player is riding the board. I replaced this with three key positions that vary depending on how fast the board is moving. As the board moves quicker the player leans back more. I also added a couple of ‘spring’ frames so that when the board thrusts upwards the player ducks down slightly. The combo of these two things seems to work pretty well – though I’m not sure if the ‘leaning back’ position is too much ‘walk like an egyptian’! Any more animation just looked too ‘wobbly’ (that’s the trouble with having an 18*18 sprite, it’s very hard to do subtle movements).

Next up was the controls themselves. I was quite keen on this being a ‘two button’ only game but using the same button for thrust and reverse (long press for reverse) just wasn’t working. It was too easy to reverse by accident and too natural to expect holding ‘thrust’ to keep thrusting. So I’m moving to a three button system where the button left will be ‘reverse’, bottom right ‘thrust’ and top ‘fire’. This is pretty easy to play on the iPad but I’m a bit worried fat fingers will get in the way of the gameplay on smaller phones (such as the older iPhones which seem tiny now)!

A knock-on effect of this is that thrust now works based on a continual applied force than a single impulse so I had to tweak the various parameters involved until this felt right. I’ve ended up with less thrust being applied as you reach terminal velocity so there’s a kind of curve going on. I’ve no idea whether this follows the laws of physics but it certainly feels nicer form a gameplay perspective.

Last but definitely not least in terms of time was getting the ‘jump’ action correct. A core feature of the game is that your jetboard becomes a weapon when you’re not riding it so this has to look and feel right.

Getting the basic movement was pretty easy – pressing fire causes an impulse which make the jetboard fly dead straight for a certain distance (so it’s easier to aim). Getting the player to jump and return to the board was also very straightforward (there’s a bunch of scenarios you have to think about but none of them present and major issues).

What wasn’t so simple was getting the ‘jump’ animation for the player to work. As the jump movement is done in code it’s very hard to preview this in Photoshop so I felt I was kind of working blindly. My first effort (which took ages) wasn’t too awful but felt more like a weird mid-air run than a jump. In the end I had to make the animation sequence fairly complex – we start with a kind of ‘run’ movement which is played again in part as the player reaches the zenith of the jump, the anim then transitions to a ‘descent’ position which is held until the player lands back on the board. When he lands a short ‘spring’ animation is played.

I’m pleased with the way this works now though I’m sure it could still be better and will gladly take any comments! I messed around with the frame timings a lot. Will probably come back to it but it’s time to move on.

Next up – probably adding some really simple enemies to test targeting and a simple lose life/new life loop.

Dev Time: 1.5 days
Total Dev Time: approx 6 days

previous|next

mockup_3x
Board Like An Egyptian?

mockup_3x
Riding The Board Sprite Sheet

mockup_3x
Jump Anim – First Attempt (Ministry Of Silly Walks)?

mockup_3x
Jump To It!
Posted in Art, Game Design, Jetboard Joust | Comments (0)