Week 6
Some User Interfaces!
▪ Displaying the power pickups time, using UI
Result:
The process for displaying for the time of the Magnet and X2 power is the same. In order to display the time left of the power before it deactivates is done within the players UI HUD, by using a ‘Progress Bar’. This bar is used to display a different colour based on its percentage value, the value of the percentage is then controlled through a function tied to the specific power time. The function retrieves the specific powers time variable from the player character, and divides its value by 100 to ensure a point value. This progress bar is then updated when the time variable changes showing a decreasing coloured bar, this is how the player will determine the length in which the power will be active for.
▪ Pause game UI
Result:
A separate ‘Widget Blueprint’ was created for the pause UI. The UI itself consists of a centre text stating ‘Game Paused’ with a smaller text to the right corner stating ‘Press P to Unpause’ and a button to return to the Menu screen (which will be implemented in next week’s work).
In order to pause the game, a custom event is created that uses a ‘FlipFlop’ node to go back and forth on two events. Once the player presses the ‘P’ key the first flipflop event is fired, this will set a paused variable to TRUE and created the pause UI adding it to the players viewport. This then will overlap the current HUD display and also start a blur animation created to ensure the focus on the screen is the pause effect. The blur effect will activate once the pause UI is created along with enabling a mouse cursor display for the player to press the button on the UI. Once the player presses ‘P’ again this will fire the second event, in which removes all the current displayed widgets, sets the pause game variable to FALSE and creates the players HUD UI adding it to the players viewport.
▪ Game over UI
Result:
Another separate ‘Widget Blueprint’ was created for the game over UI. The UI itself is a duplicate from the player HUD UI but with added features, such as a centre text stating ‘Game Over’ and two buttons, the left button stating ‘Restart’ and the right stating ‘Menu’.
In order for the game over UI to display the player must die within the game. This is done through adding to the ‘Death Function’ event within the player character blueprint that once called will remove all over displayed widgets and create the game over UI adding it to the players viewport. Once this UI is created it will activate a blur animation the same as the pause UI, enabling a mouse cursor display to interact with the buttons and with a second delay pause the game. This is done to ensure the game is not firing any unresolved events. The buttons themselves have their own event once interacted with, the restart button will fire a console command event that restarts the level, basically as if the level has just been opened. The menu button has no event as of yet but will be added in next weeks works.
Week 7
Main Menu!
▪ Main Menu - level + UI
Result:
I created a separate level for the main menu to differentiate between gameplay and starting game. I setup a very basic, small scene with the player character and a plane flooring with a camera for the menu’s perspective. Within the ‘Level Blueprint’ attached to the ‘Event BeginPlay’ node, is an event that sets the player controllers view target to the set menu camera and creates the main menu widget, adding it to the player characters viewport. The widget itself is also basic, with the games title and two buttons- ‘Start’ and ‘Quit’. The start button once pressed will conduct a console command function to open the gameplay level. The quit button once pressed uses the quit node to close the game. Regarding the other UI’s such as the ‘Pause’ and ‘Game Over’ their menu buttons are now connected to use the console command of opening the main menu level.
▪ Optimised spawning
Result:
This optimisation was primarily done due to an instance in which there was a probability for all 3 lanes to spawn the obstacles, stopping the player being able to pass and so game breaking. Therefore, I created a branch system that detects if other obstacles have been spawned in other lanes. Using the ‘Spawning Actors Lane 0’ function as an example, firstly there is a branch node that asks if any obstacles have been spawned in both Lane 1 & 2. If TRUE this would bypass the spawning obstacle section in Lane 0’s function, meaning a clear path for the player to pass. If FALSE this will continue the function as normal. This branch section is used in every lane spawning function to ensure the obstacles are spawning randomly. In order to reset the spawned obstacles variables, after the platform blueprint is destroyed after the delay, I used the ‘Event Destroyed’ node to reset those variables.
Another factor that was addressed is the amount of power pickups spawning during the run. I found that altering the percentage of spawning didn’t really change the situation, either not enough or too many were spawning. Therefore, I set another branch section to ask if any power pickups were spawned. If TRUE this would do nothing, if FLASE it would spawn as normal. Once a power pickup is spawned, this would set a timer to activate a function. This function basically resets the variable for the spawned power pickup once the time is completed. By doing this allowed me to control exactly how long it would take before another would spawn and still use the percentage events to give random results.
Week 8
Changing the way you run
▪ New movement system
Result:
Unfortunately, this week I was unable to achieve much work due to family matters, but here is a little something I managed to do.
I’ve changed the running system to now give the player more free movement between the lanes, giving the player more control over the character location of running and for it to feel more organic and natural movement.
In order to achieve this I take the player controllers Z rotation value (which is the Yaw), crate a rotation value based solely from the Z axis and apply that value to the players right vector movement input. This then allows the player to move freely from left to right without impacting distance forward or backwards.
Week 9
Changing the course you follow
▪ Corner platforms blueprint
Result:
This new blueprint features a corner turn in the course. This was done to add more variety in the course layout, keeping the player involved and alert in their environment. The blueprint mechanic itself functions in the same way as the straight platform does, just with added features specific for the corner sections. First, is the ability to turn the corner. This is done by creating a “Collision Box” component and fire an event when the player either overlaps it or end overlaps it. If the player overlaps the box, this will set a variable within the players blueprint that states TRUE to turning a corner, once they end overlap the box this will set that TRUE variable to FALSE meaning cannot turn corner. This event is specific to the player ability to turn a corner rather than an event within itself. The second feature is more collision boxes that if the player overlaps will activate the ‘Death Function’ within the player, as detailed before this will activate the ragdoll effect and create the game over screen for the player. This is done so that if the player doesn’t turn the corner in time, or if the player turns the opposite way, this will effectively kill the player giving that death result. Another difference between the corner platform to the straight is the function to spawning the obstacles or pickups, to ensure nothing is spawned on the corner section (so that the full focus is on turning within the corner) the spawning event is taken out of its mechanic. This blueprint is identical to each left and right corner, except for the placement of the collision boxes and player direction.
▪ Spawning corner platforms
Result:
A new function is created within the “GameMode” blueprint that specifically spawns the platforms for the course. This function starts with standard event of choosing a random float value from 0-1 and compares its value to the float value I have set, basically as a percentage of probability. I have set an 80% chance for the function to spawn a straight platform, which is a high percentage here so that the course isn’t turning corners to often and so that it gives the player more time to run and collect the pickups on the straight sections. But if the random float value doesn’t meet the set one, this will then lead to a “Branch” section of the event. This branch determines is a corner platform has been spawned previously, this is done for the last section in this functions event in which I will detail soon. If the result turns back TRUE then this will spawn a straight platform, if FALSE this will then lead to another probability spawn event. This last probability event basically gives a 50/50 chance to either spawn a left or a right corner. Once either corner has been spawned, this will set that corner has spawned variable to TRUE and start a timer for another function. This function basically after a set time will reset the spawned corner variable to FALSE, meaning that once a corner platform has been spawned another cannot spawn until the time has ended resetting the variable. This is don’t to somewhat control the course so that there wouldn’t be so many corners spawning after on another and also to prevent the course from overlapping itself.
▪ Player turning corners control
Result:
Once the corner platforms are spawned, its time to give the player to ability to turn set corners. I will give an example for the input of turning left. Firstly, once the input for turning left is pressed this will lead through a variety of “Branch” nodes to determine certain factors, the first branch determines if the player can turn the corner in the first place. This is determined through the corner platform blueprint once the player overlaps a collision box within it, if TRUE this will follow onto the second branch node and if FALSE will do nothing. The second branch determines have they turned right, in which the variable result would be based upon the turning right event. If TRUE, does nothing or if FALSE will continue the event. If all the requirements have been met this will change the values of a variable known as the “Desired Rotation” by taking the number 90 away from the Z (Yaw) axis value from the player controllers’ current rotation. What this essentially means is by taking away 90 from the Z axis value will rotate the player controller 90° to the left and in turn take a left turn. This event is identical for the turning right function except by determining if the player has already turned left, and by adding 90 to the Z axis value. In order to create a smooth blend for the sudden rotation, the “Rinterp To” node is used, blending the values from the player current controller rotation to the newly set desired rotation creating that smooth blend.
Week 10
Jumping sections now
▪ Jumping platforms blueprint
Result:
This new blueprint features a jumping section in the course. This was done to add more variety in the course layout, keeping the player involved and alert in their environment. The blueprint mechanic itself functions in the same way as the straight platform does, just with added features specific for it. First, is the ability of slowing down time once you get closer to the drop. This is achieved with a collision box that once the player overlaps will trigger a function that sets the world time dilation to half its normal speed, and once the player ends overlapping the box it will set the time back to normal. This is done to give players a better chance of timing their jumps, but could be developed or taken out with game testing at a later stage. The second feature is more collision boxes around the fencing that act as invisible walls to stop the player jumping over the surrounding fences, this is done by setting the collision of the boxes to block the player pawn but ignore everything else. This feature was also then implemented on the other platform blueprints to ensure the player cannot jump out of the area. The final feature is that if the player collides with the sign within the jumping platform, this will effectively kill the player, acting as an obstacle as well.
▪ Spawning jumping platforms
Result:
This spawning of the jumping platforms, acts exactly the same as the spawning of the corner platforms. The code and process is copied with very little changes, this is so that it keeps the process the same and effective. The code is then placed in the hierarchy of the spawning of probability.
▪ Player jumping + falling control
Result:
The jumping control is the default used within the ‘ThirdPerson’ template project, using the given nodes within the programme. As for the falling, a custom function is looped every 0.1 second using the ‘EventBeginPlay’ node (a more efficient way than using the ‘EventTick’ node) determining the players Z velocity. If the player is falling their Z velocity will be negative and increasing to high numbers, the function basically determines the value of the players z velocity and if its less than or equal to the set amount this will activate the ‘Death’ function within the players blueprint. Essentially killing the player if they are falling for too long being missing the jumping section.
