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].

Portobelly Production Journal #25

21/02/2019

At the start of the day I was unable to work on the project as my computer was unable to boot up. After many hours of trouble shooting I managed to fix this issue but I had wasted a lot of time on this issue before I was able to start production for the day.

Once my computer was fixed, I had a discussion with the team about the layout of the level and Will (the artist on the team) had the idea of making the cave underground. This would rearrange the order of the obstacles in the tutorial area, putting the breakable platform as the first obstacle and using it as an entrance to the cave/old world. With this layout the player would drop down a tunnel which would enter the beginning of the tutorial cave area.

Making these changes to the layout of the tutorial would cut out the platforms leading up to the breakable platform near the end of the tutorial area. During the playtest (the playtest can be found in this blog post), many players struggled the platforming section before the destructible platform so I feel that it is a good idea to remove that section.

Fig 1 - Changes to the landscape

A second landscape has been added to the map so that the intro of the map can be unloaded when the player drops into the cave area. This will make the game perform much better than having one continuous landscape. When the player falls into the new landscape the cave landscape will be loaded.

Fig 2 - New entrance to the cave area using the slam ability

Fig 3 - Level streaming volume hidden within the drop

I placed the level streaming volume within the middle of the tunnel so that the player will not be able to see the intro sub level unloading or the cave area loading. Having a drop that the player can’t jump back up allows the intro sub level to be permanently unloaded and I don’t have to worry about the player walking back through the streaming volume.

Fig 4 - New level streaming blueprint

I changed the level streaming volume so that it uses an array to load and unload levels so that multiple levels can be loaded and unloaded. This allows me to load the lighting for an area and landscape for example using a ForEachLoop for the array so that anything within the array is streamed separately.

 

Figures List

  1. Rees, O (2019). Changes to the landscape. [offline]. [Accessed 22/02/2019].

  2. Rees, O (2019). New entrance to the cave area using the slam ability. [offline]. [Accessed 22/02/2019].

  3. Rees, O (2019). Level streaming volume hidden within the drop. [offline]. [Accessed 22/02/2019].

  4. Rees, O (2019). New level streaming blueprint. [offline]. [Accessed 22/02/2019].

Portobelly Production Journal #24

20/02/2019

Today I focused on finishing the AI for the BFF so that all the states were functional.

Fig 1 - BFF using all of the active states

Fig 2 - BFF behaviour tree setup for all the states

Fig 3 - Blueprint task for locating the retreat point

After the BFF has been alerted, the next state that activates is the retreat state that is followed by the firing state. The retreat state involves the BFF running away from the player and once the desired retreat distance has been reach the BFF will begin to fire projectiles at the player. When developing this state I realised that I would have to detect where the player was so that BFF would run away from the player based on the BFF location relative to the player. Doing this makes sure that the BFF is always running away from the player during the retreat state regardless of the players location.

Fig 4 - Change speed task with public speed variable

Fig 5 - Change speed blueprint task

I created a change speed task that can be used on any of the AI classes that simply increases the players maximum walk speed. I made the float value of the max speed a public variable so that it can be changed without editing the blueprint task. This task is used to slow down the BFF when it’s patrolling and icrease the speed when it’s retreating.

 

Figures List

  1. Rees, O (2019). BFF using all of the active states. [offline]. [Accessed 22/02/2019].

  2. Rees, O (2019). BFF behaviour tree setup for all the states. [offline]. [Accessed 22/02/2019].

  3. Rees, O (2019). Blueprint task for locating the retreat point. [offline]. [Accessed 22/02/2019].

  4. Rees, O (2019). Change speed task with public speed variable. [offline]. [Accessed 22/02/2019].

  5. Rees, O (2019). Change speed blueprint task. [offline]. [Accessed 22/02/2019].

Portobelly Production Journal #23

19/02/2019

Today I focused on adding functionality to the BFF (big fungal fella) enemy. This class is a child blueprint of the PO_BP_PickupCharacter so that it can be absorb by Belly. At the moment, Belly’s absorb ability is fairly unpredictable when absorbing characters so I will aim to fix this once I have added all of the functionality to the enemies. This will be easy to make changes to all of the enemy classes because they all have the same parent blueprint.

Fig 1 - BFF AI behaviours overview

As the overview above shows, the enemy starts in a idle state, then starts patrolling between two points, after it sees the player it becomes alert, retreats away from the player and then starts to attack the player with long range arced projectiles.

Fig 2 - BFF launching itself using an arc

Fig 3 - BFF launching itself blueprint

I wanted to tackle the projectile arc first because I felt that this was going to be the most complicated state to complete. To my surprise, this was fairly easy to accomplish using the SuggestProjectileVelocity Custom Arc node which calculates an arc based on the start position and end position of the projectile and outputs the velocity to create the desired arc. The arc curvature can be changed by altering the gravity and arc param float values. To test this out I decided to launch the player so that they would land at 0, 0, 0 and this worked as intended (as can be seen above).

Fig 4 - BFF launching a projectile in an arc

Fig 5 - BFF launching a projectile blueprint

Fig 6 - BFF behaviour tree for the basic projectile

Using what I had learned about creating projectile arcs, I applied it to a projectile that is spawned out the top of the BFF’s head and instead of launching the character I added an impulse using the suggested velocity from the projectile node. The projectile is set to hit 0, 0, 0.

Fig 7 - BFF firing projectiles at Belly’s location

Fig 8 - Getting the players location blueprint task

Having the projectiles firing at a set location is not useful when creating a challenging enemy as it would be incredibly easy to avoid the projectiles. Instead I wanted the BFF to fire the projectiles at the players location. To achieve this I created a task that gets the players current location and updates the end point of the projectile so that it is launched at the players location. This makes the enemy far more challenging than just firing at a set location.

Fig 9 - BFF activation radius

Fig 10 - Activate and deactivate the BFF service

To allow the player to become active in the level a create a large spherical volume around the player that when the player overlaps with the volume the enemy becomes active. During this active state the enemy is able to perform actions such as patrolling, alert, retreat and attacking. This system is almost identical to the system used for the Boomshroom in which it checks for how many player are within the sphere volume. If this number is above 0 the state is changed to active.

Fig 11 - BFF Patrolling between two points

Fig 12 - BFF behaviour tree setup for patrolling

Fig 13 - Custom event that switches between the two target points

The patrolling state consists of two tasks, setting the next patrol point and moving to that patrol point. The move to task is a default task within the Unreal Engine and requires a vector as input and the character will walk to the location. The setting next patrol point event switches between the two selected patrol points (target point actors). I added two IsValid checks for the two patrol points that will output some text on a print string if the variables are not populated. Adding this debug message will prevent the user from accidentally placing the BFF in the level without applying target points to the character.

Fig 14 - BFF alert state

Fig 15 - BFF pop up alert blueprint

The alert state is triggered by a spherical trigger volume that if overlapped with the player the BFF state will be changed to the alert state. When the alert state is entered, the custom event above is activated that makes text above the enemy visible and makes the text scroll up from the players location. The character also jumps when the alert state is activated.

Fig 16 - Changes rotation of the character to follow the characters velocity

I applied the orient rotation to movement check box on the BFF character movement so that the enemy faces the direction of their movement. This looks far more believable than an enemy that doesn’t rotate when it changes direction. This is something that I will apply to all of the enemies apart from the spiral spore as many of it’s attacks will involve rotation.

 

Figures List

  1. Rees, O (2019). BFF AI behaviours overview. [offline]. [Accessed 20/02/2019].

  2. Rees, O (2019). BFF launching itself using an arc. [offline]. [Accessed 20/02/2019].

  3. Rees, O (2019). BFF launching itself blueprint. [offline]. [Accessed 20/02/2019].

  4. Rees, O (2019). BFF launching a projectile in an arc. [offline]. [Accessed 20/02/2019].

  5. Rees, O (2019). BFF launching a projectile blueprint. [offline]. [Accessed 20/02/2019].

  6. Rees, O (2019). BFF behaviour tree for the basic projectile. [offline]. [Accessed 20/02/2019].

  7. Rees, O (2019). BFF firing projectiles at Belly’s location. [offline]. [Accessed 20/02/2019].

  8. Rees, O (2019). Getting the players location blueprint task. [offline]. [Accessed 20/02/2019].

  9. Rees, O (2019). BFF activation radius. [offline]. [Accessed 20/02/2019].

  10. Rees, O (2019). Activate and deactivate the BFF service. [offline]. [Accessed 20/02/2019].

  11. Rees, O (2019). BFF Patrolling between two points. [offline]. [Accessed 20/02/2019].

  12. Rees, O (2019). BFF behaviour tree setup for patrolling. [offline]. [Accessed 20/02/2019].

  13. Rees, O (2019). Custom event that switches between the two target points. [offline]. [Accessed 20/02/2019].

  14. Rees, O (2019). BFF alert state. [offline]. [Accessed 20/02/2019].

  15. Rees, O (2019). BFF pop up alert blueprint. [offline]. [Accessed 20/02/2019].

  16. Rees, O (2019). Changes rotation of the character to follow the characters velocity. [offline]. [Accessed 20/02/2019].