Portobelly Production Journal #55

24/04/2019 to 03/05/2019

This blog post will be a combination of the last weeks worth of work. This week was spent finalising features of the game ready for release and fixing any major bugs with the game.

Fig 1 - Suction cone changes with Belly’s size

Fig 2 - Size change cone blueprint

After taking the game to several Bristol Games Hub playtest I discovered that a lot of people playing the game would stay at Belly’s smallest so that they would receive the speed increase and when they encountered enemies they would be able to easily absorb them. To give players an incentive to change size more often I decided to make the suction cone smaller when the player is small and when the player is maximum size the player is rewarded with a larger suction cone size. This allows players to draw enemies from further away towards the player when they are at full size. I also increased the speed of the suction ability when the player is larger. Hopefully these incentives to the player increase the chances of players to change size more often.

Fig 3 - Belly’s digestion sphere not changing with Belly’s size

Fig 4 - Adapting the digestion sphere so that it changes size with Belly

Fig 5 - Digestion sphere blueprint

When playing the game I discovered that player was unable to digest enemies/objects when they were at full size. I discovered this was due to the digestion sphere not changing size with the player which prevent from objects entering the digestion sphere during the suction period as it was inside the player. This was a massive issue because it prevented players from eating object/enemies at full size. This also illustrated that players were not changing size often during playtests or feedback sessions as this issue was discovered very late in production so no one has noticed this bug until now.
To fix this issue I made the digestion sphere scale with the players size when they change size. Doing this scales the digestion sphere with the player so that the sphere is always larger than the player so that they are always able to digest enemies and objects.

Fig 6 - Adding a suction bar that depletes when the user uses the suction ability

Fig 7 - Suction bar now recharges when the suction ability is not active

Fig 8 - Values controlling the suction bar increasing and decreasing

Fig 9 - Preventing the player from using a suction ability when it’s empty

During playtest we discovered that a lot of players were holding down the absorb button for the majority of play which made fights against enemies incredibly easy as they were able to kill enemies before they could attack the player. To prevent players from using the absorb ability constantly we decided to put a limit on how long the player could use the ability in the for of a charge timer. When the player is using the suction ability the charge on the suction bar is decreased and when they reach zero charge they are unable to use the ability. As soon as the player releases the suction button the meter begins to fill up again. We made the decision to have this ability run out quickly and recharge slowly so that players had to to use this ability sparingly.

Fig 10 - Boomshroom suction animation

Fig 11 - Boomshroom suction ability implemented

I created a suction animation to the Boomshroom so that when it is being absorb the enemy plays an animation to sell the effect of being absorbed. I feel this effect works well at clearly showing when the enemy is being absorbed as it is very different to the Boomshrooms standard animations.

Fig 12 - Implementing the first few particles on the spiral spore

Fig 13 - Top view of all of the spiral spore attack trails implemented

Fig 14 - Applying the spiral spore particles onto the character

Fig 15 - Activation and deactivation of the spiral spore particles

Before adding the particle effects to the Spiral Spore the enemy would display a red sphere around it’s tendrils when attacking to show that it was able to hit the player. Instead of having this red sphere to show that the enemy was ready to hit the player I decided to create a trailing particle effect was attached to each tendril. I feel that this was a clear indicator of when the attack starts and ends as it is very visual and it also exaggerates the movement of the spin attack.

Fig 16 - Boomshroom exploding on impact with the player

Fig 17 - Changing the move to task to a custom move to task for the Boomshroom

We felt that the Boomshroom was one of the weakest enemies in the game so I decided to refine the self destruct ability of the enemy. When the enemy ran towards the player they were programmed to run to the players last location which led to problems if the player was in the way of their last location. This would result in the enemy trying to run to the end location but being blocked so that the enemy would not explode.
To fix this issue I created a task tat would finish (move on to the next task) when the enemy has reached the end location or makes collision with the player or another object. This made the Boomshroom a lot harder to fight as you had to be weary of their self destruction charge.

Fig 18 - Belly is able to continue to jump when underneath object

I discovered that the player could continue to apply jump force while underneath object which gave an effect as if the player was hovering or stuck on the surface which was something I had not intended.

Fig 19 - Belly’s jump gets cancelled when there is an object above it

Fig 20 - Checking for object above Belly when jumping

To fix this issue I created a line trace coming from the player that would cast from the player upwards and if the player would collide with an object the jump force would stop being applied.

Fig 21 - Updated HUD bar

Will supplied me some images for the health bar and suction meter. I feel these assets are functional as UI elements and they also fit the theme of the game.

Overall I feel the project went very well and I am surprised at how much content we created we such a small team in the time we had. The project taught me a lot about game development and the Unreal Engine as well as additional skills such as animation, rigging, artificial intelligence and user interfaces.

 

Figures List

  1. Rees, O (2019). Suction cone changes with Belly’s size. [offline]. [Accessed 03/05/2019].

  2. Rees, O (2019). Size change cone blueprint. [offline]. [Accessed 03/05/2019].

  3. Rees, O (2019). Belly’s digestion sphere not changing with Belly’s size. [offline]. [Accessed 03/05/2019].

  4. Rees, O (2019). Adapting the digestion sphere so that it changes size with Belly. [offline]. [Accessed 03/05/2019].

  5. Rees, O (2019). Digestion sphere blueprint. [offline]. [Accessed 03/05/2019].

  6. Rees, O (2019). Adding a suction bar that depletes when the user uses the suction ability. [offline]. [Accessed 03/05/2019].

  7. Rees, O (2019). Suction bar now recharges when the suction ability is not active. [offline]. [Accessed 03/05/2019].

  8. Rees, O (2019). Values controlling the suction bar increasing and decreasing. [offline]. [Accessed 03/05/2019].

  9. Rees, O (2019). Preventing the player from using a suction ability when it’s empty. [offline]. [Accessed 03/05/2019].

  10. Rees, O (2019). Boomshroom suction animation. [offline]. [Accessed 03/05/2019].

  11. Rees, O (2019). Boomshroom suction ability implemented. [offline]. [Accessed 03/05/2019].

  12. Rees, O (2019). Implementing the first few particles on the spiral spore. [offline]. [Accessed 03/05/2019].

  13. Rees, O (2019). Top view of all of the spiral spore attack trails implemented. [offline]. [Accessed 03/05/2019].

  14. Rees, O (2019). Applying the spiral spore particles onto the character. [offline]. [Accessed 03/05/2019].

  15. Rees, O (2019). Activation and deactivation of the spiral spore particles. [offline]. [Accessed 03/05/2019].

  16. Rees, O (2019). Boomshroom exploding on impact with the player. [offline]. [Accessed 03/05/2019].

  17. Rees, O (2019). Changing the move to task to a custom move to task for the Boomshroom. [offline]. [Accessed 03/05/2019].

  18. Rees, O (2019). Belly is able to continue to jump when underneath object. [offline]. [Accessed 03/05/2019].

  19. Rees, O (2019). Belly’s jump gets cancelled when there is an object above it. [offline]. [Accessed 03/05/2019].

  20. Rees, O (2019). Checking for object above Belly when jumping. [offline]. [Accessed 03/05/2019].

  21. Rees, O (2019). Updated HUD bar. [offline]. [Accessed 03/05/2019].

Portobelly Production Journal #54

23/04/2019

Last week we were focusing on completing our critical report for Personal Professional Synthesis so that took up the majority of the week so I was unable to work much on Portobelly. This week I aim to complete all the major technical aspects of the game as we only have two weeks left. This will allow me to spend the last week polishing the game and fixing bugs.

Below is a discussion we had go over our plans for the next two weeks.

Fig 1 - 23 04 2019 Meeting

Fig 2 - Initial attempt at slam screenshake

Fig 3 - Slam with less screenshake

Fig 4 - Slam screenshake settings

One point that got raised multiple times during playtest feedback was that many players were not using the slam ability as they felt it didn’t have any impact. To give the slam more impact when making contact with the ground I decided to add a screenshake/camera shake when the player makes contact with the ground during a slam attack.

When a giant explosion goes off on screen there is a slight delay, after which the screen appears to shake, as though the camera were responding to the jarring force of a shockwave caused by the explosion. the end result is the perception that a hugely weighty impact has occurred.
— Swink, S

Fig 5 - Slam with impact particle emitter

Visual effects appear to be caused by another object, but are not the object itself [...] Through deft manipulation in the hands of an animator, that sequence of frames played back will cause the object to appear to have weight and presence and volume and all that good stuff
— Swink, S

After many discussions with Will (the artist) we decided to buy a VFX asset pack of the Unreal Marketplace so that we did not have to make all of the effects in the game. As Swink states VFX add weight and presence to actions I felt that the slam attack needed some form of VFX to compliment the attack. This effect matched up with the screenshake really sells the effect and I made the particle emitter scale with the size of Belly.

Controller shake can be a bit of a blunt instrument because the motion is always rotational, but it can be used to great effect in games where it is cleverly fit to the metaphor presented. A gun has recoil, for example, and that motion is something rumble motors can simulate well. Most modern console shooters use a constant rumble effect to enhance the sensation of firing of a machine gun.
— Swink, S

Using Swinks example I decided to add some controller rumble to the game when the player uses the slam ability as the controller we are using for our game supports this feature. I made the effect send a vibration that falls off quickly after it was activated. This effect is increased the larger Belly’s size is. I feel that this effect works well as it provides the player with physical feedback when they have activated a slam ability.

Fig 6 - Changing the detonator so that it requires a slam to explode the boulder with VFX

Fig 7 - Only trigger the detonator when the player uses a slam

Part of the level in Portobelly involves exploding a rock using a detonator which would explode the rock when triggered. Before this detonator would trigger when the player got close to the object but I wanted the object to trigger when the player used the slam ability so that the player had another chance to use the ability to progress. As the slam ability inflicts damage I used the any damage event to trigger the rock exploding.

Fig 8 - Detonator plunger animation

Fig 9 - Plunger animation blueprint

Using assets Will created (a box and handle for the detonator) I managed to make an animation for them using a timeline in blueprints. This time moved the plunger down when the player slammed on the top of the detonator.

Fig 10 - Test the spline mesh system for creating a fuse for the detonator

I created a spline system that would generate meshes that would follow the spline path. This system will be used to create a fuse or wire connecting the detonator to the explosives. Using a spline allows these complicated mesh paths to be created quickly and allows me to move objects along the path for example with a particle effect that will show that the fuse has been lit.

Fig 11 - Particle emitter moving along the fuse path slowly (footage sped up)

Fig 12 - Particle moving along the fuse triggers the explosion

Fig 13 - Moving a particle along the fuse spline blueprint

Using the spline path I controlled the location of the particle effect so that it move along the spline as if the fuse was lit. To make the fuse particle trigger the explosion I created a variable that would store the distance of the particle effect along the spline so that when the effect reached the end of the spline the explosion would be triggered. To finish this effect I will need to make the dynamite sticks and fuse effect disappear when the explosion is triggered.

 

Figures List

  1. Rees, O (2019). 23 04 2019 meeting. YouTube [video] 23 April. Available from: https://www.youtube.com/watch?v=zMWN67QMFsE&feature=youtu.be [Accessed 24/04/2019].

  2. Rees, O (2019). Initial attempt at slam screenshake. [offline]. [Accessed 24/04/2019].

  3. Rees, O (2019). Slam with less screenshake. [offline]. [Accessed 24/04/2019].

  4. Rees, O (2019). Slam screenshake settings. [offline]. [Accessed 24/04/2019].

  5. Rees, O (2019). Slam with impact particle emitter. [offline]. [Accessed 24/04/2019].

  6. Rees, O (2019). Changing the detonator so that it requires a slam to explode the boulder with VFX. [offline]. [Accessed 24/04/2019].

  7. Rees, O (2019). Only trigger the detonator when the player uses a slam. [offline]. [Accessed 24/04/2019].

  8. Rees, O (2019). Detonator plunger animation. [offline]. [Accessed 24/04/2019].

  9. Rees, O (2019). Plunger animation blueprint. [offline]. [Accessed 24/04/2019].

  10. Rees, O (2019). Test the spline mesh system for creating a fuse for the detonator. [offline]. [Accessed 24/04/2019].

  11. Rees, O (2019). Particle emitter moving along the fuse path slowly (footage sped up). [offline]. [Accessed 24/04/2019].

  12. Rees, O (2019). Particle moving along the fuse triggers the explosion. [offline]. [Accessed 24/04/2019].

  13. Rees, O (2019). Moving a particle along the fuse spline blueprint. [offline]. [Accessed 24/04/2019].

Bibliography

Swink, S. (2008) Game Feel A game designer’s guide to virtual sensation. 1st ed. Publisher unknown.

Portobelly Production Journal #53

12/04/2019

On Thursday, we took a build of our game to the Bristol Games Hub for an event called Feedback Thursday where we could get feedback and give feedback on peoples projects.

We watched people at the event play our game and these were a main takeaways from the event:

  • Enemies need to be harder as a lot of people did not get to see the enemies attacks before the enemies were killed.

    • Possible solutions

      • Edit the suction ability so that it doesn’t instantly kill the enemies

      • Small Belly has a weaker and smaller suction cone, whilst big Belly has a larger and stronger one

      • Possible chance enemies can escape the suction ability

      • Make Belly slower and a bit bigger once he’s eaten a mushroom

      • Make digestion longer

  • A player managed to jump through the waterfall rocks when Belly was small

    • Possible solutions

      • Get rid of the jump overrride when in this volume to force players to expand in size

  • Lots of rolling to get to the next place

    • Possible solutions

      • Add in more obstacles for Belly to interact with

        • Things to jump over

      • Possibly add in Boomshrooms to the cave

  • Suction ability has a collision attached to it

    • Possible solutions

      • Disable the collision for static objects as players were triggering the bounce mushrooms with the suction cones

  • Can suck Boomshrooms out of the ground

    • Disable this

  • Players were not using the slam as often as we would have liked them to (only using it when it was necessary)

    • Make it more satisfying so people use it

  • Everyone completed the game

  • People figures out how to use the slam ability

This playtest was incredibly useful as we were able to watch new players play our game which allowed us to see peoples reactions and problem solving to certain aspects of the game.

We also submitted our work to Feedback Friday on reddit for some feedback.

Fig 1 - Feedback Friday response 1

These piece of feedback was fairly positive as they liked certain aspects of the game such as the growing and shrinking mechanic and the waterfall section. They stated that they would like to see some more puzzles which could definitely be added as the breakable wall puzzle is something we were planning on adding which involves the player slamming on a detonator to trigger an explosion.

Fig 2 - Feedback Friday response 2

This player had some trouble understanding the suction ability which is understandable as we don’t really show the player how to use the ability. They also bought up a good point that there is no options for changing the screen mode which is something I need to add into the game so that more players will be able to play the game. Ultra wide screen support is not something I have experience with and supporting it may cause some issues with the camera view so I think I will just create options to play in windowed resolutions in a 16:9 aspect ratio.

Fig 3 - Feedback Friday response 3

This player mentions the slam ability not being very impactful which I agree with as it is not very obvious what the slam ability does so that could definitely be changed with a few particle effects and maybe some screen shake when the player hits the ground.

 

Figures List

  1. NVUnen, (2019). Reddit. Available from: https://old.reddit.com/r/gamedev/comments/bc8rr4/feedback_friday_335_explosive_results/ [Accessed 23/04/2019].

  2. SlimRam13, (2019). Reddit. Available from: https://old.reddit.com/r/gamedev/comments/bc8rr4/feedback_friday_335_explosive_results/ [Accessed 23/04/2019].

  3. Kimimaru4000, (2019). Reddit. Available from: https://old.reddit.com/r/gamedev/comments/bc8rr4/feedback_friday_335_explosive_results/ [Accessed 23/04/2019].

Portobelly Production Journal #52

09/04/2019

My goal for today was to create a death system and checkpoint system for Belly so that the player could die when too much damage has been inflicted and when the player dies they will respawn at their last checkpoint.

Fig 1 -  Basic checkpoint system resetting the players location

Fig 1 - Basic checkpoint system resetting the players location

Fig 2 - Instant kill blueprint

My first test was to see if the player would respawn at a set location after the player had died. The player dying was controlled by pressing the K button as I set it to instantly kill the player so that I could easily test this respawn system. This test was successful and I was able to change the location of where the player would respawn.

Fig 3 - Moving to last overlapped checkpoint on death

In the next checkpoint test I set up a system that would update the players respawn location when they had overlapped the checkpoint bounding box. When the player died they would respawn at their last overlapped bounding box (checkpoint volume). This system was the basis of the checkpoint system as it allows the player to change their respawn location. When this would be implemented in the level I will place checkpoint in front of significant mile stones in the level so that if the player dies soon after the checkpoint they will not have lost much progress.

Fig 4 - Death screen placeholder to cover up the checkpoint transition

Fig 5 - Blueprint controlling the fade of the death screen

One issue I was having with the spawn system was that when the player died the camera would pan to where the characters new location was. To avoid the player from seeing this transition, I created a player death screen that would pop up and cover the screen so that the player is unable to see this transition.

Fig 6 - Grave stone rising from the ground on player death

Fig 7 - Rising grave stone animation

To show the player that they have died we decided to include a gravestone that appears when the player has died. This idea came from my game jam game called “Offshoot“ because in that game when the enemies died the enemies turned into a grave stone. This also works as a good visual representation of the player dying rather than the player disappearing. To improve this death effect, I will be adding some visual effects to the death to make the effect more significant.

Fig 8 - Bouncy mushroom animation

Fig 9 - Bounce mushroom rig

Fig 10 - Belly bouncing across the new bounce mushrooms

Using the mesh provided from Will for the bounce mushrooms I created a rig so that the mushrooms had more character when the player bounces on them. Before they were static and did not seem very bouncy but now the effect is conveyed much more effectively.

 

Figures List

  1. Rees, O (2019). Basic checkpoint system resetting the players location. [offline]. [Accessed 23/04/2019].

  2. Rees, O (2019). Instant kill blueprint. [offline]. [Accessed 23/04/2019].

  3. Rees, O (2019). Moving to last overlapped checkpoint on death. [offline]. [Accessed 23/04/2019].

  4. Rees, O (2019). Death screen placeholder to cover up the checkpoint transition. [offline]. [Accessed 23/04/2019].

  5. Rees, O (2019). Blueprint controlling the fade of the death screen. [offline]. [Accessed 23/04/2019].

  6. Rees, O (2019). Grave stone rising from the ground on player death. [offline]. [Accessed 23/04/2019].

  7. Rees, O (2019). Rising grave stone animation. [offline]. [Accessed 23/04/2019].

  8. Rees, O (2019). Bouncy mushroom animation. [offline]. [Accessed 23/04/2019].

  9. Rees, O (2019). Bounce mushroom rig. [offline]. [Accessed 23/04/2019].

  10. Rees, O (2019). Belly bouncing across the new bounce mushrooms. [offline]. [Accessed 23/04/2019].

Portobelly Production Journal #51

08/04/2019

Today I decided to focus on implementing the spiral spore spin attack animation on to the spin attack within the Unreal Engine.

Fig 1 - Implementing the spin attack animation

Fig 2 - Spiral spore spin attack animation blueprint

The spin animation has to be broken into 3 different stages, the start, spin loop and end. These stages have 3 different animations attached to them which transition into each other. The animations have to be structured this way because the character may spin for a longer duration than the length of the spin animation. When the attack is initiated the first animation will play when this animation has finished the spin loop will play and when the spin attack has finished the spin loop will stop and the end spin transition will play. After this attack the enemy will return to the idle animation.

In order to finish this character I will need to create a jump, glide, dazed and suction animation.

 

Figures List

  1. Rees, O (2019). Implementing the spin attack animation. [offline]. [Accessed 23/04/2019].

  2. Rees, O (2019). Spiral spore spin attack animation blueprint. [offline]. [Accessed 23/04/2019].

Portobelly Production Journal #50

06/04/2019

Today I decided to focus on improving the rig for the spiral spore and animating the spin attack animation. I needed to improve the rig for the spiral spore because apart from the root bone the rig did not have any controls which make animating a rig much easier when they are included as you can reset bones to their starting position easily.

Fig 1 - Beginning to add controls to the spiral spore rig

Fig 2 - Finished rig with controls setup

When adding controls to the rig, I was told to freeze the transforms of the controls before attaching them to the bones. This would reset the transformation of the control returning all of it’s values to 0, 0, 0 which allows me to reset the location of the bones if I needed to return them to their starting point. Also when creating these controls I made sure to parent the controls to each other so that the control below the previous one has control over the bones above it. After creating all of the controls for the rig I discovered that I did not actually need to create the controls for the end of the tendrils as I won’t be moving them when animating.

Fig 3 - Mapping out the spin rotation

Before animating the tendrils of the rig I wanted to create the basic rotation motion of the character so that I could base the movement of the tendrils off the overall rotation of the character. When creating the rotation for the spin I needed to break the animation into three section, the start of the spin, the looping spin attack and an end of the spin. Having these sections of the animation is essential as when I take these animations into Unreal I need the middle section to loop so that it can be any length of time.

Fig 4 - Chair swing ride.

When tackling the animation for this spinning attack I used this chair swing ride as reference as when the ride spins the chairs begin to move outwards. I want to replicate a similar effect with the tendrils of the spiral spore so that the effects of physics apply to the tendrils of the spiral spore.

Fig 5 - Animating the first joint on the tendril

Fig 6 - Animating the second joint on the tendril

Fig 7 - Fully animated tendril

When animating the first tendril, I decided to animate each joint on tendril separately so that I could offset the motion of the swinging action between each joint. Whenever the spiral spore changes direction of the spinning motion the momentum of the tendril will carry on moving in the direction which will result in the tendril swinging.

Fig 8 - Half of the tendrils animated

Fig 9 - First pass on the spin animation

After animating each of the tendrils I am fairly happy with the result of the animation. With a few adjustments to the a couple of the tendrils movements this animation should be ready to import into the engine.

 

Figures List

  1. Rees, O (2019). Beginning to add controls to the spiral spore rig. [offline]. [Accessed 07/04/2019].

  2. Rees, O (2019). Finished rig with controls setup. [offline]. [Accessed 07/04/2019].

  3. Rees, O (2019). Mapping out the spin rotation. [offline]. [Accessed 07/04/2019].

  4. Beston Amusement Equipment Co., Ltd, (2016). Hot Sale Beston chair swing ride, wave swinger, yo yo,Chairo plane. YouTube [video] 27 April. Available from: https://www.youtube.com/watch?v=ZglB97aXkqg [Accessed 07/04/2019].

  5. Rees, O (2019). Animating the first joint on the tendril. [offline]. [Accessed 07/04/2019].

  6. Rees, O (2019). Animating the second joint on the tendril. [offline]. [Accessed 07/04/2019].

  7. Rees, O (2019). Fully animated tendril. [offline]. [Accessed 07/04/2019].

  8. Rees, O (2019). Half of the tendrils animated. [offline]. [Accessed 07/04/2019].

  9. Rees, O (2019). First pass on the spin animation. [offline]. [Accessed 07/04/2019].

Portobelly Production Journal #49

05/04/2019

While I was developing QWERTY Road I discovered that I could get online feedback from other developers through Reddit every Friday as part of a weekly event called Feedback Friday on the gamedev subreddit (community/forum). Using this would be ideal to get some extra feedback from others who had never played the game before. I created a build of the game and posted it on the thread along with some information about the project and these were the responses I received.

Fig 1 - Feedback Friday comment 1

First of all I’m glad this user enjoyed the shrinking and expanding ability as it a key part of the game. I agree with the point they raised about the slam ability not feeling like it has impact. This could be resolved by adding some sort of visual and audio feedback to the ability, for example, I could add particle effects when the player lands and have a louder landing sound when the player hits the ground. I’m not sure how to fix the issues with different keyboard layouts and I don’t feel like it is a priority to fix as the game is made to played with a controller.

Fig 2 - Feedback Friday comment 2

This comment talks about how the during the periods of the game where the player is just moving to the next location there should be more “life“ in the level. This could be achieved by adding more props or interactive obstacles into the play space.

 

Figures List

  1. IterativeInteractive, (2019). Reddit. Available from: https://www.reddit.com/r/gamedev/comments/b9m2hp/feedback_friday_334_new_discoveries/ [Accessed 07/04/2019].

  2. SteamyExecutioner, (2019). Reddit. Available from: https://www.reddit.com/r/gamedev/comments/b9m2hp/feedback_friday_334_new_discoveries/ [Accessed 07/04/2019].

Portobelly Production Journal #48

04/04/2019

Fig 1 - 04 04 2019 first draft of the level

Today my focus was to finish the ending section of game where Belly eats the apple. Footage of this section can be seen above. I wanted this section to include previous mechanics or platforms so that the player does not have to learn new skills during this period. I have reused the bounce mushrooms and floating rocks in this section. Now that we have a blockout for this area I can continue to refine the level.

 

Figures List

  1. Rees, O (2019). 04 04 2019 first draft of the level. YouTube [video] 4 April. Available from: https://www.youtube.com/watch?v=wVa--f_0J64&feature=youtu.be [Accessed 07/04/2019].

Portobelly Production Journal #47

03/04/2019

After a few discussions about the level design we came up with a few ideas on how to make some interesting interactions that the payer can make with the level. One of which was a door that can only be opened when enemies in the area have been destroyed. The other was a pile of rubble that has to be exploded using a detonator to progress through the level.

Fig 1 - Door opening when enemies are destroyed

I wanted to add a door system in the game so that players have a reason to fight the enemies and it will prevent players from ignoring the enemies. At the moment, I’m using a rock asset as the door but in the future I plan to have that replaced with a door asset. I created a similar system for the door used in the game jam entry called ROOM. Instead of waiting until all the enemies had be killed the doors in ROOM only opened when all the rubbish had been picked up.

Fig 2 - Door opening timeline setup

The door opens using a timeline that moves from the value of 0 to 1 in a linear path. This float value is multiplied by a set door opening distance which updates the relative location of the door. Using a timeline allow the door to smoothly open without creating an actual animation. Timelines also allow the speed of the movement to be changed easily within the engine.

Fig 3 - Door opening logic

I wanted to make this door easy to modify so I created an empty array of intractable characters so that enemies can assigned to the door. When the enemy is destroyed they are removed from the array and when the array is empty the door will open.

Fig 4 - Detonating the rock obstacle using the detonator

Fig 5 - Detonator trigger blueprint

The idea behind the exploding rock/rubble was another way to prevent the player from speeding through the level. At the moment the detonator (it’s a cube at the moment) triggers when the player overlaps with it but I plan on making it activate when the player uses the slam ability to trigger the explosion.

 

Figures List

  1. Rees, O (2019). Door opening when enemies are destroyed. [offline]. [Accessed 04/04/2019].

  2. Rees, O (2019). Door opening timeline setup. [offline]. [Accessed 04/04/2019].

  3. Rees, O (2019). Door opening logic. [offline]. [Accessed 04/04/2019].

  4. Rees, O (2019). Detonating the rock obstacle using the detonator. [offline]. [Accessed 04/04/2019].

  5. Rees, O (2019). Detonator trigger blueprint. [offline]. [Accessed 04/04/2019].

Portobelly Production Journal #46

1/04/2019

Last week I put the majority of my focus on our presentation so it was a fairly slow week in terms of production.

This week I plan to finally finish the blockout of the level so that we can begin to refine the level. In retrospect I feel I should have put a greater focus on level design during the game design document stage of development so that I could have put less thought into level design during development.

Fig 1 - April 1st Meeting

 

Figures List

  1. Rees, O (2019). April 1st Meeting. YouTube [video] 1 April. Available from: https://www.youtube.com/watch?v=AKxPc1lT3HA&feature=youtu.be [Accessed 04/04/2019].