Week 11
Time for some environment
▪ Straight platform environment blueprint
Result:
This blueprint is purely for aesthetic purposes for this game experience, it’s essentially adding some trees to the environment using several static meshes. In order to add variety to the environment, there are three custom blueprints just for the straight platform sections, changing the tree placements and scale. This is also true for the jumping platform sections, as for the corner platform sections they have one custom blueprint for each corner. These blueprints all have the same single custom event that once they are spawned into the scene after a delay they are to be destroyed. As explained previously, this is done to optimise the game as the player is unable to see behind them.
▪ Spawning the new environment blueprints
Result:
For each platform section there is now its own custom environment spawning function, this is done to separate the different environment blueprints for organisation purposes. For example, the straight platform section has a ‘StraightPlatfromEnvrio’ function. This function works similarly to the spawning of the platforms but without the probability factor, to determine which straight enviro blueprint is spawned it checks for stored boolean variables. So, firstly it checks a branch to determine if envrio01 has not been spawned, if TRUE that it hasn’t spawned, it then spawn envrio01, if FALSE that it has been spawned, it then moves to the next branch. The second branch is then asking has envrio02 not been spawned, again if TRUE to then spawn envrio02 or if FALSE to then spawn envrio03. Every time an environment is spawned it then sets its own boolean variable to TRUE, this is not true for when envrio03 is spawned, this then resets the envrio01 and enviro02 to false essentially starting the cycle again.
This then allows for the environment spawning to be set but varied, this is also followed for each of the other platforms of the jumping and corner sections.
▪ Deleting actors’ optimisation
Result:
I then discovered that over time more and more actors would be present in the game at one time given they all had a 10 second delay before being destroyed. This is due to the player becoming faster as the game progresses, meaning they are spawning more platform sections quicker adding more actors into the scene. In order to minimise this effect to ensure the game is as optimised as possible, I set the delay time for destroying the actors to a variable stored within the game modes blueprint. This variables value is determined by the speed of the player, with the players speed increasing this variable value decreases and therefore gives the spawned actors a lesser delay to being destroyed.
This is done via a custom function that determines the players movement speed every second through a looped timer to the ‘EventBeginPlay’ node and asking through a branch if the players movement speed is less then or equal to a set value. If FALSE this will do nothing but if TRUE this will set the variable to 8, basically taking 2 seconds away form the original 10 for the delay in destroying actors.
At this current movement the values are set based upon self-evaluation on how I play the game, these values will change with given game testing.
Week 12
Changing the menu
▪ Main menu - New level layout
Result:
This needed an update with the new added environment and assets to the game world. Creating this new main menu layout was simply placing the game assets within the scene to show to the player before they play the game the type of aesthetic the game appears in and also to give them a hint of sorts to the type of gameplay they will encounter, by placing the rock obstacles and coins with a magnet power-up in the background. The layout of this scene also kept in mind the placement of the title and buttons to ensure they were not covered or obstructing anything important in the scene. This was basically just to update the aesthetic of the main menu to suit the current game aesthetic.
▪ Control Scheme UI
Result:
With any game to have the control scheme to be available for the player to read and learn is a must. I opted for the show on screen before game starts approach, ensuring the player has a clear visual of it before they begin. This feature may change with further development to only be displayed if the player is playing the game for the first time and for it to be deactivated if the player returns to the menu at any point, or to either just have it available in an options section. In order to create the control scheme, I created another canvas panel within the main menu UI and by using button shapes and text showed a clear instruction of the button to be pressed for certain actions. In order to display the control scheme, the functionality Is rather simplistic, that once the player starts the game, they will be transitioning to black to which the main menu canvas is hidden and then the control scheme canvas is visible, therefore displaying the control scheme. After a delay period this will then open the game level in which the player starts to play the game.
▪ Game level - Fade in
Result:
After the delay of starting the game is completed, I found that starting the game felt like the player was being jumped into it rather than flowing in. I then created a sort of into to the game by fading the camera from black to the game environment, to make the intro more “dramatic” I opted delay the players HUD to be displayed and also disabling player input until after the HUG is displayed. This then stops the player being able to control the character as the camera is fading in, giving a more flowing intro to the game in my opinion. This was achieved through the game level blueprint, that would activate once the level has loaded.
Week 13
Atmosphere to the game
▪ Distance fog material
Result:
This material was shown in a previous video, from my other project ‘Weekly Works’. Essentially, I copied the same material and implemented here in the ‘Endless Runner’ project. I detail how I went about creating the material over in the Material section of this website. From this one material I created two instances to be used, the first to be attached to the player character so that the radius in which this post process material is effecting is only applied to the player, thus becoming more optimised. The second instance was created for the main menu level, placing a post process volume over the area only, again to ensure only contents within the volume were being affected by the post process.
▪ Road lamp blueprint
Result:
This blueprint was created to add some dynamic lighting to the level, in conjunction to the distance fog. The actor itself simply has a point light attached to emit the light simulating it coming from the mesh. In order to spawn these new lamps into the level I done this within the environment blueprints themselves, therefore when an environment platform is spawned it will also spawn lamps in specific points set with scene components. Essentially the flow of spawning the section goes from the platform itself, then spawning the environment (trees) and then lastly the lamp posts. One factor that I will need to look out for is if the spawning of the dynamic lighting will impact greatly on the games performance, I will identify this though executables and testing the level.
