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

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…

Comparing Floats within a range

So, today I needed to be able to check whether a float fell within a given range. At first I set about using a series of nested Compare objects but this was proving to be a headache getting everything in the right order and preventing ‘false triggers’.

After a while I thought, ‘why don’t I just script something that does this – how hard can it be?’ – turns out, not very.

So, here’s the code for a comparison object within Kismet that checks to see if value A falls within a range defined by value B and value C. 
The outputs are for whether value A falls within the range or outside of the defined range.

/**
 * Checks to see whether input value A is within range defined by values B & C
 */
class SeqCond_CompareFloatRange extends SequenceCondition;

var() float ValueA;
var() float ValueB;
var() float ValueC;

function Activated()
{
     // compare the values and set appropriate output impulse
     if (ValueA <= ValueC && ValueA >= ValueB)
     {
          OutputLinks[0].bHasImpulse = TRUE;
     }
     else
     {
          OutputLinks[1].bHasImpulse = TRUE;
     }
}

defaultproperties
{
     ObjName="Compare Float Range"
     ObjCategory="GATComparison"
     
     InputLinks(0)=(LinkDesc="In")
     OutputLinks(0)=(LinkDesc="In Range")
     OutputLinks(1)=(LinkDesc="Out of Range")
     VariableLinks(0)=(ExpectedType=class'SeqVar_Float',LinkDesc="A",PropertyName=ValueA)
     VariableLinks(1)=(ExpectedType=class'SeqVar_Float',LinkDesc="B",PropertyName=ValueB)
     VariableLinks(2)=(ExpectedType=class'SeqVar_Float',LinkDesc="C",PropertyName=ValueC)
}

Feel free to take and use as you see fit…

Target Marked 02

Today I finished off the prototype system for this little mini-game.
I came up with a little list of things I had to do to:
– cross-hairs for aiming
– confirmation beep for when the player aims at a target
– music bed (looping)
– air strike music (non-looping)
– Matinee sequence for air strike
– explosions, destroy buildings, etc…

I worked my way through the list in order of easiness!

I started off by implementing a confirmation beep for when the player aims at a target (when the glowing cube appears). This uses the result of the Object comparison – if there’s a match (ie. the Player is aiming at one of the designated targets) then playa beep sound. I had to use a Gate to prevent repeated triggers of the Play Sound object whilst the Player continues to aim at the same target. I also had to set up 3x separate systems, one for each target to prevent false triggers.

The next step was to create a weapon that would provide us with some cross-hairs so that the Player can more accurately aim at the target buildings.
I simply modified the existing Shock rifle weapon and removed all references to Skeletal Meshes and Anim Sets so that there is no actual weapon visible in the Player’s hands – this just left the cross-hairs. The scripts compiled OK, but there were some minor errors as a result of the missing references. The weapon would still fire, which looked quite odd as the projectiles just appeared in thin air – so I had to solve this next.
This was actually relatively simple, I just worked my way through the weapon’s code and commented out any line that instructed the game engine to play firing sounds and/or generate any firing animations/graphics/projectiles.

The next step was to be able to trigger off Kismet systems when the Player presses what used to be fire to initiate the air strike sequences. We did something similar in the Game Audio Tutorial for the sniper rifle weapon, so I used that as a reference and adapted the code to suit my purpose here.
The line “PlayerController(Instigator.Controller).ServerCauseEvent(‘TargetMarked’);” was inserted into the StartFire function so that when the Player ‘fires’ the aiming weapon, a Console Event named TargetMarked is triggered. This is received within Kismet using the Console Event object. In order to prevent false triggerings, a Gate is used between the Console Event and the Announcement / Matinee objects – the Gate is only opened when the Player is aiming at a designated target (otherwise they could call an airstrike on anything!). Separate Console Event objects and their associated Announcement / Matinee objects were needed for each of the targets.

For the music itself, some pre-existing tracks were used – nothing particularly fancy, but they serve a purpose – which was to enable me to quickly produce a prototype system.
The system that controls the music is relatively straightforward – a looping delay is used as a metronome and is set to generate a pulse on every beat at the tempo of the music bed. A Counter counts the number of beats and on the 8th beat (ie. 2x bars = length of music bed) it resets the count and re-triggers the music bed to produce a looping musical bed. When the Player targets a building (ie. aims and ‘fires’) 2x Gates are switched; the first prevents the music bed being re-triggered (this Gate was originall Open); the second Gate (which was originally Closed) is opened in order to allow the air strike music to be triggered. The next time the Counter reaches 8 (ie. the end of the current loop), the air strike music plays – This system ensures that the transition from music bed to air strike music always happens on a musical point.
At the same time, a Matinee (which controls a plane – well actually just a Manta vehicle!) is started which has been timed such that the plane reaches the targeted building just as the music climaxes. On the climax of the music some explosion Emitters are Toggled on, as is a RB_RadialImpulseActor which casues the building to ‘blow up’ (all the Actors that make up the target buildings are KActors and so respond to Physics), and an explosion sound is played.
When the explosion has finished, the music bed is faded back up and looped again.

The system has a number of switching Gates that prevent the Player from targetting buildings that have already been destroyed and also targetting buildings while the current air strike is still in progress.

The timing of the music ‘metronome’ and therefore the looping of the music bed is not 100% accurate (but when is it ever with UDK!) – the exact values of the system can be tweaked once the ‘proper’ music has been integrated rather than the temp music currently in use.

——————————————

Next Steps:
– Does it need a custom cross-hair image?
– Do I need to create ’empty’ Skeletal Maesh and Anim Set?
– ‘Proper’ music
– The system may need some tweaking when ‘proper’ music is out in – timings, etc…

Target Marked 01

This is another little system that we will be using as part of the AES Presentation.
The aim is to create a ‘mini-game’ where the player has to mark some targets for airstrike and the mechanics of which are timed to fit within musical bounds.

The first step was to knock up a quick environment for prototyping. I wanted the Player to on a hill and to have a number of targets (ie. buildings) in the environment.
I created some basic Terrain and then extruded one corner vertically to create a hill for the Player to stand on and look down on the game area.

I started off with a simple test system using the Trace object and a crate Static Mesh.
The Trace object within Kismet draws a straight line between 2 objects and determines whether that line is obstrcuted or not. We used the Trace object a few times within the Game Audio Tutorial – an example would be the rotating turret in room 406.
If you use the same object for the start and end points of the trace you can use the End Offset property to determine the length of the trace – ie. using the Player as the start and end point and applying an offset along the x axis of 1024 would produce a trace that started at the Player and drew a line 1024 units along the x axis.
If/when an object is ‘hit’ as part of the trace, the object passes the name of the ‘hit’ object, the distance from the start of the trace and the location of the ‘hit’ object.
The intention was to simply determine whether the Trace object could identify when the player is looking/aiming at the crate. I just attached the Obstructed output of the Trace object to a Log.

This little test kind of worked. In that the Trace was successful only if the Player were to stand in exactly the right location relative to the object and jump – that took some figuring out!
The Trace uses the x,y,z location of the player and appeared to eminate from the feet of the Player (hence the need to jump) – the main problem was that it didn’t take into account the direction of the Player’s view/aim.

I spent a little time searching the various forums and came across this very useful tutorial (http://utforums.epicgames.com/showthread.php?p=28104486) which positions a simple cube static mesh (it could be anything really) in exactly the same position and rotation as the Player and then attaches a DynamicTrigger to this cube with an offset in the x axis. The Player is the start of the Trace and the DynamicTrigger is the end. Ideally you’d just attach the DynamicTrigger directly to the Player, but the Attach to Actor object doesn’t extract the rotation of the Player very consistently, but it works fine for an InterpActor. The DynamicTrigger follows the movement of the Player’s view perfectly.
The Trace object determines whether any object falls between the Player and the DynamicTrigger.
The original tutorial did some quite clever stuff that was unncessary for these purposes and so the system has been simplified quite a bit and simply compares the name of the ‘hit’ object with the ‘known’ name of the crate and if they match (ie. the Player is looking at the crate) I unhid a glowing cube – this will be used in the final system to indicate that the Player is looking at a ‘target’.
The system is driven by a repeating Delay object so that the Trace object is continuously re-checking the trace between the Player and the DynamicTrigger.

After a brief testing period to ensure everything worked as it should I expanded the game to contain 5 small buildings, 3 of which are targets (identified with barrels/crates outside them). If the Player looks at one of the targets a glowing cube appears surrounding the target building. If the Player looks away from a target, the glowing cube disappears.

Next steps:
– Modify the sniper rifle weapon system from the Game Audio Tutorial – has a zoom-in aiming mode
— will need a new image for the cross-hair
– implement music system
— looping ambient bed
— ‘air strike’ music to accompany timed air strike Matinee sequence – both only triggered at musical points

Lego Blocks 02

After some quick experiments it turns out that using Matinees to ‘reset’ the blocks, as proposed in an earlier post, does not work as I’d hoped!

So, an alternative was required…

I decided to create a system that uses multiple copies of the blocks for each sub-sequence that is required, with only the current set of blocks being visible at any one time – I couldn’t figure out how to create a more elegant solution that enabled a single set of blocks to be formed into various structures, yet also respond to Physics when shot.
The first, prototype system started off with a set of blocks that were immediately affected by a [RB_RadialImpulseActor] Physics Actor which ‘pushes’ all the blocks outwards to form a pile.
When the Player presses E a sequence of [RB_RadialImpulseActor] Physics Actors are used to ‘pull’ the pile of blocks into a swirling mass of blocks.
These are then destroyed and the next set of blocks, pre-formed into a structure, is ‘unhidden’ – a series of particle emitters are used to mask the transition (eg. smoke, sparks, etc).
This worked fairly well – the movement of the blocks as a result of the various Physics Actors looked quite nice.
In order to prevent the 2nd set of blocks being affected by the Physics Actors their Movement property was set to PHYS_None.

As the different sets of blocks will be positioned in the same location this could make selecting/editing each set of blocks problematic.
To help with this I am using the Group feature of an object’s properties. You can define any Actor as belonging to a specific Group and then, using the Content Browser’s Group page, set each Group’s visibilty independently.

As the Physics of each subsequent set of blocks has been set to PHYS_None to prevent them being affected by the various Physic Actors, they now longer respond to being shot – so for the time being I’ve set up a system that uses key presses to trigger each stage of the system rather than a Take Damage event.
This is working OK, but may need to be resolved for the presentation…

After extending the system up to the point where it forms the ‘solid’ castle, I thought I’d found an odd behaviour!
The blocks appear to respond to Physics Actors inconsisently… When the Physics Actor is activated to break up the boat structure it seemed to be ‘pulling’ them in rather than ‘pushing’ them out. It turned out this behaviour was due to the previous ‘pulling’ Physics Actor not being toggled off and so it’s effect was still being applied to the boat structure.

One problem I did have was that even though the blocks/structures were hidden from the start they still ‘exist’ in terms of physics and so would get in the way of visible blocks as they fly around the area. I originally thought that this was due to the COLLIDE property being set to BlockAll – so I set all blocks to be COLLIDE_NoCollision and then used Modify Property Actions to set it back to BlockAll when I wanted them to respond to Physics. Now however, as soon as the blocks are set back to PHYS_RigidBody (so they will respond to Physics Actors) they just fall through the floor!
After a little investigation I found that it’s the Block Rigid Body property that prevents/causes this behaviour depending on whether it’s set to true/false – it’s also worth noting that setting to COLLIDE_NoCollision automatically sets the Block Rigid Body to false – it would seem that setting the COLLIDE property to BlockAll using a Modify Property Action doesn’t set it back to true. I tried to get around this using an additional Modify Property to set the Block Rigid Body but this did not seem to work.
Eventually I found the Set Rigid Body Action within Kismet – this must be a relatively new addition to UDK; I must have missed it…! Using this to set all the blocks to Block Rigid Body and then to PHYS_RigidBody meant that they behaved as they should.

Now I had the first stages of the planned system (albeit responding to key presses rather than being shot) – namely a set of blocks that immediately form a pile, which re-form into a castle strtucture, this then falls apart into a pile which re-forms into a boat structure. This falls apart and re-forms into a second castle structure.
The next step was to create the ‘solid’ castle…

I originally tried ‘attaching’ all the blocks in the structure to a ‘master’ block and then using Physics Actors in the thought that as all blocks are attached to one, they would follow the movement of the ‘master’ (one block to rule them all!). However, this didn’t work as they all just flew apart as they had done before.
The next attempt involved keeping the ‘attached’ system and using Matinee to animate the movement of the ‘master’ block – to do this the blocks had to be set to PHYS_Interpolating rather than RigidBody to enable the Matinee to control them. This works quite nicely, although the actual animation could be improved with a bit of effort – it looks a little simple at the moment.

Once I had all the behaviours I wanted I then needed to get the structure to break apart when shot rather than rely on a key press as this would look/feel better – the key press can still be used to re-form the structures.
This was actually relatively simple – the blocks just had to be set to COLLIDE_BlockAll. There were no problems with blocks interfering with earlier movements/systems as their Block Rigid Body property is set to false. I used the Attach to Event Action within Kismet to attach each block within a structure to a Take Damage event which simply replaced the original key press events.

I now have the system that was originally planned and everything seems to be working as intended, although the boat structure doesn’t appear to respond to being shot at every possible location (I’ve double-checked the properties and I can’t see anything!). It may be that this is not a major problem as the system is only for our use during a presentation.

Next steps:
– does it need sound?
– check with RS that he’s happy with it (and can’t put up with the boat’s behaviour)