Category Archives: Game Design

Jetboard Joust Devlog #40 – Bits and Bugs

Tidying up some loose ends that were annoying me before I can (finally!) start work on some new enemy types!

1. Fixed ‘Invisible JetBoard’ Bug
If the player destroyed an enemy whilst it was teleporting in the enemy’s jetboard would remain static and invisible in the world. Fixed this so that a teleporting enemy’s jetboard drops down properly.

2. Cropped Jetboard Bug
This one had been ‘bugging’ (groan) me for some time, it appeared that enemy jetboards were getting randomly cropped on occasion for no apparent reason. Turned out that it was a crop at all but the board wasn’t always orientating correctly when the enemy changed direction.

3. Particles Going Weird On Level Exit
You can see this issue at the end of the video here. To get the level transform effect I render the entire world to a back buffer and then apply a custom shader when rendering to screen – turns out that optimisations I made to my particle system meant I was rendering direct to screen all the time and ignoring the back buffer (oops).

4. Various ‘End Of Life’ Bugs
There were various problems to do with a player getting killed when already dead and controls still operating the jetboard when the player was dead – these were largely to do with the fact that enemies continue shooting at the player even when he’s already dead ‘just to make sure’. I like this though, it’s funny, so I kept it and fixed the bugs.

5. Disallow Enemy Abductions/Mutations When Player Dead
Not really a ‘bug’ per se but I didn’t like the fact that enemies could carry on abducting babies and mutating when the player couldn’t do anything about it – it didn’t seem ‘fair’ somehow. Now they just hover when the player is in the ‘lost life’ state which, though it doesn’t make logical sense, seem to work from a gameplay perspective.

6. Add Floating Scores
I just like these and nearly always put them in my games – something very old school arcade’ about them.

7. Improve AI In Small Gaps
Enemies were doing some pretty stupid things when the player took cover in a gap between two buildings. This was the result of an algorithm I wrote to calculate the closest building to the player which didn’t work properly, and part of the AI which tries to move away from the player if overlapping (ie avoid ‘kamikaze’ style behaviour). Now, when in a small gap, the enemy should move to the edge of the building that’s furthest from the player, turn around and start firing. It’s tricky to get this stuff right and fixing this took a while!

8. Improve Message Font
This was probably the bulk of the work. Previous in-game messages appeared on the scanner – I didn’t like this for two reasons; it got in the way of the action on the scanner and it necessitated the use of a very small font which made the messages unclear. Double fail. I have moved messages to the main game area which seems to work OK, designed a custom bitmap font for them based on the font I’m using for the HUD (but smaller), and also added ‘impact shader’ effects. Still a bit worried about them getting in the way of the action but actually it seems to work OK (I tried placing them over the ‘ground’ at the bottom of the screen as well but this didn’t seem to work so well).

Dev Time: 2.5 days
Total Dev Time: approx 54.5 days


Enemies Now Act More Sensibly In Small Gaps

Added Floating Scores When Enemies Are Destroyed

Designing A Custom Bitmap Font For In-Game Messages

Adding Impact Effects To In-Game Messages

Jetboard Joust Devlog #34 – Making Babies

I’ve been thinking for a while that the basic ‘destroy all enemies’ objective in Jetboard Joust was a bit too one-dimensional and that I needed to add something to give the gameplay a bit more depth.

The obvious source to look for inspiration was Defender, to which Jetboard Joust is pretty much a homage, so look to Defender I did!

In Defender you protect these little coloured blob things which get carried off by a certain type of enemy. If an invader manages to get a blob to the top of the screen it mutates and becomes a lot more dangerous. I thought I may as well go the whole hog with the Defender homage thing and replicate this scenario – maybe I could have the player protecting radioactive cannisters which enemies carry off and then use to mutate themselves?

This seemed to make sense to I went about designing some radioactive ‘cargo’. Unfortunately, despite my best efforts, it was shit! The little cannisters were OK but drawing a decent radiation symbol in about 5×5 pixels proved beyond my abilities, and the cannisters on their own just looked too boring. Time to rethink!

According to the Wikipedia page for Defender the little coloured blobs that you defend are, in fact ‘astronauts’ (not that you’d guess it from just playing the game). This triggered a memory of them being referred to as ‘humanoids’ in the original game instructions (though i could be wrong about this).

Something with a bit more character seemed a good idea so I thought I’d go about designing the most basic ‘humanoid’ form I could in as few pixels as possible and see if that would work. What I came up with kind of looked like a baby version of ET so I thought – what if you were protecting alien babies? This seemed to make sense! Babies are inherently something that warrants protecting, they look cute and have character, and having them carried off by aliens has overtones of the whole alien abduction/conspiracy thing which I liked.

So now I have alien babies! I created a little ‘idle’ sequence for them and a ‘panic’ animation for when they’re abducted. I think they’re pretty cute! Glad I was so bad at drawing radiation canisters! Now to work on their abduction…

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

previous | next

Alien Babies – Panic Animation

Alien Babies – Idle Sequence

Jetboard Joust Devlog #33 – Game On!

It’s always a great moment in the development of a game when the game actually starts to feel like a game, rather than a prototype, tech demo, or a bunch of animated GIFs on Twitter.

Thankfully I’ve now reached that stage on Jetboard Joust and have been able to spend the last couple of days refining gameplay rather than tweaking visuals or adding basic functionality – and I’m pleased to say that, considering it’s still early stages, it’s playing fairly well and has the old-school arcade feel I’d hoped for.

So now I’ll bore you with the kind of refinements I’ve been making over the last couple of days – some major, some pretty minor…

The Jump Attack
This was the really major change. It became obvious whilst testing that the ‘jump attack’ (which I’ve sometime previously referred to as the ‘weaponised jetboard’) was far too powerful and needed to be ‘nerfed’ in some way. I’ve settled for limiting the amount of jump attacks the player can do which seems to work well and is a solution I like because it’s somewhat akin to the smart bombs in Defender.

So there’s now ‘ammo’ for the jump attack which is represented by a new rocket icon in the HUD – enemies also drop extra rockets occasionally when destroyed (see the last post for more on that saga).

I was going to use the ‘jump attack’ as the basic attack when the player runs out of ammo but had never been entirely happy with this idea as I was worried that the transition from button-mashing ‘fire’ to fire a weapon to something that required a more judicious button treatment would be too jarring. I now have a separate button for ‘fire weapon’ and for ‘jump’ which works much better – the only disadvantage is that it will make the control system more complex on touchscreen devices. Those are low-priority for me at the moment though.

It was far too easy to run out of ammo so I’ve upped the initial capacity of the pistol to 24 shots. This will be expandable via weapon upgrades. It’s still pretty easy to run out of ammo but I like the gameplay aspect of having to dive down to retrieve the mini-ammo pickups all the time, it adds a ‘survival’ element which is unusual for SHMUPs but I think works nicely. It will have to be well balanced though.

I’ve added mini-health pickups as an additional occasional drop when enemies are destroyed. I felt I need something smaller than the ‘bubble’ health pickup which recharges you to full health (at least at the start of the game, the player’s max health level may be able to be upgraded).

Pickup Balancing
The algorithm that decides which pickups are dropped is ‘intelligent’ to a degree in that if the player is very low on health or rockets it is more likely to drop these items (though there is still a limit on the frequency at which these appear). I’ve done this type of thing in other games and like the result as it leads to plenty of moments where you are just ‘saved by a pickup’ which leads to more of an ‘edge of the seat’ feel – playing on the players ‘gambling response’.

Pickup balancing is going to be very important to gameplay. I’ve also added the more powerful ‘bubble’ pickups which, so far, appear after a certain number of enemy ‘batches’ have been released.

Pickup Timeouts
The ‘mini pickups’ now have a timeout attached so they don’t hang around forever. This is particularly important for the coins which otherwise could all be left for the player to scoop them up easily when the level was complete. Consequently coins have a relatively short timeout, whereas ammo, health and rockets i can afford to have hang around rather longer.

Enemy Frequency
This is another key thing to get right – so far the game seems to work better if smaller enemy batches are released frequently rather than large batches less frequently. In a previous post I talked about allocating enemies based on a difficulty score – I have also added something that prevents additional enemy batches from being released if the enemies currently in-game exceed a certain difficulty threshold. This prevents the user from becoming ‘swarmed’ by enemies which was becoming a bit of a problem.

Enemy Clustering
This one’s still on the ‘to do’ list but I need to add some variation to the speed and acceleration of the same type of enemy so they don’t end up ‘clustering’ too much which has a tendency to happen at the moment. I will probably also add some variation to the timing of their AI decisions.

Those are the main fixes – I’ve also fixed a ton of minor bugs and made a load of other minor improvements. Next step is to finish the initial set of gameplay tweaks and then start to look at optimising performance, particularly in regards to the way the ‘world wrap’ is handled.

Dev Time: 2 days
Total Dev Time: approx 35.5 days

previous | next

Enemies Now Drop Mini Health Pickups

Jetboard Joust Devlog #26 – Pistols At Dawn

So – with the AI now looking respectable it’s time to get the first basic weapon in there!

I should add that before doing this I did improve the AI a bit since the last post – instead of just charging ‘through’ the player when moving to a safe distance it now makes an attempt to fly over or under instead. This looks a lot better, particularly when going ‘face to face’ on the ground and between obstacles.

The most basic weapon, other than the jetboard jump, is the pistol (has to be). Implementing a simple pistol shot should be easy but it took me rather a long time as, as ever, I started obsessing over the details. I started with a simple two pixel square as the bullet (that’s all the room I have to play with really) but wasn’t very happy with it so began using a simple particle effect to create a type of trail instead. This looked much better but when the entire trail disappeared at the end of the bullet’s range it looked rather odd so I had to implement a way to have the trail carry on moving and disappear at the same place as the ‘main’ bullet. Doing this in an efficient manner (ie not by creating loads of separate sprite objects) was a bit of a pain in the arse – I also had to think about what would happen when the bullet collided with an obstacle too.

Got there in the end though – and added a simple particle effect for when the bullet disappears or explodes. When everything slotted together it looked quite satisfying – like fireworks.

I also added a bunch of generic parameters that will apply to every weapon and affect the speed at which a weapon can be fired – these are:

Whether the weapon auto-fires when FIRE is held.

Repeat Rate
The quickest speed at which a weapon can be fired in succession.

Clip Size
The amount of ammo that can be fired before the weapon needs reloading.

Reload Time
The time the weapon takes to reload (doh)!

I think that should give me enough configurations to play with – reloading will happen automatically if enough time is left between shots.

Once all this was sorted getting the enemy AI to fire was pretty straightforward as all the board/weapon code is the same for both player and enemies. At the moment it just pumps FIRE when within a certain range of the player so I need to add some kind of reaction time parameters but it’s pretty effective.

Maybe rather too effective – an unexpected accident was the way the enemy keeps pumping the player full of bullets even after they’re dead ‘just to make sure’. I actually think this is pretty funny so will probably leave it in there – makes the enemies seem ultra vindictive and evil!

I need to tweak this a bit and iron out some other bugs that are annoying me next – then it’ll be on to creating ‘cash’ pickups when enemies are destroyed.

Dev Time: 1.5 days
Total Dev Time: approx 29 days

previous | next

Improved AI To Circumnavigate Player More Effectively

Shock And Awe? The Final Bullet Anim

A Very Vindictive AI – I’ve Created A Monster!!

Pistols At Dawn – Proof That Violence Solves Nothing

Jetboard Joust Devlog #21 – HUD’s Up!

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

HUD Elements In Close Up

HUD in game (click for a closer look)

Getting A Roasting In Atic Atac

Gunfright – More HUD, Less Game

Dead Space – Nice HUD, Shame About The Gameplay

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

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

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

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

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

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

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

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

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

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

previous | next

Screen Division For Touchscreen Controls

Trying To Get A Smooth Tracking Camera

This No Longer Sends You Flying…

…Whereas This Still Does!

Jetboard Joust Devlog #6 – Die and Retry

Development on Jetboard Joust has suffered a bit of a hiatus since Christmas, mainly due to the fact that I’ve been spending far too long testing out alternative touchscreen control systems for ‘Attack of Giant Jumping Man’. I wrote about that (in probably far too much detail) here. Thankfully I’ll be reusing a bunch of that code in Jetboard Joust but more on that later.

Today’s main job has been completing the die/retry loop. I wanted this to feel like it was integrated into the gameplay rather than the sudden ‘cut’ you get on some games when everything just stops and you’re taken back to the start of a level. I think the world/enemy state will remain persistent between lives (if that doesn’t prove to be too much of a pain in the arse) so it’s important that the die/retry loop felt like a ‘long take tracking shot’ rather than some kind of full reboot.

So I settled on the idea of having the player fired out of a Mario-style pipe at the start of each life. This introduces the player to the world quite nicely and seems better than having them simply fall down from the top of the screen or just ‘be there’ which would have been the easiest options. There will be at least two of these pipes per level and I may also use them as a method of exiting the level (but again, more of that later).

When you fall off the jetboard the camera pans to the closest pipe that’s more than one screen width away from the player’s current position. This means I don’t have to make the player sprite ‘disappear’ somehow which I think would look pretty awkward – instead the ‘stunned’ player sprite is just scrolled offscreen.

I added a bit of recoil to the pipe as it shoots – it also wobbles a bit before firing but I couldn’t show that on the GIF due to Photoshop’s 500 frame limit on animated GIFs (there must be a better way of doing that but I haven’t figured it out yet).

As well as die/retry I’ve been fixing a bunch of bugs and quirks and improving some of the animations – such as adding a bit of compression whenever the character lands. I really need to animate that jetboard now!

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


The Die and Retry Loop – No Camera Edits Necessary

Adding Some Compression On Landing

Jetboard Joust Devlog #5 – Another One Bites The Dust

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


First Stab At Falling Animation

Dust Particles In Action

Three Ways To Fall Off A Jetboard #1

Three Ways To Fall Off A Jetboard #2

Three Ways To Fall Off A Jetboard #3

Recovering From A Fall

Jetboard Joust DevLog #3 – Jumping And Thrusting

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


Board Like An Egyptian?

Riding The Board Sprite Sheet

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

Jump To It!

Jetboard Joust DevLog #2 – Player Movement and Gameplay

Been working on the initial player movement for ‘Jetboard Joust‘ (my ‘Skateboard Joust‘ sequel) this week which, of course, also entails thinking about how the gameplay is going to work.

And the more I think about it the more I’m convinced that there’s enough ‘endless runners/jumpers/droppers/flappers/flyers/hoppers’ etc out there and I should really do something different.

So I fancy making the gameplay similar to, possibly the greatest arcade game of all time, Williams ‘Defender‘. A scrolling world that loops back on itself with a set number of enemies to destroy per level. It’s a format that doesn’t get much love nowadays but I have such strong memories of being huddled in awe around a ‘Defender‘ cabinet after going swimming on a Saturday as a kid that I think I should pay some kind of tribute to it.

Maybe the reason the format doesn’t see much action on mobile is that it requires a much greater degree of control than an ‘endless runner’. ‘Defender‘ had what seemed like a bewildering set of controls for an arcade game in it’s day. Of course, we’re all used to multi-button controllers nowadays but, as I wrote in a previous post, an iPad is most definitely NOT a gamepad so there’s no way I’m going to go down the fundamentally flawed ‘onscreen gamepad’ route.

For the mobile version I want to keep the controls as simple as possible and control everything via tapping either on the left or right of the screen. After running a few tests I think I can get this to work – tap on one side to thrust, tap and hold to reverse direction. Tap on the other side to fire (hold to repeat fire for weapons that support it).

This method means you’re almost always moving at a constant velocity left/right (unless turning) but in initial tests it seems to work OK and feel pretty intuitive. Much of the work is in getting the ‘bounce’ of the thrust action to feel right – more on that later…

Oh yeah – check out the parallax scrolling too! And I know the main character anims not working!

Dev Time: 2 days (including project setup)
Total Dev Time: approx 4.5 days


Don’t Remember Her At The Swimming Baths

First Stab At Player Movement And Parallax

I Could Never Last More Than About Two Minutes