Musical Shooter – Different Rhythms

In order to make the differences between the different firing rhythms and enemies more obvious I’ve changed the timings of the weapon and pulsing of the enemies. These are now at 1/4, 1/8 & 1/16 beats. This has helped with the feel of the game, but has highlighted a problem with the windowing system I was using to ensure the enemies dies on a musical interval.

Because the firing rates are now slower it can often take a long time for all the elements of the windowing system to align. This can make it feel like you’re having to shoot some enemies a lot more than others.
A possible solution to this would be to visually flag the enemy as dying as soon as the damage threshold has been reached (not quite sure how this would work yet…) and then ‘kill’ it on the interval.

I’ve also tweaked the appearance of the enemies slightly and things are looking a bit nicer.

Here’s a vid:

 

I cut the ‘action’ short as the windowing problem means the game can sometimes take a while to complete.

Advertisement

Musical Shooter – some more changes

I”ve been working on the mechanics of the game a bit more over the weekend.

I’ve set up different classes of the enemies, each with different colours, sizes and speeds. Each class responds to a different rhythm of shooting (which can be scrolled through using the right shoulder button of the gamepad). As the player changes firing rhythms, they change colour to match the mode – this corresponds to the colour of the enemies. In order to provide a bit info/FB to the player the enemies pulse in the tempo of the firing rhythm.

I’ve also setup the firing modes to deplete their ammo count (which is displayed in the top right of the screen). When each firing mode is out of ammo a pickup appears (coloured to match – obviously!) which returns the ammo for that mode back to full.

Here’s a video of how it looks now:

 

Now the mechanics are getting there I need to make it look a bit nicer and sort the sounds out. I also need to check how the game handles different gamepads.
I’ll also be trying to streamline the code to make it as effecient as possible and also to remedy the fact that as I’ve been tweaking things recently and adding new features I’ve been a bit slack in using ‘proper’ coding practices.

Musical Shooter – A Few Tweaks

As the various features within the game get put in, I’m finding myself playing it more and looking for minor tweaks that can be made. This post will describe a few of these that I’ve made recently as well as, more importantly, fixing the bullet removal issues I’ve been having.

Prior to this update, if I enabled the removal of bullets when the collide with an enemy then there it seemed the system was getting stuck at the point where the bullet was removed and if you kept firing in the same direction no bullet would get past the ‘removal location’, until the player moves. I spent a while scouring the code for references for the player location being used in the removal of the bullets, but there was none… It turns out I was just calling the remove function at the wrong point in the code! We now have ‘proper’ bullet behaviour.

I’ve also been playing around with some of the functions available in the Minim audio library I’m using to handle the playing of the sounds and music. I’ve implemented a basic low pass filter whose cutoff frequency is lowered when the player collides with an enemy and is suffering damage – the idea being that this will provide some audio feedback to the player. I didn’t want to use a sound effect as things are starting to get quite cluttered at times (audio-wise).

The final major tweak I’ve done, is to implement a ‘windowing’ system on the code that checks to see if the enemy has been destroyed. Prior to this, the code was working like this:
if(damage > 15 * dScale && frameCount % 16 == 0 && impactCheck == true)
So, the damage had to be above the threshold, and the frameCount had to be an exact beat, and there had to be an impact. The impact check was put in to ensure that the enemy wouldn’t destroy itself when you’re not actually shooting it as this felt a bit odd.
The problem is that the ‘perfect’ frame count and an impact don’t always align and so it could sometimes take a while to kill a specific enemy which again, didn’t feel right as you were playing.
The windowing code looks like this:
if(impactCheck && frameCount % 4 == 0 || frameCount % 4 == 1 || frameCount % 4 == 3) { if(damage > damageMax * dScale && frameCount % 16 == 0) {
The 2 if statements are nested so the first one is the window and checks the remainder of the modulo operation to see if the frame is 1 either side of the ‘perfect’ frame. If this is true, then the 2nd if statement checks for damage and an impact.
The new system has made the gameplay feel more like it should with enemies dying more reliably, although it’s not quite perfect and needs some more finessing.

I’ve also added in a sound for when the enemy takes damage. Rather than just triggering this sound for every damage instance, I’m checking to ensure that the damage sound only plays at a ‘musical point’. Again, this uses a similar windowing system as the enemy death system and so is not quite perfect yet…

Finally, I’ve implemented a basic game start and end system.

Anyways, here’s a video of how things are looking at this point:

 

Next steps = Creating some kind of scoring system; Looking into reading/writing to files to store the player’s results; Different weapon firing rhythms.

Musical Shooter – Better Aiming

I’ve made a few tweaks to the game so I thought I’d post up what I’ve done with a new video.

I’ve refined the aiming so that instead of moving the player sprite and the target independently and then calculating the angle between them, the aiming system now uses the 2nd stick to create an angle relative to the player sprite which is used as the trajectory for the bullet. Its now much easier to change the direction of shooting and also easier to play as the behaviour is easier to get your head round.
A by-product of this was that if you’re not actually aiming with the 2nd stick (ie. its position is central) the bullet system was producing static bullets with no trajectory/speed. So, the system now only fires when you’re aiming – this worked out quite well as its more obvious when the firing sound comes in and produces a bit more variation in the whole audio output.

I’ve also tried out a different effect to produce a trail that follows the player sprite around – essentially its a series of reducing circles produced by an array that uses the previous locations of the player sprite. Its a bit simpler than the particle system in use previously and I think it fits the overall general aesthetic of the game at this point a little better.

The final tweak is that the size of the enemy also determines how much damage it takes to destroy. The plan is to, at some point, produce different classes of enemies with different movement behaviours and maybe some that shoot back at the player…

I tried removing bullets when they impact with an enemy, but this caused a few problems with some of the collision systems so I’ve taken it back out for now.
I also added in a sound for when the enemy receives damage, but because (at the moment) bullets aren’t removed there was often too much damage going on and the playback of multiple damage samples simultaneously was causing clipping and other volume related problems. This is a shame as it sounds pretty good when it was working properly. Once the bullets issue has been sorted I’ll put the sounds back in again.

Here’s a video of things at this point:

Musical Shooter – Enemies Testing

I spent some time yesterday implementing a class of enemies so that I can spawn a number of them each with random sizes, start poistion, direction and speed. Once the basic behaviours were coded it was then a case of collision checking for:
– the edges of the screen so that they bounce back
– the bullets
– the player sprite

To check for collisions with the edge of the screen is pretty straightforward – you simply compare the enemy’s x,y location with either 0 or the width and height properties to see if they are outside of these bounds. If they are, just invert the velocity property which controls the direction of travel.

To check for bullets is a little trickier as you need to check every enemy against every bullet that is currently being generated. The bullets are created within an array so we can step through each element in the array and compare their respective locations to see if the distance between them falls below a defined threshold. If there is a collision, I’m drawing an ellipse over the enemy location to provide a visual indication to the player.
For every collision, the enemy’s damage variable is incremented and when it reaches a threshold the enemy can be destroyed and a sound is played- this is actually constrained to only occur on a musical interval:

if(damage > 25 && frameCount % 32 == 0 && impactCheck == true)

the impactCheck variable is being used so that the enemy is only destroyed if the player is actually shooting it as without this it felt a little odd.
When the enemy is destroyed the totalDead variable is incremented and when all the enemies have been destroyed, the game is finished.

To check for collisions with the player sprite is pretty straightforward, you just need to take the enemy diameter and player sprite diameter into account. If there is a collision, I’m drawing an ellipse over the player sprite to provide a visual indication.
If there is a collision, the playerHealth variable is reduced, this is used to determine the size of the ‘health’ bar in the top left of the screen – there’s nothing else going on yet, I was just seeing what it would look like.

Here’s a video of what I’ve got so far:

 

The next things on the list are:
– to destroy bullets on collision with an enemy
– to refine the aiming mechanism as its quite clumsy at the moment

Musical Shooter – Basic Audio Engine

I thought I’d stick the audio engine system in from the very first test just to get a feel for how things were coming along:

I’ve added a sample to the firing of the projectiles as well as the click and beat.

Obviously, this is just a quick test and the sounds will get better but I think its got potential.
Once some enemies are in I can play around with the timing of their sounds/actions…

Musical Shooter – Projectiles

A little post on setting up projectiles:

With a little help from this post on the Processing forum I’ve got a stream of projectiles which are aimed using the 2nd stick on the gamepad.

To start with I drew an ellipse using code that is similar to that used to move the player sprite around, but based on the movement of the 2nd stick – this was for a visual reference when aiming (let’s call it a target)

The system uses the PVector class to store the x,y location of the player sprite and the target and then does a bit of maths on these vectors to determine the angle and direction between the two.

On every 4th frame (which equates to 1/16beat) the system creates a series of bullets (simple ellipses) within an array and moves each of them along the path defined by the vector maths and a speed variable.

Here’s a video:

I may need to constrain the aim/target so that its closer to the centre of the player sprite at all times to modify how the aiming behaves to enable faster switching from side to side…

Now to create some enemies and collision systems…

Musical Shooter – GamePad Testing

A brief post on setting up gamepad input:

This was fairly easy once I got to grips with the procontroll library that comes bundled with Processing – this gives you access to the sticks and buttons on a gamepad (once you’ve used the getDevice() function to determine the name of your gamepad).
The values from the stick are normalised (ie. -1 to +1) in both directions so using them to move the player sprite around was simply a case of using the following code:

playerSpriteX = playerSpriteX + stick1.getY();
playerSpriteY = playerSpriteY + stick1.getX();

Yes, I know the I’m using the y axis to set the x movement (and vice versa) – for some reason the x and y axis on the left stick are the wrong way round…!

I’m just using a basic ellipse at the moment until I get things working and will then change it for something that looks a bit nicer.

I then took the DynamicParticlesImmediate example from within Processing, modified the code a little and added that so that the player sprite leaves a particle trail as it moves around.

Then it was just a case of constraining the position of the player sprite so that it can’t leave the screen and adjusting the speed of movement a little.

Here’s a little video showing what I’ve got so far:

The next step is to create the weapon projectiles…

Musical Shooter – Beat Testing

I thought it would make sense to test whether the Processing engine is capable of being reliable enough to act as a metronome and to be used to trigger sounds on specific beats.

I used a tempo of 150bpm as this meant that the various beat divisions would all fall on ‘nice’ time values :
eg. 1/4beat @ 150bpm = 400ms; 1/8beat = 200ms; 1/16beat = 100ms, etc…
This then transfers quite nicely into frame rates as a frame rate of 40fps (which should be achievable) works out as 1/64beat (eg. 25ms).

The test program counts the number of frames and every 16 frames (1/4beat = 16x 1/64beat) it triggers a click sample. At the same time it is counting the number of 1/4beats and after 2bars worth it (re)triggers a 2bar loop.
This would determine whether the timing was accurate and reliable as the click and the loop should (hopefully) stay in time.

It turns out that this little test was indeed successful and everything stays in time and sounds OK!!

The next step was to determine whether the system was still reliable whilst also having to do some graphical processing.
To do this, I used one of the examples provided with Processing (‘Bouncing Ball’) and modified the code slightly so that there were 700 balls all bouncing around the screen, each one continuously checking for collisions with all of the other balls and the boundary of the screen.

This worked as well!! (we could be on to something here…)
Whilst this is not exactly the most processor intensive task ever performed by a computer, it did demonstrate that for moderately basic applications (which is all my game is going to be) the system is reliable enough.

I’ve created a brief video that demonstrates the system so far, although I’ve reduced the number of balls to only 50 as it just looks better and you can see the individual collisions more clearly.
At the moment there is no ‘player’ interaction or anything, but as the balls bounce around, it does feel like they are aligned with the musical pulse.

Now that I know the idea is worth pursuing, its time to start working on ‘playable’ elements such as the being able to move a sprite around using a gamepad, weapon projectiles, enemies, collisions, etc…

Update

OK, so I’ve been a bit slack in posting anything for the past month as I’ve been busy with work. But I’ve managed to carve out some free time and have started a little project in Processing which will keep me pretty busy for a while and should lead to some mor regular posts.

The idea is to create a top-down space shooter in the style of Asteroids / Geometry Wars, with the aim of aligning as many of the ingame events / actions to the music.
Essentially this is a follow on from some the work I was doing in UDK to try and create a stable metronome system – turns out this isn’t possible without ‘Developer Access’ to the underlying source code.

Hopefully I’ll be posting reasonably regularly as I try out ideas and work on this…