Project Overview |
Game Trailer |
|
Role: Lead Programmer
Genre: Platformer Engine: Unreal Engine 4 Languages: C++, UE4 Blueprint Team Size: 14 People (2 Programmers) Development Time: 24 Weeks (21 Hour Weeks) Project Summary
|
|
Roles and Responsibilities
- Developed additional functionality for the third person camera.
- Implemented functionality for between-level slide sections.
- Created loading screen system to coordinate with level streaming and level loading.
- Implemented HUD, menus and options functionality.
- Created cannon mechanic.
- Developed functionality for internationalization support.
- Implemented automated performance testing utilizing Unreal Frontend.
- Served as Lead Programmer, and managed tasks with Level Designers, Artists, Game Designer and Producer for cross-discipline collaboration.
- Perforce management and initial engine setup.
- Administered daily automated builds utilizing Windows batch files.
Third Person Camera
One primary struggle of this project was making a robust third person camera for the player. Since the game is a 3D platformer, the user needs to be able to control the camera in a straightforward way. The camera system must also have some automated movement built in, such that it helps show the character where they might want to be looking.
Camera Based on Player Movement
The camera can be controlled by the right analog stick, but it also moves automatically with the player's movement. The purpose behind this behavior was for players who are not familiar with controlling the camera in such a way to still be able to manipulate the camera in some fashion.
To achieve this effect, we needed to interpolate the camera's rotation towards where the character is currently moving. To do this, we grab the yaw component of a look-at rotation created by adding the current velocity towards the player's world location. We then construct a new rotation using the yaw from the look-at rotation along with the pitch and roll preserved from the original camera's rotation.
The next component we need is the speed at which we are rotating the camera. The speed should be at its fastest when running perpendicular to where the camera is facing. As such, we take a dot product of the player's forward vector and the forward vector of the camera. We then scale the value by a desired speed value.
Finally, we take these values and plug them into the interpolation node. The resulting rotation is set as our new control rotation, resulting in a camera that rotates with player movement, and scales based on the direction traveled.
Camera Zoom/Pitch Volumes
Another aspect of camera manipulation are designer-placed camera volumes. These volumes will nudge the camera up to a certain point, as well as zoom in/out the camera based on the context of the level. These are useful for situations where the camera needs to be close to the player, or if the designer intends the player to look towards a certain location.
Slide Sections
The player goes through two slide sections in the game where they slide down a slope while gathering collectibles. The sliding state needed different movement controls from the regular movement state, since the player is now sliding down a slope as opposed to running around.
Since the player is sliding, the character needs to face forward dependent on the camera. The following blueprint keeps the player facing in front of them, while still allowing for side-to-side movement.
This blueprint code keeps the player facing forward where the camera is facing.
The team discovered through testing that giving the player free reign of the camera during these sections seemed to cause more confusion than anything. We decided to keep the camera locked in a view behind the player, keeping them focused on the obstacles before them.
The yaw is locked behind the character, while pitch and roll are preserved.
Loading Screens
When loading into any of the levels, we needed a system to hide the level streams from popping into view. This is achieved through a loading screen system that utilizes UE4's event dispatchers. Once the streams of the selected level are all loaded in, the blueprint handling the stream loading calls the "OnGameLoaded" dispatcher. All the events bound to this dispatcher then execute, including fading out the loading screen widget itself.
This is how events are bound to the OnGameLoaded dispatcher.
Calling the event dispatcher will trigger all events bound to it.
HUD and Menus Using UE4 Widgets
The in-game HUD communicates with the Player State object in order to keep track of collectible count. It also has several functions exposed so that external blueprints can communicate with it. The HUD responds to collectibles by sliding a yellow bar up, and lighting up three light bulbs to indicate the player's current progress.
The menus of the game utilize controller or keyboard input for navigation. This had to be coded manually as controller support for menus was not built into UE4 at the time. The options menu in particular took a bit of work to make the navigation work on controller, due to sliders. The values stored in the options menu are all saved to file, and applied to the corresponding values in game.
The options widget in editor.
Functionality behind toggling full-screen mode in the options menu.
Cannons
The cannons in Scrapped are set up such that they launch the player towards a specific target. The logic behind these cannons allows designers to choose where the player should land and how long the travel time is.
The player will get launched towards "Target Location" at the travel time specified.
Blueprint showing the math behind the cannon functionality.
Code Samples
This is the header file for automated testing. This code registers automated performance tests that can be called either by command line or from Unreal Frontend.
These tests log performance data to file. It reports average FPS, as well as other metrics useful for determining current performance.
This is a simple function library for use in Scrapped. This is where simple utility functions are dumped so that they can be used as blueprint nodes in the engine.
These utility functions create new custom blueprint nodes for use in the engine. These were needed in order to do things like change volume for a sound class and change the in-game text language for localization.