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 ( 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)

Lego Blocks 01

Today I started a new project – the vehicle jump is working and will do for now…

The new project is to create a little system that uses lego bricks to illustrate the difference between using pre-rendered tracks of audio vs using individual samples and the increase in variety that comes as a result. This will be used as part of a conference presentation for the upcoming AES Conference (

Essentially there will be a pile of lego bricks that form into various structures and can be shot to fall apart (or not depending on the metaphor).
– Pile of blocks
– Press E
– Turns into a castle
– Shoot castle
– Falls apart into pile of blocks
– Press E
– Turns into a boat (or other structure)
– Shoot boat
– Falls apart into pile of blocks
– Press E
– Turns into a ‘solid’ castle
– Shoot castle
– Castle falls over / wobbles but doesn’t break

In case you hadn’t figured it out, the structures that fall apart represent the use of samples as they can be re-arranged into different configurations, while the ‘solid’ castle represents the use of pre-rendered tracks as they are fixed in a single configuration.

Now, for what is only a brief illustration as part of a larger presentation, this project represents a significant amount of work as the actual system that controls the Actors is likely to be rather complex when using Kismet – it’s not really designed for this level of control. The ideal would be to create the system using scripts created for this specific implementation. However, as previously stated my intention is always to use as little “extension-ality” (if such a word exists…) – the main reason being here that I don’t really have the time to figure out how to do that at this point and I reckon I can get Kismet to ‘fake’ such a system even if it’s not the most elegant solution!

We got our excellent asset designer Chris ( to create some lego block Static Meshes which look good and I set to…

I created a test environment (just a simple room) and imported one of the blocks as a KActor (so that it would respond to Physics and so can be ‘shot’) and built a small structure.
Without any further setting of properties this worked exactly as desired – and looked pretty cool too!

Great. But then came the problem of how to get them to reform back into a castle structure from a pile…??

The first route was to try and create a Matinee sequence that started with the blocks in the desired structure position. I found this when I was creating something else and had set up a Matinee which had some Actors situated in a different location to where they were actually positioned – don’t ask, I thought I’d copied and pasted them. It was late!). Anyway, my idea was to use this to move the blocks from a pile (actual location) to defined structure (Matinee position).
To do this required all the blocks properties to be set so their Movement = PHYS_Interpolating.
Only one problem, this now meant that the blocks don’t respond to being or shot (or any other physics), as this requires the same property to be set to PHYS_RigidBody.

It was obvious that to get both behaviours (respond to physics and be ‘movable’) would mean changing the PHYS property – this can be done using the Set Physics action within Kismet.
For some reason at this point I made the decision to stop using the Matinee method and try and set the location of the Actors explicitly using x,y,z coordinates – the thinking being that I’m sure the Matinee uses a ‘relative movement’ approach to the location of Actors and this might cause problems when the prototype system is combined with the larger level being used for the AES presentation.
– I don’t have any real evidence for this notion, it seems to make sense given my experience of using Matinees and so I thought I’d try and preempt any potential problems…

I produced a system that started withe the blocks arranged in a structure, set to PHYS_RigidBody, and obtained their location and rotation using the Get Location and Rotation action (triggered on Level Start). The blocks respond to being shot and fall into a pile. When the Player presses E a Set Physics action is triggered to switch the blocks to PHYS_Interpolating, followed by a Set Actor Location which uses the original location and location vectors.
The image below shows a Kismet sequence that should help to illustrate what I mean (there’s one of these for each block)
This works quite nicely – when the original structure is shot it falls into a pile and then when the Player presses E the blocks jump to their original location (Ideally I wanted a nice animation to the movement, but that can wait!).
Because each the ‘block reset’ sequences are chained sequentially the blocks move one after the other (very quickly mind) and the effect is quite good – it’s almost like a stop-frame animation…
Occasionally there are little glitches where some of the blocks don’t return to their original positions and just hang in mid-air! It looks pretty cool actually, but will need to be resolved.

Next steps:
– Investigate whether Matinees can be used to ‘reset’ blocks instead of getting and setting Actor locations (will need to test for ‘relative movement’ and see if it’s a problem).
— Would produce easier to manage Kismet sequences as a single Matinee may be able to control multiple Actors(??)
— Can setup multiple Matinee sequences for each structure and just switch between them in the desired order
— May prevent glitches…
— Could maybe cheat and just create a Matinee sequence that animates the behaviour of the ‘solid’ castle (wobbling / falling)
— Would this need to be a different movement if the player moves round the structure before shooting?
—- if only for the presentation, may not be an issue – just don’t move!
— Can use the same method of switching PHYS mode between RigidBody and Interpolating as required
— Will the blocks stay in position when switched back to PHSY_RigidBody or will they fall?

Vehicle Jump 04

Today’s aim was to determine whether using vector coordinates to determine the vehicle’s progress down the slope would be more effective than the current system.

So the vector coordinates were broken down into x, y, z and checked to see which one described the vehicle’s motion down the slope towards the jump – turns out it was x (well it was going to be that or y).
The x value was evaluated against the x for the Note and scaled into a factor (0-1). This was plugged into the system in place of the previous method.

It appeared to work well at first but when tested with a straight run the vehicle wasn’t reaching the jump in time!

After some investigation (and much head scratching!) I’ve put it down to timing inconsistencies as a result of using a looping delay rather than a more ‘code-based’ approach – such as using CPU ticks. I’ve also moved over to the March release of UDK, but I don’t think that will have affected the timing (but you never know…!).
– the reason for avoiding the ‘code-based’ approach is that I want to achieve as much as is possible using vanilla objects (or at least easily adaptable versions, such as vehicles) so that it is accesible to as many people as possible.

I had to set the time value that represents the length of the music track to a value around 29.0 (the music is actually 32.2secs) in order to compensate for the timing issues.
– if this system were to be implemented into a game system it should be possible (with the help of a friendly programmer) to set up a much more accurate timing system — I might look into this at some point when I have the time…

I’ve also tweaked the MaxSpeed value used to increase the vehicle’s speed to improve consistency as a result of testing a variety of winding routes down the slope.

At the moment it appears to be working fairly well (although still some room for a few more tweaks, I think…).

Next steps:
– Extensive testing to check reliability – also get others to test to check I’m not ‘cheating.
– More tweaking of vehicle variables to increase stability – likely something to do with steering angles
– Make it look nice! (or at least better than it does now)
– Might be worth investigating what happens if the angle of the slope is not constant – would make for a more interesting run.

Vehicle Jump 03

So, I started off today by creating a custom [Modify Property] object in an attempt to be able to modify the MaxSpeed property of the vehicle – the idea being to be able to pass a variable into the object (something the vanilla [Modify Property] object can’t do).
There’s me thinking I’m all clever, but it turns out it doesn’t work as the vehicle (Actor) doesn’t have a “handler” for my “GAT_ModifyProperty” class – this would make sense when you think about it – all Actors recognise the “ModifyProperty” function thanks to the inheritance hierarchy, but obviously the Epic developers didn’t know I’d be creating my own version and so didn’t build that into the functionality of their classes!

Rather than rebuild the entire vehicle hierarchy to include this functionality – that would be quite a bit of work – I implemented a simpler Kismet system using [Modify Property] objects with defined values for the MaxSpeed property to see if it worked as I hoped.
The system evaluates the speed scaling factor (defined in a previous post):
– if sf > 1.0 then apply a MaxSpeed of 3500
– if sf == 1.0 then apply a MaxSpeed of 2750
– if sf < 1.0 then apply a MaxSpeed of 2500

The hope being that if the vehicle is falling behind the pace needed to ‘keep up’ with the music then the sf will produce a value > 1.0 , this will then cause the MaxSpeed to be increased which will allow the vehicle to accelerate (thanks to the adjusted TorqueVSpeedCurve parameter) in an attempt to catch back up with the music. Once it’s there the MaxSpeed will be reset back to 2750, or maybe even the lower speed of 2500 if it’s overshot the music’s progress.

Turns out this works quite nicely!
Because the vehicles progress is being evaluated fairly frequently (every 0.1secs) the changes in speed are not really obvious (although there is room for some minor tweaking…).

Turning the vehicle slows it down quite a bit so if the player does an excessive amount of veering around obstacles the vehicle can’t get up enough speed to keep pace with the music.
So, the ThrottleSpeed parameter was adjusted to enable the vehicle to accelerate back up to full speed quicker after a forced slow down – this also had the added side benefit of enabling the vehicle to accelerate beyond 2750 a little faster when the MaxSpeed is increased.

I’ve also added a [TriggerVolume] after the jump so that when the vehicle lands a musical stinger is player which works nicely.

The system is working well and is ensuring that in all but ‘extreme’ cases (see below) the vehicle always reaches the jump at the correct musical point.

Next steps:
– The vehicle is still a little twitchy when veering round obstacles at speed – need to investigate the effects of various parameters within the vehicle class.
– When the vehicle hits the jump it bottoms out which produces a fairly loud impact sound – look into tweaking the suspension settings and/or ride height.
– Occasionally when restricting the MaxSpeed to a lower value than the current speed the vehicle can jerk a little – have a look at creating a ‘stepped’ system that uses chained [Modify Property] objects to gradually decrease the speed.
– If the player hugs the side of the test environment (‘extreme’ case) the system does not quite produce the desired effect. The reason for this is that the system evaluates the distance between the vehicle and a [Note] placed in the centre of the jump. This means that even when the vehicle is on the ramp, the system determines it to be a reasonable distance and so increases the vehicle speed unnecessarily. The image below attempts to illustrate the problem (the X represents the [Note]).
The solution (hopefully) may be to use x,y,z vectors but only compare either the x or y (which ever describes the movement down the slope) – this should produce a consistent result no matter where the vehicle is across the slope.
– If the player releases the throttle (ie. they bottle it – the wimp!) then the vehicle very quickly comes to a stop and so therefore would require an excessive speed increase to catch back up with the music – look into setting up ‘auto-throttle’ when on the slope, and/or adjust the parameter(s) that determine how the vehicle slows down.

Vehicle Jump 02

Today I added numerous obstacles to the test environment – no imagination, they’re all the same: just a load of rocks!

As a result of the obstacles I discovered that by default the Scorpion vehicle is a real pig to steer when traveling at speed and so spent a lot of time crashing into rocks. Time to tweak the vehicle!
I found this page on the Epic Developers site very useful:
It contains definitions/descriptions of the key parameters and functions within the extensive hierarchy of vehicle classes – it also, rather handily, breaks down the inheritance aspects of the classes so you know where to find the functions you’re looking for.

A tip for when you’re tweaking a vehicle (or any other relatively complex class for that matter): where possible, do it one parameter at a time. Otherwise it gets very difficult as it can be hard to work out which parameter is having what effect on the system. It can also be tricky remembering the original state of multiple values for when you find that the 4 variables you’ve just changed have had a seriously negative effect on the system and you need to reset them!

I spent quite a long time tweaking various variables and have now got a vehicle which is relatively responsive when driving at speed (or at least in comparison to the original Scorpion), but also one that doesn’t flip over and/or start spinning in circles when you try to turn.
I found that these variables (all within the UTVehicle_Scorpion.uc class) proved the most useful in achieving this aim:
– MaxSteeringAngleCurve
– SteeringReductionFactor
– SteeringReductionMinSpeed
– SteeringReductionSpeed
– SpeedBasedTurnDamping

Once I had a drivable vehicle the next step was to figure out how to scale the speed of the vehicle to ensure it arrived at the end of the slope at the correct musical point. To do this I needed to know the current time position of the music and the current position of the vehicle as it travels down the slope. These values would then enable me to produce a scaling factor which could be applied to the MaxSpeed property of the vehicle to enable it to accelerate if the player deviates from the most direct route down the slope.

After a bit of head scratching I came up with the following system:
current time position / length of music (31.2secs) = amount of time left as a factor (ie. 0-1)
distance travelled down slope / length of slope (90700 units) = distance left to travel as a factor (ie. 0-1)

These 2 factors could then be ‘compared’ to produce a new factor which would be the scaling factor to be applied to the MaxSpeed property:
distance factor / time factor = speed scaling factor (ie. 0-1)

I then came across a bit of a stumbling block – namely that the [Modify Property] Action within Kismet doesn’t allow for the passing of values into it – I could have sworn that it did! Previously I’ve been using fixed values entered directly into the properties field of the object.
If this is correct, then I will have to come up with another cunning solution which may involve the scripting of a custom modify property object…
Unfortunately I did not have time today to investigate this further and so it will have to wait for another time.

Next steps:
– Investigate [Modify Property] and/or alternatives
– Experiment with different acceleration values to ensure the speed changes subtly

Things to think about:
– Modify health of vehicle so that if it crashes into an obstacle it explodes and so level needs to be restarted. This will save on creating complex switching mechanisms for resetting. Also a crash significantly impairs progress and so a significant speed boost would be required to ‘catch back up’ again. I’ve tried lowering the health to 30 (original =300), but then when the vehicle hits the jump it inflicts too much damage and it explodes. Investigate suspension settings / ride height to see if this can be prevented. The alternative may be to put DamageVolumes round all obstacles, but this would be a real pain!

Vehicle Jump 01

I’ve started a new little project which involves the manipulation of game states based on the musical soundtrack.

The idea is that you are driving a vehicle down a hill towards a jump over some obstacle, the sequence has been timed and a piece of music composed so that if the player takes the direct, straight route they will arrive at the jump at the correct point in the music (ie. a dramatic pause). However, there will be a number of obstacles en route which will cause the player to deviate from the most direct route – therefore arriving too late for the music to be in sync with the action.
The intention is to vary the speed of the vehicle to ensure that the player reaches the jump at the correct point, musically speaking.

The aim is that this should be done in such a way so that the player doesn’t realise that the mechanics of the game are being manipulated.

Currently I have a very basic prototype/testing environment which consists of a flat starting section to enable the vehicle to get up to speed, a transition to a sloped sequence, a  little ramp at the bottom of the slope and a final flat section to land on.

As the vehicle transitions onto the slope a [TrigggrVolume] starts the music which has been composed to last the time it takes to reach the bottom. I have created my own version of the Scorpion vehicle and adjusted the speed slightly to fine-tune the timing of the mechanics.
This process took quite a bit of trial and error to get things aligned correctly…

In anticipation of the need to to be able to increase the speed of the vehicle whilst it’s driving (without player input) I experimented with adjusting the various speed related properties using the [Modify Property] Action within Kismet
– MaxSpeed
– GroundSpeed
– AirSpeed
Whilst these would change I didn’t notice any appreciable change in the vehicle’s speed. So, I tried using the [Set Velocity] Action to see if that had any affect; I used the [Get Velocity] Action to determine what speed the vehicle was travelling at. This kind of worked, but was quite clunky – the vehicle would jerk when the velocity suddenly changed to new value – so that wasn’t going to work either!

After a bit of experimenting and reading of various posts on the forums it transpired that the “TorqueVSpeedCurve” within the vehicle’s script determines how the vehicle accelerates at different speeds. It turned out that the existing Scorpion vehicle (and therefore mine) was set so that when it reached a speed of 2000 it’s acceleration would be set to 0 – essentially meaning that no matter what the Speed properties were set to the vehicle would never exceed a speed 0f 2000.
So, I adjusted the Curve parameters so that the theoretical max speed was in excess of the current cap applied by the MaxSpeed/GroundSpeed/etc properties.
Now I can use the [Modify Property] Action to set the Max Speed to a higher value and the car will accelerate up to that new speed.

Next steps:
– Create obstacles within environment
– Determine calculations to analyse the distance from jump and to therefore scale max speed accordingly
– Fine tune the handling of the vehicle to make it more responsive to dodge obstacles, but also more stable – it has a habit of rolling over at speed at the moment
– Experiment with different acceleration values to ensure the speed changes subtly