Portobelly Production Journal #35

08/03/2019

During the playtest at the Games Hub (more information at the playtest can be found here), the majority of the feedback was about not having control over Belly’s movement and that was due to the player not being able to jump when Belly was bouncing.

Fig 1 - Belly chaining together multiple jumps, overriding the bounce

To allow players to override the bounce but also the retain the bounciness of Belly’s movement I had to create a system that would allow Belly to perform a jump as soon as Belly makes contact with the ground.

Fig 2 - Initial attempt at overriding the bounce by launching the player

My first attempt involved launching Belly on impact with the ground while the jump button is pressed. While this method worked it didn’t take into account jump hold time which allows the player to jump at different heights depending on how long the jump button has been held down. I had to find a different way of achieving the jump.

Fig 3 - Final jump override system using line traces

When looking at for a solution I discovered that there’s a variable within the character blueprint that allows the character to perform multiple jumps without touching the ground. Using this knowledge I created a line trace coming from the bottom of the of the player. If the line trace coming from the player is block, meaning the player is on/near the ground, the amount of jumps on the player is increased. If the player is not touching the ground the amount of jumps is set to to 1 so that the player can’t double jump in the air. This sequence is connected to the sound effect for the landing so that Belly sounds like it’s hitting the ground.

 

Figures List

  1. Rees, O (2019). Belly chaining together multiple jumps, overriding the bounce. [offline]. [Accessed 11/03/2019].

  2. Rees, O (2019). Initial attempt at overriding the bounce by launching the player. [offline]. [Accessed 11/03/2019].

  3. Rees, O (2019). Final jump override system using line traces. [offline]. [Accessed 11/03/2019].

Portobelly Production Journal #34

07/03/2019

Today I wanted to finish the basic AI states of the spiral spore.

Fig 1 - Spiral spore performing all of it’s states

Above shows the spiral spore going through all of the AI states. These states are the jump, glide, spin attack and dazed. At the moment the spin attack is just the spiral spore moving towards the player as it doesn’t have any animation attached to it so it’s hard to tell what the enemy is doing. The dazed effect activates when the player has used a spin attack since I thought it would be a good idea for the character to get dizzy after spinning. This would give the player an opportunity to attack the spiral spore.

Fig 2 - Spiral spore behaviour tree

Fig 3 - Choose attack or continue with jump blueprint task

Before the jump task is activated I decided to add a check that would see if the spiral spore is close enough to the player to attack. If the spiral spore was close enough to the player, the spiral spore’s state would change to the spin state. If the spiral spore was out of range it would execute this check task and continue to jump towards the player.

Fig 4 - Spin attack blueprint task

The spin task works similarly to the retreat task except it walks towards the player instead of running in the opposite direction to the player. The spin state is when the spiral spore will be doing damage to the player if they make contact with the player.

Fig 5 - Temporary dazed particle effect

The particle effect above is a couple of cubes arranged in a circle at different rotations which I turned into a static mesh. This static mesh is put into a particle system and rotated at a constant speed.

Fig 6 - Dazed blueprint task

Fig 7 - Particle activation custom events within the spiral spore character

The dazed particle is activated when the spiral spore has stopped it’s spin attack. After a set amount of time the dazed particle effect is deactivated and the spiral spore returns to it’s jump state.

 

Figures List

  1. Rees, O (2019). Spiral spore performing all of it’s states. [offline]. [Accessed 08/03/2019].

  2. Rees, O (2019). Spiral spore behaviour tree. [offline]. [Accessed 08/03/2019].

  3. Rees, O (2019). Choose attack or continue with jump blueprint task. [offline]. [Accessed 08/03/2019].

  4. Rees, O (2019). Spin attack blueprint task. [offline]. [Accessed 08/03/2019].

  5. Rees, O (2019). Temporary dazed particle effect. [offline]. [Accessed 08/03/2019].

  6. Rees, O (2019). Dazed blueprint task. [offline]. [Accessed 08/03/2019].

  7. Rees, O (2019). Particle activation custom events within the spiral spore character. [offline]. [Accessed 08/03/2019].

Portobelly Production Journal #33

06/03/2019

Today I wanted to focus on the AI implementation for the spiral spore.

Fig 1 - Initial glide attempt for the spiral spore

Fig 2 - Spiral spore behaviour tree

This behaviour tree works similarly to the previous enemy behaviours trees in the fact that they use two different enumerations, one for the inactive states and one for the active states. The service at the top of the behaviour tree checks if the spiral spore should be activated or not. I will probably change this service so that it only activates once so that once the spiral spore has been triggered it will stay active even if the player moves away from the enemy.

Fig 3 - Glide blueprint task

Fig 4 - Spiral spore character blueprint

Getting the glide to work as I intended caused me a lot of issue because Unreal doesn’t not support AI navigation while the player is flying or falling. To combat this I had to take a different approach to how the character will move. I used a projectile node to launch the enemy at the player with a reduced velocity. I also reduced the gravity scale when the enemy reaches the apex of the jump. To notify the apex of the jump I had to bind a custom event to the apex of the jump within the character blueprint. The character blueprint controls the active states of the spiral spore much like the systems used with the other enemies.

Fig 5 - Landing sound cue setup

Since the sound designer on the team had created some landing/bounce sound effects I decided to implement them into the game to add some more “game feel“ to Belly’s movement. When setting up the sound cue for the I used a randomise node so that I could input several sound effects at random so that the player won’t receive the same sound effect often. Doing this will add some variety to the landing sound effect and prevent it form becoming repetitive.

Fig 6 - Bounce sound blueprint attached to OnLanded event

I wanted the sound effect to be played at a different pitch depending on the size of Belly. For example, when the player is small a higher pitch sound will be played than if the player was larger.

 

Figures List

  1. Rees, O (2019). Initial glide attempt for the spiral spore. [offline]. [Accessed 07/03/2019].

  2. Rees, O (2019). Spiral spore behaviour tree. [offline]. [Accessed 07/03/2019].

  3. Rees, O (2019). Glide blueprint task. [offline]. [Accessed 07/03/2019].

  4. Rees, O (2019). Spiral spore character blueprint. [offline]. [Accessed 07/03/2019].

  5. Rees, O (2019). Landing sound cue setup. [offline]. [Accessed 07/03/2019].

  6. Rees, O (2019). Bounce sound blueprint attached to OnLanded event. [offline]. [Accessed 07/03/2019].

Portobelly Production Journal #32

05/03/2019

Fig 1 - Spiral spore before painting skin weights

Fig 2 - Spiral spore after painting skin weights

Paint the skin weights for this character was probably the most time consuming of all the characters due to the high amount of separate joints. When I was painting the skin weights I used either 0 influence represented by the black area or 1 influence represented by the white area.

Fig 3 - Rotating multiple joints at once

When animating the tendrils of the spiral spore I wanted to rotate all of the joints in the tendrils at once so that they curved together. Doing this made animating the tendrils much quicker than rotating the joints individually and I feel it gives a better effect than animating the joints separately. I tried adding constraints to the tendrils so that I could easily select all the joints within the tendrils quickly however I did not find out how to do this so I resorted to manually selecting each joint in the tendril.

Fig 4 - Spiral spore idle animation work in progress

Fig 5 - Spiral spore idle animation

When creating the idle animation for the spiral spore I wanted the tendrils feel like they are moving freely as if they are being effected by physics. To create this feel I tried to make the tendrils move with the momentum of the caps movement.

Fig 6 - Spiral spore written feedback

Fig 7 - Spiral spore feedback pic 1

Fig 8 - Spiral spore feedback pic 2

Fig 9 - Spiral spore feedback pic 3

This feedback is really useful as it explains in detail how I can improve my animation and I will definitely be incorporating it into my animation once I have finished the AI of the spiral spore. I agree with the points made about the swaying of the tendrils as I had trouble trying to sync the swaying of the tendrils with the movement of the cap.

 

Figures List

  1. Rees, O (2019). Spiral spore before painting skin weights. [offline]. [Accessed 06/03/2019].

  2. Rees, O (2019). Spiral spore after painting skin weights. [offline]. [Accessed 06/03/2019].

  3. Rees, O (2019). Rotating multiple joints at once. [offline]. [Accessed 06/03/2019].

  4. Rees, O (2019). Spiral spore idle animation work in progress. [offline]. [Accessed 06/03/2019].

  5. Rees, O (2019). Spiral spore idle animation. [offline]. [Accessed 06/03/2019].

  6. Stokes, S (2019). Spiral spore written feedback. [offline]. [Accessed 06/03/2019].

  7. Stokes, S (2019). Spiral spore feedback pic 1. [offline]. [Accessed 06/03/2019].

  8. Stokes, S (2019). Spiral spore feedback pic 2. [offline]. [Accessed 06/03/2019].

  9. Stokes, S (2019). Spiral spore feedback pic 3. [offline]. [Accessed 06/03/2019].

Portobelly Production Journal #31

04/03/2019

Last week I set myself the goal of refining Belly so that he was ready for the presenting at the Bristol Games Hub. Although I was unable to fix all the issues with Belly, I managed to sort out the roll animation for Belly. During the playtest we received some really useful feedback which we can apply to the future development of the game.

This week I plan to have finished all of the AI behaviours so that I can begin to block out the end section of the game. Once we have the initial overview of the level we can work out the pacing of the level and begin to refine the level design. The last enemy that needs work is the spiral spore that may be the most challenging enemy to develop due to it’s complicated movement method.

Fig 1 - 04 03 2019 chat

Fig 2 - Creating “floaty” jump for the spiral spore

Fig 3 - Floaty jump when falling blueprint test

One of the planned requirements for the spiral spore was to create movement that felt “floaty“ during the jump and glide movement states. To achieve this feel I reduced the gravity scale of the spiral spore when the character is falling. Although this solution works, it doesn’t give my intended effect because it reduces the launch velocity due to the falling state being active as soon as the player leaves the ground rather than activating the falling when the player is moving towards the ground.

Fig 4 - Separate tendril connectors for the front and back of the head

Fig 5 - Completed rig with the tendrils

Fig 6 - Rig naming conventions

When creating the rig for the spiral spore I decided to split the cap into two halves, the front and the back so that the groups of tendrils can be moved together. This allows me to animate the cap easily if that is needed.

 

Figures List

  1. Rees, O (2019). 04 03 2019. YouTube [video] 04 March. Available from: https://www.youtube.com/watch?v=vY_uep23p3k&feature=youtu.be [Accessed 06/03/2019].

  2. Rees, O (2019). Creating “floaty” jump for the spiral spore. [offline]. [Accessed 06/03/2019].

  3. Rees, O (2019). Floaty jump when falling blueprint test. [offline]. [Accessed 06/03/2019].

  4. Rees, O (2019). Separate tendril connectors for the front and back of the head. [offline]. [Accessed 06/03/2019].

  5. Rees, O (2019). Completed rig with the tendrils. [offline]. [Accessed 06/03/2019].

  6. Rees, O (2019). Rig naming conventions. [offline]. [Accessed 06/03/2019].

Portobelly Production Journal #30

28/02/2019

Today I spent the majority of the day building versions of the project ready for play testing at the Bristol Games Hub Anti-Social event. This event served as a good opportunity to display Portobelly as there were many game developers at the the event ranging from hobbyists to those within the games industry. This opportunity was far more valuable than playtesting to those in our class because those at the Games Hub had never played our game.

Fig 1 - 28 02 2019 Games hub playtest

Points raised during the playtest at the Bristol Games Hub:

  • When Belly is bouncing allow the player to override the bounce with a jump to give the player more control over the character.

  • Add squash and stretch to Belly.

  • Add more movement based mechanics, weight play (getting heavier when you get larger).

  • Make sure you can’t kill the mushroom (the villager mushroom you have to follow at the end of the build).

  • Hold the players hand a bit more when introducing new mechanics (like the slam).

  • The waterfall section could include an example of the waterfall in non challenging environment to teach the player the mechanic.

  • Combine character abilities into the same button mapping so the player uses less buttons.

I feel the most important piece of feedback from these points is the first one about overriding the bounce as it effects gameplay and it was bought up the most during the playtest. I plan to implement this feature as soon as possible since it was causing a lot of players problems.

A lot of the other pieces of feedback can be completed during the polishing stage of development as they are only minor changes that would enhance the feel or level layout of the game.

 

Figures List

  1. Rees, O (2019). 28 02 2019 Games hub playtest. YouTube [video] 04 March. Available from: https://www.youtube.com/watch?v=9ybJvUNsx_c&feature=youtu.be [Accessed 04/03/2019].

Portobelly Production Journal #29

27/02/2019

Today I focused on the AI for the villager mushroom. This AI will be used when the mushroom runs and jumps away from the player.

Fig 1 - Villager running away from Belly

Fig 2 - Villager runaway behaviour tree

Fig 3 - Construction script allow the user to change the size of the trigger sphere

The sphere radius activates the mushrooms retreat action when the player enters the radius. This sphere radius can be changed from the editor which allows the user to adjust the distance the player has to be from the mushroom in order to activate the retreat state.

Fig 4 - Changes to the villagers acceleration

I wanted to make the mushroom run faster than the player so that Belly was unable to catch up with mushroom. I decreased the acceleration of the mushroom so that the villager would gradually run away from the player rather than reaching full speed instantly.

Fig 5 - Villager walking into a jump volume

When the mushroom villager overlaps with the jump volume the villager is forced to jump. The jump volume allows the user to choose an end point for the villager to jump. The villager is launched in an arc from the start point (the initial overlap point) to the desired end point.

Fig 6 - Villager run and jump behaviour tree

Fig 7 - Villager unable to jump across the gorge due to navigation mesh constraints

Due to the limitations of the navigation mesh, the villager was unable to jump over the gap. I managed to solve this by increasing the size of the navigation mesh.

Fig 8 - Villager jump task

Fig 9 - Villager successfully jumping across the bounce pads

Fig 10 - Bounce dampening puddle with adjustable size controls

The puddle volume decreases the bounce height of the player. We needed to implement this puddle after the jump down the cave so that the player did not perform an extremely high bounce. This puddle can be used in over areas where the player jumps from a high height.

I created a vector variable that is exposed within the editor on the puddle volume so that the user can customise the size of the puddle easily. When designing levels, this should make implementing these volumes easy to adjust.

Fig 11 - Puddle viewport

Fig 12 - Scaling the box using the construction script

Fig 13 - Overlap events for the puddle

When creating the logic for the puddle, rather than doing the logic within the character blueprint I wanted to contain the functionality within the puddle blueprint. When the player overlaps with the puddle volume the bounce dampening is applied and when the player leaves the volume the bounce dampening is reset.

Fig 14 - Belly jumping in the bounce dampening puddle

Fig 15 - Belly at full size is unable to get through the cave

When play testing the game I discovered that Belly was unable to get through the cave entrance at full size. I only recently discovered this as when testing the level I spend most of my time at Belly’s smallest size due to the speed increase at the smallest size. This issue was fixed fairly quickly after it’s discovery.

 

Figures List

  1. Rees, O (2019). Villager running away from Belly. [offline]. [Accessed 04/03/2019].

  2. Rees, O (2019). Villager runaway behaviour tree. [offline]. [Accessed 04/03/2019].

  3. Rees, O (2019). Construction script allow the user to change the size of the trigger sphere. [offline]. [Accessed 04/03/2019].

  4. Rees, O (2019). Changes to the villagers acceleration. [offline]. [Accessed 04/03/2019].

  5. Rees, O (2019). Villager walking into a jump volume. [offline]. [Accessed 04/03/2019].

  6. Rees, O (2019). Villager run and jump behaviour tree. [offline]. [Accessed 04/03/2019].

  7. Rees, O (2019). Villager unable to jump across the gorge due to navigation mesh constraints. [offline]. [Accessed 04/03/2019].

  8. Rees, O (2019). Villager jump task. [offline]. [Accessed 04/03/2019].

  9. Rees, O (2019). Villager successfully jumping across the bounce pads. [offline]. [Accessed 04/03/2019].

  10. Rees, O (2019). Bounce dampening puddle with adjustable size controls. [offline]. [Accessed 04/03/2019].

  11. Rees, O (2019). Puddle viewport. [offline]. [Accessed 04/03/2019].

  12. Rees, O (2019). Scaling the box using the construction script. [offline]. [Accessed 04/03/2019].

  13. Rees, O (2019). Overlap events for the puddle. [offline]. [Accessed 04/03/2019].

  14. Rees, O (2019). Belly jumping in the bounce dampening puddle. [offline]. [Accessed 04/03/2019].

  15. Rees, O (2019). Belly at full size is unable to get through the cave. [offline]. [Accessed 04/03/2019].

Portobelly Production Journal #28

26/02/2019

As my aim for this week is to refine Belly’s ability today I decided to finish Belly’s rolling animation.

Fig 1 - When rolling Belly skips a frame of animation

Fig 2 - Graph editor for the broken roll animation

During Belly’s rolling animation Belly slightly snaps to a new rotation due to a few of the frames of animation skipping when the animation loops. This causes the smooth roll animation to be interrupted. This is a problem because it prevents the animation from looping perfectly.

Fig 3 - Belly rolling smoothly

Fig 4 - Graph editor for the fixed roll animation

To solve the rolling animation issue I made the animation start and finish at 360 degrees so that the animation would perfectly loop when the animation is played. As you can see above this worked as planned and now loops smoothly.

Fig 5 - Syncing the roll to the speed of Belly’s movement

The next step in finishing the roll animation was to sync the roll speed with the of the players movement. If the roll was not synchronised with the speed of the player, Belly would look like it was moving across a surface with little friction and wouldn’t sell the effect of rolling. I achieved this by tweaking the play rate of the animation until it was in sync with the players movement.

When the player has passed the cave section of the map I wanted the player to have something to follow so that they have an incentive to leave the cave and move onto the next area. To fulfil this need I used one of the villager mushrooms that would use the retreat task to run away.

Fig 6 - Female mushroom before painting skin weights

Fig 7 - Female mushroom with finished skin weights

Before creating the AI of this character I wanted to rig the character so that I could apply a walk and idle animation to the character. I created the rig so that it can hopefully be used for the other villager. This would save me a lot of time when it comes to rigging the other mushroom. When I was painting weights for this mushroom I had to allow the legs to have influence over the grass skirt so that when the mushroom moved it’s legs the skirt would move with the legs.

Fig 8 - Female mushroom idle animation

Fig 9 - Female mushroom walk animation

The walk and idle animations are fairly basic as this enemy will only be used in a few areas of the game. Also this character is really small on the screen so that a lot of the details of the animation can’t be seen in detail.

Fig 10 - Female mushroom using a 1D blend space

Above shows the animations applied to the a 1D blend space. This blend space is attached to the player and the players velocity decides where on the blend space should be played.

 

Figures List

  1. Rees, O (2019). When rolling Belly skips a frame of animation. [offline]. [Accessed 02/03/2019].

  2. Rees, O (2019). Graph editor for the broken roll animation. [offline]. [Accessed 02/03/2019].

  3. Rees, O (2019). Belly rolling smoothly. [offline]. [Accessed 02/03/2019].

  4. Rees, O (2019). Graph editor for the fixed roll animation. [offline]. [Accessed 02/03/2019].

  5. Rees, O (2019). Syncing the roll to the speed of Belly’s movement. [offline]. [Accessed 02/03/2019].

  6. Rees, O (2019). Female mushroom before painting skin weights. [offline]. [Accessed 02/03/2019].

  7. Rees, O (2019). Female mushroom with finished skin weights. [offline]. [Accessed 02/03/2019].

  8. Rees, O (2019). Female mushroom idle animation. [offline]. [Accessed 02/03/2019].

  9. Rees, O (2019). Female mushroom walk animation. [offline]. [Accessed 02/03/2019].

  10. Rees, O (2019). Female mushroom using a 1D blend space. [offline]. [Accessed 02/03/2019].

Portobelly Production Journal #27

25/02/2019

Last week I set myself the goal of implementing the animations and AI of the BFF and to blockout the level. I have completed the AI for the BFF but I did not manage to complete the animations for the BFF as I started working on the blockout as I felt getting the blockout completed was more urgent. I have setup the rig for the BFF so that when I come to animating the BFF I will not have to rig the character.

This week I plan to refine Belly by fixing issues with the character and building the project so that we can show the project at the Bristol games hub meetup.

Fig 1 - 25 02 2019 playtest

During the playtest I discovered that aspects of the game need to be changed due to the results of the playtest. Player 1 mentioned that he would like to have opportunities to move in the opposite direction to discover secrets. During his footage you could see that they were moving backwards often to try and find secrets in the game.

Both players got stuck in the bouncing mushroom section so I feel this needs to be changed so that the player can exit this section if they fall into it. Also this section would be less of an issue if there was an visual explanation on how the mushrooms worked before jumping on the platforms. This would show the player how to use the mushroom pads without failing on their first try.

Fig 2 - 25 02 2019 Discussion

Above is a discussion we had about the production of the game.

Fig 3 - Starting to rig Belly

Belly currently uses an event tick to roll around the environment which is performance intensive. It also has an effect with the roll where Belly’s rotation snaps to a certain position if the player changes their movement direction. This effect is not intended and needs to be resolved. My solution is to control the players rolling through animating Belly rolling.

Fig 4 - Belly before painting skin weights

Fig 5 - Belly after painting skin weights

I began to rig and paint the skin weights of belly making sure that the limbs only had influence over the their area. This was to prevent the arms from moving Belly’s body in undesired ways.

Fig 6 - Belly rotating from the root

I soon discovered that when I began to animate Belly rolling I was unable to rotate Belly around the joint in the centre of Belly as it would deform Belly’s mesh. To fix this issue I had to make the root joint have 0 influence over the mesh so that Belly could be rotated around the central joint.

Fig 7 - Belly forward roll

Fig 8 - Belly backwards roll

Fig 9 - Belly right roll

Fig 10 - Belly left roll

Using the central joint as the origin for the rotation I was able to rotate Belly in 4 directions so that I could apply this to a blend space for Belly’s rolling animation.

Fig 11 - Belly rolling blend space causes rotation snapping

When creating the blend space I was unable to make the blend space transition smoothly between the different states as the rolling would snap to a certain point when the blend space wasn’t at an extreme value.

Fig 12 - Animation blueprint using the forward roll

Fig 13 - Belly animation blueprint calculating the play rate of the forward roll

Instead of using a blend space to control Belly’s movement I decided to use a single rolling animation and alter the play rate based on the players X velocity.

Fig 14 - Belly with the rolling animation fixed

Above shows the rolling animation fixed so that Belly’s rotation no longer snaps to a point when the player changes direction. Although this animation is not perfectly synced up with the speed of the player this can be fixed fairly easily with some minor adjustments to the play rate.

 

Figures List

  1. Rees, O (2019). 25 02 2019 playtest. YouTube [video] 26 February. Available from: https://www.youtube.com/watch?v=LoXis2A1UpQ [Accessed 26/02/2019].

  2. Rees, O (2019). 25 02 2019 Discussion. YouTube [video] 26 February. Available from: https://www.youtube.com/watch?v=WwuOojDEN9w [Accessed 26/02/2019].

  3. Rees, O (2019). Starting to rig Belly. [offline]. [Accessed 26/02/2019].

  4. Rees, O (2019). Belly before painting skin weights. [offline]. [Accessed 26/02/2019].

  5. Rees, O (2019). Belly after painting skin weights. [offline]. [Accessed 26/02/2019].

  6. Rees, O (2019). Belly rotating from the root. [offline]. [Accessed 26/02/2019].

  7. Rees, O (2019). Belly forward roll. [offline]. [Accessed 26/02/2019].

  8. Rees, O (2019). Belly backwards roll. [offline]. [Accessed 26/02/2019].

  9. Rees, O (2019). Belly right roll. [offline]. [Accessed 26/02/2019].

  10. Rees, O (2019). Belly left roll. [offline]. [Accessed 26/02/2019].

  11. Rees, O (2019). Belly rolling blend space causes rotation snapping. [offline]. [Accessed 26/02/2019].

  12. Rees, O (2019). Animation blueprint using the forward roll. [offline]. [Accessed 26/02/2019].

  13. Rees, O (2019). Belly animation blueprint calculating the play rate of the forward roll. [offline]. [Accessed 26/02/2019].

  14. Rees, O (2019). Belly with the rolling animation fixed. [offline]. [Accessed 26/02/2019].

Portobelly Production Journal #26

24/02/2019

Fig 1 - Before camera tracking changes

Fig 2 - After camera tracking changes

After discussion with Will (the artist on Portobelly), he felt that the camera should not the follow the player when the player is jumping as it makes the player lose track of the ground. As you can see in the GIFS above the original camera controls (on the left) follow the players Z axis location whereas with my new system (on the right) the Z axis follows the ground level. If the player is a exceeds a certain distance away from the ground the camera will continue to follow the player so that the player is always in the camera view.

Fig 3 - Blueprint that keeps the camera at a consistent height relative to the ground

The camera tracking was achieved by creating a line trace below the player that finds out the distance of the ground from the centre of the player and if that distance is below a certain threshold the camera will be set at ground level. I have added a value to the distance from the ground so that the camera is always slightly higher than the ground level as when it was at the ground level the camera was too close to the ground.

Fig 4 - Shrink and expand sound effects

Fig 5 - Sound cue for the shrink/expand using continuous modulation

When working with our sound designer, he created a shrink/expand sound for Belly. Using the continuous modulation within the sound cue editor I was able to set the pitch of the sound as a parameter so that I could manipulate this sound within blueprints.

Fig 6 - Sound blueprint attached to the shrink/expand input event

This blueprint above creates the sound for the shrink and expand ability when the triggers are activated and stops the sound when the triggers are released. Based on the players size the pitch of the sound will increase and decrease creating a different sound for the different sizes of Belly.

Fig 7 - Manually streaming individual levels without a ForEachLoop

When I was trying to stream multiple sub levels at once using the previous ForEachLoop I discovered that the level streaming nodes are delayed so that they do not work using a ForEachLoop as the loop executes within a frame so that the level streaming node can’t complete multiple nodes within that time. I resolved this issue by putting the nodes one after the other.

 

Figures List

  1. Rees, O (2019). Before camera tracking changes. [offline]. [Accessed 25/02/2019].

  2. Rees, O (2019). After camera tracking changes. [offline]. [Accessed 25/02/2019].

  3. Rees, O (2019). Blueprint that keeps the camera at a consistent height relative to the ground. [offline]. [Accessed 25/02/2019].

  4. Rees, O (2019). Shrink and expand sound effects. YouTube [video]. 24 February. Available from: https://www.youtube.com/watch?v=bFXIhuankeM&feature=youtu.be {Accessed 25/02/2019}

  5. Rees, O (2019). Sound cue for the shrink/expand using continuous modulation. [offline]. [Accessed 25/02/2019].

  6. Rees, O (2019). Sound blueprint attached to the shrink/expand input event. [offline]. [Accessed 25/02/2019].

  7. Rees, O (2019). Manually streaming individual levels without a ForEachLoop. [offline]. [Accessed 25/02/2019].